SBOM in CI/CD: produce an inventory from the software you ship
Generate the SBOM from the build you distribute, give it the same release identity as the product, and retain the generation command and tool version. An inventory is useful only when its coverage and omissions are understood.
Start with the build inputs
An SBOM describes software components and their relationships. CycloneDX is one established machine-readable format. The engineering task is to make the inventory correspond to a release, rather than a developer’s current workstation.
Gather lockfiles, package manifests, container images, firmware components and supplier inventories as appropriate. Record which inputs the chosen generator can inspect. A dependency lockfile alone may omit bundled native libraries or proprietary firmware components.
A pipeline design your team can reproduce
- Build from an identified commit and pinned dependency inputs.
- Run a generator that supports the relevant package or image ecosystem.
- Validate the output format and confirm expected first-party and third-party components are present.
- Attach the product version, commit and build identity to the inventory.
- Store the inventory, tool version and generation command with the release artefacts.
- Re-run the process on a clean worker and compare the result.
Make limitations visible
Treat an empty or unexpectedly small inventory as a failed check, not a successful green pipeline. Define simple coverage expectations for the product: for example, whether the distributed container’s operating-system packages and application dependencies are both included.
Keep a short exclusions record. If a supplier component cannot be inspected, identify its owner and the evidence you are requesting. Do not label unknown components as safe simply because the scanner returned no findings.
Connect the inventory to vulnerability work
The SBOM is an input to triage. A finding still needs investigation: is the component present in the shipped version, is the affected functionality reachable, and what mitigation or update is appropriate? Preserve the reasoning alongside the issue.
Use separate acceptance criteria for generating the inventory, monitoring findings and completing remediation. This avoids confusing a working scanner with a working security process.
What the first assessment can deliver
For the agreed build, Dotgrey Continent produces a first SBOM and a reusable generation command. Wider CI integration, multiple build variants, supplier coverage and ongoing monitoring are scoped explicitly for implementation.
Bring the repository, a reproducible build description and the release packaging details. If the build cannot run in the available environment, resolve that dependency at kickoff instead of hiding it behind an inventory file.
Official sources and references
The suggested workflows are Dotgrey engineering recommendations. Official texts determine obligations; applicability must be checked for each product.