A Software Bill of Materials is an inventory. Specifically, it’s a machine-readable list of the components in a piece of software—the packages, libraries, and dependencies that make up an application or container image—with enough identifying information to check each component against CVE databases, license registries, and compliance frameworks.
The grocery analogy is common for a reason: if you know what’s in your software, you know what to check when a new vulnerability is disclosed. If you don’t know what’s in your software, vulnerability response requires examining every application individually every time a CVE is published. At scale, that’s not practical.
What an SBOM Actually Contains?
An SBOM document lists each component with identifying information:
- Supplier name: Who produced the component
- Component name: The package name
- Component version: Specific version string
- Unique identifier: Package URL (purl) or similar machine-readable identifier
- Dependency relationships: Which components depend on which other components
- SBOM author and timestamp: Who generated the SBOM and when
These fields are the minimum elements defined by NTIA guidance under EO 14028. An SBOM with all minimum elements populated is sufficient for compliance reporting and can be ingested by standard vulnerability management tools.
The format is standardized: CycloneDX (from OWASP, security-focused) and SPDX (from the Linux Foundation, license-compliance-focused) are both accepted by NIST and referenced in federal guidance. Both can be generated by the same tools and consumed by the same vulnerability management platforms.
Why Federal Guidance Now Requires SBOMs?
Executive Order 14028 (Improving the Nation’s Cybersecurity, May 2021) directed NIST to develop guidelines for software security practices for federal software vendors. NIST’s guidance, implemented through the NTIA minimum elements document, established SBOM requirements for software sold to federal agencies.
The requirement is now operational: companies selling software to the federal government are expected to provide SBOMs with their products. Federal procurement processes increasingly include SBOM as a requirement alongside security certifications and FedRAMP authorization.
The underlying reasoning is that SBOMs provide the visibility necessary for rapid vulnerability response. When Log4Shell was disclosed in December 2021, organizations with SBOMs for their software could identify affected systems in hours. Organizations without SBOMs spent days or weeks manually investigating which software used Log4j. The difference was consequential for remediation timelines.
Why Commercial Organizations Need SBOMs Too?
Federal requirements are the visible driver, but the underlying business case applies to commercial organizations:
Vendor SBOMs for procurement: Organizations buying software from vendors are increasingly requesting SBOMs as part of procurement. If a vendor’s software has a critical CVE in a component, the buyer needs to know whether they’re affected before the vendor communicates. An SBOM makes that independent verification possible.
Incident response speed: When a critical CVE is disclosed, having SBOMs for your software means you can query “which of our services includes this package?” in minutes. Without SBOMs, the answer requires scanning every service—which takes hours to days for large fleets.
License compliance: SBOMs make license auditing tractable. Knowing which open source packages are included in each product, with their license identifiers, enables legal review of copyleft license obligations and commercial license tracking.
Customer and partner requirements: Organizations in financial services, healthcare, and government contracting increasingly require SBOM documentation from software vendors as a security requirement. Having a repeatable SBOM generation process positions you to meet these requirements efficiently.
The Three Steps to Your First SBOM
Step 1: Generate an SBOM from a container image
For organizations running containerized software, the container image is the natural starting unit for SBOM generation. Tools like Syft (from Anchore), Trivy (from Aqua Security), and cdxgen generate SBOMs from container images with minimal configuration:
# Using Syft to generate a CycloneDX SBOM
syft your-container-image:tag -o cyclonedx-json > sbom.json
# Using Trivy to generate an SBOM
trivy image –format cyclonedx your-container-image:tag > sbom.json
The resulting SBOM is a JSON file listing all installed packages. This is a static SBOM—it reflects what’s installed in the image, not necessarily what executes during application operation.
Step 2: Validate the SBOM against CVE databases
Once the SBOM exists, existing vulnerability management tools can consume it. Grype (from Anchore) accepts SBOM files as input and returns CVE findings:
grype sbom:sbom.json
Many organizations already run CVE scanning; the SBOM provides a persistent, portable artifact that can be re-evaluated against current CVE databases without rescanning the image.
Step 3: Store and associate SBOMs with deployments
Software supply chain security programs that generate SBOMs as a one-time activity miss most of the value. The SBOM is most useful when it’s associated with the specific deployed version of the software—so that when a CVE is disclosed, you can query which deployed versions are affected.
OCI registry annotations can store SBOM references alongside container images. Attestation tools (cosign from Sigstore) can attach signed SBOMs to image digests, creating a cryptographic link between the image and its SBOM that can be verified at deployment time.
Secure software supply chain practices include storing SBOMs as part of the CI/CD pipeline output—generated at build time, signed, and stored in the registry alongside the image. This produces a current SBOM for every production image version automatically.
Static vs. Runtime SBOMs
The static SBOM generated from a container image lists what’s installed. A runtime SBOM—generated from execution profiling data—lists what executes during application operation. These are different inventories.
The difference matters for vulnerability management: a runtime SBOM narrows the CVE finding list to packages that actually execute, which is the population that represents actual exploitable exposure. Static SBOM findings include CVEs in packages that never load during application operation.
Organizations starting with SBOMs should begin with static SBOM generation—it’s achievable immediately with existing tooling—and evolve toward runtime-augmented SBOMs as the vulnerability program matures.
Frequently Asked Questions
What is an SBOM and what does it contain?
An SBOM, or Software Bill of Materials, is a machine-readable inventory of every component in a piece of software—the packages, libraries, and dependencies that make up an application or container image. Each entry includes the supplier name, component name, version, a unique identifier such as a package URL, dependency relationships, and authorship metadata. This structured inventory is the foundation for checking components against CVE databases, license registries, and compliance frameworks.
Why does your organization need an SBOM now?
Federal procurement under Executive Order 14028 now requires SBOMs from software vendors selling to government agencies, and commercial organizations face increasing SBOM requests from customers in financial services, healthcare, and government contracting. Beyond compliance, having an SBOM means that when a critical CVE is disclosed—like Log4Shell—you can identify every affected system in minutes instead of spending days manually investigating your entire software fleet.
What is the difference between a static SBOM and a runtime SBOM?
A static SBOM is generated from the container image and lists all installed packages regardless of whether they execute during application operation. A runtime SBOM is generated from execution profiling data and lists only the packages that actually load and run. The runtime SBOM produces a smaller, more accurate picture of actual exploitable exposure, since CVEs in packages that never execute cannot be reached through the application.
Which SBOM format should organizations choose—CycloneDX or SPDX?
Both CycloneDX and SPDX are accepted by NIST and referenced in federal guidance, and both can be generated by the same tools. CycloneDX, from OWASP, is better supported by security-focused vulnerability management tools and has broader adoption in the security community, making it the better default choice. SPDX has stronger tooling for license compliance use cases, so organizations with significant open source license obligations may find value in generating both formats.
Practical Steps for Getting Started
Prioritize container images in production first. The production container fleet is where SBOM coverage provides immediate security value. Start there, not with development or testing images.
Integrate SBOM generation into your CI pipeline. SBOM generation that runs manually is SBOM generation that doesn’t happen consistently. A CI stage that generates and stores the SBOM with every image build ensures coverage across the fleet.
Choose a format based on your tooling ecosystem. CycloneDX is better supported by security-focused vulnerability management tools; SPDX has stronger license compliance tooling. If in doubt, generate CycloneDX—it has broader adoption in the security community.
Communicate your SBOM practice to customers and auditors. Being able to say “we generate and store SBOMs for all production software, and can provide them upon request” is a meaningful security posture statement that increasingly matters in procurement and audit contexts.
The SBOM doesn’t need to be perfect on the first iteration. A generated, validated, stored SBOM that’s imperfect is infinitely more useful than no SBOM when a critical vulnerability is disclosed against one of your production components.