SBOM Generator

Understanding Software Bill of Materials

A Software Bill of Materials (SBOM) is a formal, structured list of components, libraries, and modules that make up a piece of software. Think of it as an ingredients list for your application - it tells you exactly what software components you are depending on.

🔍

Visibility

Know exactly what third-party code you are shipping. Identify all direct and transitive dependencies in your software supply chain.

🛡️

Security

Quickly respond to vulnerability disclosures by knowing which components are affected. Enable automated vulnerability scanning and patch management.

⚖️

Compliance

Meet regulatory requirements (EO 14028) and industry standards. Track license obligations to avoid legal issues with open source usage.

SBOM Standards Comparison

Feature CycloneDX SPDX

Organization OWASP Linux Foundation

Primary Focus Security & DevSecOps License Compliance

Formats JSON, XML, Protobuf JSON, RDF, Tag-Value

ISO Standard ECMA-424 ISO/IEC 5962:2021

Vulnerability Support Native (VEX, VDR) Via Extensions

Services/APIs Supported Limited

Executive Order 14028 Requirements

Executive Order 14028 "Improving the Nation's Cybersecurity" mandates SBOM requirements for software sold to the U.S. federal government:

• Machine-Readable Format: SBOMs must be in standard formats (CycloneDX or SPDX)

• NTIA Minimum Elements: Include supplier name, component name, version, unique identifiers, dependency relationships, author, and timestamp

• Automation: SBOMs should be generated automatically during build process

• Updates: New SBOM required for each software release or update

Best Practices for SBOM Management

• DO Automate SBOM generation in your CI/CD pipeline for every build

• DO Include transitive dependencies - not just direct dependencies

• DO Version your SBOMs and maintain historical records

• DO Integrate with vulnerability databases for continuous monitoring

• DON'T Rely on manual processes - SBOMs get outdated quickly

• DON'T Ignore license information - it's critical for compliance

What Is an SBOM (Software Bill of Materials)

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and dependencies that make up a software application. Just as a physical product has a bill of materials listing every part and sub-assembly, an SBOM catalogs every open-source library, commercial component, and internally developed module in your software.

SBOMs have become essential for software supply chain security. The 2021 Executive Order on Improving the Nation's Cybersecurity (EO 14028) mandated SBOMs for software sold to the U.S. federal government, and industry adoption is accelerating as organizations seek to manage the risk posed by vulnerabilities in third-party components (as demonstrated by Log4Shell, Spring4Shell, and the xz Utils backdoor).

SBOM Formats

What an SBOM Contains

Common Use Cases

• Vulnerability management: When a new CVE is published, search your SBOMs to instantly determine which applications are affected and need patching
• License compliance: Identify all open-source licenses in your software to ensure compliance with license obligations (GPL, LGPL, AGPL reciprocal requirements)
• Supply chain security: Monitor components for known vulnerabilities, malicious packages, and end-of-life status across your entire software portfolio
• Government compliance: Meet SBOM requirements for federal software procurement under EO 14028 and CISA guidance
• Vendor risk assessment: Request SBOMs from software vendors to evaluate the security and licensing risk of their products before procurement

Best Practices

1. Generate SBOMs automatically in CI/CD — Manual SBOM creation is unsustainable and error-prone. Use tools like Syft, Trivy, or CycloneDX plugins in your build pipeline to generate SBOMs automatically.
2. Include transitive dependencies — Your application may directly use 20 packages, but those packages depend on hundreds more. A complete SBOM includes the entire dependency tree.
3. Update SBOMs with every release — SBOMs are snapshots. Generate a new SBOM for every software release and store it alongside the release artifacts.
4. Monitor for new vulnerabilities continuously — Generate the SBOM once, but monitor it continuously. New CVEs are published daily for existing components.
5. Use VEX for vulnerability status — Vulnerability Exploitability eXchange (VEX) documents supplement SBOMs by indicating whether a known vulnerability actually affects your specific usage of a component.