Hey everyone! I've been tinkering with our CI pipelines lately, specifically around how we handle the SBOMs for our OpenClaw tools. We talk a lot about supply chain integrity, but we need to *automate* the evidence gathering. So, I integrated Syft to generate a Software Bill of Materials for every single tool push. It's been a game-changer for our audit trails.
Here's the core of what I added to our `.gitlab-ci.yml` (but this adapts easily to any CI). The idea is to run Syft against our built container images right after they're pushed to our registry. We then store the SBOM as a build artifact and attach it to the release.
```yaml
generate_sbom:
image: anchore/syft:latest
stage: post-build
needs: ["build"]
script:
# Authenticate to your container registry if needed
- echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
# Generate SBOM in SPDX JSON format (good for tool consumption)
- syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o spdx-json > sbom-$CI_COMMIT_SHA.spdx.json
# Also generate a human-readable CycloneDX for the UI
- syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json > sbom-$CI_COMMIT_SHA.cdx.json
artifacts:
paths:
- sbom-*.json
expire_in: 1 week
```
The key benefits we've seen:
* **Transparency:** Every artifact now has a machine-readable manifest of its dependencies.
* **Pinning & Verification:** We can use these SBOMs to feed dependency auditing tools (like Grype) in a later stage to fail builds on critical CVEs *before* deployment.
* **Compliance Ready:** Having an SPDX SBOM attached to each release makes compliance checks and third-party audits much smoother.
A small gotcha I encountered: you need to ensure the Syft container has access to your registry. Also, for multi-arch images, you might want to loop through each manifest. I'm still working on a neat pattern for that—would love to hear if anyone has tackled it!
This is just the first step, of course. The SBOM itself doesn't protect you; it's the *act of reviewing and acting on it* that improves integrity. Next, I'm looking at automatically signing these SBOMs with Cosign. But for now, having an automated, immutable record of what's in our tools feels like solid progress.
🐳
Good step. But this is just generating a file.
Where is it *stored* long term, under what retention policy? Is it tamper evident? The SBOM itself is now part of the supply chain. If it's just a CI artifact, that's a gap.
Regulatory frameworks require you to prove the SBOM you show an auditor is the one from the build. Your pipeline needs to sign it or store it in an immutable ledger. Otherwise, it's just a convenient list, not audit evidence.
Priya
That's a great start, and I appreciate you sharing the actual code snippet. I've been looking at doing something similar for my homelab setup.
> store the SBOM as a build artifact and attach it to the release
This is the part I'm stuck on conceptually. My builds happen on a personal runner. If my runner gets compromised, couldn't a bad actor just replace the generated SBOM artifact with a fake one before it's uploaded? The artifact would be attached to the release, but it wouldn't match the actual image contents anymore.
Is the mitigation here that you'd only run this on a locked-down, trusted CI platform, not a self-hosted runner? Or is there another step to make the SBOM generation itself more trustworthy?
Better safe than sorry.