Integrating SBOM Generation into Your CI/CD Pipeline
The CRA expects a current, machine-readable SBOM for every release. The only sustainable way to deliver that is to generate it automatically in your build pipeline. Here is how.
Why the SBOM Has to Live in the Pipeline
Under CRA Annex I Part II, manufacturers must maintain a machine-readable software bill of materials and keep it current throughout the support period. A hand-maintained SBOM in a spreadsheet is obsolete the moment a developer bumps a dependency. The only reliable approach is to generate the SBOM as an artefact of every build — the same way you already produce binaries and container images.
Done well, SBOM generation adds seconds to a build and gives you a versioned, auditable record of exactly what shipped in each release.
The Pipeline Pattern
A robust CRA-aligned pipeline has four stages layered onto your existing build:
1. Generate
Run an SBOM generator against your source, lockfiles, or built container image. Proven, widely used tools include:
- Syft — generates SPDX or CycloneDX from container images and filesystems
- cdxgen — broad language coverage, CycloneDX output
- Trivy — SBOM generation plus vulnerability scanning in one binary
- Package-manager-native options — the Maven CycloneDX plugin, or npm sbom
Prefer scanning the built artefact (container image or release bundle) over source alone, so the SBOM reflects what actually ships, including base-image components.
2. Attach and version
Store the SBOM as a build artefact tagged with the exact release version and commit SHA. For container images, attach it as an OCI referrer or SLSA attestation so the SBOM travels with the image. Keep historical SBOMs — market surveillance authorities can ask for the SBOM that corresponded to a specific version on sale at a specific time.
3. Sign
Sign the SBOM (for example with Sigstore cosign) so downstream consumers — and auditors — can verify it was produced by your pipeline and not tampered with. Provenance is increasingly expected by enterprise buyers.
4. Scan and gate
Feed the SBOM into a vulnerability matcher — Grype, Dependency-Track, or Trivy — cross-referencing components against NVD, OSV, and the EUVD. Configure a policy gate: fail the build, or raise a tracked issue, when a component carries a known-exploitable vulnerability above your threshold. This is what turns the SBOM from a document into a control.
Depth: Go Transitive
The CRA requires at least top-level dependencies, but serious vulnerabilities — Log4Shell is the textbook case — hide in transitive dependencies. Configure your generator for a full transitive SBOM. Modern tooling makes this the default rather than an expensive extra.
Essential Fields to Verify
Whatever tool you use, confirm each component record carries:
- Exact name and version (not a range)
- Package URL (PURL) — critical for accurate database matching
- Supplier and license
- A cryptographic hash (SHA-256 minimum)
- Dependency relationships
Feeding the SBOM Downstream
The SBOM is not just an internal artefact. Under the CRA you must be able to provide it to market surveillance authorities on request, and enterprise customers increasingly demand it at procurement. Publish a VEX (Vulnerability Exploitability eXchange) statement alongside it so consumers know which known CVEs actually affect your product — CycloneDX supports VEX natively.
The Payoff
Once SBOM generation is wired into CI/CD, three CRA obligations become almost automatic: you always have a current SBOM, you know within minutes when a new CVE affects a shipped component, and you can prove component-level detail during an Article 14 incident. The work is front-loaded into pipeline configuration once, then it runs on every commit.
Ready to assess your CRA compliance obligations?
Try the Free Applicability Checker