Most of the code that ships in a modern application was not written by the team that ships it. Open source libraries, transitive dependencies and vendored packages make up the majority of the bytes in a typical build, and every one of those components carries its own vulnerability history. Software composition analysis (SCA) tools exist to map that risk. The problem is that organizations rarely run just one SCA tool, and even when they do, the results live in a vendor console that the rest of the vulnerability program cannot see.
This article looks at how PMAP treats SCA as a first-class connector class. It covers the three SCA vendors PMAP speaks to, how their results arrive, how software bill of materials (SBOM) documents are pulled and stored in CycloneDX or SPDX format, and how the transitive dependency graph becomes something you can actually read. The angle here is the vendor ecosystem and the ingestion model. If you are choosing between SCA platforms or trying to unify the ones you already run, this is the connector behavior that matters.
For the broader picture of how every scanner, ticketing system and pipeline plugs into one platform, start with the security integration layer pillar. For a vendor-neutral primer on the document format itself, see what is an SBOM. To decide where SCA fits next to static and dynamic testing, read SAST vs DAST vs SCA.
Why Open Source Risk Needs Its Own Connector Class
A vulnerability scanner that probes a running host and an SCA tool that reads a package-lock.json are doing fundamentally different jobs. The host scanner asks “what is exposed on this asset right now.” The SCA tool asks “what known-vulnerable components did this build pull in, and through what dependency chain.” Those questions produce different evidence, different identifiers and different lifecycles. Treating them as the same kind of integration loses information.
PMAP’s integration domain models this difference explicitly. It is the universal connector hub for every external system the platform speaks to, and it dispatches vendor-specific logic through a registry of connector archetypes rather than a hardcoded switch statement buried in the core. Each archetype describes a behavioral contract. Scanner connectors create and control remote scans. ITSM connectors create and reconcile tickets. SCA tools do not fit either of those shapes cleanly, because you do not “launch” an SCA scan the way you launch a network scan against a target range. SCA results are produced as part of a build or a project analysis that already happened on the vendor side, and PMAP’s job is to pull them.
That is why SCA vendors register under the PullOnlyConnector archetype. The contract for a pull-only connector is a scheduled project-level results pull. There is no remote scan CRUD, no launch or pause control surface, because that is not how these tools operate. Recognizing this distinction up front is what keeps the platform honest. PMAP does not pretend to drive an SCA engine it cannot drive. It pulls what the engine produces, normalizes it and folds it into the same finding model that every other source feeds.
This separation also explains why the dependency graph and the SBOM export are SCA-specific capabilities rather than universal ones. A network scanner has no concept of a transitive dependency tree, and there is no SBOM to pull from a DAST run. These are properties of the open source supply chain, and they get a dedicated surface because the underlying data exists only here.
The SCA Connectors PMAP Supports
PMAP supports three SCA vendors as named, first-class integration types. In the platform’s vendor catalog they appear under the SCA category as snyk_open_source, black_duck_sca and sonatype_lifecycle. Those constants map to Snyk Open Source, Black Duck and Sonatype Lifecycle respectively. Each ships as its own connector sub-package with its own client and its own severity mapper, so the differences between vendors are absorbed at the edge instead of leaking into the core.
The category itself is meaningful. PMAP groups every supported integration into categories such as VM/Scanner, SAST, DAST, SCA, ITSM and CI/CD. The SCA category is what the type catalog uses to render the right wizard, expose the right auth fields and decide which capabilities to offer. When you add an SCA integration, PMAP knows to surface SBOM and dependency-graph controls that would make no sense on a network scanner.
Snyk and Black Duck as Pull-Only Connectors
Snyk Open Source, Black Duck and Sonatype Lifecycle all register as PullOnlyConnector implementations. In practice this means the integration record holds the credentials and configuration for the vendor account, and PMAP reaches into that account to retrieve results at the project level. You do not orchestrate a scan from PMAP. The build pipeline or the developer’s commit already triggered the SCA analysis on the vendor side, and PMAP collects the output.
This is the same archetype that backs several SAST tools, which is deliberate. SCA and pull-based static analysis share the same retrieval shape even though the vulnerability classes differ. The connector contract is the common factor. What changes per vendor is the client that talks to the Snyk API versus the Black Duck API versus the Sonatype API, and the mapper that turns each vendor’s severity language into PMAP’s normalized scale. Everything downstream of that mapper is identical regardless of which SCA tool produced the finding.
Because all three are pull-only, none of them expose the remote-scan launch, pause, resume or stop controls that VM and DAST connectors offer. That is not a missing feature. It is an accurate reflection of how the tools work. If you need to kick off an SCA analysis, you do it in the build, and PMAP picks up the result on its next pull.
Scheduled Project-Level Results Pull
The defining behavior of the pull-only archetype is the scheduled project-level results pull. PMAP runs a background scheduler that ticks every minute and evaluates each integration’s cron expression. When an SCA integration’s schedule is due, PMAP fires the import pipeline for that vendor, pulls the current project-level results and writes a schedule-log entry recording how many findings were imported and how long the run took.
You configure this per integration. Each SCA connector has its own cron schedule and its own enable/disable toggle, plus a manual run-now action when you want results immediately rather than waiting for the next tick. The schedule log gives you a history of every pull, so you can confirm that Snyk, Black Duck and Sonatype are all reporting on the cadence you expect. If a vendor account goes stale or a project stops returning results, the log is where that shows up first.
The import itself is idempotent, which matters more for scheduled pulls than almost anywhere else. Because the same projects get pulled over and over on a cron, the pipeline has to guarantee that re-importing the same results does not create duplicate findings. PMAP handles this with fingerprint matching, covered in detail further down.
SBOM Export in CycloneDX and SPDX
A software composition analysis program that cannot produce an SBOM is incomplete. The SBOM is the inventory. It is the machine-readable list of every component, version and license that went into a build, and it is increasingly a contractual and regulatory expectation rather than a nice-to-have. PMAP treats SBOM ingestion as a dedicated SCA capability.
The mechanism is a single endpoint. A POST to the integration’s /sboms route tells PMAP to pull an SBOM from the SCA vendor. The platform supports both major formats: CycloneDX and SPDX. CycloneDX is the OWASP-stewarded SBOM standard built specifically for application security and supply chain use cases, and SPDX is the ISO/IEC 5962 standard with deep roots in license compliance. PMAP does not invent its own format. It pulls the standard document the vendor already produces, in whichever of the two standards you ask for, so the artifact you store is portable to any other tool that reads CycloneDX or SPDX.
Pulling the SBOM is only half the value. The other half is making it durable and findable, which is the next concern.
Where SBOMs Are Stored and Listed
When PMAP pulls an SBOM it stores the document in MinIO, the platform’s object store, and persists the SBOM’s metadata in the database. The raw document lives as an object you can retrieve later, and the metadata record is what makes it queryable. A GET on the same /sboms route lists the stored SBOM documents for that integration, so you can see every SBOM you have pulled, when it was pulled and from which project.
This storage model is consistent with how PMAP handles other vendor artifacts. Scanner connectors archive their raw vendor payloads to MinIO as an audit and replay guarantee, and the SBOM export follows the same discipline. The point is that an SBOM is not a transient view you glance at once and lose. It is an artifact with a retention requirement, and storing it in object storage with a metadata index means you can answer “what did we ship in this build, and what was in it” months after the fact. When a new vulnerability lands against a component, the historical SBOM is what tells you which releases were affected.
The SBOM export runs synchronously in the handler. PMAP pulls the document from the vendor, uploads it to MinIO and inserts the metadata record in one request, bounded by how fast the vendor responds. There is no separate background job to track, which keeps the operation predictable: when the call returns, the SBOM is stored and listed.
Reading the Transitive Dependency Graph
Knowing that a vulnerable component is present in your build is useful. Knowing how it got there is what makes the finding actionable. A vulnerable library that you import directly is one fix. The same library pulled in three levels deep by a dependency of a dependency is a different conversation, because you may not be able to upgrade it without upgrading the parent that requires it.
PMAP exposes this through the dependency graph capability. A GET on the integration’s /projects/{projectId}/dep-graph route fetches the transitive dependency tree for an SCA project. The graph is the structure that connects a direct dependency to every transitive package it drags in. When you can read that tree, you can trace a vulnerable component back to the top-level dependency that introduced it and reason about the real remediation path.
This is where SCA earns its place as a distinct connector class. The dependency graph is not a generic vulnerability concept. It is a property of how package managers resolve and nest open source code, and it only exists because the SCA tool reconstructed it from the build. PMAP surfaces that tree directly rather than flattening it into a list of components, so the chain of responsibility stays visible. For a triage analyst, the difference between “upgrade this one direct dependency” and “this is buried under a framework we cannot easily move” is the difference between a same-day fix and a planning ticket.
The dependency graph and the SBOM together give you two complementary views of the same supply chain. The SBOM is the flat inventory of everything present. The dependency graph is the structure that explains why each thing is present. A mature open source vulnerability management practice uses both.
Normalizing SCA Severity Into One Model
The hardest part of running multiple security tools is not collecting their output. It is making that output comparable. Snyk, Black Duck and Sonatype each have their own severity language, their own scoring emphasis and their own opinion about what “high” means. If you import those scales verbatim, you end up with three incompatible notions of severity sitting in one platform, and your prioritization falls apart.
PMAP solves this with strict severity governance. Every connector produces a NormalizedFinding.Severity through its own mapper. The Snyk mapper, the Black Duck mapper and the Sonatype mapper each translate their vendor’s native severity into PMAP’s single normalized scale. Crucially, PMAP never persists vendor severity as authoritative. The vendor’s label is an input to the mapper, not the stored truth. What lands in the finding record is PMAP’s normalized severity, which means a high from Snyk and a high from Black Duck mean the same thing once they are inside the platform.
There is a second governance layer on import. Each SCA integration carries an import severity threshold, and findings below that configured minimum are discarded at import time. This lets you decide, per vendor, how much of the long tail you want to ingest. If a particular SCA tool is noisy at the low end, you can raise its threshold and keep your finding set focused on what is worth triaging. After import, the platform’s rule engine can override severity further, so a normalized scale is the floor of the prioritization logic rather than the whole of it.
The net effect is that open source vulnerability management stops being three separate severity conversations. It becomes one. When a remediation manager looks at the critical findings across the program, the SCA results sit on the same scale as everything else, and the question “which of these matters most” has a single, coherent answer.
Deduplicating Dependency Findings
Scheduled pulls create a deduplication problem by design. If PMAP pulls the same SCA project every hour, and that project still contains the same vulnerable component it had an hour ago, the platform must not create a new finding on every pull. Otherwise the finding count balloons with phantom duplicates and the program loses trust in its own numbers.
PMAP handles this through fingerprint matching. All import pipelines are idempotent: re-importing the same results produces no duplicates. Findings are matched by a fingerprint, so a vulnerable dependency that appears in pull after pull is recognized as the same finding and updated in place rather than re-created. The same logic protects you when two different SCA tools report overlapping packages. If the fingerprints align, the finding is one record, not two.
This idempotency is also what makes scheduled SCA pulls safe to run frequently. Because the pipeline upserts against stable identifiers rather than inserting blindly, you can pull as often as your cadence demands without inflating the finding set. The raw vendor payloads are archived in object storage, which means a pull can be replayed for audit without risking data loss. For a supply chain security team that wants near-continuous visibility into open source risk, frequent pulls without duplicate noise is exactly the property you need.
SCA in the CI/CD Auto-Scan Flow
SCA is most powerful when it runs early, where a vulnerable dependency can be caught before it merges rather than after it ships. PMAP connects SCA to the development pipeline through its CI/CD auto-scan orchestrator. When a CI event arrives from a connected pipeline, the orchestrator applies a branch filter and then fans out to the configured targets, which can include SCA integrations.
This means a push or pull request on a watched branch can trigger an SCA pull as part of the orchestrated flow, folding open source analysis into the same gate that handles static analysis. The orchestrator always emits a runbook trigger event as well, regardless of the auto-scan state, so downstream automation can react to the CI event even when no scan is fired. The SCA fan-out is one branch of a broader pipeline-aware design.
This article stays on the SCA side of that relationship. The full mechanics of pipeline-triggered scanning, the six CI/CD vendors PMAP normalizes, signed webhook verification and the PR security gate live in the CI/CD and webhooks cluster. If your goal is to wire SCA into a shift-left pipeline, that is where the operational setup is documented. Here, the point is simply that SCA is a valid fan-out target, so your open source analysis can be event-driven rather than waiting on a cron.
Choosing SCA Alongside SAST and DAST
SCA does not replace static or dynamic testing. It complements them, and a complete application security program runs all three because each one sees a different layer of risk. SAST reads your first-party source code and finds the flaws your developers wrote. DAST exercises the running application from the outside and finds the flaws that show up at runtime. SCA inventories the third-party components you pulled in and finds the known vulnerabilities someone else already disclosed.
PMAP keeps these as distinct categories precisely because they answer distinct questions. An SCA finding points at a CVE in a dependency with a fix version. A SAST finding points at a line of your own code with a weakness class. A DAST finding points at an exploitable behavior on a live endpoint. The remediation owner, the evidence and the fix are different in each case, and collapsing them would lose that specificity. By modeling SCA as its own connector class with its own SBOM and dependency-graph surface, PMAP preserves what makes open source risk unique while still folding it into one normalized finding set for prioritization.
For a deeper comparison of where each scan type fits and how to sequence them, see the dedicated SAST vs DAST vs SCA breakdown. The short version is that SCA is the layer that watches the supply chain, and it deserves a tool that understands SBOMs and dependency graphs rather than one that treats a dependency vulnerability like a host finding.
How PMAP Centralizes SCA and SBOM Data
Pull it all together and the SCA story is consistent with how PMAP treats every other source. Three SCA vendors, Snyk Open Source, Black Duck and Sonatype Lifecycle, register as pull-only connectors under the SCA category. Their results arrive through scheduled project-level pulls driven by a per-integration cron, with a run-now option and a schedule log for visibility. SBOMs are pulled in CycloneDX or SPDX format, stored in object storage and listed with persisted metadata. The transitive dependency graph is fetched per project so you can trace any vulnerable component back to its source.
Every one of those findings runs through the same governance the rest of the platform enforces. Connector mappers produce a normalized severity, the import threshold trims the low end, fingerprint matching prevents duplicates and the CI/CD orchestrator can fan out to SCA as part of a pipeline event. The result is that open source risk stops being a siloed vendor console and becomes part of one correlated program, on one scale, with the supply chain artifacts you need for audit and remediation.
For the operational walkthrough of connecting an SCA vendor and pulling your first SBOM, follow the guide on ingesting SCA results and SBOM with Snyk and Black Duck. For connector and credential management across every category, see integration management. And to see how this connector class fits the wider platform, the security integration layer pillar maps the whole picture.
See the integration platform datasheet and centralize Snyk, Black Duck and Sonatype with full SBOM ingestion.
Frequently Asked Questions
Which SCA tools does PMAP integrate with?
PMAP supports three software composition analysis vendors as first-class integration types: Snyk Open Source, Black Duck and Sonatype Lifecycle. They appear in the platform’s SCA category, and each ships as its own connector with its own client and severity mapper so vendor differences are handled at the edge rather than in the core.
How do SCA results get into PMAP?
SCA vendors register as pull-only connectors, which means PMAP retrieves results at the project level on a schedule rather than launching scans remotely. A background scheduler evaluates each integration’s cron expression and fires the import pipeline when a pull is due. You can also trigger an immediate run, and every pull is recorded in a schedule log with the count of findings imported.
Can PMAP pull SBOMs, and in which formats?
Yes. PMAP can pull a software bill of materials from an SCA vendor in either CycloneDX or SPDX format. The document is stored in object storage and its metadata is persisted, so you can list every SBOM you have pulled and retrieve the original artifact later. These are the two industry-standard SBOM formats, so the documents stay portable to other tools.
What is the difference between CycloneDX and SPDX?
Both are standard SBOM formats and PMAP supports pulling either. CycloneDX is the OWASP-stewarded format designed for application security and supply chain use cases. SPDX is the ISO/IEC 5962 standard with strong roots in license compliance. PMAP does not transform between them. It pulls the standard document the vendor produces in whichever format you request.
Can I see the dependency graph for an SCA project?
Yes. PMAP fetches the transitive dependency tree for an SCA project, so you can trace a vulnerable component back to the top-level dependency that introduced it. This matters because a vulnerable library pulled in deep by a transitive dependency has a different remediation path than one you import directly.
How does PMAP keep severity consistent across SCA tools?
Each connector produces a normalized severity through its own mapper, and PMAP never stores vendor severity as authoritative. A high from Snyk and a high from Black Duck mean the same thing once they are inside the platform. An import severity threshold per integration discards findings below your configured minimum, and the rule engine can override severity further after import.
Will repeated SCA pulls create duplicate findings?
No. All import pipelines are idempotent. Findings are matched by fingerprint, so a vulnerable dependency that appears on pull after pull is recognized as the same finding and updated in place instead of re-created. This is what makes frequent scheduled pulls safe to run without inflating the finding count.
Can SCA run as part of a CI/CD pipeline?
Yes. PMAP’s CI/CD auto-scan orchestrator can fan out to SCA integrations when a CI event arrives on a watched branch, after applying a branch filter. This lets open source analysis run as part of a pipeline event rather than only on a cron. The full pipeline setup is covered in the CI/CD and webhooks cluster.
