Software Bill of Materials
also called SBOM
A machine-readable inventory of every component and dependency in a piece of software, including transitive ones, used to answer exposure questions quickly.
The question an SBOM exists to answer is the one that matters on a bad day: a critical vulnerability is announced in a library — are we affected, and where?
Without one, that takes days of searching across repositories and running systems, and the answer is never confidently complete. Log4Shell demonstrated this at scale: the vulnerable library was frequently a transitive dependency several levels deep, present in systems whose owners did not know they used Java logging at all.
Generated at build time by scanning the dependency graph, in a standard format — SPDX or CycloneDX — and stored as an artefact alongside the build, so it describes exactly what was shipped rather than what the current source produces.
What makes it useful rather than a compliance artefact:
It must cover transitive dependencies, which is where the exposure usually is. It must be queryable across the estate — one SBOM per service is only useful if something can search all of them at once. It should be signed and attached to the artefact, so its provenance is verifiable. It should feed continuous scanning, so a newly-disclosed vulnerability is matched against what is deployed rather than requiring a fresh scan.
US executive order 14028 and the EU Cyber Resilience Act are both driving this from good practice towards a requirement.