SBOM - Software Bill of Materials

SBOM (Software Bill of Materials) answers a question that millions of IT teams asked simultaneously during the Log4Shell incident (December 2021): "Are we using log4j? If so, where?" Without SBOM: weeks of manual searching through hundreds of repositories. With SBOM: an answer in seconds.

SBOM Formats

SPDX (Software Package Data Exchange)

• Developed by the Linux Foundation
• ISO/IEC 5962:2021 (international standard)
• Formats: .spdx (tag-value), .json, .yaml, .xml, .rdf
• Strength: best license compliance support
• Tooling: syft, spdx-tools, fossology

{
  "spdxVersion": "SPDX-2.3",
  "name": "myapp",
  "packages": [{
    "SPDXID": "SPDXRef-log4j",
    "name": "log4j-core",
    "version": "2.14.1",
    "supplier": "Organization: Apache Software Foundation",
    "licenseDeclared": "Apache-2.0",
    "externalRefs": [{
      "referenceCategory": "SECURITY",
      "referenceType": "cpe23Type",
      "referenceLocator": "cpe:2.3:a:apache:log4j:2.14.1:*"
    }]
  }]
}

CycloneDX

• Developed by OWASP
• Focus: Security use cases (vulnerability management)
• Formats: .json, .xml
• Strength: Best security tool integration
• Tooling: cdxgen, syft, Dependabot
• VEX (Vulnerability Exploitability eXchange) as an extension

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "log4j-core",
    "version": "2.14.1",
    "group": "org.apache.logging.log4j",
    "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
    "licenses": [{"license": {"id": "Apache-2.0"}}],
    "vulnerabilities": [{
      "id": "CVE-2021-44228",
      "ratings": [{"severity": "critical", "score": 10.0}]
    }]
  }]
}

SWID (Software Identification Tags)

• ISO/IEC 19770-2 Standard
• Focus: Asset Management, Software Inventory
• Less common in open-source tooling
• More common in commercial software (Windows Installer)

Recommendation by Use Case

Use Case	Recommended Format
Security Focus	CycloneDX (best CVE integration)
License Compliance	SPDX
Enterprise/Asset	SWID + SPDX

Generate SBOM

# syft (Anchore - Open Source)
# Installation:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Python project:
syft dir:./myapp -o spdx-json=sbom.spdx.json
syft dir:./myapp -o cyclonedx-json=sbom.cdx.json

# Docker image:
syft nginx:latest -o spdx-json=nginx-sbom.spdx.json

# NPM project:
syft dir:./webapp --catalogers javascript-lock-file

# cdxgen (CycloneDX Generator - OWASP)
npm install -g @cyclonedx/cdxgen
cdxgen -t nodejs -o bom.json ./myapp
cdxgen -t python -o bom.json ./myapp
cdxgen -t java -o bom.json ./myapp
# Supports 30+ languages/ecosystems

# Trivy (Aqua Security)
# SBOM from image:
trivy image --format cyclonedx --output sbom.json nginx:latest
# SBOM from filesystem:
trivy fs --format spdx-json --output sbom.json ./

# GitHub Dependency Graph (SaaS)
# Automatic for all GitHub repos (when enabled)
# Export via API:
gh api /repos/{owner}/{repo}/dependency-graph/sbom > sbom.json

# SBOM signing (for chain of trust) via Sigstore cosign:
cosign attach sbom --sbom sbom.cdx.json container-image:tag
cosign verify-blob sbom.cdx.json --certificate cert.pem
# SBOM signing is important for:
# → Supply chain trust (I prove: this SBOM is mine)
# → Immutability (SBOM has not been tampered with)

SBOM for Vulnerability Management

# grype - Vulnerability scanner with SBOM input (Anchore)

# Install grype:
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh

# Scan directly on the image:
grype nginx:latest

# Scan on the SBOM file (faster, can be done offline!):
grype sbom:./sbom.spdx.json

Output:

NAME         INSTALLED  FIXED-IN  VULNERABILITY   SEVERITY
log4j-core   2.14.1     2.17.1    CVE-2021-44228  Critical
log4j-api    2.14.1     2.17.1    CVE-2021-44228  Critical

# Exit code for CI/CD:
grype sbom:./sbom.json --fail-on critical
# exit 1 if Critical CVEs are found → Build fails!

Log4Shell Example: SBOM vs. No SBOM

Scenario: December 10, 2021, CVE-2021-44228 published.

Without SBOM:

• IT: "Do we have log4j anywhere?"
• Dev Team A: "Don't think so, check it out..."
• Dev Team B: "We're building on Spring, no idea if it's included"
• 3 weeks of manual searching through hundreds of repos...

With SBOM:

grype sbom:service-a/sbom.json --fail-on critical  # → 0 findings
grype sbom:service-b/sbom.json --fail-on critical  # → FAIL: log4j 2.14.1!
grype sbom:service-c/sbom.json --fail-on critical  # → 0 findings
grype sbom:service-d/sbom.json --fail-on critical  # → FAIL: log4j 2.12.3!

10 minutes to identify all affected services → immediate patch plan for exactly 2 out of 10 services.

VEX (Vulnerability Exploitability eXchange)

Complements SBOM: "CVE-XYZ is present, but not exploitable because..." Reduces false positives (e.g., CVE in a code path that is never executed).

{
  "vulnerabilities": [{
    "id": "CVE-2021-44228",
    "analysis": {
      "state": "not_affected",
      "justification": "code_not_reachable",
      "response": ["will_not_fix"],
      "detail": "log4j-core is bundled but the JndiLookup class is disabled in deployment"
    }
  }]
}

Regulatory SBOM Requirements

U.S. Executive Order 14028 (May 2021)

• "Improving the Nation's Cybersecurity"
• SBOM requirement for software providers to U.S. federal agencies
• Baseline definition: NTIA minimum elements for SBOM
• Impact: U.S. market → indirectly a global requirement

EU Cyber Resilience Act (CRA) - effective from 2027

• Applies to all "Products with Digital Elements" in the EU market
• Requirement: "Vulnerability Disclosure Policy" + SBOM-like documentation
• Annex I: technical documentation including all dependencies
• Fines: up to 15 million EUR or 2.5% of annual turnover
• Affects: almost all software sold in the EU

NIS2 Directive (effective October 2024)

• Art. 21: "Supply Chain Security" as a mandatory control
• SBOM as a tool for implementing supply chain security
• Critical facilities: more detailed requirements

NTIA Minimum Elements (US, October 2021)

6 mandatory fields per component:

1. Supplier Name (manufacturer)
2. Component Name
3. Component Version
4. Other Unique Identifiers (PURL, CPE)
5. Dependency Relationship (who depends on whom?)
6. Author of SBOM Data

Best Practices for SBOM Implementation

• Generate SBOM in CI/CD (each build → new SBOM)
• Sign SBOMs (Sigstore cosign)
• Store SBOMs in Artifact Registry (alongside Docker image)
• Automated vulnerability scan against SBOM (grype in pipeline)
• SBOM retention: at least as long as the software is supported
• Include transitive dependencies (A → B → C: all three!)