You cannot secure what you cannot see. This principle is the foundation of every security program, and container images are no exception. The software bill of materials — the complete inventory of what is installed in a container image — is the prerequisite to every security decision you make about that image.
But SBOMs have a precision problem that most security teams have not fully reckoned with, and that problem gets worse as they try to use SBOM data to satisfy compliance requirements.
What a Static SBOM Tells You?
A software bill of materials generated from a container image at build time tells you what was installed in the image. Tools like Syft, Trivy, or CycloneDX generators can extract this inventory: package names, versions, licenses, and the CVEs associated with each package.
This inventory is useful. It is the starting point for CVE assessment. It enables license compliance review. It provides the component list that supply chain security programs require.
But static SBOMs have a fundamental limitation: they describe what was installed, not what is used.
A container image with 400 installed packages has a 400-package SBOM. Of those 400 packages, the application may use 50. The SBOM does not tell you which 50. It lists all 400 with equal weight.
“A 400-package SBOM is technically accurate. It is also operationally useless for prioritization. When everything has equal weight, nothing gets prioritized.”
The Staleness Problem
Static SBOMs generated at build time become stale immediately. The moment a base image update is pulled, the SBOM changes. The moment a dependency is updated, the SBOM changes.
For compliance programs that require continuous component inventory, a build-time SBOM requires a process to ensure it is regenerated and retained for every image change. This is operationally manageable in a good CI/CD pipeline but requires active maintenance.
More fundamentally: a SBOM generated from an image does not reflect what is running in production if the running image differs from the built image. Runtime drift — modifications to containers after deployment — creates a gap between the SBOM and the actual production state.
This gap is where software supply chain security requires a different approach.
The Runtime Bill of Materials
A runtime BOM captures what is actually executing in a container, not just what is installed. The distinction:
Static SBOM (installed): Package X, version 1.2.3 is present in the image filesystem.
Runtime BOM (executing): Package X, version 1.2.3 was loaded and called during observed execution of the application.
The runtime BOM provides a more accurate security baseline:
For CVE prioritization: A CVE in a package that appears in the runtime BOM is in actively executing code. A CVE in a package that appears in the static SBOM but not the runtime BOM is in code that was installed but not called during observed execution.
For compliance evidence: Regulators and auditors asking “what software components are present in your production systems” are best answered with the runtime BOM — the components that are actually executing, not the full installed footprint that includes packages with no runtime role.
For supply chain assurance: If a compromised package appears in the runtime BOM, it is being executed. If it appears only in the static SBOM, it may or may not have active code running.
Building an Accurate SBOM Through Hardening
The cleanest approach to SBOM accuracy is to ensure that the static SBOM and the runtime BOM converge: remove packages that do not execute, so every package in the image is a package that the application needs.
Container image tool capabilities that perform runtime profiling and automated component removal produce a hardened image where the installed package list matches the executed package list. The static SBOM of a hardened image is an accurate representation of what executes in production because unused packages have been removed.
This convergence has compliance implications: the SBOM is both complete (every installed package listed) and accurate (every listed package is actually used). When an auditor asks for the component inventory, the hardened image SBOM is the answer. There is no gap between what the SBOM says and what is executing.
SBOM Formats and Regulatory Requirements
The regulatory landscape for SBOMs is becoming more specific. Executive Order 14028 (US Cybersecurity EO) established SBOM as a requirement for software sold to the federal government. FDA has issued guidance on SBOMs for medical devices. NTIA has published minimum element requirements.
The formats that satisfy regulatory requirements:
SPDX (Software Package Data Exchange): An OASIS standard with broad tooling support. Satisfies NTIA minimum elements and is accepted by federal procurement requirements.
CycloneDX: OWASP-developed format with strong integration into the security tooling ecosystem. Well-supported for vulnerability assessment workflows.
Both formats can represent static SBOMs (installed packages) and can be extended to represent runtime execution information when tooling supports it.
For organizations subject to SBOM regulatory requirements, the technical requirements are:
- Complete inventory of all components
- Component version information
- Dependency relationships between components
- A timestamp indicating when the SBOM was generated
A hardened image with automated SBOM generation in the pipeline satisfies all these requirements with inherent consistency: every image has an SBOM generated at build time, in a standard format, with complete component information.
Frequently Asked Questions
What is the purpose of a software bill of materials (SBOM) for container image security?
An SBOM provides a complete inventory of every package, library, and dependency installed in a container image, along with their versions and known CVEs. For container image security, this inventory is the prerequisite to every security decision: you cannot scan for vulnerabilities, assess compliance, or respond to new CVE disclosures without knowing what components are present. The SBOM enables CVE triage, license compliance review, and rapid impact assessment when vulnerabilities are disclosed against specific packages.
Why is container image security important for compliance programs?
Container image security is central to compliance because regulators and auditors increasingly require documented evidence of what software components are present in production systems and what vulnerabilities they carry. Frameworks like Executive Order 14028 and FDA medical device guidance explicitly require SBOMs. A hardened container image with automated SBOM generation in the pipeline provides continuous, consistent compliance evidence — every image has an SBOM generated at build time, in SPDX or CycloneDX format, with complete component information.
Is an SBOM legally required for container images?
SBOM requirements are becoming legally mandated in specific contexts. US Executive Order 14028 established SBOM as a requirement for software sold to the federal government. The FDA has issued guidance requiring SBOMs for medical device software. The NTIA has published minimum element requirements that define what a compliant SBOM must contain. Organizations outside these regulated sectors are not currently legally required to produce SBOMs, but the regulatory trend is toward broader requirements, and producing SBOMs is increasingly a procurement requirement from enterprise buyers.
What is the difference between a static SBOM and a runtime bill of materials for container security?
A static SBOM lists all packages installed in a container image — it is generated at build time and describes what is present on disk. A runtime bill of materials (runtime BOM) captures which packages are actually loaded and executed during real application operation. The distinction matters for CVE prioritization: a CVE in a package that appears in the runtime BOM is in actively executing code, while a CVE in a package that appears only in the static SBOM may be in code that was installed but never called. Hardening a container image to remove unused packages causes the static SBOM and runtime BOM to converge.
The SBOM as a Security Decision Tool
The SBOM becomes operationally useful when it is treated as a living security artifact rather than a compliance checkbox:
CVE triage input: When new CVEs are disclosed, query your SBOM database to identify which images contain the affected package. The SBOM enables rapid impact assessment.
Incident response support: When an incident involves a container, the SBOM tells you every component present that might have contributed to the compromise.
Vendor assessment: When evaluating vendor-supplied container images, extract their SBOM and assess it against your CVE threshold and policy requirements before deployment.
License compliance: The SBOM enables automated license review to catch copyleft licenses or license conflicts before they reach production.
SBOM generation is the starting point. The security value comes from using the SBOM data continuously — for CVE tracking, policy enforcement, and decision support. A SBOM that is generated and filed is an audit artifact. A SBOM that is queried and acted on is a security tool.
