A software bill of materials (SBOM) is a structured list of the components that make up a piece of software: the open-source and commercial libraries it includes, their versions, suppliers and how they relate to each other. Like an ingredients label on food, it lets the people who run the software see what is inside. Its most practical use is speed: when a flaw is announced in a widely used component, an SBOM helps an organization find out quickly which of its applications contain it.
At a glance
- An SBOM lists software components, their versions and suppliers, usually in a machine-readable format such as SPDX or CycloneDX.
- Software makers typically generate it automatically during the build process.
- Buyers use SBOMs to check exposure to newly announced vulnerabilities and to assess supplier practices.
- An SBOM is an inventory, not a security assessment; it must be matched with vulnerability data to show risk.
- Government and customer expectations for SBOMs are growing, but requirements vary by market and jurisdiction.
What problem it solves
Modern software is assembled more than written. A typical application includes many open-source libraries, each of which may pull in others. When a serious vulnerability is announced in one of those components, organizations need to answer a simple question: do we run anything that contains it? Without an inventory, answering means emailing every software supplier and waiting, while attackers start exploiting the flaw within days or hours.
An SBOM turns that into a lookup. Matched against databases of common vulnerabilities and exposures (CVE), it shows which applications are likely affected so teams can prioritize patches or ask the right supplier the right question. It also helps defend against supply chain attacks, where attackers tamper with a component that many products depend on, by making it easier to see where that component is used. For software makers, producing SBOMs encourages better control of what goes into their products.
How it works
Generation. Build tools and application security testing tools, particularly software composition analysis, create an SBOM as code is compiled or packaged. Tools can also scan finished applications or container images, but that tends to be less complete.
Content. An SBOM typically records each component’s name, version, supplier, a unique identifier and its relationship to other components. Many also include licenses and cryptographic hashes for checking integrity.
Format and sharing. SPDX and CycloneDX are the common formats. Suppliers share SBOMs with customers through portals, on request, or alongside software releases, and update them when the software changes.
Use. Buyers load SBOMs into a vulnerability management or SBOM management tool, which compares components against vulnerability data and alerts when a new issue matches. Because many matched vulnerabilities aren’t exploitable in a specific product, some suppliers publish Vulnerability Exploitability eXchange (VEX) statements to say whether a known issue affects them.
When it matters for buyers
- When a widespread vulnerability hits. SBOMs shorten the time to know whether you’re exposed.
- When selling software to government or regulated customers. US federal software supply-chain guidance and the EU Cyber Resilience Act have made SBOMs a growing expectation; check what applies to your market.
- When assessing software suppliers. Whether a vendor can produce an accurate, current SBOM says a lot about its development practices, and fits naturally into third-party risk management (TPRM).
- When you build software. Generating SBOMs as part of DevSecOps helps you respond to customers and incidents. See our application security testing overview.
Questions to ask vendors
- Can you provide an SBOM for the products and versions we use, and in which format?
- How is it generated, and does it include indirect dependencies as well as direct ones?
- How often is it updated, and how will we be notified of new versions?
- Do you publish VEX or similar statements on whether known vulnerabilities affect your product?
- How quickly do you assess and communicate exposure when a major component vulnerability is announced?
- For SBOM management tools: which formats can you ingest, and how do you reduce false matches?
How it differs from software asset management
Software asset management (SAM) tracks which software products an organization owns and runs, including licenses, versions and where they are installed, mainly to control cost and license compliance. An SBOM looks one level deeper: it lists what is inside a single software product. SAM tells you that you run a particular application on 200 machines; the application’s SBOM tells you which libraries that application contains. Combining the two helps you go from “this library is vulnerable” to “these machines are affected”.