Image represents a media kit with boilerplate, logos and more
Developer Guide

Software Bill of Materials (SBOM)

A software bill of materials (SBOM) is a list of all components, libraries, and dependencies within a software application to manage security risks and improve transparency.

TL;DR overview

  • A software bill of materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and dependencies in a software application.
  • SBOMs are increasingly required by regulations and procurement policies to improve software supply chain transparency and security.
  • By identifying all third-party and open source components, SBOMs help teams track known vulnerabilities and respond faster to emerging threats.
  • SonarQube Advanced Security supports software composition analysis (SCA) to identify vulnerable dependencies and generate SBOM-related insights.

What is SBOM in software development?

A Software Bill of Materials (SBOM) is a comprehensive, structured list of all components, libraries, dependencies, and modules used that make up a software application. It acts as an inventory that provides visibility into the software supply chain, allowing organizations to track the origin, version, and licensing of every software component used.

As modern applications increasingly rely on open-source software (OSS) and third-party dependencies, SBOMs have become essential for understanding software composition, mitigating security risks, and ensuring regulatory compliance. Organizations and developers use SBOMs to proactively address supply chain vulnerabilities, open-source license risks, and software integrity concerns, making them a crucial aspect of secure software development and DevSecOps practices.

Why is an SBOM important?

The rise of cybersecurity threats and supply chain attacks has made SBOMs a necessity for businesses and regulatory bodies. High-profile security incidents, such as Log4Shell (Log4j vulnerability), exposed the risks of using unverified and outdated software components. Without an SBOM, organizations may not even be aware of which vulnerable dependencies are present in their applications, leading to delayed responses and increased security risks. By maintaining a comprehensive SBOM, software teams can quickly identify and remediate vulnerabilities, improve incident response times, and enhance software supply chain security. 

SBOMs streamline software audits, ensuring compliance with frameworks like ISO 27001, NIST, SOC 2, FedRAMP, and the Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028).

Key Components of an SBOM

An SBOM typically includes:

  1. Component Name – Identifies the software component (e.g., a specific open-source library).
  2. Version Number – Specifies the exact version of the component to track vulnerabilities.
  3. License Information – Ensures compliance with open-source software (OSS) licensing requirements.
  4. Supplier Information – Identifies the original creator or vendor of the component.
  5. Dependency Relationships – Maps out how components interconnect, including direct and transitive dependencies.
  6. Unique Identifiers – Uses standardized identifiers like CPE (Common Platform Enumeration) or PURL (Package URL) to facilitate tracking in vulnerability databases such as NVD (National Vulnerability Database).

Benefits of Using SBOMs

1. Enhanced Security and Vulnerability Management

By having a clear inventory of software components, SBOMs allow teams to quickly identify and patch security vulnerabilities. Tools like SonarQube integrate SBOM analysis into security workflows, automatically flagging potential risks.

2. Regulatory and Compliance Adherence

Governments and industries are increasingly mandating SBOMs as part of cybersecurity compliance. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) have emphasized SBOM adoption in frameworks like NIST SP 800-218 (Secure Software Development Framework).

3. Risk Reduction in Software Supply Chain

Organizations gain visibility into third-party dependencies, reducing the likelihood of supply chain attacks. By integrating SBOMs into CI/CD pipelines, development teams can automate risk assessments and prevent insecure dependencies from reaching production.

4. Efficient Incident Response

When vulnerabilities like CVE-2021-44228 (Log4j exploit) emerge, companies with an SBOM can instantly determine their exposure and apply patches faster than those relying on manual tracking.

5. Better Software Quality and Governance

SBOMs provide transparency in software composition, allowing enterprises to enforce security policies, ensure software integrity, and make informed decisions about software dependencies.

How to Generate an SBOM in Software Development

Generating an SBOM ensures that organizations have a clear view of their software composition, enabling them to identify security risks, enforce compliance policies, and improve software quality. To create an SBOM effectively, developers and security teams must use automated tools, standardized formats, and integrated workflows to ensure accuracy, completeness, and real-time updates.

1. Choose the Right SBOM Format

