What Is an SBOM?
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component in a piece of software — every open-source library, third-party module, and their respective versions. Think of it as a nutritional label for software.
Why SBOMs Matter
The Log4Shell vulnerability (December 2021) demonstrated why SBOMs are critical: organizations scrambled for weeks to determine whether their software contained the vulnerable Log4j library. With SBOMs, that question could have been answered in seconds.
SBOMs help organizations:
- Respond to vulnerabilities faster — Instantly identify which products are affected by a new CVE
- Manage supply chain risk — Understand your dependency on third-party components
- Meet regulatory requirements — US Executive Order 14028 requires SBOMs for software sold to federal agencies
- Evaluate vendor security — Request SBOMs from software vendors as part of procurement
SBOM Formats
| Format | Maintained By | Focus | |---|---|---| | SPDX | Linux Foundation | License compliance + security | | CycloneDX | OWASP | Security and supply chain | | SWID Tags | ISO/NIST | Software identification |
SPDX and CycloneDX are the most widely adopted formats for security use cases.
SBOM Contents
A complete SBOM includes:
- Component name and version
- Supplier/author information
- Dependency relationships (direct vs. transitive)
- License information
- Unique identifiers (CPE, PURL)
- Hash values for verification
Generating SBOMs
SBOMs can be generated at different stages:
- Build time: Most accurate, captures exact versions used during compilation
- Source analysis: Parses dependency manifests (package.json, go.mod)
- Binary analysis: Reverse-engineers components from compiled binaries
Tools like Syft, Trivy, CycloneDX CLI, and SPDX tools can generate SBOMs automatically. SCA tools like Snyk, Mend.io, and Black Duck also generate SBOMs as part of their analysis.