SBOM
In software supply chain security, an SBOM is a software bill of materials: a formal, machine-readable inventory of the components in a piece of software, including transitive dependencies, with versions and relationships. It answers one question fast, namely whether you contain a given component, and it answers no other question at all.
How it works
An SBOM is generated during the build, when the resolved dependency set is actually known, and published in one of the established formats, principally SPDX or CycloneDX. Each component carries an identifier, a version, a supplier and its relationship to the others, so consumers can traverse the graph rather than read a flat list.
The reason this became a procurement item rather than an engineering nicety is regulatory. The European Cyber Resilience Act places obligations on manufacturers of products with digital elements to identify and document the components they ship, and public sector tenders increasingly ask for the artefact by name. Verify the exact obligations and the applicable dates against the published text before quoting them in a document.
What goes wrong
Generation from the wrong place. An SBOM produced from a manifest lists what the developers asked for; an SBOM produced from the build lists what was actually resolved, including the transitive components that make up most of the graph and most of the risk. The two differ, and the second is the one worth having.
Staleness is the next problem. An SBOM describes one build. If it is generated once for a tender and never regenerated, it describes software that is no longer shipping, which is worse than none because it is trusted. It has to be an artefact of every build, stored with the release.
Then the honest limitation: it is an inventory, not an assessment. It tells you a component is present, not whether the vulnerable function is reachable, not whether the code was modified after the build, and not whether the component was compromised upstream. Reachability is the job of software composition analysis, and integrity of the build itself is the job of signing and provenance, which is what a supply chain attack targets.
Where this shows up in an audit
In a technical due diligence the presence of a current SBOM is a strong signal about engineering maturity, and its absence is a finding in its own right, because it means the target cannot answer the component question in an incident. We check that it is generated per build, that it covers transitive dependencies, and that somebody consumes it, since an artefact nobody reads is a compliance gesture. This is part of how we review software composition in a due diligence.