Before generating an SBOM, it is important to select a standardized format to ensure interoperability with security tools, compliance frameworks, and industry best practices. The three most widely used SBOM formats are:

  • SPDX (Software Package Data Exchange) – Developed by the Linux Foundation, SPDX is an industry-standard format that documents software components, licenses, and security metadata, making it ideal for open-source compliance and software auditing.
  • CycloneDX – Created by the OWASP Foundation, CycloneDX is optimized for security analysis and software supply chain risk management. It provides enhanced support for vulnerability tracking, dependency relationships, and cryptographic hashes.
  • SWID (Software Identification Tags) – A format recommended by NIST that is widely used in enterprise software asset management and compliance tracking.

Selecting the right SBOM format depends on your organization’s security, compliance, and integration requirements. 

2. Use Automated SBOM Generation Tools

Manually creating an SBOM is time-consuming and prone to errors. Instead, organizations should leverage automated SBOM tools that integrate directly into their DevOps and CI/CD pipelines. 

These tools scan project dependencies, extract metadata, and generate a structured SBOM in the chosen format, ensuring up-to-date and accurate software inventories.

3. Integrate SBOM Generation into CI/CD Pipelines

To ensure that SBOMs remain current and automatically updated, organizations should integrate SBOM generation into their continuous integration/continuous deployment (CI/CD) workflows. This ensures that every software build includes a real-time inventory of all dependencies. Best practices include:

  • Automating SBOM generation at every build stage – Configure your tool to automatically generate an SBOM each time new code is built.
  • Enforcing SBOM validation – Implement security gates that block deployments if critical vulnerabilities are detected in SBOM components.
  • Maintaining historical SBOM records – Store previous versions of SBOMs in version control systems (Git, GitHub, Bitbucket, etc.) to enable traceability and auditing.

By integrating SBOM generation into DevOps workflows, organizations can continuously monitor software risks, improve transparency, and ensure regulatory compliance.

4. Include Key SBOM Metadata for Security and Compliance

To maximize the effectiveness of an SBOM, it must contain comprehensive metadata about each software component. An effective SBOM should include:

  • Component Name and Version – Clearly identify the software package and its exact version.
  • Supplier Information – Provide details about the vendor, developer, or open-source project that created the component.
  • License Details – Ensure compliance by documenting whether the component follows MIT, GPL, Apache, or proprietary licenses.
  • Dependency Relationships – Map direct and transitive dependencies to understand how components interact within the software stack.
  • Unique Identifiers – Use security-standard identifiers like CPE (Common Platform Enumeration), PURL (Package URL), or SWID tags to track vulnerabilities.
  • Cryptographic Hashes – Generate SHA-256 or other cryptographic hashes for software artifacts to prevent tampering and ensure integrity.

Organizations can improve vulnerability management, track licensing obligations, and enhance software supply chain security by enriching the SBOM with security-relevant metadata,

5. Cross-Check SBOM Components Against Vulnerability Databases

Once an SBOM is generated, it must be cross-referenced with vulnerability databases to identify known security risks. This process helps organizations proactively detect and remediate vulnerabilities before software is deployed. Some of the best sources for vulnerability tracking include:

  • National Vulnerability Database (NVD) – A widely used database that tracks Common Vulnerabilities and Exposures (CVEs).
  • OSV (Open Source Vulnerabilities) Database – A Google-maintained repository that maps open-source software vulnerabilities.
  • GitHub Security Advisories – Provides real-time alerts for security vulnerabilities in GitHub-hosted projects.

Automating vulnerability scanning against these databases ensures that SBOM components remain secure and compliant with industry standards.

6. Store and Share SBOMs Securely

Organizations should store SBOMs in secure repositories and make them accessible to relevant stakeholders, including security teams, software vendors, and regulatory bodies. Best practices for SBOM storage and sharing include:

  • Version control repositories (Git, GitHub, GitLab) – Maintain SBOM history for traceability and auditing.
  • Cloud-based security platforms – Use tools like AWS Security Hub, Google Artifact Registry, or Azure DevOps Security Center to manage SBOMs centrally.
  • Regulatory reporting – Share SBOMs with auditors and customers to demonstrate software transparency and compliance with security mandates like ISO 27001, FedRAMP, and NIST 800-218.

