What is a software bill of materials?
A software bill of materials is the itemised list of components inside a release, down to the version of each one and the licence it carries. It is generated at the moment the artefact is assembled rather than reconstructed afterwards. When a vulnerability is published, the inventory is how an organisation establishes which deployed artefacts contain the affected component.
Also called: SBOM
Why the inventory has to exist before the advisory does
The question arrives on a Friday afternoon from a security team that has read an advisory, and it is always the same question: which of our systems contains this component? An organisation holding a current inventory per release answers within the hour. An organisation without one convenes a working group and answers in a fortnight, during which the exposure continues. The inventory cannot be produced retrospectively with any confidence, because the artefact in production was assembled from dependencies that have since moved.
- An inventory turns vulnerability response from an investigation into a lookup.
- Transitive dependencies are where exposure usually lies, and only generation reaches them.
- Licence obligations become discoverable before a release reaches a client.
- Procurement in several sectors now requires an inventory as a condition of supply.
How a software bill of materials works
- The inventory is generated by the release pipeline from the resolved dependency graph.
- Direct and transitive components are recorded with their versions and digests.
- The document is signed and stored against the artefact it describes.
- Deployed artefacts are correlated with their inventories in a queryable index.
- Published advisories are matched against that index on a continuous basis.
- Each match produces a ticket naming the affected environment and its owner.
How a software bill of materials is evaluated
An inventory is assessed on completeness and on how fast it answers a real advisory. Examine the following across the artefacts currently deployed:
- proportion of deployed artefacts with a current inventory
- depth of transitive dependency capture
- elapsed time from an advisory to a list of affected environments
- accuracy of version data against the artefact as deployed
- coverage of base images and of model serving layers
Limitations, risks and common failure modes
- An inventory generated at a different moment from the artefact describes something else.
- Base image contents are omitted, which is where most components actually reside.
- The document exists per release and is never indexed against what is deployed.
- Component names differ between inventory and advisory, so matching fails silently.
- Model weights and their dependencies are excluded from scope entirely.