In what order should you set up SBOM management in CI/CD?

Set up SBOM management in CI/CD in this order: pick a format, generate an SBOM for every build, store it with the build, match it to vulnerability data, add a gate only after you trust the results, then share SBOMs and VEX with customers. Gating first creates noise and gets switched off.

Step 1: Choose the format and fields

Pick SPDX or CycloneDX based on what your customers and tools accept. CycloneDX is published as ECMA-424 and also covers hardware, services and VEX (CycloneDX). Decide the fields you want, using the CISA minimum elements as a guide, noting that CISA published a draft update in August 2025 and lists a newer 2026 edition on its resources page (CISA).

Step 2: Generate on one pipeline

Choose one representative service. Add a build step that generates the SBOM from the resolved dependencies, ideally from the lockfile or the built artifact rather than the manifest alone. Run it on every build, not nightly, so each release has its own record.

Check the output against what you know: do transitive dependencies appear, and do container layers if you ship images? Our CLI generates SBOMs and supports many package managers, so that is one way to do this step; any generator that meets your checks works.

Step 3: Store with the build

Attach the SBOM to the build artifact, or push it to a store keyed by service, version and build ID. The goal is to answer, months later, which releases contained a given library. If you cannot query it, you have files, not management.

Step 4: Match to advisories

Now compare stored SBOMs to vulnerability data, including advisories for new flaws published after the build. This is where an SBOM earns its keep: a new advisory appears, and you list affected releases in minutes.

Report only. Do not block anything yet. Read the findings for a few weeks and note which are noise.

Step 5: Add reachability and context

Raw matches overwhelm teams. Add reachability analysis, which checks whether your code calls the vulnerable function, and exposure context. See the interactive demo below for what the output looks like.

Step 6: Gate

Once findings are credible, add a gate with a narrow rule: block new critical findings that are reachable and have a fix available. Keep an allow list with reasons and expiry dates. Widen the rule over time.

Step 7: Share

Send SBOMs to customers who ask, with VEX statements that say which listed vulnerabilities do not affect the product. CISA describes VEX as an attestation that says whether a product is affected by a known vulnerability (CISA).

Open the full walkthrough at /demos/ci-cd-actions.

How do you prove it works?

Pick a library you know is in one service. Ask the store which releases contain it, and compare the answer with the repository history. If the two agree, the pipeline is trustworthy. If they differ, find out why before you roll it out wider.

What if builds get slower?

Generate from the lockfile or the built image, which is quick, and run matching as a separate job so it does not block the build. Cache vulnerability data between runs. If a step still adds minutes, run it in parallel with tests rather than skipping it.

What to do

1. Choose SPDX or CycloneDX and list required fields.
2. Add SBOM generation to one pipeline and verify the output by hand.
3. Store each SBOM by service, version and build ID.
4. Match SBOMs to advisories in report only mode.
5. Add reachability and exposure context.
6. Turn on a narrow gate with an expiring allow list.
7. Roll out to other pipelines, then share SBOMs and VEX.

Quick check

Sources

• CycloneDX specification overview
• CISA SBOM
• CISA 2025 minimum elements (draft)

Last reviewed: 18 October 2026.