By maintaining secure and transparent SBOM records, organizations can improve collaboration, regulatory readiness, and software supply chain trust.

7. Continuously Update SBOMs as Software Evolves

SBOMs must be treated as living documents that evolve with the software lifecycle. Regular updates and re-scanning are essential to track new dependencies, retire outdated components, and address security risks. 

Best practices include:

  • Regenerating SBOMs for every new software release to reflect the latest changes.
  • Automating SBOM updates in CI/CD workflows to ensure real-time accuracy.
  • Reviewing SBOMs periodically to identify stale or deprecated dependencies.

Keeping SBOMs up to date enhances security posture, ensures compliance, and provides organizations with a strong defense against software supply chain attacks.

SBOM and DevSecOps Integration

A robust SBOM strategy aligns with DevSecOps principles, embedding security into every stage of software development. By using automated SBOM tools in CI/CD pipelines, organizations can shift security left, enabling early detection of outdated, vulnerable, or non-compliant dependencies before production deployment.

What are SBOM best practices? 

Organizations must follow SBOM best practices to maximize its effectiveness, ensure data accuracy, and integrate it seamlessly into their software development lifecycle (SDLC). Simply generating an SBOM is not enough. 

1. Automate SBOM Generation and Maintenance

Manually creating an SBOM is inefficient and prone to errors. To keep pace with modern software development, organizations should automate SBOM generation using DevSecOps tools that integrate with their CI/CD pipelines. Tools like SPDX, CycloneDX, OWASP Dependency-Check, Trivy, and Syft allow developers to continuously generate and update SBOMs whenever new code is built or deployed. By embedding SBOM generation into automated build pipelines, teams ensure that software inventories remain current, accurate, and aligned with the latest updates and security patches.

2. Ensure SBOM Completeness and Standardization

A well-structured SBOM should contain all software components, including direct and transitive dependencies, along with key metadata such as:

  • Component Name and Version – Clearly identify each software package.
  • Supplier Information – Track the origin of the software component.
  • License Details – Ensure compliance with open-source and proprietary licensing terms.
  • Dependency Relationships – Map how components interact within the software ecosystem.
  • Security Identifiers – Use standardized identifiers like CPE (Common Platform Enumeration), SWID (Software Identification), or PURL (Package URL) to facilitate vulnerability tracking.

To enhance interoperability, organizations should follow industry-standard SBOM formats, such as SPDX (Software Package Data Exchange) and CycloneDX, which are widely supported by security tools and regulatory frameworks.

3. Integrate SBOM into DevSecOps and CI/CD Workflows

To maximize the impact of SBOMs, they should be seamlessly integrated into DevSecOps practices and CI/CD pipelines. This ensures that security assessments, compliance checks, and risk analyses are conducted early and continuously throughout the software development lifecycle (SDLC). Best practices include:

  • Automated SBOM scans – Run security scans against vulnerability databases like the National Vulnerability Database (NVD) to detect risks before deployment.
  • Policy enforcement – Establish SBOM-based policies that prevent vulnerable, outdated, or non-compliant dependencies from being included in software builds.
  • Continuous monitoring – Implement real-time SBOM validation to track component changes and flag security vulnerabilities or licensing conflicts proactively.

By embedding SBOM checks within DevOps workflows, organizations can shift security left, reducing the risk of supply chain attacks and compliance violations.

4. Use SBOMs for Vulnerability and Risk Management

One of the most valuable use cases of an SBOM is vulnerability management. When a new software vulnerability, such as the Log4Shell exploit (CVE-2021-44228), is discovered, organizations with an up-to-date SBOM can immediately assess their exposure and implement patches. Best practices for using SBOMs in security management include:

  • Cross-referencing vulnerabilities – Continuously compare SBOM data with threat intelligence sources like MITRE CVE, NVD, and GitHub Security Advisories.
  • Prioritizing remediation – Use risk-based scoring (e.g., CVSS - Common Vulnerability Scoring System) to prioritize critical vulnerabilities and automate patching.
  • Incident response planning – Keep a historical record of SBOMs to track past software versions, enabling faster forensic analysis and incident response.

