Most security teams do not have a tooling shortage. They have a connection shortage. A typical enterprise runs a network scanner, a web application scanner, a static analysis tool, a software composition tool, an ITSM platform for ticketing, and a handful of CI/CD systems that build and ship code every day. Each of those tools speaks its own dialect. Each one has its own credentials, its own severity scale, its own data format, and its own idea of what a vulnerability looks like. The work of moving data between them is rarely automated. It is done by analysts copying spreadsheets, by scripts that break on the next vendor API change, and by point connectors that solve exactly one path and nothing more.
A unified security integration layer fixes the connection problem at the source. Instead of wiring each tool to each other tool individually, you wire every external system into one central hub. That hub normalizes the data, enforces consistent severity, handles credentials safely, and routes results into a single vulnerability model. This article explains what a real integration layer looks like, why it beats the point-connector approach, and how PMAP implements one across 30 vendor types spanning vulnerability management, DAST, SAST, SCA, ITSM, and CI/CD.
This is the third pillar in our series on the building blocks of modern vulnerability operations. If you want the full picture of how a finding moves from intake to closed, start with our guide to the vulnerability management lifecycle. If your immediate problem is consolidating many scanners into one pipeline, read multi-vendor scan orchestration. This pillar focuses on the layer underneath both of those: the connector and integration fabric that every other capability depends on.
Why a Single Integration Layer Beats Point Connectors
The point-connector model is seductive because it starts simple. You need Tenable findings inside Jira, so you build or buy a Tenable-to-Jira connector. Then you need Qualys results in ServiceNow, so you add a second connector. Then a GitHub pipeline needs to trigger a Checkmarx scan, so you add a third. Each connector works in isolation. The trouble is what happens when you have a dozen of them.
Point connectors do not share anything. Each one stores its own credentials, applies its own severity logic, and has its own failure behavior. When a vendor rotates an API contract, you patch one connector and pray the rest still work. When an auditor asks how a credential is protected, you have a dozen different answers. When a severity number means one thing in your scanner and another thing in your ticket system, nobody owns the reconciliation. The maintenance cost grows with every pair of tools you connect, and the security surface grows with every credential you scatter across scripts and config files.
A unified integration layer inverts that model. There is one place where every external system is registered. There is one place where credentials live, encrypted at rest. There is one severity policy that every connector flows through. There is one record format that every import produces. Adding a new tool means registering one more connector against a shared contract, not writing one more bespoke pipeline. PMAP builds this layer as a dedicated domain. A single integrations record stores credentials and configuration, and a layered service dispatches vendor-specific logic through a registry of connector archetypes. There are no hardcoded vendor switch statements in the core, so the platform can grow its catalog without rewriting the engine that drives it.
The practical payoff is consistency. Whether a finding arrives from a network scanner, a DAST tool, a SAST engine, or an SCA scanner, it enters the same correlation pipeline, carries a governed severity, and lands in the same finding model. That is what makes downstream automation, reporting, and ticketing reliable. You cannot automate triage on top of data that arrives in five incompatible shapes. The integration layer is what gives every other capability a clean foundation to build on.
The Connector Archetypes Behind PMAP
The reason a single layer can support so many vendors without collapsing into special cases is that PMAP does not treat every tool as unique. It groups them into a small set of connector archetypes, each defined by a clear interface. A vendor package implements the archetype that fits its behavior, registers itself with the connector registry, and the core engine talks to it through the interface. New vendors slot into an existing archetype rather than forcing changes to the platform.
There are four archetypes. The ScannerConnector archetype covers tools that expose remote scan management and a results fetch. This is the model for Nessus, Tenable SC and Tenable.io, Qualys, Rapid7, Acunetix, Invicti, Burp, SonarQube, and MobSF. PMAP can list, create, launch, pause, resume, stop, and poll scans on these systems directly. The PullOnlyConnector archetype covers tools where PMAP does not drive the scan but pulls results on a schedule at the project level. This fits Checkmarx One and Checkmarx SAST, Snyk, Black Duck, Sonatype, Prisma Cloud, and Fortify. The ITSMConnector archetype covers ticketing platforms that need ticket create, update, and status sync, which is Jira, ServiceNow, and ManageEngine. The AssetSourceConnector archetype covers systems that enumerate repositories and pipelines and fan out CI events, which is GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket.
This archetype design is the quiet engineering decision that makes everything else possible. Because the core engine only knows about four interfaces, the maintenance burden does not scale with the vendor count. Vendor packages self-register through an init() function that calls Register(type, factory), and the resolver looks up the factory and type-asserts the archetype when a request arrives. Adding a connector is an additive change. It does not ripple into the parts of the platform that handle correlation, severity governance, or ticketing. For a deeper look at how the connector catalog is structured, see our cluster article on the 30-vendor connector marketplace.
Scanner Connectors: VM, DAST, SAST and SCA
The largest group of connectors brings vulnerability data into PMAP. These span four scanning disciplines, and the integration layer treats them as a coherent family rather than four separate problems.
On the vulnerability management side, PMAP connects to Nessus, Tenable.sc, Tenable.io, Qualys VMDR, Rapid7 InsightVM, and Nuclei. On the DAST side, it connects to Burp Suite Enterprise, Invicti, and Acunetix. On the SAST side, it connects to Checkmarx SAST, Checkmarx One, SonarQube, and Fortify. On the SCA side, it connects to Snyk, Black Duck, and Sonatype Lifecycle. PMAP also reaches Prisma Cloud for container scanning, MobSF for mobile, and Nmap, Masscan, and Nuclei for network discovery and file-based import. Each vendor lives in its own sub-package with a client, an importer, an enricher, and a mapper, so the vendor-specific quirks stay isolated where they belong.
Three behaviors make these scanner connectors trustworthy in production. First, every import is idempotent. Re-importing the same vendor scan produces no duplicates because findings are matched by fingerprint and assets are matched by IP, hostname, or external ID. You can rerun an interrupted import without fear of polluting your data. Second, scanner connectors archive the raw vendor payload to object storage, which gives you an audit and replay guarantee. If you ever need to prove what a vendor actually returned, the original payload is preserved. Third, dispatch is resumable. Connector HTTP calls tolerate on-premises TLS configurations, and a sync or import that gets interrupted simply hits the same external IDs and upserts rather than duplicating on the next run.
For teams that cannot connect a live API, the integration layer also supports file-based import. You can upload Nmap XML, Masscan JSON or list output, Nuclei JSONL, SARIF, or NessusXML files, and findings and assets are created and enriched idempotently from the file. This matters for air-gapped environments and for tools whose output you receive as artifacts rather than through an API. The scan-side mechanics of how these imports become a single correlated pipeline are covered in depth in our multi-vendor scan orchestration pillar.
Severity Governance Across Every Connector
A unified integration layer has to solve a problem that point connectors usually ignore: severity does not mean the same thing across vendors. A “high” from one scanner is not necessarily a “high” from another, and trusting raw vendor severity creates a triage queue full of noise and false confidence.
PMAP handles this with severity governance at the connector boundary. Each connector produces a NormalizedFinding through its own mapper, which is vendor-specific logic that lives in the connector sub-package. PMAP never persists vendor severity as authoritative. Instead, every imported finding flows through an import_severity_threshold configured on the integration, and findings below that minimum are discarded at intake. After that, the finding rule engine can override severity further based on your own policy. The result is that severity is something your program decides, not something a scanner vendor dictates.
This is one of the clearest examples of why the integration layer belongs at the center rather than the edges. If severity normalization lived inside each point connector, you would have a dozen different severity policies and no way to enforce a consistent one. Centralizing it means one threshold policy, one override mechanism, and one severity scale that everything downstream can rely on. To see how severity then drives prioritization and SLA tracking across the whole finding lifecycle, our vulnerability management lifecycle pillar walks through the full path.
ITSM Ticketing: Two-Way Sync With Jira and ServiceNow
Finding a vulnerability is only useful if it reaches the team that can fix it, and in most enterprises that means a ticket. The ITSM half of the integration layer is where PMAP connects to the systems your remediation owners already live in. It supports Jira, ServiceNow, and ManageEngine ServiceDesk Plus, and it treats ticketing as a two-way relationship rather than a one-way export.
Ticket creation is flexible. You can create a single ticket for one finding with full control over the vendor fields, including custom fields, labels, assignee, reporter, Jira components, and ServiceNow impact, urgency, and category. You can create a ticket as a standalone issue, as a subtask, or as a linked issue, depending on how your team structures work. When you need to move at scale, bulk ticket creation pushes up to 500 tickets in a single call, using the Jira batch endpoint where available, with the cap enforced on the server side so a runaway batch cannot overwhelm a vendor. For change-controlled environments, PMAP can also create a change-management record, a ServiceNow change request or a ManageEngine change, linked back to the finding.
The two-way part is what keeps the picture honest. PMAP reconciles vendor-side ticket status back to the finding through two complementary mechanisms. Inbound webhooks receive events from Jira, ServiceNow, and ManageEngine as they happen, updating finding status and posting notes from vendor-side comments. A background poller runs every five minutes against every active ITSM integration, pulling status updates and mirroring them to findings. The poller supplements the webhooks, so if a webhook delivery fails, the next polling pass reconciles the gap. There is also a manual sync endpoint that triggers an immediate polling pass when you do not want to wait for the timer.
How a closed ticket affects the finding is itself a policy choice. When auto_close_on_resolve is set to true, a ticket moving to a done status closes the finding directly. When it is false, which is the default, the finding transitions to retest so a security analyst verifies the fix before it is considered resolved. That default is deliberate. A developer marking a ticket done is a claim, not proof, and the safer path routes the finding back through verification. For a full walkthrough of the ticketing workflow, see our cluster article on ITSM vulnerability ticketing, and for the complete picture of how PMAP unifies ticketing with CI/CD, the ITSM and CI/CD integration platform datasheet covers it end to end.
Field Mappings and Dry-Run Before You Push
The detail that separates a usable ticketing integration from a frustrating one is how it handles the gap between your data model and the vendor’s. Your severity scale is not Jira’s priority scale. Your status workflow is not ServiceNow’s. Without a mapping layer, every ticket either pushes raw values that the vendor rejects or forces analysts to translate by hand.
PMAP stores persistent field mapping rules per integration. You define how severity maps to vendor priority and how your status values map to vendor statuses, and those rules are evaluated automatically before each ticket is created. The mappings live with the integration, so they apply consistently to every ticket that flows through it. You can also set global ticket-creation presets that are shared across findings, which keeps field defaults consistent without re-entering them every time.
Before you push tickets at scale, you can preview the outcome. The ITSM dry-run endpoint simulates a bulk ticket creation and returns a diff of what would be created and updated, including statistics on which mapping rules matched. This turns a risky bulk operation into a reviewable one. You see exactly what is about to happen, you confirm the mappings behaved as expected, and only then do you commit. Combined with rule-match statistics and a description preview that renders your template with sample finding data, the dry-run gives you the confidence to automate ticketing without surprises.
CI/CD Pipelines and the Auto-Scan Orchestrator
The shift-left movement put security testing inside the development pipeline, and a serious integration layer has to meet code where it is built. PMAP connects to GitHub, GitLab, Jenkins, Azure DevOps, Bamboo, and Bitbucket as CI/CD sources, and it turns pipeline events into security action.
The flow begins with an inbound CI webhook. When a pipeline runs, the CI system posts an event to PMAP, which normalizes it into a CIEvent and hands it to the auto-scan orchestrator. The orchestrator applies a branch filter first, so you only act on the branches that matter, and then fans out to pipeline triggers and to SAST and SCA integrations. One important detail is that the orchestrator always emits a runbook trigger event regardless of whether auto-scan is enabled, which means your automation can react to pipeline activity even when you are not launching a scan. For the deeper automation story of how those triggers drive runbooks, see our pillar on vulnerability management automation.
PMAP also reports back into the pipeline, which is what makes CI/CD integration a control rather than just a data feed. It can post a security-summary comment to a pull request or merge request, and it can report a commit check status that gates the merge. The gate is threshold-driven. The orchestrator evaluates configured severity lists for blocking and warning. If new findings at a blocked severity appear, the commit check is set to failure, which can stop a risky change from merging. A warn-only configuration sets the check to pending instead. Every CI event is also recorded in an audit log that captures the event type, repository, branch, commit, pull request, the action taken, and whether the inbound signature was valid.
That signature check deserves emphasis, because a webhook endpoint that anyone can call is a liability. PMAP verifies every inbound CI webhook against a vendor-appropriate scheme. GitHub uses an HMAC-SHA256 signature, GitLab uses a constant-time token comparison, Azure DevOps uses a bearer token, and Jenkins, Bamboo, and Bitbucket use their own token or signature schemes. On a production instance, a missing secret rejects every inbound hook outright. The pipeline does not get to trigger scans or move findings unless it proves who it is. Our cluster article on CI/CD security scans goes deeper into building these gates into your delivery process.
SBOM Export and Dependency Graphs From SCA
Software composition analysis answers a question that network scanning never could: what is actually inside your software. As software supply chain risk has moved to the center of security programs, the ability to pull a bill of materials and trace transitive dependencies has become a core integration requirement rather than a nice-to-have.
PMAP’s SCA connectors do two things beyond ordinary finding import. First, they export a software bill of materials. You can pull an SBOM in CycloneDX or SPDX format from an SCA vendor, and PMAP stores it in object storage and persists the metadata so you can list and retrieve stored SBOMs later. This gives you a durable record of your software composition at a point in time, which is exactly what supply chain audits and incident response increasingly demand. Second, the connectors expose a dependency graph. For an SCA project, PMAP can fetch the transitive dependency tree, so you can see not just the direct package that introduced a vulnerable component but the full chain that pulled it in.
These two capabilities turn SCA from a flat list of vulnerable libraries into a navigable picture of your software supply chain. The SBOM export gives you the inventory, and the dependency graph gives you the relationships. Together they let a remediation owner answer the questions that actually drive a fix: where did this dependency come from, what else depends on it, and what is the blast radius of upgrading or removing it.
Asset Sync and CMDB Reconciliation
A vulnerability program is only as good as its picture of what it is protecting. If your asset inventory is stale, your scans miss systems, your reports undercount risk, and your coverage metrics lie to you. The integration layer is one of the main ways PMAP keeps its asset inventory aligned with the systems of record that already track your infrastructure.
PMAP supports two asset-discovery paths through integrations. Network-discovery scanners feed a discovery inbox, where assets found by tools like Nmap and Masscan surface for review. An operator can bulk-assign those discovered assets to the right company and project rather than having unknown systems clutter the inventory. The second path is asset sync against a CMDB or vendor asset list. PMAP diffs the vendor’s asset list against its own inventory and presents the delta, so you can see exactly what is new, what changed, and what is missing before anything is written. A bulk upsert then applies the delta, reconciling your inventory with the source of truth in one reviewed operation.
The diff-then-import pattern is what makes this safe to run regularly. You are never blindly overwriting your inventory with whatever a vendor reports. You see the proposed changes first, you confirm them, and then they apply. For the full story of how that inventory becomes the foundation of a vulnerability program, including risk scoring and scan coverage, our pillar on attack surface and asset inventory covers the asset side in depth, and our cluster article on CMDB asset integration focuses on the reconciliation mechanics.
Credential Security and Connection Testing
Every integration is, at its core, a set of credentials that grant access to a sensitive system. A scanner credential can launch scans. An ITSM credential can create and close tickets. A CI credential can read source. Scattering those credentials across scripts, environment files, and point connectors is how breaches start. Centralizing and protecting them is one of the strongest arguments for a unified integration layer.
PMAP encrypts every credential at rest. All password, token, and key fields are stored in an encrypted credentials column, and they are decrypted on demand using the platform key only when a connector actually needs them. There is no plaintext credential sitting in a config file. The credentials live in one protected place, and the connector reads them through a controlled path rather than holding its own copy.
Beyond storage, the integration layer makes credentials testable. You can run an inline connection test before you ever save an integration, validating that the credentials work against the live vendor without persisting a broken configuration. You can also test a saved integration later, which stamps a last-tested timestamp on success. A test returns useful diagnostics, including latency, the vendor version, license information, and any warnings such as a managed-scanner mode that limits what PMAP can do. This means an operator never has to guess whether a connector is healthy. They test, they read the result, and they know. For a deeper look at how PMAP protects connector secrets, our cluster article on connector credential security walks through the model.
A Schema-Driven Type Catalog for Dynamic Wizards
The final piece of a maintainable integration layer is how it presents itself to the people configuring it. A platform that hardcodes a custom form for every vendor in its user interface has a hidden coupling: every new connector requires frontend work, and the catalog can drift out of sync with what the backend actually supports.
PMAP avoids that with a schema-driven type catalog. A single endpoint returns a categorized catalog of every supported vendor type, complete with descriptors for each authentication field and configuration field. The user interface reads that catalog and renders the right wizard dynamically, with no vendor-specific frontend code. When a new connector is added on the backend, it appears in the catalog with its own auth and config fields, and the wizard renders it correctly without a frontend change. The catalog is the contract between the connector layer and the configuration experience.
This is the same principle that runs through the entire integration domain. The connector registry decouples the core from vendors. The archetype interfaces decouple the engine from individual tools. The type catalog decouples the configuration UI from the vendor list. At every layer, the design choice is the same: define a contract once, and let new vendors plug into it rather than forcing changes to the system around them. That is what lets the catalog grow to 30 vendor types and keep growing without the platform becoming unmaintainable.
How PMAP Routes Every External System
Step back from the individual capabilities and the shape of the whole layer comes into focus. The integration domain is PMAP’s universal connector hub, and it sits at a precise place in the architecture. It is upstream of finding, scan, and asset, because scan imports feed findings in, remote scan records are created here, and asset-sync and network-discovery imports populate inventory. It is consumed downstream by report, analytics, notification, and runbook, because the data it brings in fuels reporting and metrics, and CI events emit the runbook triggers that drive automation.
A scanner finding enters through a scanner connector, gets normalized through the connector’s mapper, passes the severity threshold, flows through the correlation pipeline that deduplicates it, and lands in the finding model. An ITSM action goes the other direction: a finding becomes a ticket, the ticket lives in Jira or ServiceNow, and the webhook and poller keep its status reconciled back to the finding. A CI event arrives on a verified webhook, the orchestrator filters and fans out, scans launch or runbooks trigger, and a pull request gets a comment or a status check. Every one of these paths runs through the same hub, with the same credential protection, the same severity governance, and the same record format on the other side.
When delivery matters, the same centralization holds. The notification engine that announces what the integration layer brings in is itself a fan-out hub, delivering across in-app, email, webhook, Slack, and Microsoft Teams channels, with the same kind of host allowlisting that guards outbound webhook destinations against abuse. The pattern repeats because it works. One layer, one contract, one place to secure, and one consistent shape for everything that flows through. That is what a unified security integration layer buys you, and it is why connecting your stack through one hub beats wiring it together one fragile point connector at a time.
The connector layer is the foundation, not the finish line. Once your tools speak through one hub, the work of triage, correlation, automation, and reporting all gets easier, because every capability is building on consistent data. If you are evaluating how to bring your existing tools together, the ITSM and CI/CD integration platform datasheet shows how PMAP connects your stack through one layer.
Frequently Asked Questions
How many tools and vendors can PMAP integrate with?
PMAP’s integration domain supports 30 vendor connectors spanning vulnerability management, DAST, SAST, SCA, container scanning, mobile, network discovery, ITSM, and CI/CD. The vulnerability management connectors include Nessus, Tenable.sc, Tenable.io, Qualys VMDR, Rapid7 InsightVM, and Nuclei. DAST covers Burp, Invicti, and Acunetix. SAST covers Checkmarx SAST, Checkmarx One, SonarQube, and Fortify. SCA covers Snyk, Black Duck, and Sonatype Lifecycle. ITSM covers Jira, ServiceNow, and ManageEngine, and CI/CD covers GitHub, GitLab, Azure DevOps, Jenkins, Bamboo, and Bitbucket. New connectors slot into one of four shared archetypes, so the catalog grows without rewriting the core engine.
What does two-way ITSM sync actually mean?
Two-way sync means status flows in both directions between PMAP and your ticketing platform. PMAP creates tickets in Jira, ServiceNow, or ManageEngine from findings, pushing severity, description, and metadata. It then keeps those tickets reconciled back to the finding through inbound webhooks that fire on vendor-side events and a background poller that runs every five minutes. If a webhook delivery fails, the next polling pass closes the gap. When a ticket reaches a done status, the finding either closes directly or transitions to retest for analyst verification, depending on your configuration.
How are connector credentials protected?
Every credential field, including passwords, tokens, and keys, is encrypted at rest in a dedicated encrypted credentials column. Credentials are decrypted on demand using the platform key only when a connector needs them to make a call, so no plaintext secret sits in a config file. You can validate credentials with an inline connection test before saving an integration, and test a saved integration later to confirm it stays healthy. A test returns latency, vendor version, license information, and any warnings.
Can PMAP integrate security scanning into a CI/CD pipeline?
Yes. PMAP connects to GitHub, GitLab, Jenkins, Azure DevOps, Bamboo, and Bitbucket. An inbound CI webhook is normalized into an event and handed to an auto-scan orchestrator that applies a branch filter and fans out to pipeline triggers and SAST or SCA scans. PMAP can post a security-summary comment to a pull request and set a commit check status that gates the merge, blocking on new findings at a configured severity. Every inbound webhook is signature-verified, and a missing secret on a production instance rejects the hook.
Does PMAP support SBOM export and software composition analysis?
Yes. PMAP’s SCA connectors, which include Snyk, Black Duck, and Sonatype Lifecycle, can export a software bill of materials in CycloneDX or SPDX format, store it in object storage, and persist its metadata for later retrieval. They can also fetch the transitive dependency graph for a project, so you can trace a vulnerable component through the full chain of dependencies that introduced it, not just the direct package.
How does PMAP keep its asset inventory in sync with our CMDB?
PMAP supports asset sync against a CMDB or vendor asset list. It diffs the external asset list against its own inventory and presents the delta, showing what is new, changed, or missing before anything is written. A bulk upsert then applies the reviewed delta. Network-discovery scanners feed a separate discovery inbox where found assets surface for bulk assignment to the right company and project. Both paths use a review-before-import pattern so the inventory is never blindly overwritten.
Why is a single integration layer better than individual point connectors?
Point connectors each store their own credentials, apply their own severity logic, and fail in their own way, so the maintenance and security cost grows with every pair of tools you connect. A single integration layer registers every external system in one place, with one encrypted credential store, one severity governance policy, and one normalized record format. New tools plug into shared connector archetypes rather than requiring bespoke pipelines. The result is consistent data that downstream correlation, automation, and reporting can rely on, which point connectors cannot provide.
