How to Generate an SBOM for Container Workflows

If you’re deploying containers at any scale, you’ve probably encountered security audits asking for a complete list of what’s inside your images. That’s where SBOMs come in. A Software Bill of Materials (SBOM) is essentially an inventory of all dependencies, libraries, and packages bundled into your container image. Think of it like a nutrition label for your software—it tells you exactly what ingredients are present. As container security becomes a core requirement for compliance frameworks like SLSA and regulations such as the Executive Order on Cybersecurity, understanding how to generate and integrate SBOMs into your CI/CD pipeline is becoming a table-stakes skill for DevOps and platform engineers.

SBOMs can be generated at two different points in your workflow, each with tradeoffs worth understanding. Build-time generation happens during the Docker build process—tools scan the Dockerfile layers and assembled image before you push it anywhere, catching supply chain issues early. Post-build generation happens after your image is already built and stored in a registry, using tools that analyze the final artifact without needing rebuild access. Build-time approaches give you tighter feedback loops and can fail builds immediately, but require integrating tooling into your Dockerfile or build scripts. Post-build approaches are more flexible and don’t require build process changes, but they’re slightly slower and come after the image is already tagged and distributed. For most teams, a hybrid approach works best: run a quick scan at build time for immediate feedback, then generate a detailed SBOM in your registry as a final quality gate.

The technical side is more approachable than you might expect. Tools like Syft (from Anchore) and Trivy (from Aqua) read your container image layers, analyze package managers (pip, npm, apt, yum), and extract version information—they’re essentially reverse-engineering what got installed. You can integrate them into Docker builds with a simple step: RUN syft . -o cyclonedx > sbom.json (CycloneDX and SPDX are the two major SBOM formats). If you’re using CI/CD systems like GitHub Actions or GitLab CI, you’d typically generate the SBOM as a build artifact or push it to your artifact registry metadata. For teams already running on AWS, you can integrate with ECR image scanning or use third-party tools that post SBOM data to S3 or a compliance database for audit trails. The output is machine-readable JSON or XML, so automation can validate it (checking for known-vulnerable packages, enforcing approved licenses) without human review every time.

Practically speaking, SBOMs solve real compliance and incident-response problems. If a critical vulnerability is discovered in a dependency like Log4j, you need to know instantly which of your 500 deployed services are actually affected—an SBOM gives you that answer in seconds rather than days of manual auditing. Teams building regulated systems (fintech, healthcare) are often required to prove they know what they’re shipping. But even if compliance isn’t your driver, SBOMs help with cost optimization (identifying bloated base images), license compliance (catching GPL dependencies you didn’t intend to include), and faster incident response. Start by adding one SBOM generation step to your existing CI/CD pipeline—pick Syft or Trivy (both are free, production-ready, and easy to run), store the output alongside your image, and you’ve solved the “what’s in my container” problem. As your container practices mature, you can layer on policy enforcement (blocking images that contain high-severity CVEs) and audit trails for compliance.