SBOMs in 2026: The Gap Between Compliance Theater and Real Supply Chain Security

Everyone Has an SBOM. Almost Nobody Uses It.

SBOMs — Software Bills of Materials — were supposed to revolutionize software supply chain security. After the SolarWinds and Log4Shell incidents, the US Executive Order 14028 mandated SBOMs for federal software procurement. The EU Cyber Resilience Act (CRA) now requires SBOMs for all products sold in the EU. CISA, the NSA, and 19 international partners published a joint "Shared Vision of SBOM for Cybersecurity" in 2026.

Every major compliance framework now expects SBOMs. And most companies generate them.

The problem? Most SBOMs are compliance theater. They're generated as the last step of a build pipeline, dumped into an artifact repository, and never looked at again. They don't improve security because nobody consumes them for security decisions.

In March 2026, Manifest released a new SBOM generator for C/C++ — historically the biggest blind spot in SBOM tooling. This is progress. But the tooling gap is only part of the problem. The real gap is between generating SBOMs and using them.

What an SBOM Actually Is

An SBOM is a machine-readable inventory of every component in a software artifact: libraries, frameworks, modules, and their versions, licenses, and relationships.

Two dominant formats:

CycloneDX (OWASP)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.21.1",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{"license": {"id": "MIT"}}],
      "hashes": [
        {"alg": "SHA-256", "content": "a1b2c3d4..."}
      ]
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{"license": {"id": "MIT"}}]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:npm/[email protected]",
      "dependsOn": ["pkg:npm/[email protected]"]
    }
  ]
}

SPDX (Linux Foundation)

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-express",
      "name": "express",
      "versionInfo": "4.21.1",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.21.1.tgz",
      "licenseConcluded": "MIT"
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-express"
    }
  ]
}

Both formats capture the same essential information. CycloneDX is more popular in security contexts, SPDX in compliance and legal contexts.

The Five Stages of SBOM Maturity

Stage 1: No SBOM (Still Common)

Organizations at this stage have no formal component inventory. They might know their direct dependencies but have no visibility into transitive dependencies.

Risk: When a vulnerability like Log4Shell drops, they spend days figuring out if they're affected.

Stage 2: Compliance SBOM (Most Organizations)

SBOMs are generated as the last build step to satisfy procurement requirements:

# Typical CI pipeline — SBOM as afterthought
stages:
  - build
  - test
  - deploy
  - generate-sbom  # Last step, never consumed

generate-sbom:
  stage: generate-sbom
  script:
    - syft . -o cyclonedx-json > sbom.json
    - aws s3 cp sbom.json s3://artifacts/sbom/
  # Nobody ever reads this file

Problems:

• Generated after deployment — if a vulnerability is found, the code is already in production
• Not validated for accuracy
• Not integrated with vulnerability management
• Exists only to satisfy a checkbox

Stage 3: Integrated SBOM

SBOMs are generated during the build process and integrated with vulnerability scanning:

# Better: SBOM integrated into pipeline
stages:
  - build
  - generate-sbom
  - vulnerability-check
  - compliance-check
  - deploy

generate-sbom:
  stage: generate-sbom
  script:
    - syft . -o cyclonedx-json > sbom.json
    - grype sbom:sbom.json --fail-on critical
  artifacts:
    paths:
      - sbom.json

vulnerability-check:
  stage: vulnerability-check
  script:
    # Check SBOM against known vulnerabilities
    - bomber scan sbom.json --provider osv
    # Block deployment if critical vulns found
    - bomber scan sbom.json --provider osv --fail-on-severity critical

Stage 4: Continuous SBOM

SBOMs are continuously updated and monitored — not just at build time:

# Continuous SBOM monitoring service
class SBOMMonitor:
    def __init__(self):
        self.sbom_store = SBOMDatabase()
        self.vuln_feed = VulnerabilityFeed()  # OSV, NVD, GitHub Advisory

    async def on_new_vulnerability(self, vuln):
        """When a new CVE is published, check all SBOMs."""
        affected_components = vuln.affected_packages

        for component in affected_components:
            # Find all deployments using this component
            affected = self.sbom_store.find_by_component(
                name=component.name,
                version_range=component.vulnerable_versions
            )

            for deployment in affected:
                alert = SecurityAlert(
                    severity=vuln.severity,
                    component=component,
                    deployment=deployment,
                    remediation=vuln.remediation
                )
                await self.notify(alert)

    async def on_new_deployment(self, sbom):
        """When new code deploys, check SBOM against all known vulns."""
        for component in sbom.components:
            vulns = self.vuln_feed.check(component)
            if vulns:
                await self.notify_deployment_risk(sbom, vulns)

Stage 5: SBOM-Driven Security (Aspirational)

SBOMs drive automated security decisions:

• Automatic patching of vulnerable components
• Runtime enforcement (block execution of unattested components)
• Supply chain integrity verification (signatures, provenance)
• License compliance automation
• Vendor risk scoring based on dependency health

