Most security teams do not run one scanner. They run a vulnerability scanner for infrastructure, a DAST tool for web applications, a SAST engine in the pipeline, a software composition analysis tool for open-source risk, an ITSM platform for remediation tickets, and a CI/CD system that fires builds all day. Each tool produces its own findings, its own severity scale, and its own asset list. The hard part is never buying another tool. The hard part is making the tools you already own talk to one platform without rebuilding the same plumbing for every vendor.
PMAP approaches this as a vendor marketplace. Instead of a fixed list of bespoke integrations, it exposes a universal connector hub that catalogs 30+ vendor types across 9 categories and renders each one through a shared, schema-driven wizard. A single integration record holds the credentials and configuration. The platform dispatches vendor-specific behavior through a registry of connector archetypes, so adding a new tool does not mean rewriting the core. This article walks through what the marketplace covers, how it is organized, and how to read it before you commit to a stack.
If you want the architectural context first, the security integration layer pillar explains how PMAP unifies external tools at a system level. This page zooms into the catalog itself: the categories, the vendors, and the structure underneath.
One Hub, Every Category of Security Tool
The integration domain in PMAP is built as a single connector hub rather than a pile of one-off scripts. It manages the full lifecycle of every external system PMAP speaks to. That includes scanner connectors for infrastructure, web, code, and dependencies, ITSM and ticketing platforms for remediation, and CI/CD pipelines for shift-left scanning.
The design goal is consistency. Every integration, regardless of vendor, is stored as one integrations record. That record carries the name, the type, the connection details, and the encrypted credentials. When PMAP needs to run a scan, create a ticket, or sync an asset, it resolves the right connector for that record and dispatches the work. The core service does not contain a giant switch statement that hardcodes each vendor. It looks up a factory in a registry and calls a shared interface. This is the difference between a hub and a bundle of separate plugins. A hub gives you one mental model, one configuration surface, and one place to test a connection.
For a buyer evaluating coverage, this matters more than any single logo on a slide. A marketplace that grows by registering new types is one you can extend. A marketplace that grows by forking the codebase per vendor is one that will eventually stall. PMAP sits firmly in the first camp, and the rest of this article shows why.
The Nine Connector Categories
PMAP groups its supported vendor types into nine categories. The grouping is not cosmetic. It maps to how the platform treats each tool: which interface it implements, what kind of results it returns, and where those results land in your pipeline. The nine categories are Discovery and Network, VM and Scanner, SAST, SCA, DAST, ITSM and Issue Tracker, Container, CI/CD, and Mobile.
Reading the catalog by category is the fastest way to answer the real procurement question, which is not “do you integrate with X” but “do you cover the surface I need to protect.” Infrastructure, web apps, source code, dependencies, and mobile each carry distinct risk, and each maps to a category here. The next sections break down the categories most teams shortlist first.
VM Scanners: Nessus, Tenable, Qualys, Rapid7, Nuclei
The VM and Scanner category covers the classic vulnerability management surface, which is hosts, networks, and infrastructure. PMAP supports Nessus, Tenable.io, Tenable.sc, Qualys VMDR, Rapid7 InsightVM, and Nuclei in this category.
These are the connectors most teams start with, because infrastructure scanning is where vulnerability management began. In PMAP they are full scanner connectors, which means PMAP does not just import results. It can list, create, launch, pause, resume, stop, and poll remote scans on the vendor through a vendor-agnostic scan wizard. You drive Tenable or Qualys from PMAP rather than tabbing between consoles. Results come back as normalized findings, mapped through each connector’s own logic, and flow into the same finding pipeline regardless of which scanner produced them.
DAST: Acunetix, Invicti, Burp
The DAST category covers dynamic application security testing, which is scanning running web applications from the outside. PMAP supports Acunetix, Invicti, and Burp Suite Enterprise here.
DAST connectors carry capabilities the VM category does not need. PMAP can list recorded login sequences and attach one to a scan so the scanner authenticates before it crawls, which is essential for testing anything behind a login. It can read and update the URL scope, the include and exclude lists, on the vendor side so you control what gets crawled. It also manages vendor-side recurring scan schedules, distinct from PMAP’s own cron, for tools that maintain their own scheduling. These are the details that separate a token DAST checkbox from a connector that actually runs authenticated application scans.
SAST: Checkmarx, SonarQube, Fortify
The SAST category covers static application security testing, which is analyzing source code without running it. PMAP supports Checkmarx One, Checkmarx SAST, SonarQube, and Fortify in this category.
SAST tools behave differently from network scanners. They are tied to projects and repositories rather than IP ranges, and PMAP treats most of them as pull-only connectors that retrieve results on a scheduled project-level pull rather than orchestrating a remote scan launch. This fits how SAST runs in practice, where the scan is often triggered inside the pipeline and PMAP’s job is to collect and normalize the output. The results land as findings in the same console as everything else, so a code-level weakness sits next to an infrastructure CVE under one triage view.
SCA: Snyk, Black Duck, Sonatype
The SCA category covers software composition analysis, which is finding known vulnerabilities and license risk in open-source dependencies. PMAP supports Snyk, Black Duck, and Sonatype Lifecycle here.
SCA connectors add two capabilities tuned to dependency risk. PMAP can pull a software bill of materials, a CycloneDX or SPDX SBOM, from the vendor, store it in object storage, and keep the metadata for later reference. It can also fetch the transitive dependency graph for an SCA project, so you can see not just which package is vulnerable but how it got pulled into your build. As open-source risk and SBOM expectations rise across the industry, this category has moved from optional to expected, and PMAP treats it as a first-class scanner type rather than a bolt-on.
ITSM and CI/CD: Jira, ServiceNow, GitHub, GitLab and More
The last two categories most buyers shortlist are about what happens after detection. The ITSM and Issue Tracker category supports Jira, ServiceNow, and ManageEngine ServiceDesk Plus. The CI/CD category supports GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket.
ITSM connectors close the remediation loop. PMAP can create single or bulk tickets, push finding metadata into the vendor, and keep status in sync in both directions, so a ticket that moves to done on the ITSM side reflects back on the PMAP finding. CI/CD connectors push scanning left. They enumerate repositories and pipelines, receive build and pull-request webhooks, fan out to SAST and SCA scans, and report a pass or fail check status back to the commit. Two categories that are easy to overlook on a coverage chart are often the ones that decide whether the platform actually changes how your team works.
Beyond these headline categories, the catalog also includes Discovery and Network with Nmap and Masscan, Container with Prisma Cloud, and Mobile with MobSF. Together the nine categories span the surfaces a modern security program has to watch.
Four Connector Archetypes Behind the Catalog
Underneath the 30+ vendor types sit only four connector archetypes. Every supported tool implements one of them, and that is what keeps the marketplace coherent as it grows.
The first archetype is the scanner connector, used by tools that support remote scan create, control, and results fetch. Nessus, the Tenable family, Qualys, Rapid7, Acunetix, Invicti, Burp, SonarQube, and MobSF fall here. The second is the pull-only connector, used by tools where PMAP retrieves results on a scheduled project-level pull rather than launching scans. Checkmarx One and SAST, Snyk, Black Duck, Sonatype, Prisma Cloud, and Fortify fall here. The third is the ITSM connector, used for ticket create, update, and status sync, covering Jira, ServiceNow, and ManageEngine. The fourth is the asset-source connector, used for repository and pipeline enumeration plus CI fan-out, covering GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket.
This is the structural reason a 30+ vendor catalog stays maintainable. PMAP does not have 30 special cases. It has four contracts, and each new tool slots into one of them. When you evaluate the marketplace, the archetype tells you what to expect from a connector before you read the vendor-specific notes. A scanner archetype means you can orchestrate scans. A pull-only archetype means PMAP collects what the tool produces on its own schedule. The pattern is predictable across the whole catalog.
A Schema-Driven Type Catalog, Not Hardcoded Forms
A marketplace is only useful if you can actually configure what is in it. Many platforms hardcode a separate form for every vendor, which is why their integration screens lag behind their feature lists. PMAP takes a different route. It exposes a single endpoint that returns a categorized, schema-driven catalog of every supported vendor type, complete with the authentication-field and configuration-field descriptors each one needs.
The practical effect is that the add-integration wizard renders itself from that catalog. The front end does not ship a hand-built form per vendor. It reads the descriptors and draws the right fields for whichever type you pick, whether that is an API token for one tool or a username and base URL for another. When a new vendor type is added to the catalog, the wizard picks it up without a front-end rewrite. This is the schema-driven integration wizard, and it is the reason the catalog can grow without the configuration surface falling behind.
For a buyer, this is a quiet signal of maturity. A platform that drives its own wizard from a type catalog is one designed to add vendors as data, not as code. That tends to mean faster support for the tools you ask about after you sign.
How a New Vendor Self-Registers
The same design shows up one layer deeper, in how connectors join the platform at all. Vendor packages self-register through an initialization step that calls a register function with the type and a factory. At runtime, when PMAP needs to act on an integration, it resolves the matching factory and asserts the right archetype: a scanner, a pull-only connector, an ITSM connector, or an asset source.
This registry pattern is the engineering counterpart to the schema-driven catalog. The catalog tells the user interface what fields a vendor needs. The registry tells the core service how to dispatch work to that vendor. Neither requires editing a central switch statement. A new connector registers itself and declares its type, and the rest of the platform discovers it. There is even a demo mode that short-circuits resolution to a canned connector, so a vendor like Qualys or Rapid7 can be previewed in the interface without live credentials.
You do not need to read the source to benefit from this. The point for an evaluator is that breadth here is structural, not accidental. The marketplace is wide because the architecture makes width cheap, and that is the kind of breadth that keeps growing after launch.
How Results Stay Consistent Across the Whole Catalog
Breadth is worthless if every vendor’s output lands in a different format. The value of a marketplace is a single, comparable view, and PMAP enforces that through normalization and deduplication that apply to every connector in the catalog.
Each connector produces a normalized finding through its own mapper. PMAP never persists vendor severity as authoritative. Severity flows through a threshold filter and an optional rule engine override, so a critical from one scanner and a critical from another are measured on PMAP’s scale, not the vendor’s. Imports are idempotent. Re-importing the same vendor scan produces no duplicates, because findings are matched by fingerprint and assets by IP, hostname, or external identifier. Raw vendor payloads are archived so an import can be replayed without losing data.
This is what makes running two tools in the same category a deliberate choice rather than a noise generator. Overlapping scanners are deduplicated against the same finding model. The marketplace is not just a list of things PMAP can connect to. It is a list of things PMAP can connect to and then present as one coherent picture. For the deeper buyer’s view of choosing scanners across these categories, the scanner selection guide works through the trade-offs in detail.
How to Read the Marketplace Before You Buy
When you evaluate the catalog, resist the urge to scan for individual logos. A logo match tells you almost nothing about depth. Read it by category and by archetype instead.
Start with the surfaces you have to protect and map them to categories. Infrastructure points you to VM and Scanner. Public web applications point to DAST. Source code points to SAST. Open-source dependencies point to SCA. A pipeline that should gate insecure merges points to CI/CD. A remediation process that lives in tickets points to ITSM. If a category that matters to you is well populated, that is a stronger signal than any single vendor name.
Then check the archetype for the specific tool you care about. A scanner archetype means PMAP can orchestrate scans, drive the wizard, and pull results. A pull-only archetype means PMAP collects what the tool produces on its own schedule, which is the right fit for most SAST and SCA tools. An ITSM archetype means two-way ticket sync. An asset-source archetype means repository and pipeline awareness with CI fan-out. The archetype sets your expectations before any vendor-specific detail.
Finally, confirm the normalization story. Coverage without normalization is just more dashboards. Because PMAP maps every connector to one finding model, deduplicates by fingerprint, and ignores vendor severity in favor of its own threshold and rules, the breadth of the catalog turns into a single triage queue rather than nine separate ones. That is the difference a marketplace is supposed to make. The two-way ITSM integration article shows how this plays out specifically on the remediation side, where findings become tickets and ticket status flows back automatically.
How the Marketplace Fits the Integration Layer
The marketplace is the visible surface of something larger. Underneath the catalog of 30+ vendor types is the integration layer, the part of PMAP that unifies external tools, normalizes their output, and feeds the rest of the platform. Scan imports become findings. Asset-sync and network-discovery imports become inventory. CI events become pipeline triggers and runbook actions. The marketplace is how you choose what plugs in. The integration layer is how everything that plugs in stays consistent.
That is why the catalog should be read as part of a system, not as a feature list. A wide marketplace bolted onto a weak core gives you many ways to import noise. A wide marketplace built on shared archetypes, a schema-driven catalog, a self-registering registry, and one normalized finding model gives you many ways to import signal. PMAP is designed for the second outcome. For the full architectural picture, see the security integration layer pillar, and for the buyer-facing detail on each connector category, read the ITSM and CI/CD integration platform datasheet.
The takeaway is simple. The number of supported tools is the headline. The structure underneath is the story. PMAP offers 30+ vendor types across 9 categories, and it offers them in a way that keeps growing and keeps the data clean as it does.
Frequently Asked Questions
How many tools and categories does PMAP support?
PMAP’s connector catalog spans 30+ vendor types across 9 categories: Discovery and Network, VM and Scanner, SAST, SCA, DAST, ITSM and Issue Tracker, Container, CI/CD, and Mobile. Each category maps to a specific surface, from infrastructure and web applications to source code, dependencies, and mobile, so coverage is organized by what you protect rather than by vendor name alone.
Which vulnerability scanners can PMAP connect to?
In the VM and Scanner category, PMAP supports Nessus, Tenable.io, Tenable.sc, Qualys VMDR, Rapid7 InsightVM, and Nuclei. These are full scanner connectors, so PMAP can list, create, launch, pause, resume, stop, and poll remote scans on the vendor through a vendor-agnostic scan wizard, and it imports the results as normalized findings.
Does adding a new vendor require custom development?
No, not in the way a hardcoded integration would. Vendor packages self-register with the connector registry by declaring a type and a factory, and the add-integration wizard renders its fields from a schema-driven type catalog rather than a hand-built form per vendor. Breadth comes from this structure, which is why the catalog can grow as data rather than as forked code.
How does PMAP keep results consistent across so many different tools?
Every connector produces a normalized finding through its own mapper, and PMAP never treats vendor severity as authoritative. Severity passes through a threshold filter and an optional rule engine. Imports are idempotent, with findings matched by fingerprint and assets matched by IP, hostname, or external identifier, so re-importing the same scan creates no duplicates and overlapping scanners are deduplicated.
What are the four connector archetypes?
The four archetypes are the scanner connector for remote scan orchestration, the pull-only connector for scheduled results retrieval, the ITSM connector for two-way ticket sync, and the asset-source connector for repository and pipeline enumeration with CI fan-out. Every supported tool implements one of these, which is what keeps a 30+ vendor catalog maintainable.
Can PMAP run more than one tool in the same category?
Yes. Because all connectors map to one finding model and deduplicate by fingerprint, running two scanners in the same category is a deliberate coverage decision rather than a source of duplicate noise. Overlapping findings are reconciled against the same model, so you get broader coverage without a messier triage queue.
How does the marketplace relate to PMAP's integration layer?
The marketplace is the catalog you choose connectors from. The integration layer is the system that normalizes their output and feeds the rest of the platform, turning scan imports into findings, asset syncs into inventory, and CI events into pipeline and runbook triggers. The marketplace decides what plugs in, and the integration layer keeps everything that plugs in consistent.
