What Is SBOM? Practical Guide to Implementation

What is an SBOM?

A software bill of materials (SBOM) is a structured, machine-readable inventory that lists every component, library, and dependency packaged inside a software application. Think of it as an ingredient label for software: it tells you exactly what went into the build, where each piece came from, and which version is running.

That visibility matters because modern applications are assembled primarily from open-source components, and any one of those components can introduce vulnerabilities or license obligations you never explicitly accepted. Understanding your software composition is the first step toward managing that risk.

Supply chain attacks like the XZ Utils backdoor and the event-stream compromise both exploited open-source dependencies that downstream projects trusted implicitly, exactly the components an SBOM is designed to make visible and auditable. Without an SBOM, your security team is left guessing which applications pulled in the affected library, how deep it sits in the dependency tree, and whether the vulnerable code path is even reachable in your environment.

CI/CD Security Best Practices [Cheat Sheet]

Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.

Your work email here

Download

What is an SBOM's role in software supply chain security?

Software supply chain attacks have moved from theoretical risk to operational reality. Attackers increasingly target the build pipeline itself, injecting malicious code into trusted libraries, package registries, and CI/CD tooling, as documented in recent supply chain attack campaigns. Wiz Research found that 90% of malicious packages originated from public registries, reinforcing how dependent modern development has become on ecosystems where trust is assumed rather than verified.

An SBOM gives defenders a verifiable record of what actually shipped, so when a new vulnerability drops, the first question ("are we affected?") has a concrete, auditable answer instead of a fire drill. That shift from reactive scrambling to immediate lookup is what makes SBOMs a foundational control rather than a nice-to-have.

Executive Order 14028 directly empowers CISA to set the standards and minimum elements for SBOMs, meaning CISA's published guidance carries regulatory force for any vendor supplying software to the U.S. federal government. In practice, federal procurement contracts now require SBOM delivery as a condition of purchase, and private-sector buyers are following that lead.

That trajectory has played out quickly. Gartner projected that 60% of organizations building or procuring critical infrastructure software would mandate SBOMs by 2025, and adoption has broadly tracked that pace. Teams that build SBOM generation into their workflows now avoid scrambling when contract requirements catch up.

Why are SBOMs important?

The business case for SBOMs extends well beyond regulatory compliance. When a critical vulnerability like Log4Shell surfaces, organizations with SBOMs can identify affected applications within minutes, while those without them spend days or weeks hunting through codebases manually. That speed difference translates directly into reduced exposure windows and lower incident costs.

Open-source software (OSS) now comprises the majority of dependencies in a typical application, so an SBOM must track not only each component's vulnerability history but also its license terms. A single copyleft dependency can create significant license compliance obligations for your entire product. A Synopsys OSSRA report found that 84% of audited codebases contained at least one known open-source vulnerability, underscoring how pervasive this exposure really is.

Following open-source security best practices helps reduce this risk, but visibility through SBOMs remains the foundation. The challenge goes deeper than what your manifest files show: transitive dependencies are rarely listed in a project's own manifest, creating blind spots in vulnerability management unless your SBOM generation tool performs full dependency resolution rather than a shallow scan.

Your application might declare 30 direct dependencies, but the actual dependency tree could include hundreds of transitive packages you never explicitly chose. Here are the core drivers that make SBOM adoption a priority:

• Faster incident response: When a zero-day drops, an SBOM lets you query your inventory and identify every affected application in minutes

• License compliance: SBOMs surface copyleft and restrictive licenses before they create legal exposure in your product distribution

• Procurement readiness: Federal and enterprise buyers increasingly require SBOMs as a condition of vendor selection

• Transitive dependency visibility: Full dependency resolution reveals the indirect packages that shallow manifest scans miss entirely

What should an SBOM include?

The NTIA published a set of minimum elements that every SBOM should contain. These elements establish a baseline for interoperability, so consumers of your SBOM can actually use it for vulnerability management, license auditing, and procurement validation.

When your SBOM records a component as log4j 2.14.1 with a Package URL (PURL), a scanner can instantly cross-reference that identifier against the NVD and surface CVE-2021-44228 (the Log4Shell vulnerability) without any manual triage. That automatic lookup is only possible when the SBOM uses standardized identifiers rather than freeform text.

Your SBOM may surface dozens of CVEs across its components, but a paired Vulnerability Exploitability eXchange (VEX) document narrows that list to only the findings that are reachable in your build. In practice, this means your team stops chasing CVEs in vendored code that never executes in production and focuses on the ones that actually matter.

Common SBOM formats

Two formats dominate the SBOM ecosystem: SPDX and CycloneDX. Both are open standards, both support machine-readable output, and both are actively maintained. The choice between them typically comes down to your primary use case.

SPDX was originally created by the Linux Foundation to facilitate license compliance across open-source ecosystems, which is why it carries richer license expression syntax than CycloneDX and remains the preferred format for legal and OSPO teams. With the release of SPDX 3.0, the standard also expanded its security capabilities significantly, though license compliance remains its strongest suit.

