What is an SBOM?
An SBOM (Software Bill of Materials) is an inventory of the software components in an application, software stack or device. SBOMs typically also communicate information about software licenses, vulnerabilities, and other metadata of interest to integrators, supply chains and deployers.
The term SBOM follows an older term - bill of materials (BOM or HBOM) that describes the hardware components in product. SBOMs have been generated, maintained and transmitted across supply chains for decades. The importance of SBOMs has grown in recent years from a combination of regulatory requirements and increasing awareness of software supply chain security risks. In 2021, the Biden Administration's issued an executive order (EO14028) that included a mandate for SBOMs to accompany software being sold into the U.S. federal government. EO14028 was followed by additional SBOM-related requirements from other branches of the US Government and from the EU.
SBOM Elements
At this writing, there does not exist a recognized standard for what constitutes an SBOM. In practice, most SBOMs include a common set of fields to describe covered components. These fields align with guidance from the U.S. federal government NTIA on the minimum elements of an SBOM.
Supplier
Component Name and Version
Dependencies on other software, internal and external
Author of SBOM Data
Timestamp
Why are SBOMs important?
SBOMs are important because they provide comprehensive visibility into the components that make up software, which is essential for security, compliance, and risk management. They promote and enable
Software Transparency
License Management and Compliance
Supply Chain Security and Vulnerability Management
Regulatory Compliance
SBOM Formats
Between accepted standards, vendor-specific formats and extensions to standards, SBOM file and data formats have multiplied. The most common and important SBOM data formats include:
SPDX - System Package Data Exchange
SPDX is an open standard for communicating SBOM information, including provenance, license, security, and related information. SPDX reduces redundancy by providing common formats for organizations and communities to share data, streamlining compliance, security, and dependability. The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.
SPDX is an open source project hosted by the Linux Foundation. The grass-roots effort includes representatives from a diverse set of organizations—software, systems and tool vendors, foundations and systems integrators. Work is done by three sub-groups: the tech team, the legal team, and the outreach team. There is also a monthly general call which provides an overview of progress on the entire project. For more information about getting involved, see the Participate page.
The SPDX project is composed of:
The SPDX Specification itself
The SPDX License List (including exceptions, matching guidelines, license IDs, and license expression syntax)
SPDX tools and libraries for working with the SPDX documents and SPDX License List
Since OpenTAP is published and distributed under version 2.0 of the Mozilla Public License, it's SPDX designation in an SBOM would be "MPL-2.0".
OWASP CycloneDX
CycloneDX from OWASP helps organizations achieve detailed visibility into software ecosystems by representing inventories of software components, dependencies, and relationships. These inventories include information about first-party and third-party libraries, library versions, and hierarchical interconnections. Capturing this data in a machine-readable format lets organizations identify risks such as outdated components, licensing conflicts, or vulnerabilities. This transparency fosters informed decision-making and strengthens security across the software lifecycle.
The CycloneDX specification goes beyond simple inventories by enabling integration into vulnerability management systems, regulatory compliance frameworks, and software procurement processes. Developers, security teams, and auditors can rely on CycloneDX to provide actionable insights about their software, from the design phase through deployment and maintenance. With its focus on automation and interoperability, the CycloneDX specification simplifies the complexities of software supply chain security while promoting efficiency and resilience.
Highlights
CycloneDX provides detailed inventory of software components, including dependencies and hierarchical relationships.
Enables rapid identification of outdated components, licensing conflicts, and vulnerabilities.
Facilitates integration with vulnerability management systems and compliance frameworks.
Supports end-to-end transparency across the software lifecycle.
SWID - Software identification
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) publishes, ISO/IEC 19770-2, a standard for software identification (SWID) tags that defines a structured metadata format for describing a software product. A SWID tag document is composed of a structured set of data elements that identify the software product, characterize the product's version, the organizations and individuals that had a role in the production and distribution of the product, information about the artifacts that comprise a software product, relationships between software products, and other descriptive metadata. The information in a SWID tag provides software asset management and security tools with valuable information needed to automate the management of a software install across the software's deployment lifecycle. SWID tags support automation of software inventory as part of a software asset management (SAM) process, assessment of software vulnerabilities present on a computing device, detection of missing patches, targeting of configuration checklist assessments, software integrity checking, installation and execution whitelists/blacklists, and other security and operational use cases.
Software Identification (SWID) Tags are an ISO standard (ISO/IEC 19770-2) that provides a structured metadata format for software components.
SWID is recognized in the NTIA minimum elements for SBOMs, but is less commonly used than SPDX or CycloneDX.
PURL
The Package URL (PURL) specification is an open standard for uniquely identifying software packages across different ecosystems. A PURL is a specially formatted URL that describes the location of a software package' or its identity in a package registry. It encodes the package type (e.g., npm, Maven, PyPI), the name, version, and other qualifiers in a single string.
How PURL Works
PURL provides a simple, universal identifier for software components, making it easy to track and share which components exist in a software stack. A Package URL is structured similarly to a web URL, with multiple components separated by specific symbols. The general syntax is:
pkg:<type>/
<namespace>/
<name>@<version>
?<qualifiers>#<subpath>Each part of this string has a specific meaning, which we'll outline below; you can also reference the PURL Spec’s GitHub README and PURL Types page for additional context.
Required Fields
scheme: The scheme is alwayspkg, indicating a package URL (just likehttporhttpsin web URLs). This constant prefix helps tools recognize a PURL immediately.type: The package type or ecosystem, such asnpm,maven,pypi,nuget,gem(RubyGems), etc.name: The name of the package (artifact or module name).
PURL supports a broad array of programming languages and package types, including npm (Node.js/JavaScript packages), pypi (Python packages), maven (Java artifacts), nuget (.NET packages), gem (Ruby Gems), golang (Go modules), cargo (Rust crates), docker (container images), and system packages like deb (Debian/Ubuntu) or rpm (Fedora/RedHat).
CPE - NIST Common Platform Enumeration
Another commonly used software identifier is NIST CPE (Common Platform Enumeration). An older system for identifying software products, CPE is widely used in vulnerability databases like the National Vulnerability Database (NVD).
CPE is a structured naming scheme for information technology systems, software, and packages. Based upon the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name.
Both CPE and PURL are machine-readable naming schemes for software, but they were designed for different contexts and have distinct attributes.
SBOM Tools
SBOM creation and management tools fall into three major categories
Build tools that produce SBOMs as part of their build process
SBOM scanning and management tools, usually associated with the major SBOM projects and formats
Feature-rich software composition analysis (SCA) tools
The following table summarizes available open source and proprietary tools for SBOM generation and management:
| Tool/Platform | SBOM Generation? | SBOM Management? | Open Source? | Formats Supported |
| Anchore | ✔ | ✔ | SPDX, CycloneDX | |
| Black Duck | ✔ | ✔ | SPDX, CycloneDX | |
| CycloneDX Gen | ✔ | ✔ | CycloneDX | |
| Finite State | ✔ | ✔ | SPDX, CycloneDX, others | |
| FOSSA | ✔ | ✔ | SPDX | |
| FOSSID | ✔ | ✔ | SPDX | |
| FOSSOLOGY | ✔ | ✔ | SPDX | |
| Microsoft SBOM | ✔ | ✔ | SPDX | |
| Snyk | ✔ | SPDX, CycloneDX | ||
| Sonatype SBOM Mgr | ✔ | ✔ | SPDX, CycloneDX | |
| SPDX Gen | ✔ | ✔ | SPDX | |
| Syft | ✔ | ✔ | SPDX, CycloneDX | |
| Tern | ✔ | ✔ | SPDX, CycloneDX, HTML | |
| Xygeni | ✔ | ✔ | SPDX, CycloneDX |
SBOMs and Test Automation
SBOMs have several practical applications in test automation that significantly enhance the quality, security, and compliance of software under test:
Vulnerability Detection and Management: integrating SBOMs into test automation pipelines provides an up-to-date inventory of software components and versions. Automated tests can use SBOM data to cross‑reference component versions with vulnerability databases and flag known vulnerabilities as part of continuous integration and delivery (CI/CD) workflows.
Dependency Management and Assurance: SBOMs provide transparency into open source and third-party dependencies. Test automation can leverage SBOMs to validate the inclusion of only approved and secure components, helping prevent the use of deprecated or unauthorized libraries.
License Compliance Validation: automated pipelines can inspect SBOMs to confirm that included components adhere to licensing policies, reducing legal risk and ensuring regulatory compliance.
Security Regression Testing: if a vulnerability exists in a particular library, automated systems can query SBOMs across projects to identify if impacted versions are present. Regression tests can then prioritize to mitigate exposure.
Incident Response: As new threats emerge, SBOMs allow testers and security engineers to determine exposure via automated searches, streamlining patching and exclusion of vulnerable components from deployment pipelines.
Risk Assessment: SBOMs facilitate automated risk scoring during pre-release testing. Test automation systems can integrate such checks and automatically report or block builds that exceed risk thresholds.
Test Coverage Analysis: SBOMs help ensure that critical components are covered by security, integration, and functional tests, reducing untested attack surfaces.
Continuous Compliance Auditing: By maintaining SBOMs for each software release, organizations can automate audit trails for all deployed components, supporting ongoing compliance and regulatory readiness in highly regulated sectors.
Conclusion
SBOMs empower test automation not just to validate code correctness, but also to ensure that software compositions are secure, compliant, and up to date throughout the lifecycle of continuous delivery. Increasingly, creation, management and transmission of detailed SBOMs is no longer a nicety, but instead a hard requirement in sales contracts and commercial licensing agreements that govern supply chains. To meet these requirements, software test and QA departments need to invest in integrating SBOM tooling into their workflows and deliver rich, annotated SBOMs together with test results and compliance data.