SBOM: creating and maintaining your software inventory
What is an SBOM
A Software Bill of Materials (SBOM) is the equivalent of an ingredient list for software. It documents all components (libraries, frameworks, tools) used in an application, along with their versions, licenses, and provenance.
The analogy to a food ingredient list is instructive. When a food safety authority identifies a contaminated ingredient, manufacturers can immediately determine which products are affected and issue targeted recalls. Without ingredient lists, every product would need to be recalled as a precaution. SBOM enables the same targeted, rapid response to software vulnerabilities and malicious components.
Why it is essential
When a critical vulnerability is disclosed (like Log4Shell or the XZ Utils backdoor), the first question is: “do we use this component?” Without an SBOM, answering that question can take days of manual investigation across hundreds of repositories. With an up-to-date SBOM, the answer is immediate.
Log4Shell (CVE-2021-44228) illustrated this problem at scale. The Apache Log4j library was embedded in thousands of commercial products, often without the vendors being aware because it arrived as a transitive dependency of another library. Organizations spent weeks inventorying their software to determine exposure. Those with SBOMs resolved the question in hours.
SBOMs are increasingly required by regulation. US Executive Order 14028 mandates them for software sold to the federal government. NIS2 and DORA both drive SBOM adoption through supply chain security requirements.
The regulatory driver has accelerated SBOM adoption significantly. For organizations selling to government clients or operating in regulated industries, SBOM generation is no longer optional. For others, the operational security benefit is compelling enough to justify adoption independently.
Standard formats
- SPDX (Linux Foundation): ISO standard format, the most widely standardized
- CycloneDX (OWASP): lightweight, security-optimized, strong tooling support
- SWID: older format, less commonly used in modern toolchains
CycloneDX has gained significant adoption in security tooling because it was designed specifically for security use cases, including vulnerability tracking, license compliance, and component integrity verification. SPDX has broader acceptance in legal and compliance contexts due to its ISO standardization. Both formats are supported by most modern tooling; choosing between them depends primarily on your downstream consumers.
Generation tools
| Tool | Ecosystems | Cost |
|---|---|---|
| Syft (Anchore) | Multi-language, containers | Free |
| Trivy (Aqua) | Multi-language, containers, IaC | Free |
| cdxgen | Node, Java, Python, Go | Free |
| FOSSA | Multi-language | Commercial |
Syft and Trivy are the most commonly deployed open source options for organizations building SBOM capabilities. Both integrate well with container workflows — generating SBOMs from container images as well as source code. For organizations primarily working with Node.js or Java, cdxgen provides deep ecosystem-specific analysis.
Trivy’s dual capability as both a vulnerability scanner and SBOM generator is particularly valuable: the same tool that generates your SBOM can continuously scan it against vulnerability databases, providing an integrated workflow.
Pipeline integration
SBOMs should be generated automatically at each build and stored alongside the release artifact. Vulnerability scans should run against the SBOM on every CVE database update, not just at build time. This enables continuous vulnerability awareness across your deployed software inventory.
The operational model for SBOM-driven vulnerability management looks like this:
- Generate: SBOM is produced automatically during CI/CD build
- Store: SBOM artifact is stored alongside the build artifact in a registry or artifact store
- Scan: SBOM is scanned against CVE databases (NVD, OSV, GitHub Advisory Database) at build time
- Monitor: continuous re-scanning triggers alerts when new CVEs affect components in deployed SBOMs
- Remediate: alerts are routed to the appropriate team with component version and remediation guidance
The monitoring step is where many organizations have gaps. Generating an SBOM at build time is table stakes; continuously monitoring deployed SBOMs against new vulnerability disclosures is where the operational value lies. A component that was vulnerability-free when deployed may have critical CVEs disclosed months later, and without continuous monitoring, those vulnerabilities go undetected in production.
License compliance
SBOMs also enable license compliance management. Open source licenses carry obligations ranging from minimal (MIT, Apache 2.0) to commercially restrictive (GPL, AGPL). Inadvertently shipping a GPL component in a proprietary product, or an AGPL library in a SaaS application, can create significant legal exposure.
SBOM-based license scanning identifies potentially problematic license combinations early in the development process, when remediation (replacing a library) is inexpensive, rather than during a legal review before a product launch or acquisition.
SBOM sharing
For software vendors, providing SBOMs to customers is increasingly expected. Customers need to understand what is in the software they operate. Industry groups and regulators are establishing standards for SBOM sharing, including mechanisms for distributing SBOMs at scale without exposing internal implementation details that represent competitive or security-sensitive information.
Advertisement