What is an SBOM?
A software bill of materials (SBOM) provides a detailed inventory of every software component in an application by cataloging open-source and third-party commercial dependencies along with key metadata such as component names, descriptions, versions, and licenses.
Modern software systems, especially those supporting interconnected software supply chains, combine components from many internal and external sources. This complexity increases exposure to supply chain attacks that exploit known vulnerabilities in widely reused packages. SBOMs also increase visibility into software components, which allows vulnerability management tools to pinpoint where real risks exist across dependencies.
Unlike traditional asset inventories, SBOMs track nested dependencies and component provenance throughout the software development lifecycle. Having this additional context helps teams understand how third-party updates, licensing changes, or compromised packages affect downstream software products. SBOMs also enhance visibility into patch status and license usage, helping organizations maintain code integrity and reduce the likelihood of malicious code entering production environments.
What is an SBOM’s role in software supply chain security?
As supply chain attacks keep growing in frequency and sophistication, SBOMs have become a foundational control for software supply chain security. They give organizations visibility into the full set of software components that make up an application, especially open-source software and third-party software development teams don’t maintain. Visibility like this lets security teams identify affected software packages quickly when new vulnerabilities emerge, assess blast radius across environments, and prioritize remediation efforts more effectively.
SBOMs also offer security teams visibility into the dependencies introduced by vendors, helping them perform more accurate risk assessments.
United States government guidance has also accelerated adoption. Executive Order 14028, for instance, directs federal agencies to promote SBOM usage for software procurement and risk management, setting the expectation that vendors may need to provide SBOMs to fulfill contracts. Agencies like CISA and NTIA have published additional guidance to standardize SBOM data exchange and usage across the cybersecurity ecosystem. These trends also extend beyond the US. The EU’s Cyber Resilience Act(CRA) also mandates SBOMs.
These high-profile incidents illustrate why SBOMs matter in practice:
Shai-Hulud npm supply chain attack: In 2025, Wiz Research discovered a self-replicating worm that compromised hundreds of npm packages and harvested cloud credentials, API keys, and GitHub tokens from victim environments. Teams with accurate SBOMs could quickly identify whether affected package versions were present in their codebases, while organizations without that inventory faced a slower manual triage process.
SolarWinds supply chain attack: Adversaries compromised the SolarWinds Orion software build process, impacting thousands of organizations. An SBOM alone wouldn’t have prevented the attack, but it could have significantly reduced investigation times by clarifying which systems depended on the compromised software package.
Many SBOMs come from SCA tools, so integrating them with container scanning and runtime security provides a full picture from build through deployment. Combining these controls provides a unified view of risk from code to cloud rather than isolated point-in-time assessments.
Because today’s software supply chains include AI services and models, organizations are increasingly pairing SBOMs with AI-BOMs to track AI-specific assets and risks that traditional SBOMs miss.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Why are SBOMs important?
SBOMs provide a detailed inventory of software components, which allows organizations to identify, track, and manage security risks more effectively. They also boost transparency across development teams, vendors, and stakeholders, making it easier to maintain accurate dependency data as applications evolve.
Here are four factors that explain why SBOMs play a critical role in cloud security programs:
| Benefit | What it means |
|---|---|
| Transparency and visibility | Shows every open-source component, third-party library, and internal package in an application so teams can evaluate risk before introducing a dependency and monitor it after deployment. |
| Regulatory and customer compliance | Supports frameworks like PCI DSS and HIPAA by providing verifiable documentation of software components and licensing, helping teams respond to audits and customer security questionnaires. |
| Incident response and forensics | Reduces investigation time by letting teams reference SBOM data to identify which packages are vulnerable, where they run, and which applications they affect, without manually tracing dependencies across repositories. |
| Proactive vulnerability management | Gives security teams a reliable baseline so they can quickly spot if affected components exist when new vulnerabilities emerge and prioritize remediation based on real exposure. |
What should an SBOM include?
An effective SBOM documents all open-source and proprietary software components in a software product and provides enough context to support security, compliance, and risk management use cases across the software lifecycle.
At a minimum, an SBOM should include these elements:
Component identifiers: Each entry should list the supplier name, component name, version, origin, and unique identifiers like hashes, package URLs, or commit references. These identifiers allow security teams to reliably correlate SBOM data with vulnerability scanning tools, vulnerability exploitability exchange data, and external databases like CVE and NVD.
Dependency relationships: SBOMs should clearly document how software components depend on one another, including nested and transitive dependencies. This relationship mapping helps teams understand how vulnerabilities propagate through applications and across environments.
Licensing information: Each component should include its license type, such as MIT, Apache, BSD, or GPL. Compliance teams use SBOM document license information to validate and enforce open-source usage policies more effectively.
External references: Links to documentation, repositories, or vendor resources provide additional context about component functionality, maintenance status, and support models, making them especially useful when assessing third-party software risk.
SBOMs enable vulnerability management by precisely and consistently identifying software components. However, they don’t list vulnerabilities on their own. Security teams typically pair SBOM data with vulnerability scanning, SCA tools, and threat intelligence sources to identify known vulnerabilities and prioritize remediation based on real-world exposure and impact.
Common SBOM formats
Organizations can generate SBOMs manually or automatically, though modern software environments strongly favor automation for accuracy and scale. Automated SBOM generation also integrates directly into CI/CD workflows and build systems, keeping SBOM data current as applications change. Automation reduces human error while improving consistency across teams and environments.
Manual SBOM creation is effectively obsolete in modern CI/CD. Maintaining accuracy with daily commits is impossible manually.
After generation, SBOMs typically follow one of several standardized formats that support interoperability and data exchange across the software supply chain. Here are a few examples:
Software Package Data Exchange (SPDX): SPDX standardizes how organizations represent SBOM data by defining software components, licensing information, and dependency relationships. The format supports both human-readable and machine-parsable formats, like JSON, XML, and YAML. Standardization helps organizations streamline license compliance and share SBOM data across vendors, customers, and security tools.
CycloneDX: CycloneDX describes internal and external software components, services, and their interdependencies. It outputs structured formats like JSON, XML, or protobuf and supports extensible metadata fields, including optional vulnerability and patch-related data. Development teams often choose CycloneDX for its flexibility and strong alignment with application security and SCA workflows.
The following example illustrates how SBOM formats work in practice using a simplified CycloneDX inventory in JSON format:
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"version": 1,
"components": [
{
"type": "library",
"name": "nacl-library",
"version": "1.0.0"
}
]
}Organizations also use software identification (SWID) tags to record identification data about installed software. Teams use them alongside SBOMs to improve asset and component tracking. Regulatory bodies and the US government recognize SPDX, CycloneDX, and SWID tags as acceptable SBOM formats, reflecting their broad adoption across the software ecosystem.
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.
SBOM implementation: A step-by-step guide
This structured, four-step approach can help your teams adopt SBOMs without adding unnecessary friction:
1. Choose the right SBOM standard
SBOM adoption starts with selecting a standard that aligns with your tooling, partners, and regulatory obligations. Widely adopted standards like SPDX and CycloneDX, for example, support consistent data exchange across development teams, security tools, and external stakeholders.
2. Automate SBOM generation
Automation improves accuracy, reduces human error, and allows development teams to move quickly without sacrificing visibility or control. Integrating SBOM generation into CI/CD workflows also ensures that every build produces an up-to-date inventory of software components.
3. Track and update software components
By pairing SBOM data with vulnerability scanning and SCA, security teams can quickly map newly disclosed CVEs, including high-impact issues like Log4j, to software components, shorten remediation timelines, and improve supply chain risk awareness across environments.
4. Review and monitor compliance
Embedding compliance checks into development workflows helps teams validate licensing information, verify component integrity, and maintain versioned SBOM records. This approach improves audit readiness while strengthening trust with business stakeholders.
Treat SBOMs as part of your broader cloud operating model by using continuous generation, validation, and monitoring. These methods ensure that SBOMs evolve with your applications and support transparency, compliance, and resilience across the software supply chain.
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.
4 advanced implementation strategies
Teams that already generate SBOMs find additional value when extending their use beyond documentation into daily security and development workflows.
These four advanced strategies focus on operationalizing SBOM data to actively support software supply chain security, risk management, and faster responses to emerging threats:
1. Integrating SBOMs into CI/CD pipelines
When teams integrate SBOM generation into CI/CD workflows, they gain earlier visibility into risky dependencies and reduce the likelihood that vulnerable or noncompliant software packages will reach production. This strategy also aligns SBOM generation with existing developer workflows, minimizing disruption while improving coverage.
🛠️ Action step: Configure your CI/CD tool (such as GitHub Actions, GitLab CI, or Jenkins) to automatically invoke SBOM generation tools like Syft or Trivy during each build phase.
2. Enforcing SBOM compliance through policy as code
By enforcing SBOM compliance through policy as code, organizations define rules governing acceptable licenses, approved software vendors, and vulnerability thresholds based on SBOM data.
🛠️ Action step: Implement SBOM policy rules using tools like Open Policy Agent or Conftest to validate against criteria such as source trust and license types. You can then embed them as checks in your deployment workflow.
3. Enabling continuous monitoring and drift detection
Teams typically generate SBOMs during development, but production environments can drift as configurations change or untracked components appear. Adding continuous monitoring to the process helps organizations detect discrepancies between declared SBOM data and the software actually running in cloud environments.
When these tools identify drift, teams can investigate unauthorized changes, regenerate SBOMs, and reassess risk. This capability also strengthens supply chain risk detection and supports faster incident response when unexpected software components surface.
🛠️ Action step: Deploy a runtime scanner with a solution like Wiz, which continuously compares current workloads to the last known SBOM and flags discrepancies in real time.
4. Verifying SBOM integrity and traceability
Capabilities such as digital signatures, checksums, and versioned storage help teams confirm that SBOMs remain unaltered from build through deployment.
Maintaining a historical record of SBOM versions also supports audits, forensic analysis, and regulatory reporting. Over time, this traceability strengthens confidence in SBOM data and reinforces accountability across software development and security teams.
🛠️ Action step: Use a secure artifact repository to sign SBOMs at build time and store versioned SBOMs with commit metadata for a traceable audit history.
Wiz’s approach to SBOM security
What is SBOM scanning?
An SBOM contains an inventory of all software components, libraries, dependencies, versions, licenses, and relationships.
Read more
SBOM data delivers the most value when teams connect it to real cloud assets, runtime exposure, and active risk signals across environments. That’s why Wiz treats SBOM security as part of a broader code-to-cloud security model rather than a standalone compliance task.
Wiz Code extends SBOM and Kubernetes bill of materials capabilities by providing continuous visibility into software components, dependencies, and their relationships to cloud resources. This integration helps security teams understand not only what components exist, but also where they run and how they affect overall security risk.
An agentless platform approach to SBOM security offers these advantages:
Flexibility and simplicity: Agentless scanning eliminates the need to deploy and maintain agents, which reduces operational overhead and compatibility issues across operating systems and cloud platforms.
Instant and comprehensive visibility: Wiz generates a detailed inventory of application components, including open-source libraries, operating system packages, and nested dependencies, within minutes and without blind spots.
Searchable SBOM data across environments: Security teams can quickly search for specific software packages across cloud accounts and workloads, accelerating investigations into high-impact vulnerabilities like XZ Utils.
Continuously updated inventories: Automated SBOM generation keeps component inventories current as applications change to support faster remediation and more accurate supply chain risk assessments.
By tying SBOM data directly to cloud context, Wiz helps organizations move beyond static inventories. With our platform, security teams can prioritize remediation based on real exposure, reduce manual effort, and strengthen software supply chain security from development through runtime.
Try Wiz’s free demo today to see how agentless SBOM generation and real-time vulnerability mapping can help you reduce blind spots, cut manual overhead, and secure every build from code to cloud.
To see how SBOM strategies, software supply chain visibility, and modern code security practices are evolving across the industry, download our State of Code Security 2025 report.
SBOM FAQs
Below are some common questions about SBOMs: