Software Bill of Materials (SBOM)
A software bill of materials (SBOM) is a machine-readable inventory of every component in a piece of software — the ingredient list for supply chain defense.
A software bill of materials (SBOM) is a formal, machine-readable inventory of the components that make up a piece of software: every library, framework, and module, with versions, suppliers, and the relationships between them. The analogy is the ingredient label on packaged food — you may trust the product, but when a specific ingredient is recalled, the label is how you find out whether you are affected.
How it works
Modern applications are mostly assembled, not written: the overwhelming majority of a typical codebase is open source components pulled in as dependencies, each with dependencies of its own. An SBOM makes that invisible tree explicit. Standard formats — SPDX and CycloneDX are the two dominant ones — let build tools generate the inventory automatically and let security tools consume it: matching components against vulnerability databases, flagging unmaintained or policy-violating licenses, and answering the question that defines every supply chain incident: do we run the affected component, and where?
That question is why SBOMs moved from nice-to-have to expectation. When Log4Shell broke in 2021, organizations without component inventories spent weeks grepping servers to learn whether they ran Log4j at all. Regulators noticed: the US executive order on cybersecurity made SBOMs a requirement in federal software procurement, and the EU's Cyber Resilience Act pushes manufacturers in the same direction. When the next poisoned package or hijacked dependency makes headlines, an SBOM turns "are we exposed?" from an archaeology project into a query.
How to defend with it
- Generate SBOMs in the build pipeline. An inventory created automatically at build time stays current; one written by hand is out of date before it ships.
- Demand SBOMs from vendors. Your exposure includes the components inside the software you buy, not just the software you write.
- Connect the inventory to action. An SBOM only helps if it feeds vulnerability management and patch management — inventory without remediation is a list of regrets.
- Pair the component view with the human view. An SBOM tells you what code you run; it says nothing about the phished maintainer or fake recruiter who compromises it next — that layer is covered in our guide to security awareness for developers, and a supply chain attack usually starts there.
Related terms
NOUSEC simulates attacks across 8 channels and turns the results into one number your board can read.
Book a demo