A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and modules that make up a piece of software. Think of it as a nutritional label for software — it tells you exactly what ingredients went into building the product, in what versions, and under what licenses.

The term "Bill of Materials" originates in manufacturing, where it describes a hierarchical list of the raw materials, parts, and components needed to build a product. In software, the concept maps cleanly: open-source libraries, proprietary SDKs, operating system packages, and container base images are all "components" that ship with your product.

Why SBOMs Exist

Modern software is almost never built from scratch. The average enterprise application pulls in hundreds of open-source dependencies, many of which have their own transitive dependencies. A typical Node.js application may have thousands of packages in its node_modules directory — most of which the development team has never audited.

This opacity creates risk. When a critical vulnerability like Log4Shell (CVE-2021-44228) or the XZ Utils backdoor (CVE-2024-3094) is disclosed, organizations that lack an SBOM must scramble to determine whether they are affected. Those with SBOMs can answer the question in seconds.

The Supply Chain Context

Software supply chain attacks have grown dramatically. Attackers increasingly target the build pipeline — injecting malicious code into popular open-source packages rather than attacking end targets directly. An SBOM provides the forensic foundation to detect such attacks and trace their blast radius.

The 2021 SolarWinds attack illustrated how a single compromised build step could propagate malicious code to thousands of downstream organizations. SBOM adoption is one of the primary systemic responses to this class of threat.

Three primary SBOM formats are in active use today, each with distinct design philosophies, strengths, and community adoption patterns. Understanding the differences will guide your tooling and compliance decisions.

SPDX — Software Package Data Exchange

Developed by the Linux Foundation and standardized as ISO/IEC 5962:2021, SPDX is the oldest and most widely recognized SBOM format. It was originally designed for license compliance and legal due diligence, making it the natural choice for organizations with strong open-source governance requirements.

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-web-app",
  "documentNamespace": "https://example.com/sbom/my-web-app-1.0.0",
  "documentDescribes": ["SPDXRef-Package"],
  "packages": [
    {
      "SPDXID": "SPDXRef-Package",
      "name": "my-web-app",
      "versionInfo": "1.0.0",
      "downloadLocation": "https://github.com/example/my-web-app",
      "filesAnalyzed": false
    },
    {
      "SPDXID": "SPDXRef-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "licenseDeclared": "MIT",
      "copyrightText": "Copyright OpenJS Foundation"
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-Package",
      "relatedSpdxElement": "SPDXRef-lodash",
      "relationshipType": "DEPENDS_ON"
    }
  ]
}

SPDX supports multiple serialization formats: JSON, YAML, RDF, and its own tag-value text format. The tag-value format is human-readable and commonly used in open-source license scanning workflows. SPDX 3.0, released in 2024, introduces a significant restructuring with a profile-based model that extends coverage to security, AI/ML, and dataset use cases.

CycloneDX

Created by OWASP, CycloneDX was designed from the ground up for security use cases. It supports detailed vulnerability tracking, CVSS scores, and risk assessment alongside component inventory. CycloneDX is the preferred format in security tooling ecosystems (Dependency-Track, Grype, etc.) and is frequently specified in government security frameworks.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2024-01-15T12:00:00Z",
    "component": {
      "type": "application",
      "name": "my-web-app",
      "version": "1.0.0",
      "purl": "pkg:npm/my-web-app@1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [
        { "license": { "id": "MIT" } }
      ],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "e82c1d9e6c54e89b1b5a5f4d16e20e9e4e0c9a6c8a2b3e5f7a9c1e3f5a7c9e1"
        }
      ]
    }
  ]
}

A key differentiator of CycloneDX is the Package URL (purl) standard, which provides a universal, ecosystem-agnostic way to identify packages. A purl like pkg:npm/lodash@4.17.21 unambiguously identifies the package across any system that understands the purl specification.

SWID Tags

ISO/IEC 19770-2 Software Identification (SWID) Tags are XML-formatted identifiers attached to installed software products. Unlike SPDX and CycloneDX which describe a software's dependencies, SWID tags describe the software itself — acting as an identity layer for asset management and software inventory systems. SWID tags are commonly used in enterprise IT asset management (ITAM) and government procurement contexts.

