An SBOM sitting in a file share is a compliance artefact. An SBOM connected to live vulnerability intelligence is a security capability. The difference is Software Composition Analysis (SCA) — the discipline of continuously monitoring your software components for known vulnerabilities and license risks.
This guide explains how SCA works, how it integrates with the SBOM-to-vulnerability workflow mandated by the EU Cyber Resilience Act, and what an effective SCA programme looks like in practice.
What Is Software Composition Analysis?
SCA is the automated process of identifying open-source and third-party components in your software and assessing them for:
- Known security vulnerabilities — CVEs published in databases like NVD and OSV
- License compliance risks — GPL contamination, incompatible licenses, unlicensed code
- Outdated components — dependencies that are significantly behind current versions or end-of-life
- Malicious packages — typosquatting, dependency confusion, backdoored packages
SCA is not the same as SAST (Static Application Security Testing) or DAST (Dynamic Analysis). SAST finds vulnerabilities in code you wrote. SCA finds vulnerabilities in code others wrote that you are using. For the modern software stack — where 70–90% of code in a typical application comes from third-party dependencies — SCA is often the higher-value security activity.
The SCA Pipeline
Vulnerability Databases: Where SCA Gets Its Intelligence
NVD — National Vulnerability Database
The NVD, maintained by NIST, is the authoritative source for CVE metadata in the US and internationally. It provides CVSS scores, CWE classifications, CPE identifiers (for matching affected products), and references. NVD currently contains over 250,000 CVE entries.
Limitation: NVD has faced significant enrichment backlogs since early 2024. As of writing, thousands of CVEs have minimal metadata — no CVSS score, no affected version ranges. This makes NVD-only SCA incomplete.
OSV — Open Source Vulnerabilities
OSV, maintained by Google, addresses NVD's weaknesses for open-source software specifically. OSV sources vulnerability data directly from package maintainers (PyPI Advisory Database, RustSec, npm security advisories, GitHub Advisory Database, etc.) and provides precise version ranges. OSV is the best source for open-source component vulnerability matching using PURLs.
GHSA — GitHub Security Advisories
GitHub's Security Advisory Database covers vulnerabilities in packages hosted on GitHub. It feeds into OSV and is particularly strong for npm, Composer, and pip packages.
The PURL: The Key to Accurate Matching
The accuracy of SCA depends entirely on how well vulnerability databases match your specific component versions. The Package URL (purl) is the standardised identifier that enables this matching. A purl looks like:
pkg:npm/[email protected]
pkg:maven/org.apache.logging.log4j/[email protected]
pkg:pypi/[email protected]
pkg:golang/github.com/gin-gonic/[email protected]Your SBOM must contain accurate purls for each component. A component listed without a purl — or with an incorrect version — may not match vulnerability records even when the component is affected.
False Positives and VEX
A persistent challenge in SCA is false positives: vulnerabilities that match a component in your SBOM but are not actually exploitable in your context. Common reasons:
- The vulnerable function is in the library but your code never calls it
- A WAF or network control mitigates the vulnerability
- The vulnerability requires a configuration your deployment doesn't use
- The component is used only in test infrastructure, not production
VEX (Vulnerability Exploitability eXchange) is the emerging standard for communicating this context. A VEX document, produced by a manufacturer, declares the exploitability status of a vulnerability in their specific product context. VEX statuses include: not_affected, affected, fixed, under_investigation.
CycloneDX 1.4+ supports embedding VEX data directly in the SBOM. CISA has published VEX use cases and guidance. Under the CRA, VEX documents will become increasingly important for demonstrating active vulnerability management.
Integrating SCA into Your Development Workflow
At pull request / merge request
Run SCA on every PR to catch newly introduced vulnerable dependencies before they merge. Tools like Dependabot, Renovate, or grype can be configured as PR checks.
# Example: grype scan in CI
grype sbom:sbom.cdx.json --fail-on highAt build time
Generate a fresh SBOM from the exact build artefact (not just source) and scan it. Container images often have additional OS packages not present in source-level scans.
Continuously in production
SCA must run continuously — not just at build time. New CVEs are published daily. A component that was clean at build time may be vulnerable a week later. Connect your SBOM inventory to a platform like CRATrust that monitors for new vulnerability publications and alerts you when any component in any of your products is newly affected.
CRA Compliance and SCA
The CRA does not mandate a specific SCA tool, but it does mandate outcomes that are practically only achievable with SCA:
- "No known exploitable vulnerabilities" at market placement → requires SCA scan before release
- Ongoing monitoring throughout supported lifecycle → requires continuous SCA
- 24-hour ENISA notification of actively exploited vulnerabilities → requires monitoring that can detect within hours, not days
- SBOM maintenance → the SBOM that feeds your SCA must be kept current