SBOM Explained: Why Every Application Needs a Software Bill of Materials

What Is a Software Bill of Materials?

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all the components that make up a piece of software. Just as a food label lists every ingredient in a product, an SBOM lists every library, framework, module, and tool used to build an application, along with their versions, licenses, and cryptographic hashes.

The concept is borrowed from manufacturing, where bills of materials have been standard practice for decades. If you build a car, you know every bolt, wire, and chip in it. If a supplier issues a recall for a defective brake component, you can immediately identify which vehicles are affected. Software should work the same way, but until recently, most organizations had no idea what components their applications actually contained.

When the Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, organizations worldwide scrambled to determine whether they were affected. Companies with SBOMs answered the question in minutes by searching their component inventory. Companies without SBOMs spent days or weeks manually scanning repositories, build artifacts, and production systems. Some never found all instances. This single incident crystalized the value of SBOMs for the entire industry.

The Regulatory Landscape: Why SBOM Is Becoming Mandatory

US Executive Order 14028 on Cybersecurity

In May 2021, President Biden signed Executive Order 14028, "Improving the Nation's Cybersecurity," which included a landmark requirement: any software vendor selling to the federal government must provide an SBOM. The order directed NIST, NTIA, and CISA to develop minimum SBOM requirements, and those requirements have been progressively enforced since 2022.

Key provisions of the executive order relevant to SBOMs include:

• Section 4(e) — Requires NIST to publish guidelines for the minimum elements of an SBOM, including component identity, version, supplier, dependency relationships, author, and timestamp.
• Section 4(f) — Mandates that software vendors provide SBOMs to federal purchasers and make them available to the public.
• Section 4(g) — Requires the establishment of a program to review and assess the security of critical software, with SBOM as a foundational input.

EU Cyber Resilience Act

The European Union's Cyber Resilience Act (CRA), adopted in 2024, requires manufacturers and developers of products with digital elements to provide an SBOM. The CRA applies to any product sold in the EU market that includes software, from IoT devices to enterprise applications. Non-compliance can result in fines up to 15 million euros or 2.5% of global annual turnover, whichever is higher.

FDA Cybersecurity Guidance for Medical Devices

The FDA now requires SBOMs as part of premarket submissions for medical devices that contain software. This requirement, formalized in the 2023 Consolidated Appropriations Act, means that medical device manufacturers must provide a complete SBOM including commercial, open-source, and off-the-shelf components.

Industry Standards

Beyond government mandates, several industry frameworks now reference or require SBOMs:

• NIST SP 800-218 (SSDF) — The Secure Software Development Framework includes SBOM generation as a recommended practice.
• PCI DSS v4.0 — Requirement 6.3.2 requires maintaining an inventory of custom and third-party software components, which is effectively an SBOM.
• SOC 2 — Auditors increasingly ask for evidence of dependency tracking, and an SBOM satisfies this requirement elegantly.

SPDX vs CycloneDX: Choosing a Format

Two primary SBOM formats have emerged as industry standards: SPDX and CycloneDX. Both are machine-readable, well-documented, and supported by major tooling. The choice between them depends on your specific needs and ecosystem.

SPDX Example

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application-sbom",
  "documentNamespace": "https://example.com/sbom/my-app-v2.1.0",
  "creationInfo": {
    "created": "2026-03-12T10:00:00Z",
    "creators": ["Tool: security-factor-365-1.0"],
    "licenseListVersion": "3.19"
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-express",
      "name": "express",
      "versionInfo": "4.18.2",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        { "algorithm": "SHA256", "checksumValue": "a1b2c3d4..." }
      ],
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/express@4.18.2"
        }
      ]
    }
  ]
}

CycloneDX Example

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-12T10:00:00Z",
    "tools": [{ "name": "Security Factor 365", "version": "1.0" }],
    "component": {
      "type": "application",
      "name": "my-application",
      "version": "2.1.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "hashes": [
        { "alg": "SHA-256", "content": "a1b2c3d4..." }
      ],
      "licenses": [
        { "license": { "id": "MIT" } }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:npm/my-application@2.1.0",
      "dependsOn": ["pkg:npm/express@4.18.2"]
    }
  ]
}

What to Include in Your SBOM

The NTIA's minimum elements for an SBOM, published in response to Executive Order 14028, define the baseline of what every SBOM should contain:

Required Data Fields

• Supplier name — The entity that creates, defines, and identifies the component (e.g., "Express.js Contributors" for the Express framework).
• Component name — The identifier assigned to the component by the supplier (e.g., "express").
• Version — The exact version of the component (e.g., "4.18.2"). Avoid version ranges; pin to exact versions.
• Unique identifier — A universally unique identifier such as a Package URL (purl). For example: pkg:npm/express@4.18.2.
• Dependency relationships — Which components depend on which other components, forming the complete dependency tree.
• Author of SBOM data — The entity that created the SBOM itself (your organization or your build system).
• Timestamp — When the SBOM was generated.

Recommended Additional Fields

• Cryptographic hashes — SHA-256 hashes of each component's binary or source archive, enabling integrity verification.
• License information — SPDX license identifier for each component (e.g., MIT, Apache-2.0, GPL-3.0-only).
• Download location — Where the component was obtained from (registry URL, Git repository).
• Known vulnerability status — Whether any known vulnerabilities affect each component at the time of SBOM generation.
• End of life / support status — Whether the component is actively maintained.