Choosing a Format

In practice, the choice often comes down to your primary use case and the ecosystem of your consumers:

SBOM generation can occur at multiple stages of the software lifecycle. The approach you choose affects both the accuracy of the resulting document and the operational burden on your team.

Build-Time Generation

Generating an SBOM during the build process is the gold standard. At build time, the exact set of resolved dependencies is known with certainty — the package manager has already resolved the dependency graph, selected specific versions, and (ideally) verified hashes. Build-time SBOMs capture what was actually built, not what was merely specified.

Analysis-Time Generation

When you cannot modify the build pipeline — for legacy software, acquired applications, or third-party binaries — analysis-time tools can scan existing artifacts to produce an SBOM. These tools analyze:

• Package manifest files (package.json, requirements.txt, go.mod, etc.)
• Lock files (package-lock.json, poetry.lock, Cargo.lock)
• Binary artifacts through string extraction and hash matching
• Container image layers via the layer filesystem

Key Generation Tools

The open-source ecosystem has produced excellent SBOM generation tools for every major language ecosystem:

# Generate SBOM from a container image (CycloneDX JSON)
syft ghcr.io/example/my-app:latest -o cyclonedx-json > sbom.json

# Generate from a local directory (SPDX JSON)
syft dir:./my-project -o spdx-json > sbom.spdx.json

# Generate and attest to a container image
syft attest --output cyclonedx-json \
  ghcr.io/example/my-app@sha256:abc123... \
  > sbom.attestation.json

# Automatic ecosystem detection
cdxgen -o bom.json .

# Specify project type explicitly
cdxgen -t nodejs -o bom.json ./my-app

# Generate for a container image
cdxgen -t docker -o bom.json ghcr.io/example/my-app:latest

# Recursive for multi-module repositories
cdxgen --deep -o bom.json .

CI/CD Integration

Automating SBOM generation in your pipeline ensures that every release artifact has a corresponding SBOM without requiring manual steps. Here is a minimal GitHub Actions workflow:

name: Generate and Attest SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      id-token: write
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.cyclonedx.json

      - name: Upload SBOM as release asset
        if: github.event_name == 'release'
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ github.event.release.upload_url }}
          asset_path: sbom.cyclonedx.json
          asset_name: sbom.cyclonedx.json
          asset_content_type: application/json

An SBOM is only valuable if it is actively used. The real power of SBOMs emerges when they are fed into tooling that can query them against vulnerability databases, license catalogs, and organizational policy rules.

Vulnerability Scanning

The most immediate use case is mapping SBOM components to known vulnerabilities using databases like the National Vulnerability Database (NVD), OSV (Open Source Vulnerabilities), and commercial sources like GitHub Advisory Database.

# Scan an SBOM file directly
grype sbom:./sbom.cyclonedx.json

# Scan and output as table (default) or JSON
grype sbom:./sbom.spdx.json -o json > vulns.json

# Fail on vulnerabilities above a threshold
grype sbom:./sbom.json --fail-on high

# Example output snippet:
# NAME        INSTALLED  FIXED-IN   TYPE  VULNERABILITY   SEVERITY
# lodash      4.17.4     4.17.21    npm   CVE-2021-23337  High
# minimist    1.2.5      1.2.6      npm   CVE-2021-44906  Critical

Dependency-Track for Continuous Monitoring

Dependency-Track (OWASP) is the most capable open-source platform for ongoing SBOM management. It accepts SBOMs, continuously monitors components against multiple vulnerability data sources, tracks component age, and enforces policy rules. It provides a REST API suitable for automation and integrates with JIRA, Slack, and security information platforms.

License Compliance Analysis

License compliance is the original motivation for SBOMs. Key concerns include:

