Generating an SBOM for a DevContainer Image
When a CVE lands, you need to know instantly whether your dev image is affected. This page generates a Software Bill of Materials (SBOM) for the pinned image with syft and stores it, turning vulnerability response from a rebuild-and-scan into a fast query.
Prerequisites
You need syft and the pinned image to inventory.
syftinstalled (or an SBOM action in CI).- The digest-pinned image reference.
- A place to store the SBOM artifact.
Step-by-Step Implementation
- Generate the SBOM from the pinned image.
syft mcr.microsoft.com/devcontainers/base@sha256:PINNED -o spdx-json > sbom.spdx.json
- Generate it in CI and attach it to the build.
- run: syft $IMAGE -o cyclonedx-json > sbom.cdx.json
- uses: actions/upload-artifact@v4
with: { name: sbom, path: sbom.cdx.json }
- Query it when a CVE lands.
grep -i "openssl" sbom.spdx.json # affected? which version?
- Regenerate whenever you refresh the pinned digest.
Common Pitfalls
SBOM gaps are none generated, or generated from a tag not a digest.
| Symptom | Root Cause | Remediation |
|---|---|---|
| Can't tell if a CVE affects us | No SBOM | Generate one with syft per build |
| SBOM doesn't match the image | Generated from a tag | Generate from the pinned digest |
| SBOM lost after the build | Not stored | Upload it as a build artifact |
| SBOM stale after a bump | Not regenerated | Regenerate on each digest refresh |
Conclusion
An SBOM makes vulnerability response a query, not an investigation. Generate it with syft from the pinned digest, store it alongside the image, and regenerate it whenever you refresh the pin — then answering 'are we affected by CVE-X?' takes seconds.
FAQ
What is an SBOM and why generate one for a dev image? A Software Bill of Materials is a machine-readable inventory of every package in an image. For a dev image, it lets you answer 'are we affected by this CVE?' instantly by querying the SBOM, instead of rebuilding and re-scanning each project when a vulnerability is announced.
Which format should I use, SPDX or CycloneDX? Either works; both are widely supported. SPDX is common for license/compliance workflows and CycloneDX for security tooling. syft emits both — pick the one your downstream tools consume, and be consistent across images.
When should I regenerate the SBOM? On every build, and specifically whenever you refresh the pinned base digest, since the package set changes. Store it as a build artifact next to the image so the SBOM always describes the exact bytes you shipped.
Related
- Up to Container Registry Best Practices for Dev Images — the overview of image strategy.
- Scanning DevContainer Images for Vulnerabilities — the scanning companion.
- Pinning Base Image Digests with sha256 — the digest the SBOM describes.