The Expanding BOM Family: CBOM, MLBOM, AIBOM

As the SBOM concept has matured, the industry has recognized that software components are not the only things that need transparency inventories. Several related BOM types have emerged:

CBOM (Cryptography Bill of Materials)

A CBOM inventories all cryptographic algorithms, protocols, and certificates used by an application. With the approaching transition to post-quantum cryptography, organizations need to know exactly where they use RSA-2048, AES-128, SHA-1, and other algorithms that may need to be replaced. A CBOM enables "crypto agility" by giving you a complete map of your cryptographic surface.

CycloneDX 1.5+ natively supports CBOM through its cryptographic properties extension, which can enumerate:

• Algorithms in use (AES-256-GCM, RSA-4096, Ed25519, etc.)
• Key lengths and generation methods
• Certificate authorities and certificate expiration dates
• TLS protocol versions and cipher suites
• Libraries providing cryptographic implementations

MLBOM (Machine Learning Bill of Materials)

An MLBOM inventories the components of a machine learning system: training datasets, model architectures, training parameters, framework versions, and performance metrics. As ML models are increasingly embedded in software products, understanding what went into a model is critical for bias detection, regulatory compliance, and security assessment.

AIBOM (AI Bill of Materials)

An AIBOM extends the MLBOM concept to encompass all AI components in a system, including the AI models, their training data provenance, fine-tuning datasets, guardrails, evaluation benchmarks, and third-party AI services consumed via APIs. With the EU AI Act imposing transparency requirements on AI systems, the AIBOM is becoming an essential compliance tool.

Automating SBOM Generation in CI/CD

Manual SBOM creation is impractical and error-prone. For SBOMs to be accurate and up-to-date, generation must be fully automated as part of your CI/CD pipeline. Here is a practical approach to automation:

When to Generate SBOMs

• On every release build — Generate an SBOM for every version of your application that reaches staging or production. Store it alongside the build artifacts.
• On pull request (optional) — Generate a diff-SBOM that shows which components were added, removed, or updated in the PR. This gives reviewers visibility into dependency changes.
• On schedule (for deployed applications) — Regenerate SBOMs periodically for running applications to detect configuration drift or unauthorized changes.

CI/CD Integration Example

name: Build and Generate SBOM
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Generate SBOM (CycloneDX)
        run: npx @cyclonedx/cyclonedx-npm --output-file sbom.json

      - name: Generate SBOM (SPDX)
        run: |
          curl -sSfL https://github.com/anchore/syft/releases/latest/download/syft_linux_amd64.tar.gz | tar xz
          ./syft . -o spdx-json=sbom-spdx.json

      - name: Validate SBOM
        run: |
          npx @cyclonedx/cyclonedx-cli validate --input-file sbom.json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.json
            sbom-spdx.json

SBOM Storage and Distribution

Generated SBOMs need to be stored securely and made accessible to the right stakeholders:

• Artifact repositories — Store SBOMs alongside release artifacts in your artifact repository (Artifactory, Nexus, Azure Artifacts).
• Container registries — For containerized applications, attach SBOMs to container images using OCI artifacts or Sigstore attestations.
• Dedicated SBOM management platforms — Tools like Dependency-Track ingest SBOMs and provide continuous monitoring for newly disclosed vulnerabilities affecting your components.
• Customer-facing portals — If regulatory requirements mandate SBOM sharing with customers, establish a secure distribution mechanism.

From SBOM to Action: Continuous Monitoring

An SBOM is only valuable if you act on it. The real power of SBOMs comes from continuous monitoring: automatically cross-referencing your component inventory against vulnerability databases as new CVEs are published.

When you maintain current SBOMs for all your applications, a newly disclosed vulnerability triggers an immediate, automated workflow:

1. Vulnerability published — A new CVE is published for a specific package version.
2. SBOM search — Your monitoring system searches all SBOMs to identify which applications use the affected component.
3. Impact assessment — For each affected application, the system determines whether the vulnerable code path is reachable and whether compensating controls exist.
4. Prioritized notification — Application owners are notified with the specific component, version, vulnerability details, and recommended remediation.
5. Tracking — Remediation progress is tracked against SLA targets (e.g., critical vulnerabilities patched within 48 hours).

Without SBOMs, this same process involves manual scanning, frantic Slack messages asking "does anyone use Log4j?", and incomplete answers that leave the organization exposed. With SBOMs, the answer is instant and comprehensive.

Getting Started: A Practical Roadmap

1. Week 1-2: Choose your SBOM format (SPDX, CycloneDX, or both) and select generation tooling appropriate for your language ecosystem.
2. Week 3-4: Integrate SBOM generation into your CI/CD pipeline for one pilot application. Generate SBOMs on every release build.
3. Month 2: Set up continuous monitoring by feeding SBOMs into a vulnerability tracking system. Establish SLAs for vulnerability remediation.
4. Month 3: Roll out SBOM generation to all applications. Begin tracking SBOM coverage as a security program metric.
5. Ongoing: Extend to CBOM for cryptographic transparency. Evaluate MLBOM/AIBOM if your organization uses AI/ML. Prepare for regulatory audits by maintaining an SBOM archive with historical versions.