SBOM Generation in CI/CD: A Complete Integration Guide for DevOps Teams

Generating an SBOM manually, on demand, when someone asks for it, is compliance theater. The value of SBOM comes from automation — generating an accurate, up-to-date inventory on every build, automatically cross-referencing it against vulnerability databases, and alerting immediately when new risks are introduced. This guide covers the practical integration of SBOM generation into your CI/CD pipeline.

Choosing Your Generation Tool

For open source SBOM generation in CI/CD, two tools dominate: Syft (by Anchore) and Trivy (by Aqua Security). Syft is purpose-built for SBOM generation, supports both SPDX and CycloneDX output, and has excellent ecosystem coverage. Trivy is a broader security scanner that includes SBOM generation alongside vulnerability scanning and secrets detection — making it a strong choice if you want a single tool for multiple security functions.

GitHub Actions Integration

name: SBOM Generation
on: [push]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Syft
        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
      - name: Generate SBOM
        run: syft . -o cyclonedx-json=sbom.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Vulnerability Scanning the SBOM

After generating the SBOM, scan it for vulnerabilities using Grype (Anchore's companion vulnerability scanner) or Trivy:

- name: Scan SBOM for vulnerabilities
  run: |
    curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
    grype sbom:sbom.json --fail-on high

The --fail-on high flag causes the build to fail if any high or critical severity vulnerabilities are found — creating a quality gate that prevents vulnerable software from being deployed.

SBOM Storage and Attestation

SBOMs should be stored alongside the build artifacts they describe — not as standalone documents that may get out of sync with the software. For container images, the standard approach is to attach the SBOM as an OCI attestation using Cosign. For package artifacts, storing the SBOM as a build artifact in your artifact repository (Nexus, Artifactory, JFrog) keeps it co-located with the artifact. Always include the build timestamp and commit SHA in the SBOM metadata so it can be traced back to a specific build.

// Recommended Tool

Production-Ready SBOM Generation with Fossity

Fossity — Fossity provides CI/CD-native SBOM generation with native integrations for GitHub Actions, GitLab CI, and Jenkins — plus centralized SBOM management, policy enforcement, and vulnerability monitoring at scale. Upgrade from scripts to a managed platform.

Visit Fossity.com →
// Author: Esteban C.