June 24, 2026 update: Docker published fresh SBOM guidance for teams that build and ship container images. An SBOM, or software bill of materials, is the inventory that tells you which packages, libraries, base image layers, and dependencies are inside an image before it becomes a production risk.
For small hosting teams, agencies, SaaS operators, and ecommerce developers, the practical value is simple: when a new vulnerability lands, you can search real image inventories instead of guessing which Dockerfiles, base images, and services might be exposed.
Who This Helps
- Agencies deploying WordPress, WooCommerce, Laravel, Node, or Python projects in containers.
- Hosting teams that maintain customer workloads, internal control panels, backup jobs, or edge services with Docker or Kubernetes.
- SaaS teams that need vulnerability evidence for customers, cyber insurance, vendor reviews, or compliance checks.
- Developers moving from informal Docker builds to signed images, image scanning, and release approvals.
What To Include In The SBOM Workflow
- Generate an SBOM for each release image. Treat the SBOM as part of the release artifact, not an afterthought created only during an incident.
- Keep image identity attached. Record the image name, tag, digest, build date, source repository, base image, and environment where the image is allowed to run.
- Use a standard format. SPDX and CycloneDX are the common formats most security tools, customer reviewers, and compliance workflows understand.
- Connect scanning to the SBOM. Pair the inventory with Docker Scout or another maintained vulnerability scanner so dependency findings can be tied back to actual images.
- Review base images first. Outdated base images are often the fastest way for old packages to follow every application rebuild into production.
- Keep SBOMs with release evidence. Store them where the team can retrieve them during rollback, customer review, incident response, or renewal questionnaires.
Safe Rollout Checklist
- Start with staging. Generate SBOMs for staging images first, then compare the output against production images to spot drift.
- Define a release gate. Decide which severity levels block deployment, which findings require an exception, and who can approve that exception.
- Check rebuild behavior. Confirm that rebuilding from the same source does not quietly pull a different base image or package set without review.
- Document exceptions. If a finding is not exploitable in your configuration or is waiting for an upstream fix, record the reason, owner, and review date.
- Verify after deployment. Confirm the running image digest matches the reviewed image, then keep the SBOM with the deployment record.
Where This Fits With Docker Content Trust
SBOMs do not replace image signing. Signing helps prove where an image came from and whether it changed. SBOMs explain what is inside that image. If your team is already reviewing Docker Content Trust changes, pair that migration with SBOM generation and image scanning so your release process checks both identity and inventory.
Fix I.T. Phill has a related guide here: Docker Content Trust Retirement: Migration Checklist for CI and Kubernetes.
What To Avoid
- Do not generate SBOMs once and let them go stale.
- Do not store SBOMs where only one developer can find them.
- Do not rely on image tags alone; keep digests and release dates with the SBOM.
- Do not treat a clean scan today as proof that the same image will stay clean after tomorrow’s advisory.
- Do not skip customer communication planning if your team hosts regulated, ecommerce, healthcare, nonprofit, or enterprise workloads.
Good First Implementation
Pick one actively maintained application image, generate an SBOM with Docker Scout or an equivalent maintained tool, store it next to the release record, and scan it before the next production deploy. Once that works, add the same review to base images, scheduled rebuilds, CI releases, and Kubernetes rollouts.
Sources
- Docker: What is an SBOM?
- Docker Scout documentation: view and create SBOMs
- CISA: Minimum Elements for a Software Bill of Materials
- NIST Secure Software Development Framework SP 800-218
Need help turning container review into a repeatable release process? Fix I.T. Phill can help set up image inventory, backup planning, staging checks, deployment records, and vulnerability review workflows that fit the way your team actually ships.