By using SBOMs as a security intelligence tool, organizations can proactively mitigate risks, reduce attack surfaces, and enhance software resilience.

5. Maintain SBOM Transparency Across the Software Supply Chain

SBOMs are not just for internal security teams; they should also be shared with key stakeholders, including software vendors, customers, and regulatory agencies. Maintaining supply chain transparency helps build trust and ensures that all parties are aware of potential security and compliance risks. Best practices include:

  • Sharing SBOMs with customers and regulators: Provide SBOM reports to government agencies, enterprise customers, and auditors to demonstrate compliance.
  • Securing SBOM data: While transparency is important, organizations must also protect SBOM data from unauthorized access to prevent supply chain manipulation.
  • Using SBOMs for vendor risk assessment: Evaluate third-party software suppliers based on their security posture, SBOM disclosures, and open-source hygiene.

By making SBOMs part of supply chain due diligence, organizations can reduce risks from third-party dependencies and enforce secure software sourcing practices.

6. Ensure Regulatory and Compliance Alignment

With increasing regulatory scrutiny, SBOMs are becoming a mandatory compliance requirement across industries. The U.S. Executive Order 14028 requires all federal contractors to produce and maintain SBOMs, setting a precedent for broader regulatory adoption. To ensure compliance, organizations should:

  • Align SBOM policies with industry frameworks like ISO 27001, SOC 2, FedRAMP, PCI DSS, and NIST 800-218 (Secure Software Development Framework).
  • Adopt SBOM disclosure practices that meet government and enterprise security mandates.
  • Prepare for audits by maintaining up-to-date SBOM records, tracking software changes, and demonstrating a commitment to software transparency and security.

By proactively aligning SBOM processes with compliance standards, organizations can avoid regulatory penalties, legal risks, and software liability issues.

7. Keep SBOMs Updated Throughout the Software Lifecycle

An SBOM is not a one-time document; it must be continuously updated and versioned to reflect changes in software components over time. Best practices for maintaining an accurate and dynamic SBOM include:

  • Regenerating SBOMs with every build or release to account for new, removed, or updated dependencies.
  • Tracking SBOM changes across versions to maintain historical records for security auditing.
  • Automating SBOM updates using tools that integrate with package managers (Maven, npm, PyPI, etc.) and version control systems (GitHub, GitLab, Bitbucket).

Keeping SBOMs fresh and accurate ensures that security teams, developers, and compliance officers always have the latest visibility into software components.

Future of SBOM in Software Development

As governments and enterprises push for software transparency and accountability, SBOMs are evolving into a standard practice for software security. The U.S. Executive Order 14028 mandates SBOM adoption for federal contractors, signaling a global shift toward secure software supply chains. Innovations in AI-driven vulnerability detection, blockchain-based SBOM tracking, and real-time dependency monitoring will further enhance the effectiveness of SBOMs in the coming years.

Final Thoughts on SBOM

A Software Bill of Materials (SBOM) is no longer optional—it’s a critical asset for secure software development, compliance, and risk management. Whether you’re a developer, security professional, or enterprise leader, implementing SBOMs in your software workflows ensures better security, transparency, and resilience against cyber threats. As the software supply chain grows more complex, leveraging automated SBOM tools will be essential to maintaining a secure, compliant, and high-quality software ecosystem.

SBOM and Sonar

SonarQube offers significant advancements for secure software development and comprehensive software supply chain management. Providing security offerings to include comprehensive vulnerability and license management for both proprietary and third-party open-source components.

SonarQube announced Advanced Security that will include support for the generation of SBOMs, providing detailed inventories of all involved software components, libraries, and dependencies. This integration guarantees better visibility into software composition, enabling teams to proactively manage risks and vulnerabilities

These advancements align with prominent security frameworks, such as NIST, making SBOMs a crucial part of secure software development, regulatory compliance, and risk mitigation. The integration of SBOMs in CI/CD pipelines will automate security assessments and compliance checks, thus embedding secure practices across all stages of the software development lifecycle. 

