Day 83: SBOM and signing
Proving what's in your image, and that it's really yours
A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of every component (and its exact version) in a built artifact — every dependency, every OS package, every layer. When a new CVE is announced, an SBOM lets you answer "are we affected, and where?" instantly across every image you've ever shipped, instead of re-scanning everything from scratch.
syft myregistry/api:${{ github.sha }} -o cyclonedx-json > sbom.jsonSigning
An SBOM tells you what's in an image; signing proves the image itself hasn't been tampered with since your pipeline built it, and really came from your pipeline. cosign signs an image using a key pair (or, more commonly now, short-lived 'keyless' signing tied to your CI identity), and anyone can later verify the signature before deploying.
cosign sign myregistry/api:${{ github.sha }}
# Later, before deploying:
cosign verify myregistry/api:${{ github.sha }}This is supply chain security, concretely
SBOM + signing together answer two different questions: 'what exactly is in this image?' and 'do I trust that this image really came from our pipeline, unmodified?' Both matter independently — Phase 26's SLSA framework formalizes exactly this kind of provenance guarantee.
Key terms
- SBOM
- A complete inventory of every component and version in a built artifact.
- Image signing (cosign)
- Cryptographically proving an image's authenticity and integrity.
A critical CVE is announced in a library. Why is having SBOMs for all your past images valuable right now?
