What is an SBOM?
An SBOM, or Software Bill of Materials, is a formal inventory of every component that goes into an application: open-source libraries, third-party modules, transitive dependencies and their associated versions. By analogy, it is the list of ingredients on a food product, applied to software.
Modern software is assembled far more than it is written: a typical application relies on hundreds of third-party components, most of them from open-source projects maintained by teams you do not control.
Why it matters for your organization
Without an SBOM, you cannot quickly answer the most urgent question during a vulnerability event: "is this vulnerable component present in our estate, and where?" Incidents like Log4Shell showed that organizations with an up-to-date SBOM responded in hours, while others spent days searching blind.
The SBOM is also a pillar of third-party risk management: it makes the software supply chain visible, which is often the blind spot of vendor questionnaires. It is gradually becoming a regulatory and contractual requirement, notably in public procurement and critical sectors.
What a good SBOM should contain
- Name and version of each component.
- Supplier or origin of the component.
- Unique identifiers (such as Package URL or CPE) for automated correlation.
- Dependency relationships between components, including transitive dependencies.
- License information, useful for legal risk as much as security risk.
Where organizations most often fall short
Generating an SBOM once is not enough: it must be regenerated with every release and continuously checked against vulnerability databases. Many organizations produce an SBOM to tick a box, without integrating it into their patch-management process or requiring SBOMs from their own suppliers. A static, isolated SBOM loses most of its value.