The executive order on cybersecurity put SBOMs on every CISO's radar. But two years later, most organizations are still struggling with the basics. They can generate an SBOM for a single container image if pressed, but they have no strategy for doing it consistently across hundreds of microservices, serverless functions, and infrastructure components.
The problem is not tooling. The tools are good enough. The problem is strategy -- knowing where to generate SBOMs, what format to use, how to store them, and most importantly, how to make them useful for security decisions.
Why Most SBOM Efforts Fail
The typical SBOM initiative goes like this: someone reads about the executive order, installs Syft or Trivy on a developer's laptop, generates an SBOM for one container image, exports it as a JSON file, and declares victory in a slide deck.
Three months later, nobody knows where that JSON file is. Nobody is generating SBOMs for new builds. The SBOM program exists on paper and nowhere else.
This happens because SBOM generation was treated as a one-time activity instead of an integrated part of the software delivery pipeline. A useful SBOM strategy requires automation, consistency, and a clear plan for what you do with the data.
Choosing Your SBOM Format
Two formats dominate the cloud-native space: CycloneDX and SPDX. Both are machine-readable, both support the data fields you need, and both have active communities. Here is how to choose.
CycloneDX was designed specifically for security use cases. It has first-class support for vulnerability data, service definitions, and dependency relationships. If your primary use case is security analysis and vulnerability management, CycloneDX is the more natural fit. It is also the format that most security tools prefer to consume.
SPDX has a longer history and broader scope. It was originally designed for license compliance and has been adopted as an ISO standard. If your organization has significant open-source license compliance requirements, SPDX covers that ground more thoroughly.
My recommendation: pick CycloneDX unless you have a specific reason to use SPDX. For security-focused SBOM programs, CycloneDX is more straightforward and better supported by the tools you will be integrating with.
Standardize on one format. Using both formats across different teams creates a translation problem that wastes time and introduces errors. Pick one and enforce it organization-wide.
Where to Generate SBOMs
In a cloud-native environment, you have multiple points where SBOMs can be generated. Each has trade-offs.
Build-Time Generation
This is the most common approach and should be your baseline. Generate an SBOM as part of your CI/CD pipeline, right after the build step completes.
For container images, tools like Syft and Trivy can analyze the final image and produce a comprehensive SBOM that includes OS packages, language-specific dependencies, and binary artifacts. For language-specific builds (npm, pip, Maven), these tools can analyze the lock files and produce SBOMs without needing a container image.
The advantage of build-time generation is that you have full context about the build environment. You know exactly what went into the artifact because you just built it.
The disadvantage is that build-time SBOMs are static. They reflect the state of the artifact at build time, not at runtime. If your container starts downloading additional packages at startup (which it should not, but let us be realistic), the build-time SBOM will not capture them.
Registry-Time Generation
Some container registries can generate or store SBOMs when an image is pushed. ECR, Artifact Registry, and Harbor all support some form of SBOM integration.
This approach catches images that were built outside your CI/CD pipeline -- developer builds, third-party images, and base images pulled from public registries. It is a good complement to build-time generation but should not replace it.
Runtime Analysis
Runtime SBOM generation uses agents or eBPF probes to observe what packages are actually loaded by running containers. This captures the ground truth of what is executing in production.
Tools like KubeClarity and CAST AI can perform runtime SBOM analysis in Kubernetes environments. This is valuable for validating your build-time SBOMs and catching drift, but it adds operational complexity and performance overhead.
Use all three layers. Build-time for coverage, registry-time for catching gaps, and runtime for validation. The overlap is intentional and useful.
Container Image SBOM Strategy
Container images are the most common artifact type in cloud-native environments and the most critical to get right.
Scan the final image, not just the Dockerfile. A Dockerfile tells you what packages were installed, but multi-stage builds, base image contents, and post-install scripts mean the final image may contain more (or fewer) packages than the Dockerfile suggests. Always generate SBOMs from the built image.
Include base image information. Your SBOM should record which base image was used. When a vulnerability is found in ubuntu:22.04, you need to quickly identify every image in your organization that inherits from it.
Handle multi-architecture images. If you build multi-arch images (linux/amd64, linux/arm64), generate separate SBOMs for each architecture. The package sets can differ between architectures.
Track image-to-deployment mapping. An SBOM for an image that is not deployed anywhere is low priority. An SBOM for an image running in production on customer-facing infrastructure is critical. You need a system that connects image SBOMs to deployment context.
Serverless and Function SBOMs
Serverless functions are often overlooked in SBOM strategies because they do not produce container images. But they have dependencies too.
Generate SBOMs from deployment packages. AWS Lambda deployment packages, Azure Functions bundles, and GCP Cloud Functions archives all contain dependencies that should be tracked. Run your SBOM tool against the deployment artifact before uploading it.
Include runtime information. Serverless runtimes provide a base set of libraries. Your SBOM should note the runtime and version (Node.js 18, Python 3.11, etc.) because vulnerabilities in the runtime affect your function.
Track Lambda layers separately. If you use Lambda layers, generate SBOMs for each layer independently. Layers can be shared across functions, so a vulnerability in a layer has a wider blast radius.
Infrastructure-as-Code SBOMs
Your Terraform modules, Helm charts, and Kubernetes manifests have dependencies too. They reference specific provider versions, chart versions, and container images.
Generate SBOMs for Terraform configurations. Track which provider versions and module versions your infrastructure depends on. When a vulnerability is found in the AWS Terraform provider, you need to know which configurations are affected.
Track Helm chart dependencies. Helm charts can reference other charts as dependencies. Your SBOM should capture this dependency tree.
SBOM Storage and Distribution
Generating SBOMs is only half the battle. You need to store them in a way that makes them accessible and useful.
Store SBOMs alongside artifacts. The SBOM for a container image should be stored in the same registry, attached to the image using OCI artifacts or cosign attestations. This ensures the SBOM travels with the artifact.
Maintain a central SBOM database. In addition to storing SBOMs with artifacts, maintain a searchable database of all SBOMs. When a new CVE drops, you need to query across all SBOMs to find affected deployments. A collection of JSON files in S3 will not cut it.
Version your SBOMs. An SBOM is a snapshot in time. As you rebuild artifacts, store the new SBOM alongside the old one. You may need historical SBOMs for incident investigation or compliance audits.
Making SBOMs Actionable
The real value of SBOMs is in the actions they enable.
Automated vulnerability correlation. When a new CVE is published, automatically cross-reference it against your SBOM database to identify affected artifacts and deployments. This turns a vulnerability disclosure from "we need to check everything" into "here are the five services affected."
License compliance checking. SBOMs contain license information for every component. Automate license policy checks to catch copyleft or restricted licenses before they reach production.
Dependency freshness tracking. Use SBOMs to identify artifacts running outdated dependencies. A component that has not been updated in two years is likely accumulating vulnerability debt.
How Safeguard.sh Helps
Safeguard.sh automates the entire SBOM lifecycle for cloud-native environments. It generates SBOMs at build time through CI/CD integration, stores them in a searchable central database with full version history, and continuously correlates them against vulnerability data.
When a new CVE is disclosed, Safeguard.sh tells you within minutes which of your deployed services are affected, which environments they run in, and what the remediation path looks like. It turns SBOMs from a compliance artifact into an operational security tool that saves your team hours of manual investigation on every vulnerability disclosure.