• Copyleft licenses (GPL, LGPL, AGPL) may impose distribution requirements on your product
• Attribution requirements require you to include license notices in your distributions
• Patent grants vary significantly between permissive licenses (Apache 2.0 vs. MIT)
• License compatibility — some license combinations cannot legally coexist in the same binary

# Analyze project and produce a BOM + license report
ort analyze -i ./my-project -o ./ort-results

# Run license and vulnerability evaluations
ort evaluate -i ./ort-results/analyzer-result.json \
  -o ./ort-results \
  --rules-file ./custom-rules.kts

# Generate HTML and PDF reports
ort report -i ./ort-results/evaluation-result.json \
  -o ./reports \
  -f HtmlTemplate,PdfTemplate,SpdxDocument

SBOM requirements are transitioning from voluntary best practices to legal mandates. The regulatory landscape is evolving rapidly, and organizations selling software into regulated markets must track requirements across multiple jurisdictions.

US Executive Order 14028

The Executive Order on Improving the Nation's Cybersecurity (May 2021) was the watershed moment for SBOM policy in the United States. Section 4(e) directed NIST and NTIA to establish SBOM standards for federal software procurement. The NTIA's "minimum elements" framework, published in 2021, specifies seven required data fields for a conformant SBOM:

EU Cyber Resilience Act

The Cyber Resilience Act (CRA), adopted in 2024 and entering into force in 2027, imposes cybersecurity requirements on all hardware and software products sold in the EU with "digital elements." SBOM requirements under the CRA are part of a broader obligation to document software components and maintain vulnerability disclosure processes.

Products classified as "Class I" (higher risk) and "Class II" (critical) face additional conformity assessment requirements, and manufacturers must provide SBOMs upon request to market surveillance authorities.

FDA Medical Device Guidance

The FDA's 2023 guidance on cybersecurity for medical device software requires SBOM submission as part of premarket approval (PMA) and 510(k) submissions. Medical device SBOMs must cover all commercial, open-source, and off-the-shelf software components and must be kept current throughout the device's lifecycle.

Defense and Critical Infrastructure

The Department of Defense (DoD) has incorporated SBOM requirements into its software acquisition policies. CMMC (Cybersecurity Maturity Model Certification) Level 2 and above require software supply chain risk management practices that include SBOM generation and analysis. Critical infrastructure sectors (energy, financial services, healthcare) are seeing similar SBOM requirements emerge from sector-specific regulators.

Implementing a comprehensive SBOM program is a journey, not a one-time task. Organizations typically progress through distinct maturity stages as they build capability, automate processes, and extend coverage across their software portfolio.

SBOM Maturity Model

Recommended Toolchain

For organizations starting their SBOM journey, the following open-source toolchain covers generation, analysis, and management for most modern application stacks:

SBOM Attestation with Sigstore

A generated SBOM is only trustworthy if you can verify that it was produced by a legitimate build system and hasn't been tampered with. Sigstore provides a free, open-source signing infrastructure that ties cryptographic signatures to build system identity (OIDC), creating a verifiable chain of custody.

# Attach an SBOM as an OCI attestation (keyless, via Sigstore)
cosign attest \
  --predicate sbom.cyclonedx.json \
  --type cyclonedx \
  ghcr.io/example/my-app@sha256:abc123...

# Verify the attestation later
cosign verify-attestation \
  --type cyclonedx \
  --certificate-identity-regexp "https://github.com/example/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/example/my-app@sha256:abc123...

# Download and inspect the SBOM
cosign download attestation \
  --predicate-type cyclonedx \
  ghcr.io/example/my-app@sha256:abc123... \
  | jq '.payload | @base64d | fromjson'

Distributing SBOMs to Customers

The final maturity step is making SBOMs available to your customers and downstream consumers. Common distribution mechanisms include:

• Release artifacts: Include sbom.json alongside release binaries on GitHub Releases, S3, or your release portal
• OCI registry attachments: Attach SBOMs as OCI artifacts to your container images using cosign
• Well-known URL: Publish at https://example.com/.well-known/sbom or equivalent
• On-request portal: For enterprise customers with contractual SBOM requirements, a secure customer portal