Quick answer: Software supply chain security is the set of controls that protect the code, dependencies, build systems and distribution channels your software passes through before it reaches production. An SBOM (software bill of materials) is the inventory that makes those controls possible; it only reduces risk when it is machine-readable, generated at build time, and consumed to answer "are we affected?" within hours of a new disclosure.
Software supply chain security has moved from a niche concern to the third item on the OWASP Top 10:2025, where "Software Supply Chain Failures" (A03) replaced the narrower "Vulnerable and Outdated Components" category of 2021. The reason is a run of incidents that no amount of in-house code review would have caught: the SolarWinds build-system compromise, Log4Shell, the xz-utils backdoor planted over two years by a trusted maintainer, compromised GitHub Actions, and self-propagating worms spreading through npm maintainer accounts in 2025.
Regulation has followed: EO 14028 and NIST's SSDF (SP 800-218) made SBOMs and attestations a US procurement expectation, CISA has revised its SBOM minimum elements, and the EU Cyber Resilience Act phases in reporting obligations from September 2026 and applies in full from December 2027.
This article is for AppSec and platform leaders who have been asked for "an SBOM" and want to know what good looks like: what to put in it, how it differs from the SCA scanner you already run, how VEX and SLSA fit, and which controls actually stop the recurring attack patterns.
What is software supply chain security, and what is it protecting?
The software supply chain is everything between a developer's intent and a running artifact: source repositories, open source dependencies, package registries, build pipelines, CI runners, signing keys, base images, artifact stores and the update channel to customers. Software supply chain security assures the integrity of each link. Three threat groups, each needing a different control:
- Vulnerable dependencies — Examples: Log4Shell, Spring4Shell, long-lived CVEs in transitive packages · Primary control: SCA with reachability, SBOM-driven exposure queries, upgrade hygiene
- Malicious dependencies — Examples: Typosquatted packages, hijacked maintainer accounts, protestware, the xz-utils backdoor, worms spreading through npm publish tokens · Primary control: Registry policy, provenance verification, package pinning, cooling-off periods for new versions
- Compromised build and delivery — Examples: SolarWinds-style build injection, tampered GitHub Actions, leaked signing keys, poisoned base images · Primary control: SLSA-aligned hardened builds, signed provenance, isolated runners, artifact signing and verification
Most organizations invest heavily in the first row and little in the other two, which is where the headline incidents of the last five years came from.
What is an SBOM and what must it contain?
A software bill of materials is a machine-readable inventory of the components in a piece of software, including their versions, suppliers and the relationships between them. CISA describes it as a nested list of ingredients.
The two dominant formats are SPDX (an ISO/IEC standard) and CycloneDX (an Ecma standard). Both are fine; what matters is that you pick one and generate it automatically. The minimum elements guidance originally published by NTIA, and since revised by CISA, expects at minimum:
- Data fields for each component: supplier, component name, version, unique identifiers (such as package URL or CPE), dependency relationships, the SBOM author, and a timestamp. CISA's revised guidance adds fields such as license, component hash and generation context.
- Automation support: a standard machine-readable format so the SBOM can be ingested, not read by a human.
- Practices and processes: frequency (a new SBOM for every new build), depth (transitive dependencies, not just direct ones), handling of unknowns, and distribution to the people who need it.
A practical SBOM example: a CycloneDX JSON file generated in CI for a Java service lists the service as root component, a few hundred Maven artifacts with coordinates and hashes, the dependency graph, and a reference to the build that produced it. Nobody reads it; a tool queries it.
SBOM vs SCA: what is the difference?
- What it is — SBOM: An inventory document (a noun) · Software composition analysis (SCA): A scanning process that analyzes dependencies for known vulnerabilities and license issues (a verb)
- Produced by — SBOM: Build tooling, SCA tools, package managers · Software composition analysis (SCA): Commercial or open source scanners
- Primary purpose — SBOM: Transparency and exposure lookup, shareable with customers and regulators · Software composition analysis (SCA): Finding and prioritizing vulnerable packages during development
- Covers — SBOM: Everything in the artifact, including components you did not write · Software composition analysis (SCA): Usually dependencies declared in manifests; better tools also inspect binaries
- Shelf life — SBOM: Snapshot of one build · Software composition analysis (SCA): Continuous, re-run on every build and on new CVE publication
Most SCA tools can emit an SBOM and most SBOM platforms can scan one. The distinction that matters: SCA is how you fix vulnerable dependencies in software you build; SBOM is how you know what is in software you build and buy, so you can answer "are we affected?" across the whole estate when the next Log4Shell lands.
Does an SBOM actually prevent supply chain attacks?
No; that confuses inventory with control. An SBOM did not stop xz-utils (the malicious code was in the legitimate upstream release) or compromised GitHub Actions (the problem was in the build, not the components).
What an SBOM does is cut incident response from weeks to hours. The organizations that handled Log4Shell well could query "which deployed artifacts contain log4j-core below 2.17" on the first morning; the others spent two weeks emailing teams. That gain is real and is why regulators want SBOMs. Just do not sell it internally as prevention.
Prevention of the second and third threat groups comes from other controls:
- Provenance and SLSA. SLSA v1.0 Build L1 requires provenance documenting how an artifact was built; L2 requires it signed and generated on a hosted build platform; L3 requires hardened builds where runs cannot influence each other and signing keys stay away from user-defined steps. Target L3 for production software, in practice by standardizing on a managed CI platform that generates signed provenance.
- Dependency intake policy. Pin versions and hashes, use a private proxy registry, apply a cooling-off period (commonly 7-14 days) before adopting newly published versions, and block install scripts where possible. A cooling-off period alone would have blunted most of the 2025 npm worm incidents.
- Credential hygiene in CI. Short-lived workload-identity tokens instead of long-lived publish tokens; no secrets in build logs; separate signing from build.
- Verification at consumption. Verify signatures and provenance of third-party artifacts and base images before they enter your build.
What is VEX, and why does it matter for SBOM consumers?
VEX (Vulnerability Exploitability eXchange) is a companion document to an SBOM in which the software producer states, for a given vulnerability, whether the product is affected, not affected (with a justification such as "vulnerable code not present" or "not reachable"), fixed, or under investigation.
VEX exists because an SBOM scanned against the NVD produces a long list of theoretical matches, most not exploitable in that product. Without VEX, every customer who receives your SBOM opens a ticket about every one of them; with VEX, you make the reachability determination once and publish it. Suppliers should plan to produce VEX; consumers should require it in contracts alongside the SBOM.
In practice: the first 48 hours after a critical disclosure
Scenario. An insurer with roughly 600 internal services and 150 commercial applications learns on a Tuesday evening that a widely used JSON library has a critical deserialization flaw, already on CISA's KEV list.
Hour 0-2. The platform team queries the SBOM repository (one SBOM per build, indexed by package URL): 212 internal artifacts contain the library, 140 in production. Vendor risk checks the SBOMs and VEX statements received under contract: 9 of 150 vendors declare the component, 4 have already published "not affected" justifications.
Hour 2-12. Reachability data is joined to the SBOM results: 61 of the 140 production services call the vulnerable path and become P0 tickets routed by ownership. The other 79 go to the regular upgrade train with a "vulnerable code not in execute path" justification recorded.
Hour 12-48. Fixes ship through the standard pipeline, which regenerates SBOMs and signed provenance, so "are we still affected?" is answered by the same system. The 5 unresponsive vendors receive a contractual notice with a 72-hour deadline.
Without the SBOM repository, step one alone would have been a two-week survey across 60 engineering teams. That is the honest business case for SBOMs: not prevention, but response at the speed regulators and boards now expect.
Who needs an SBOM under the EU Cyber Resilience Act and other regimes?
The CRA requires manufacturers of products with digital elements sold in the EU to document components, including a machine-readable SBOM covering at least top-level dependencies, and to report actively exploited vulnerabilities to ENISA on short timelines; reporting obligations apply from September 2026 and the full obligations from December 2027. In the US, SBOMs flow from EO 14028 through NIST SSDF attestations for federal suppliers, and the FDA requires them for medical devices. The UK's NCSC supply chain guidance and Software Security Code of Practice push the same direction without mandating a format. In Australia, APRA CPS 234 and the SOCI Act frame third-party software risk as board-level accountability, which in practice means auditors ask how you know what is in your software.
For how to prioritize the vulnerabilities an SBOM surfaces, see our guide to vulnerability prioritization with EPSS and KEV. For the newest supply chain vector, AI coding assistants recommending packages that do not exist, see our article on securing AI-generated code.
Key takeaways
- Supply chain failures are now A03 in the OWASP Top 10:2025; the headline incidents came from malicious packages and compromised builds, not just old CVEs.
- Generate an SBOM for every build in SPDX or CycloneDX, with transitive depth, and store it where it can be queried in minutes.
- SBOM is inventory; SCA is scanning. You need both, and VEX to stop the inventory generating noise.
- Prevention comes from SLSA L3 builds, signed provenance, dependency pinning with cooling-off periods, and short-lived CI credentials.
- The EU CRA's 2026-2027 deadlines make SBOM and vulnerability handling a roadmap item now for anyone selling into Europe.
Join your peers at AppSec World 2027
AppSec World is the global application security forum: one meeting place for AppSec, product security and engineering leaders, with content by practitioners for practitioners and no product pitches. Join us in 2027 in New York, May 5, San Francisco, May 20, Melbourne, June 3, Sydney, June 10 and London, October 27.
Not ready to register? Sign up for updates and we will let you know when agendas and speakers are announced.