When a critical vulnerability lands in a widely used library, the first question is "where do we run this?" Organisations that can answer in minutes have an inventory; the rest spend a week asking teams.
What an SBOM is
A software bill of materials lists the components in a build — direct and transitive dependencies, versions and licences — in a standard format (CycloneDX or SPDX). Generated at build time, stored with the artefact, and queryable across the estate.
What it does not do
An SBOM does not tell you whether you are exploitable. A vulnerable function may never be called, or the component may be unreachable. It narrows "which of our 400 services might be affected" to a list you can triage; reachability analysis and context do the rest.
Making it useful
- Generate on every build, not on request.
- Store centrally and make it searchable by component and version.
- Include container base images and operating system packages, which is where most of the count comes from.
- Track provenance: who built it, from which source, with what signature.
The adjacent controls
Pinned dependency versions, a review step for new dependencies, build systems that cannot be modified by a pull request, and signed artefacts. Most supply chain incidents begin with a compromised build or a typo-squatted package, both of which an SBOM records after the fact and provenance controls prevent.