The C/C++ Problem (And Manifest's Solution)

SBOM generation for interpreted languages (Python, JavaScript, Ruby) is relatively straightforward — you parse package.json, requirements.txt, or Gemfile.lock and enumerate dependencies.

C and C++ are different. There's no universal package manager. Dependencies are often:

• Vendored (copied directly into the source tree)
• Compiled from source (no manifest file)
• Linked dynamically at runtime
• Embedded as submodules or subtrees
• Downloaded via shell scripts in the build process

Manifest's March 2026 C/C++ SBOM generator addresses this by:

1. Analyzing build systems (CMake, Make, Meson, Bazel)
2. Scanning binary artifacts for embedded library signatures
3. Matching source code against known open-source packages
4. Tracing dynamic library loading at runtime

This matters because critical infrastructure — operating systems, embedded systems, automotive software, medical devices — is overwhelmingly C/C++. Without accurate C/C++ SBOMs, the most critical software in the world has the worst supply chain visibility.

The EU Cyber Resilience Act Impact

The CRA requires:

1. SBOM generation: All products with digital elements must include an SBOM
2. Vulnerability handling: Manufacturers must actively monitor and patch vulnerabilities in their components
3. Incident reporting: Security incidents related to supply chain compromises must be reported within 24 hours
4. Update mechanism: Products must have a secure update mechanism for at least 5 years

CRA Timeline:
  - August 2025: Reporting obligations take effect
  - February 2027: Full compliance required
  - Non-compliance: Up to €15M or 2.5% of global annual revenue

For any company selling software products in the EU — which includes SaaS companies serving EU customers — SBOM is no longer optional. It's a legal requirement with significant financial penalties.

Building an Effective SBOM Program

Step 1: Choose Your Toolchain

# Generation tools
synft .                          # Anchore Syft — multi-ecosystem
trivy fs . --format cyclonedx    # Aqua Trivy — includes vuln scanning
cdxgen -t python .               # CycloneDX generator

# Vulnerability scanning against SBOMs
grype sbom:sbom.json             # Anchore Grype
bomber scan sbom.json            # Bomber — multi-source vuln checking
osv-scanner --sbom sbom.json     # Google OSV scanner

# SBOM management
dependency-track                  # OWASP Dependency-Track (self-hosted)
guac                             # Google GUAC (Graph for Understanding
                                 #   Artifact Composition)

Step 2: Integrate Into CI/CD

# GitLab CI example — SBOM as a first-class citizen
sbom-generate:
  stage: build
  script:
    - syft . -o [email protected] > sbom.json
    # Sign the SBOM for integrity
    - cosign sign-blob --key cosign.key sbom.json > sbom.sig
  artifacts:
    paths:
      - sbom.json
      - sbom.sig
    expire_in: 1 year

sbom-vulnerability-check:
  stage: test
  needs: [sbom-generate]
  script:
    # Check against multiple vulnerability sources
    - grype sbom:sbom.json --fail-on critical
    - osv-scanner --sbom sbom.json
  allow_failure: false  # Block deployment on critical vulns

sbom-license-check:
  stage: test
  needs: [sbom-generate]
  script:
    # Check for license compliance
    - grant check sbom.json --config license-policy.yaml
  allow_failure: false

sbom-publish:
  stage: deploy
  needs: [sbom-generate, sbom-vulnerability-check, sbom-license-check]
  script:
    # Publish to Dependency-Track for continuous monitoring
    - curl -X POST "$DTRACK_URL/api/v1/bom" \
        -H "X-Api-Key: $DTRACK_KEY" \
        -H "Content-Type: multipart/form-data" \
        -F "project=$PROJECT_UUID" \
        -F "[email protected]"

Step 3: Deploy Continuous Monitoring

OWASP Dependency-Track is the leading open-source SBOM management platform:

# Docker Compose for Dependency-Track
services:
  dependency-track-api:
    image: dependencytrack/apiserver:latest
    environment:
      - ALPINE_DATABASE_URL=jdbc:postgresql://postgres:5432/dtrack
      - ALPINE_DATABASE_DRIVER=org.postgresql.Driver
    ports:
      - "8081:8080"
    volumes:
      - dt-data:/data

  dependency-track-frontend:
    image: dependencytrack/frontend:latest
    environment:
      - API_BASE_URL=http://localhost:8081
    ports:
      - "8080:8080"

  postgres:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=dtrack
      - POSTGRES_PASSWORD=${DT_DB_PASSWORD}
    volumes:
      - pg-data:/var/lib/postgresql/data

Dependency-Track continuously monitors your SBOMs against the NVD, GitHub Advisory Database, and OSV, alerting you when new vulnerabilities affect your deployed software.

Step 4: Implement SBOM Attestation

SBOMs should be signed and attested to prove they haven't been tampered with:

# Generate SBOM
syft . -o cyclonedx-json > sbom.json

# Create in-toto attestation
cosign attest --key cosign.key \
  --type cyclonedx \
  --predicate sbom.json \
  registry.example.com/myapp:v2.1.0

# Verify attestation before deployment
cosign verify-attestation \
  --key cosign.pub \
  --type cyclonedx \
  registry.example.com/myapp:v2.1.0

This creates a cryptographic chain of trust: the SBOM was generated by your build system, hasn't been modified, and accurately represents the software artifact.

The VEX Companion

Vulnerability Exploitability eXchange (VEX) documents complement SBOMs by stating whether a known vulnerability in a component actually affects your product:

{
  "document": {
    "category": "csaf_vex",
    "title": "VEX for MyApp v2.1.0"
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2024-12345",
      "product_status": {
        "known_not_affected": ["MyApp v2.1.0"]
      },
      "threats": [
        {
          "details": "The vulnerable function in lodash is not called by our application. Import chain exists but the affected code path is unreachable."
        }
      ]
    }
  ]
}

Without VEX, every vulnerability in your SBOM generates an alert. With VEX, you communicate which vulnerabilities are actually exploitable in your context — reducing alert fatigue by 60-80%.

Metrics That Matter

Track these metrics to measure your SBOM program's effectiveness:

The Bottom Line

SBOMs are now legally required for many organizations and expected by most enterprise procurement processes. But generating an SBOM and filing it away is worse than useless — it creates a false sense of security.

The organizations that benefit from SBOMs are those that treat them as living security artifacts: generated during build, checked against vulnerability databases before deployment, continuously monitored after deployment, and attested for integrity.

Stop generating SBOMs as compliance artifacts. Start using them as security tools. The difference between the two is the difference between checking a box and actually securing your supply chain.