What is a software bill of materials (SBOM)?
A software bill of materials (SBOM) is a machine-readable inventory of the components, libraries, modules, and dependencies inside a piece of software. That inventory turns the first question after any disclosure, "are we affected?", into a lookup instead of a hunt.
The NSA's July 2026 announcement describes an SBOM as a nested inventory, a "list of ingredients" for software. That framing fits modern builds: most applications are assembled from open-source packages, each with dependencies of its own. Understanding your software composition is where managing that risk starts.
Two incidents show where implicit trust in open-source registries breaks down. Log4Shell sat deep inside Java dependency trees, and teams without an inventory searched codebases and images by hand. The XZ Utils backdoor went further, planting a backdoor in a trusted compression library.
Those incidents pushed component inventories into legal and procurement conversations. Three drivers usually lead the business case:
Incident response speed: When a new CVE lands, one query shows every affected application and version.
Open-source license compliance: Recorded license identifiers expose copyleft obligations before a release ships. Following open-source security best practices keeps that review routine.
Supply chain integrity: Hashes and supplier data let you verify that what shipped matches what you built and approved.
Secure Coding Cheat Sheet
An SBOM makes your application's components visible; secure coding practices complement that visibility during development. Use this cheat sheet as a reference for building more secure software.
SCA vs. SBOM: What is the difference?
Teams often use SCA and SBOM interchangeably, yet they sit at different layers. Software composition analysis (SCA) actively scans code and flags vulnerable or risky components. An SBOM is the portable, standardized artifact that records what those components are.
Put simply, SCA asks the questions and the SBOM holds answers you can hand to someone else. The table below shows how they differ.
| Dimension | Software Composition Analysis (SCA) | Software Bill of Materials (SBOM) |
|---|---|---|
| Primary Definition | Active security scanning process that inspects codebases | Machine-readable manifest listing all constituent components |
| Timing in SDLC | Executed during coding, build pipelines, or test gates | Generated at build time, packaged, and tracked continuously |
| Primary Output | Vulnerability reports, policy alerts, remediation guidance | Standardized, vendor-neutral data files (SPDX, CycloneDX) |
| Interoperability | Typically proprietary to the scanning tool or platform | Open standard designed for sharing across vendors and buyers |
| Core Purpose | Risk identification and pipeline enforcement | Component transparency, auditability, and regulatory compliance |
In practice, DevSecOps pipelines run both in sequence. The SCA engine resolves dependencies and enforces policy at the build gate, then the pipeline publishes the inventory alongside the artifact. Later, SBOM scanning re-checks that stored file against new CVEs without a rebuild.
What does an SBOM include? Minimum elements and schema anatomy
The NTIA's 2021 minimum elements set the SBOM baseline for five years. In July 2026, CISA, the NSA, the FBI, and international partners published the 2026 Minimum Elements for an SBOM to replace that list. It keeps the original fields and adds component hash, license, and generation tool context.
| Element | What it captures | Why it matters | Origin |
|---|---|---|---|
| Supplier name | Entity that created or maintains the component | Establishes provenance and accountability | NTIA 2021 |
| Component name | Name of the software package | Identifies the package across tools and registries | NTIA 2021 |
| Version | Specific release of the component | Links to known vulnerability records | NTIA 2021 |
| Unique identifier | PURL, CPE, or SWID tag | Lets scanners cross-reference vulnerability feeds automatically | NTIA 2021 |
| Dependency relationship | How components connect, direct or transitive | Maps the path from your code to nested packages | NTIA 2021 |
| Author of SBOM data | Who produced the document | Supports audit trails and trust checks | NTIA 2021 |
| Timestamp | When the document was produced | Shows freshness against the current build | NTIA 2021 |
| Component hash | Cryptographic digest such as SHA-256 | Proves the file matches the listed component | 2026 update |
| License | License identifier for each component | Surfaces copyleft obligations early | 2026 update |
| Generation tool and context | Tool that produced the inventory and how it ran | Explains coverage gaps between documents | 2026 update |
Identifiers do the heavy lifting. A Package URL (PURL) encodes ecosystem, namespace, name, and version in one string, and CPE is the NVD's naming scheme. Record log4j-core 2.14.1 with its PURL, and a scanner matches it to CVE-2021-44228 (Log4Shell) with no manual triage.
Dependency relationships matter just as much. Your manifest declares direct dependencies by name. Transitive ones arrive because a direct dependency needs them, and they often outnumber the packages you chose.
Here is one component in CycloneDX JSON, including the hash and license fields the 2026 update expects.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "library",
"group": "org.apache.logging.log4j",
"name": "log4j-core",
"version": "2.14.1",
"purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
"hashes": [
{ "alg": "SHA-256", "content": "sha256-digest-of-log4j-core-2.14.1-jar" }
],
"licenses": [
{ "license": { "id": "Apache-2.0" } }
]
}
]
}Solving alert fatigue with VEX
Matched against vulnerability feeds, a raw component list can surface thousands of CVEs, most in code that never runs. Vulnerability Exploitability eXchange (VEX) documents state whether a product is actually affected by a given CVE.
Under the OpenVEX specification, each VEX statement carries one of four statuses: not_affected, affected, fixed, or under_investigation. A not_affected status includes a justification, such as the vulnerable code not being present or reachable. Your team can then close findings with an auditable reason instead of a shrug in a ticket.
Watch 5-min demo
An SBOM records your dependencies, but prioritizing their risks requires context. Explore Wiz Code in a five-minute recorded demo to see its approach to application security.
SBOM formats and standards compared
Two formats dominate: CycloneDX and SPDX. Both are open and actively maintained, so the choice follows your main use case. For a deeper breakdown, see our guide to standard SBOM formats.
CycloneDX, maintained by OWASP and standardized as ECMA-424, was built for application security pipelines. It supports VEX natively and extends to SaaSBOM for services and HBOM for hardware. Most scanners read CycloneDX JSON without conversion.
SPDX comes from the Linux Foundation and is standardized as ISO/IEC 5962:2021. Its license compliance roots give it the richest license expression syntax, and DEPENDS_ON relationships describe the dependency graph explicitly. SPDX 3.0 added security profiles, though licensing remains its strongest suit.
| Feature | SPDX | CycloneDX |
|---|---|---|
| Maintained by | Linux Foundation | OWASP |
| Formal standard | ISO/IEC 5962:2021 | ECMA-424 |
| Primary design focus | License compliance, with security expanded in SPDX 3.0 | Security and vulnerability management |
| License expression syntax | Rich, SPDX-native expressions | Supported, but less granular |
| VEX support | Security profile in SPDX 3.0 or external documents | Built-in |
| Dependency syntax | DEPENDS_ON relationships | Dependencies element |
| Output formats | JSON, RDF, YAML, tag-value | JSON, XML, Protocol Buffers |
| Best fit | Legal and OSPO teams, regulatory submissions | Security teams, vulnerability triage |
SWID tags (ISO/IEC 19770-2) predate both formats and still appear in some enterprise software catalogs. Their XML structure suited installed desktop software, so they lost ground to JSON-based formats in container and CI/CD ecosystems.
A component list says what is inside an artifact, but not how it was built. SLSA (Supply-chain Levels for Software Artifacts) fills that gap by defining levels of build provenance. In-toto supplies the signed attestation format that carries provenance and inventories alongside the artifact.
In practice, lockfiles, image layers, and runtime data all feed one generator. Its SPDX or CycloneDX output then serves vulnerability scanners, VEX statements, and audit tools.
The lifecycle of an SBOM: Pre-build, CI/CD, and cloud runtime
An inventory is only as accurate as the stage that produced it. Each stage sees a different slice of the software, so mature programs combine all three.
Source code and build-time generation
Build-time tools parse manifests and lockfiles such as package.json, pom.xml, go.mod, and requirements.txt. Lockfiles matter most because they pin exact resolved versions, including transitive packages. The tradeoff is rich source context with no view of base image layers or OS utilities.
In CI/CD, a common pattern runs Syft as a post-build step that writes CycloneDX JSON. Grype or Trivy then scans that file and fails the build on critical findings. Policy-as-code adds rules on top, such as OPA Rego policies that block AGPL licenses or packages from untrusted registries.
Container layer and workload ingestion
Containers add a second inventory that manifests never see. Scanners unpack each image layer and read OS package databases: dpkg for Debian and Ubuntu, rpm for Red Hat-family images, and apk for Alpine. Those packages merge with application dependencies, which is where container security scanning and inventory work overlap.
BuildKit can produce an SBOM during the image build with docker buildx build --sbom=true and attach it as an attestation. Teams then sign them with Cosign and store them as OCI artifacts next to the image digest, so consumers can verify who produced the inventory.
Dynamic runtime discovery
Some components only exist after deployment. Shared libraries loaded at runtime, WordPress plugins installed through an admin panel, and serverless layers attached at deploy time never appear in a build SBOM. eBPF-based sensors observe these from the kernel, recording which libraries processes actually load.
Comparing the build-time document against runtime state is how you catch drift. An unapproved package in a running container points to manual patching, tampering, or a pipeline bypass. That comparison is a core habit of a mature software supply chain security program.
Guide to SBOM Tools: 5 Picks for Enterprise Security Teams
Compare the 5 best SBOM tools for enterprise security teams. Learn key features, SBOM formats, and how to build SBOM generation into your security workflow.
Read more
Global regulatory mandates and compliance frameworks
Executive Order 14028 (2021) kicked off federal SBOM work and remains in effect. OMB memo M-26-05, issued January 23, 2026, rescinded memos M-22-18 and M-23-16. Agencies now take a risk-based approach, may still require SBOMs by contract, and must keep software and hardware inventories.
In Europe, the Cyber Resilience Act, Regulation (EU) 2024/2847, requires a machine-readable SBOM covering at least top-level dependencies (Annex I, Part II(1)). Reporting duties start September 11, 2026, and the main obligations apply from December 11, 2027. The document does not need to be public; manufacturers provide it to market surveillance authorities on request.
Sector rules point the same way. The PCI DSS v4.0 standard (Requirement 6.3.2) asks for an inventory of bespoke and custom software and its third-party components. In healthcare, Section 524B of the FD&C Act requires cyber device makers to include an SBOM in premarket submissions, as the FDA premarket cybersecurity guidance explains.
| Framework | Who it applies to | What it asks for |
|---|---|---|
| EO 14028 and OMB M-26-05 | Software suppliers to U.S. federal agencies | Risk-based decisions; SBOMs only where an agency requires them by contract |
| EU Cyber Resilience Act | Manufacturers of products with digital elements sold in the EU | Machine-readable SBOM covering at least top-level dependencies |
| PCI DSS v4.0 Requirement 6.3.2 | Organizations handling cardholder data | Inventory of bespoke and custom software and third-party components |
| FDA Section 524B | Makers of cyber devices | SBOM covering commercial, open-source, and off-the-shelf components in premarket submissions |
Common implementation pitfalls and misconceptions
Most SBOM programs stall on the same three problems. Each one has a known fix.
Static inventory blindness
A JSON file in a storage bucket describes one build at one moment. In auto-scaling Kubernetes clusters and serverless platforms, workloads turn over constantly, so that file drifts out of date within days.
The fix is continuous inventory tied to running workloads.
The noise dilemma
An unprioritized SBOM flags hundreds of CVEs, and developers quickly learn to ignore the queue. Reachability analysis sorts findings by whether the vulnerable code can actually run:
Reachable function: Your code calls the vulnerable function, so the finding moves to the top of the queue.
Reachable dependency: The library is imported, but the vulnerable method is never invoked.
Not reachable: The package is present, but its code is never loaded into memory.
Pair those classes with VEX statements and dependency scanning that understands cloud context. The list shrinks to fixes worth a developer's time.
The IP exposure myth
Some teams hesitate to share SBOMs because they fear leaking proprietary code. The document lists component names, versions, hashes, and licenses, never your algorithms, business logic, or source code. If the supplier list itself is sensitive, share it under NDA or on request.
How Wiz approaches software supply chain visibility and cloud SBOMs
Component data usually lives in three places that never meet: repository scans, pipeline artifacts, and production workloads. Wiz connects them so one inventory follows a package from commit to runtime.
Wiz Code reads repositories through VCS connectors and checks builds with the Wiz CLI. Wiz Cloud then scans registries and running workloads, and every package lands on the Wiz Security Graph.
Agentless workload scanning: Wiz scans VM, container, and serverless filesystems across AWS, Azure, and GCP without agents. The Sensor Workload Scanner extends coverage to on-prem and hybrid infrastructure.
Runtime validation: The eBPF-based Wiz Runtime Sensor in Wiz Defend confirms which packages actually load.
Standards-based export: Teams export SPDX, CycloneDX, or CSV with full dependency data and schedule delivery to an AWS S3 bucket for GRC.
Reachability plus cloud context: Findings are tagged by reachability class. The graph adds internet exposure, lateral movement paths, privileged IAM roles, and DSPM data access.
AI supply chain coverage: The AI bill of materials (AI-BOM) inventories AI SDKs, models, and frameworks across Bedrock, Azure AI, and Vertex AI.
Together, those signals filter out unexploitable findings. A CVE in a public-facing service with admin permissions outranks the same CVE in an isolated container.
Because code scans, pipeline checks, and runtime data all feed the same graph, each finding keeps its deployment context.
One boundary: Wiz scans, inventories, assesses, and exports standardized SBOMs, but it does not replace your version control, package managers, or build compilers.
Schibsted runs more than 60 brands and relies on the Wiz agentless SBOM for dependency visibility. When a bug bounty report flagged a potential backdoor in a code library, the team used it to quickly assess exposure and remediate.
Get a demo to see which vulnerable packages are reachable in your environment.
See Wiz in action
Explore how Wiz connects SBOM inventories with reachability and cloud exposure to help your team prioritize vulnerable packages. A personalized walkthrough can show how this approach fits your environment.
