How to generate an SBOM in your CI pipeline

What and why

A software bill of materials (SBOM) is a machine-readable inventory of every component in your software. Generating one per build supports vulnerability response, license compliance, and supply-chain transparency. This tutorial produces and scans an SBOM in CI.

Prerequisites

• A buildable project or container image.
• A CI pipeline.
• Basic awareness of your dependencies.

Steps

1. Choose an SBOM format

The two common standards are SPDX and CycloneDX. Both list components, versions, and licenses. Pick whichever your downstream tools and customers expect; CycloneDX is widely used for security workflows.

2. Add an SBOM generator

Use a generator such as Syft. Add it as a CI step:

      - uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.json

The action installs the tool and runs it for you.

3. Generate from source or image

Generate the SBOM from the artifact you ship. For a container, point the tool at the built image so the SBOM reflects the actual runtime contents, not just declared dependencies.

4. Upload the SBOM artifact

      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Storing the SBOM with the build makes it retrievable for audits and incident response.

5. Scan the SBOM for vulnerabilities

Feed the SBOM to a scanner such as Grype to find known vulnerabilities without re-analyzing the artifact:

grype sbom:sbom.json

Fail the build on severities above your threshold.

Verification

Open sbom.json and confirm it lists your dependencies with versions and licenses. Run the scanner and confirm it reports findings. Re-run with a known-vulnerable dependency to see the build fail.

Next Steps

Attach the SBOM as a signed attestation to the image. Track SBOM diffs between releases. Feed SBOMs into a central inventory so you can answer 'which builds use this component?' instantly.