Software Bill of Materials FAQs

What does an SBOM look like?

An SBOM looks like a structured, machine-readable file, usually in JSON or XML, that lists each component in an application along with its details. Each entry typically shows the component name, version, supplier, license, and a unique identifier, plus how it connects to other components. People rarely read an SBOM line by line. Instead, security and compliance tools read it to match components against vulnerability and license data.

What is the difference between SPDX and CycloneDX?

SPDX and CycloneDX are the two most widely used SBOM formats, and they differ mainly in origin and emphasis. SPDX, a Linux Foundation project, grew out of license compliance and documents components, licenses, and provenance in detail. CycloneDX, created by OWASP, was designed for security use cases and has strong support for vulnerability data and dependency relationships. Both are machine-readable and widely supported, so the best choice depends on your tooling and on what your customers or regulators expect.

Is an SBOM legally required?

Whether an SBOM is required depends on your industry, region, and customers. In the United States, Executive Order 14028 brought SBOM expectations into federal software procurement, and medical device makers face SBOM expectations from the FDA. In the European Union, the Cyber Resilience Act expects manufacturers of products with digital elements to document their software components. Even where no law applies, large customers increasingly request SBOMs in security reviews and contracts, so confirm the rules for your sector with your compliance team.

What are the NTIA minimum elements for an SBOM?

The NTIA minimum elements are the baseline requirements that U.S. guidance expects an SBOM to meet. They include seven data fields: supplier name, component name, component version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. They also cover automation support and practices such as regular updates. Meeting this baseline makes an SBOM usable across tools and organizations, though many teams add license and hash data for extra value.

What is the difference between an SBOM and software composition analysis?

An SBOM is an inventory of what is in your software, while software composition analysis (SCA) is the process of examining those components for known vulnerabilities, license risks, and outdated versions. SCA tools often generate an SBOM as part of a scan, and they can also read one that already exists. In short, the SBOM is the list, and SCA is the analysis that turns the list into risk decisions. Most teams need both.

What are the limitations of an SBOM?

An SBOM is an inventory snapshot, not a verdict on risk. It shows which components you use, but not whether a vulnerability is reachable or exploitable in your code. Its accuracy depends on how it was generated, and it can miss components that scanners struggle to detect, such as vendored or statically linked code. It also goes stale as dependencies change. Pair SBOMs with vulnerability scanning, automated code scanning, and regular regeneration to close these gaps.

Can an SBOM detect malicious dependencies?

An SBOM cannot detect malicious dependencies on its own, but it makes them much easier to find and contain. Because it lists the exact packages and versions you use, you can quickly check whether a newly reported compromised package is in your software. Detecting the malicious package itself requires other controls, such as checking against malware and advisory feeds, verifying package integrity with hashes, and reviewing new dependencies before they are added.

How do you generate an SBOM for C and C++ projects?

Generating an SBOM for C and C++ is harder because these languages have no single, standard package manager. Dependencies may come from system libraries, vendored source folders, Git submodules, or several build systems, so a tool cannot rely on one manifest file. Teams usually combine build-system integration with source or binary scanning to capture components. Using a dependency manager such as Conan or vcpkg, where possible, makes the inventory more accurate and easier to automate.

How do you manage SBOMs across an enterprise?

Managing SBOMs at scale means automating creation, storage, and review instead of handling files by hand. Generate an SBOM for every build in your CI/CD pipeline, store each one in a central, searchable repository, and tie it to a specific release. Then monitor those SBOMs continuously against new vulnerability disclosures and assign clear ownership for responding to findings. Consistent formats and naming make it easier to answer questions like which applications use a given library.

How do AI coding assistants affect SBOM accuracy?

AI coding assistants can add dependencies that developers never explicitly chose, which makes inventories harder to keep accurate. An assistant may suggest or import packages that are unvetted, and some suggestions refer to packages that do not exist. Because both developer-written and AI-generated code can pull in third-party components, teams should generate SBOMs automatically at build time instead of relying on manual lists, and they should review new dependencies before they merge.