CycloneDX was designed from the ground up for software supply chain security, and its native support for Vulnerability Exploitability eXchange (VEX) reflects that priority. Most modern vulnerability scanners consume CycloneDX JSON natively, which reduces friction in automated pipelines and makes it the natural choice for teams whose primary SBOM use case is vulnerability triage.

Secure Coding Best Practices

Equip your team to build resilient applications with actionable secure-coding blueprints, shift-left strategies, and practical remediation for today's most critical vulnerabilities.

Your work email here

Download

Implementing an SBOM program: the maturity model

Rolling out SBOMs across an organization is not a single deployment. It is a capability you build incrementally, and CISA has formalized that progression into a maturity model as part of its broader software supply chain security guidance.

The model treats CI/CD pipeline integration as a mid-maturity milestone: organizations typically begin by generating SBOMs manually for their highest-risk products, then graduate to automated generation on every build once tooling and processes are in place. Here is how that progression looks in practice.

Phase 1: Software composition analysis (SCA) tooling

Software composition analysis is the process that produces an SBOM: an SCA tool inspects your build environment, resolves the full dependency graph, and serializes the result into a standardized SBOM document. At this phase, teams evaluate and adopt open-source SCA tooling to generate their first SBOMs.

Tools like Syft (from Anchore) handle SBOM generation, while Grype and Trivy scan the resulting SBOM for known vulnerabilities. Starting with manual generation against your highest-risk applications builds familiarity with the output format and surfaces any tooling gaps before you automate. For a deeper comparison of scanning approaches, see SAST vs. SCA.

Phase 2: CI/CD pipeline integration

Tools like Syft (generation) and Grype (scanning) are embedded as steps in your CI/CD pipeline, so every successful build automatically produces and validates a fresh SBOM without any manual intervention. This is where SBOM generation stops being a periodic exercise and becomes a continuous artifact of your build process.

When configuring the SBOM generation step, you need to specify an output format because downstream tools are not format-agnostic. CycloneDX JSON is widely supported by vulnerability scanners, while SPDX is often required for regulatory submissions. A typical integration adds Syft as a post-build step that outputs CycloneDX JSON, followed by a Grype scan that gates the pipeline if critical vulnerabilities appear.

Phase 3: Enforcing compliance and drift detection

At full maturity, SBOMs become inputs to policy-as-code frameworks. Teams write OPA (Open Policy Agent) or Rego policies that evaluate SBOM contents against organizational rules: no components with AGPL licenses, no packages with unpatched critical CVEs older than 30 days, no dependencies from untrusted registries. Pipeline gates enforce these policies automatically, and any drift between the SBOM and runtime state triggers alerts.

Runtime monitoring adds a second layer. By comparing the SBOM generated at build time against what is actually running in production, teams can detect unauthorized packages, supply chain tampering, or configuration drift that introduced components outside the approved bill of materials. This level of visibility is a core component of a mature software supply chain security program.

Real-life story: How Schibsted upgraded its security with advanced SBOM capabilities

With more than 60 brands and 1,200 developers, Schibsted needed to unify its cloud security without slowing innovation. By adopting Wiz, the company gained agentless SBOM visibility into its open-source and third-party dependencies across its environment, all while keeping developer workflows intact. 

This capability proved valuable when a bug bounty program revealed a potential backdoor in a code library. Schibsted used Wiz’s SBOM feature to quickly assess its exposure and remediate the issue before it could escalate. 

The team has since eliminated critical risks across its cloud estate and continues to rely on Wiz to maintain visibility, reduce vulnerabilities, and support ongoing compliance needs.

Wiz’s approach to SBOM security

Wiz Code, the platform's ASPM (application security posture management) layer, includes SCA capabilities that detect vulnerabilities and license risks across third-party libraries during development. Rather than treating SCA findings as a standalone list, Wiz connects them to the Security Graph, which correlates code-level dependency data with cloud configuration, identity permissions, network exposure, and runtime behavior.

Consider the difference in practice: a critical CVE in a library that runs in an isolated, non-internet-facing container with no sensitive data access is a fundamentally different priority than the same CVE in a public-facing service with admin-level cloud permissions. Wiz surfaces that distinction automatically through agentless scanning and reachability analysis, filtering roughly 90% of vulnerability noise so teams can focus on what is actually exploitable.

As organizations adopt AI services, the SBOM challenge expands beyond traditional software components. Wiz's AI-BOM capability inventories AI-specific assets (SDKs, models, frameworks, and connected data stores) across managed platforms like AWS Bedrock, Azure AI, and Google Vertex AI. This gives security teams a unified view of both traditional and AI supply chain risk, grounded in the same cloud context that makes vulnerability findings actionable rather than overwhelming.

To see how Wiz connects SBOM data to cloud context and helps your team focus on exploitable vulnerabilities, Get a demo.

Catch code risks before you deploy

Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

SBOM FAQs

Below are some common questions about SBOMs: