Software bill of materials (SBOM)
Also known as: SBOM
A software bill of materials (SBOM) is an inventory of every component inside a piece of software: open-source libraries, their versions, and where they came from.
It works like the ingredient list on food packaging. While an SBOM doesn't make software secure on its own, it answers the first question in every major vulnerability scramble: are we using the broken thing, and where?
Software bill of materials (SBOM), explained at three levels
At home
Think of the ingredient list on a box of cereal. If a recall is announced for one ingredient, you can check the box and know right away whether yours is affected. Software has ingredients too: most apps are built from dozens or hundreds of pieces of code borrowed from other projects. An SBOM is the ingredient list for a piece of software.
At work
A software bill of materials, or SBOM, is an inventory of every component inside a piece of software: open-source libraries, their versions, and their suppliers. Because most modern software is built largely from such components, an SBOM lets a company answer quickly whether a newly announced vulnerability affects its products. Businesses care because customers and regulators increasingly require one, and it speeds up security response.
At home
An SBOM is usually a machine-readable file in one of two formats, SPDX or CycloneDX. For each component it records the name, version, supplier, and a unique identifier such as a package URL, plus how components depend on each other. That includes indirect dependencies, the libraries your libraries rely on. Scanning tools compare those identifiers against vulnerability databases and flag any component with a known flaw.
At work
At work, SBOMs are generated automatically during the build by tools such as Syft, Trivy, or package-manager plugins, which read lock files and container images. Each release gets its own SBOM, stored alongside the software and often shared with customers. Vulnerability management platforms then match SBOMs continuously against advisories, so when a new flaw is published, the team sees every affected product and version. Medical device makers already must provide SBOMs to the US FDA.
At home
An SBOM tells you a vulnerable library is present, not whether the vulnerable code is ever used. Many flagged flaws sit in functions a product never calls, so a raw SBOM scan produces a long list of false alarms. VEX documents, short for Vulnerability Exploitability eXchange, let the supplier state whether a product is actually affected. In my opinion, that pairing is what makes SBOMs useful instead of overwhelming.
At work
SBOM quality varies: incomplete transitive dependencies, components copied directly into code, and inconsistent identifiers are common. The NTIA minimum elements and CISA guidance set baselines, and the EU Cyber Resilience Act will require manufacturers to maintain SBOMs. Mature programs generate one per build, sign it, attach VEX statements, and monitor continuously against new advisories. Treat SBOMs as somewhat sensitive, since a complete inventory is also a map for attackers looking for weak components.
Real-world examples
At home
Jerome develops a small open-source app. When a business user asked for an SBOM before approving it, he added one command to his build pipeline that generates a CycloneDX file with every release.
At work
Aisha is a security manager at a medical device company selling to hospitals. Her team ships an SBOM with every software update. When a new flaw hit a common compression library, they confirmed within an hour which device models were affected.
Common confusions
- An SBOM proves software is secure. — It's an inventory. It shows what's inside, not whether it's safe.
- Every listed vulnerability needs fixing immediately. — Many flaws aren't reachable in a given product. VEX statements clarify real impact.
- SBOMs are a one-time document. — Every new build can change components, so SBOMs should be generated with each release.
For analysts
Ask vendors for SBOMs during procurement, and ask how fast they can answer 'are you affected?' when the next big vulnerability lands. I'd treat a vague answer as a real supply chain risk.
History & origin
Manufacturing has used bills of materials for generations, and software versions of the idea were discussed in the 2010s, but the idea went mainstream after the 2020 SolarWinds breach. In May 2021, US Executive Order 14028 directed federal agencies to require SBOMs from software suppliers, and the NTIA published minimum elements that July. Months later, the Log4Shell vulnerability of December 2021 showed why: thousands of organizations spent weeks finding out where a single logging library was hidden. Two formats dominate, SPDX (an ISO standard since 2021) and OWASP's CycloneDX. The EU Cyber Resilience Act now requires manufacturers to prepare SBOMs, with its main obligations applying from December 2027. In my view, Log4Shell did more for SBOM adoption than any regulation.