SBOM generation in CI/CD pipelines - which tools are you actually using in production?

DevOps & Infra
, , ,
1

I’ve been getting more pressure from our security team (and a few enterprise customers) to ship SBOMs with every release. The US executive order stuff from a couple years ago seemed like it might fade away, but if anything the requirements have gotten stricter. A lot of our customers now require SBOM attestations before they’ll even evaluate our product.

The problem is that the tooling landscape is kind of overwhelming right now, and I’m having trouble figuring out what actually works at scale in a real CI/CD pipeline versus what just looks good in a blog post.

Here’s our setup: we ship a mix of Go microservices and a Node.js frontend, all containerized and deployed to EKS via ArgoCD. Our CI runs in GitHub Actions. Right now we have zero SBOM generation, so I’m starting from scratch.

The specific things I’m trying to figure out:

  1. SBOM format: CycloneDX vs SPDX. I know SPDX is the ISO standard now, but CycloneDX seems more developer-friendly and has better tooling support. Is anyone using one and wishing they’d picked the other?

  2. Generation tools: I’ve been looking at Syft (from Anchore) for container image SBOMs and Trivy for vulnerability scanning on top of that. But I’ve also seen people mention cdxgen for CycloneDX generation and spdx-sbom-generator for SPDX. For those of you running this in CI, what’s the actual GitHub Actions step look like? Something like:

# is this the right approach?
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE_TAG }}
    format: cyclonedx-json
    output-file: sbom.cdx.json

- name: Attest SBOM
  uses: actions/attest-build-provenance@v2
  with:
    subject-path: sbom.cdx.json

  1. SLSA provenance: GitHub now has native SLSA Level 3 support for Actions, but the docs are kind of sparse on how to combine SBOM attestation with SLSA provenance attestation into a single verifiable bundle. Is anyone doing both, or is SLSA overkill for most teams?

  2. Storage and distribution: Once you’ve got the SBOM, where do you put it? OCI registry alongside the image? Separate artifact store? We need customers to be able to pull the SBOM for any version they’re running.

  3. The Go vs Node.js gap: Go’s dependency tree is pretty clean since everything compiles to a single binary, so SBOM generation is straightforward. Node.js with its node_modules black hole is a different story. Anyone have tips for getting accurate, non-gigantic SBOMs out of a Node project?

I feel like the supply chain security space has matured a lot in the last year or so, but I’m still not finding great “here’s what we actually run in prod” write-ups. Would love to hear what’s working for people.

Seed content posted by the DevForums team to help get our community started. Have a better answer? Jump in!