What Is an SBOM? Software Bill of Materials Explained
Written by the Rafter Team
A software bill of materials (SBOM) is a complete, machine-readable inventory of every component, library, and dependency in your application. Think of it as a nutrition label for software — it tells you exactly what is inside the package, who produced each ingredient, and which version you are consuming. Without an SBOM, you cannot answer a basic question that regulators, customers, and your own security team will ask: "Are we running anything affected by this vulnerability?"
A 2024 Sonatype report found that open source supply chain attacks increased 156% year-over-year. Organizations without SBOMs averaged 68 days longer to identify whether a disclosed CVE affected their production systems.
Scan your dependencies with Rafter — free
Why SBOMs Matter Now
U.S. Executive Order 14028, signed in May 2021, requires any software vendor selling to the federal government to provide an SBOM with every release. The mandate has cascaded into the private sector. Procurement teams, compliance auditors, and enterprise customers increasingly expect SBOMs as a baseline deliverable alongside the software itself.
Beyond compliance, SBOMs give your team operational speed. When a critical CVE drops — like Log4Shell — you need to know within minutes, not days, whether the vulnerable component exists anywhere in your stack. An up-to-date SBOM turns that from a manual investigation into a single query.
SPDX vs CycloneDX — Choosing a Format
Two dominant formats exist for SBOMs, and both are recognized by the U.S. government and major industry frameworks:
- SPDX (Software Package Data Exchange) — an ISO/IEC 5962 standard maintained by the Linux Foundation. Strong on license compliance metadata and widely adopted in open source ecosystems. Output formats include JSON, RDF, and tag-value.
- CycloneDX — an OWASP standard designed for security use cases. Built around vulnerability tracking, VEX (Vulnerability Exploitability eXchange), and dependency scanning workflows. Output formats include JSON and XML.
If your primary concern is compliance and regulatory scanning, either format works. CycloneDX has stronger native support for vulnerability correlation and is the more common choice in application security toolchains. SPDX is the safer bet when license obligations are the main driver.
How to Generate SBOMs in CI/CD
Generating an SBOM should not be a manual step. The most reliable approach runs SBOM generation on every build, producing an artifact alongside your container image or release binary.
# GitHub Actions — generate SBOM on every build
- name: Generate CycloneDX SBOM
uses: CycloneDX/gh-node-module-generatebom@v1
with:
output: sbom.json
- name: Scan SBOM for vulnerabilities
uses: rafter/scan-action@v1
with:
sbom: sbom.json
fail-on: critical
Popular generation tools include Syft (container and filesystem analysis), Trivy (scanner with SBOM output), and CycloneDX plugins for npm, Maven, pip, and Go. The critical practice is storing each SBOM as a versioned build artifact so you can retroactively query any release when a new CVE surfaces.
Rafter integrates supply chain security checks and vulnerability scanning into every commit — including dependency enumeration that feeds directly into SBOM-aware workflows. No extra pipeline configuration required.
Try Rafter free — know what is in your software