SBOM (Software Bill of Materials)

An SBOM provides a detailed manifest of every piece of code in your application, including open-source libraries, third-party components, and their versions. Think of it as a nutritional label for software.

Why it matters

• Enables rapid response when vulnerabilities are disclosed (like Log4j)—you can instantly identify which applications are affected.
• Required by federal regulations: Executive Order 14028 mandates SBOMs for software sold to the U.S. government.
• Supports license compliance by tracking open-source components and their distribution requirements.
• Builds customer trust by demonstrating transparency in your software supply chain.

Key concepts

• SPDX (Software Package Data Exchange): ISO-standard format for SBOMs with rich licensing information.
• CycloneDX: OWASP-backed format optimized for security use cases and vulnerability correlation.
• VEX (Vulnerability Exploitability eXchange): Companion document stating whether known vulnerabilities are actually exploitable in your context.
• Dependency graph: Hierarchical view showing direct and transitive dependencies.

Generation approaches

• Build-time generation: Most accurate, captures exact versions used during compilation.
• Source code analysis: Parses manifest files (package.json, requirements.txt, pom.xml).
• Binary analysis: Reverse-engineers compiled artifacts when source is unavailable.
• Runtime inspection: Captures what's actually loaded during execution.

Operational best practices

• Generate SBOMs automatically in your CI/CD pipeline for every release.
• Store SBOMs alongside artifacts in your repository or registry.
• Continuously monitor SBOMs against vulnerability databases (NVD, OSV, GitHub Advisory).
• Establish policies for acceptable risk levels and automated blocking.