The software supply chain has become the soft underbelly of modern applications. While teams harden their APIs, patch their runtimes, and rotate their secrets, the dependencies they pull from package registries often go uninspected. A single compromised npm package or a vulnerable transitive dependency buried three layers deep in a container image can bypass every perimeter control you have.
The Software Bill of Materials (SBOM) has emerged as the foundational tool for addressing this gap. It is a machine-readable inventory of every component in a software artifact, including transitive dependencies, version information, licenses, and checksums. Recent regulatory developments, including the EU Cyber Resilience Act and updated CISA guidelines published in July 2026, are making SBOMs a legal requirement rather than a best-practice recommendation.
Let’s break down what SBOMs are, the competing standards, and how to integrate them into a CI/CD pipeline with practical tooling.
What an SBOM Actually Contains
An SBOM is not just a list of top-level dependencies from your go.mod or package.json. It is a hierarchical inventory that captures every component shipped in your software, including:
- Direct dependencies — packages you explicitly declared
- Transitive dependencies — packages your dependencies depend on, recursively
- Version identifiers — exact versions, including commit hashes where applicable
- License information — the legal terms for each component
- Cryptographic hashes — typically SHA-256, for integrity verification
- Supplier information — who maintains or published each component
The hierarchy matters. Each component can have its own SBOM describing its subcomponents, creating a nested structure that mirrors how software is actually built. A container image might reference an application SBOM, which references a library SBOM, which references an OS-level package SBOM.
CycloneDX vs SPDX: Choosing a Standard
Two SBOM formats dominate the landscape: CycloneDX and SPDX. Both are accepted by CISA and international standards bodies, but they have different strengths.
CycloneDX, originally developed within the OWASP community and now an Ecma International standard (ECMA-424), was purpose-built for security workflows. It has native support for vulnerability data through VEX (Vulnerability Exploitability eXchange), dependency graphs that map component relationships, and specialized BOM types for different artifact categories like SaaSBOM for cloud services and ML-BOM for machine learning models.
SPDX, an ISO/IEC standard (ISO/IEC 5962), evolved from the Linux Foundation’s licensing compliance work. It excels at license analysis and attribution, with a comprehensive license expression syntax that handles complex dual-license and exception scenarios. SPDX has broader tool adoption in enterprise environments, particularly where legal review is involved.
The pragmatic answer for most teams: generate both. A single build can produce a CycloneDX SBOM for security scanning and an SPDX SBOM for compliance, each feeding into the appropriate workflow.
Generating SBOMs in CI/CD
Several mature tools generate SBOMs from different artifact types. The most widely used open-source options are Syft by Anchore and CycloneDX tooling. Syft supports the widest range of ecosystem detection — it can analyze container images, filesystem directories, and even bare tarballs.
Here is how to generate an SBOM from a container image using Syft in a GitHub Actions workflow:
# .github/workflows/sbom.yml
name: Generate SBOM
on:
push:
branches: [main]
release:
types: [published]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapp:latest .
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
image: myapp:latest
format: cyclonedx-json
output-file: sbom.cdx.json
upload-artifact: true
- name: Upload as release asset
if: github.event_name == 'release'
uses: softprops/action-gh-release@v2
with:
files: sbom.cdx.jsonThis workflow generates a CycloneDX JSON file on every push and attaches it to releases. The upload-artifact: true flag stores the SBOM as a GitHub Actions artifact for 90 days.
Vulnerability Scanning with SBOMs
Generating an SBOM is only half the equation. The real value comes from consuming it — feeding the SBOM into a vulnerability scanner that cross-references components against CVE databases. Grype works naturally with Syft’s output:
# Generate SBOM from a container image
syft myapp:latest -o cyclonedx-json=sbom.cdx.json
# Scan the SBOM for known vulnerabilities
grype sbom:sbom.cdx.json --fail-on=high
# The --fail-on flag exits non-zero
# when vulnerabilities at or above
# the specified severity are foundThe --fail-on=high flag makes this a gate in CI: if high-severity vulnerabilities are detected, the build fails. You can tune the threshold based on your risk appetite.
VEX: Documenting Risk Decisions
Not every CVE in your SBOM actually affects your application. A vulnerable library might be present but unused, or the vulnerable code path might not be reachable. VEX (Vulnerability Exploitability eXchange) documents lets you record these decisions in a machine-readable format that travels alongside the SBOM.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"vulnerabilities": [
{
"id": "CVE-2024-1234",
"source": {
"name": "NVD"
},
"analysis": {
"state": "not_affected",
"justification": "requires_dependency",
"response": ["will_not_fix"],
"detail": "Vulnerable function not called in application code"
}
}
]
}This VEX document asserts that CVE-2024-1234, while present in the dependency tree, does not affect your application because the vulnerable code path is never invoked. Scanners that understand VEX will skip this finding instead of flagging it as a false positive.
The Regulatory Landscape in 2026
SBOM adoption is no longer purely voluntary. The regulatory environment has shifted significantly:
- EU Cyber Resilience Act (CRA) — requires manufacturers of products with digital elements to provide an SBOM as part of technical documentation. Enforcement begins on a phased timeline through 2027.
- CISA 2026 Minimum Elements — the updated guidance, published in July 2026, expands the original NTIA minimum elements with richer data fields for component relationships, hash algorithms, and machine-processable formats.
- BSI TR-03183-2 — Germany’s Federal Office for Information Security has published technical guidelines requiring SBOMs for software used in critical infrastructure.
The CISA update is particularly noteworthy because it officially recognizes both CycloneDX and SPDX as compliant formats and introduces discussion of cloud and AI workloads that may warrant additional SBOM elements. This is a signal that SBOM requirements will expand beyond traditional application software into infrastructure-as-code templates and ML model artifacts.
Practical Recommendations
Building SBOM generation into your pipeline is straightforward. Making it actionable requires more thought:
- Generate at build time, not deploy time — the SBOM should reflect what was built, not what is running. Store it as a build artifact.
- Attach to releases — publish SBOMs alongside release artifacts so consumers can verify what they are installing.
- Scan continuously — new CVEs are published daily. An SBOM generated six months ago will miss vulnerabilities disclosed since. Set up recurring scans against your latest SBOM.
- Document exceptions with VEX — when a vulnerability is not applicable, record why. This reduces alert fatigue and creates an audit trail.
- Version your SBOMs — tag each SBOM with the build commit, image digest, and version tag. An SBOM without provenance is just data.
Wrapping Up
SBOMs have crossed the threshold from nice-to-have to regulatory requirement. The tooling is mature, the standards are stable, and the CI/CD integration patterns are well established. Teams that start generating and scanning SBOMs now will be ahead of the compliance curve, but more importantly, they will catch supply chain vulnerabilities before they reach production rather than during an incident response.