What Are the Elements of an SBOM?

February 29, 2024
By Aaron Linskens

8 minute read time

A software bill of materials (SBOM) is not just a list, but a detailed inventory that captures the components and dependencies contained within a piece of software.

You generate an SBOM not only as a matter of record-keeping, but also as a first step to secure and manage your software supply chains. In an era of software complexity and interconnectivity, software supply chain attacks continue to increase.

In this blog post, we build on the insights from the inaugural post of our SBOM content series, which highlighted the essential role of SBOMs in enhancing organizational transparency, security, and compliance. We now dig into what exactly makes up an SBOM, and why generating and managing SBOMs helps level up your cybersecurity.

Understanding Components and Dependencies

At the heart of any software lies its components and dependencies — the basic building blocks and web of interconnections that define its structure and functionality.

Notably in the context of software composition analysis (SCA), you record these elements in an SBOM.

Components

A software component is a modular, reusable unit of code that serves a specific function within a software system.

Components reduce the need to "reinvent the wheel" by allowing developers to integrate existing solutions into their projects.

While not mandatory, an SBOM typically captures the following information for components:

• Name, version, and supplier: In most cases, an SBOM lists the name, version, and supplier of each software component, whether open source or proprietary.

• Licenses: A thorough understanding of licensing terms for software components is essential to adhere to legal requirements and manage the rights for use, modification, and distribution.

Dependencies

A software dependency is a connection between software components, where one component relies on another for proper functionality.

Understanding and managing dependencies is crucial for maintaining software stability and security, as vulnerabilities or updates in dependencies can directly impact your software.

In the context of an SBOM, understanding these dependencies is critical for several reasons:

• Maintaining software stability and security: Dependencies can be sources of vulnerabilities or need updates to maintain the security and stability of the software. An SBOM provides a detailed mapping of dependencies, showing how components are interlinked with the potential risks or points of failure they might introduce.

• Dependency management: Managing dependencies, particularly in complex software projects, is essential for ensuring the security, reliability, and compliance of software. Tools and practices for dependency scanning and mapping enable developers to assess the health of a network of dependencies within software.

• Avoiding dependency hell: By understanding the nuances of direct and transitive dependencies and employing management strategies, developers can navigate the web of software dependencies. This proactive approach helps prevent "dependency hell," where managing and resolving dependencies becomes excessively complicated.

Licenses and Versioning

Managing licenses and versioning is essential for legal compliance and maintaining software integrity.

SBOMs facilitate this by comprehensively documenting software components, their origins, dependencies, and associated licenses. This allows organizations to remain compliant and up-to-date with the latest updates, ensuring maximum security and functionality.

Licenses

Each software component may have its own license, which dictates how it can be used, modified, and distributed. SBOMs provide a comprehensive overview of these licenses, helping organizations avoid legal pitfalls and ensure compliance.

Each component within an SBOM may be governed by its own licensing terms, from strict proprietary licenses to more permissive open source licenses.

SBOMs play a pivotal role in managing licenses by enabling the following:

• Ensure compliance: By identifying and understanding the specific licenses attached to each software component, organizations can adhere to legal obligations, avoiding potential litigation and financial penalties associated with license violations.

• Risk management: Licenses in SBOMs alert organizations to potential legal or operational risks, such as dependencies on software with incompatible licenses or components no longer maintained.

• Strategic decision-making: Organizations can make informed decisions regarding the selection of software components, preferring those whose licenses align with their project's needs and risk tolerance.

Versioning

Versioning is the practice of assigning unique version numbers to different states of software, allowing precise control over and tracking of changes.

SBOMs track versions and offer insights such as:

• Monitoring of software evolution: SBOMs provide a historical record of the versions of each component used in a software product, offering insights into the software's development over time. This is crucial for understanding the impact of each component on the software's functionality and security posture.

• Facilitating updates and rollbacks: By tracking the version history of components, SBOMs enable easier updates to newer versions or rollbacks to previous stable versions if necessary. This is vital for addressing security vulnerabilities or compatibility issues.

• Security vulnerability management: Versioning information within SBOMs allows organizations to quickly identify which newly discovered vulnerabilities affect components based on their version numbers. Organizations can then prioritize and apply necessary patches or updates to mitigate risks.

NTIA Minimum Elements

Following guidelines outlined by Executive Order 14028 on Improving the Nation's Cybersecurity, the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), defined the "minimum elements" necessary for an effective SBOM.

These elements, designed to enhance transparency in software supply chains, enable better management of vulnerabilities and risks. Below we explore these minimum elements, divided into three critical areas.

Data Fields

At the heart of an SBOM are the data fields, which serve as the baseline information required for each component within the software.

The NTIA defines the following data fields in its minimum SBOM elements:

• Supplier: Identity of the creator or provider of the component.

• Component name: The name of the software component.

• Version: Specific version information of the component.

• Other identifiers: Unique identifiers, such as package URLs (PURLs) or common product enumerators (CPEs).

• Dependency relationships: Information on how components are related or depend on each other.

• SBOM author: The entity responsible for generating the SBOM.

• Timestamp: When the SBOM was created or last updated.

Automation Support

For SBOMs to effectively function across various software ecosystems, embedding automation support is indispensable.

Automation not only streamlines the SBOM generation process, but also ensures that the SBOMs are accessible and decipherable by diverse software tools.

NTIA defines these key aspects of automation support regarding SBOMs:

• Automatic generation: Leveraging advanced tools and methodologies enables the creation of SBOMs without manual input, thereby reducing human error and increasing efficiency. This process facilitates the automatic compilation of detailed and accurate SBOMs, capturing the essential data of software components and their interrelations.

• Machine-readability: To maximize the utility and interoperability of SBOMs, they must be formatted so that software tools can easily process. Adopting standardized data formats, such as Software Package Data Exchange (SPDX) and CycloneDX, ensures SBOMs can be integrated and utilized within various environments. These formats allow for uniform representation of SBOM data, making it straightforward for tools across the software development and security spectrum to interpret and act upon the information contained within SBOMs.

Practices and Processes

Finally, NTIA's definition of practices and processes focuses on how to request, generate, and utilize SBOMs within an ecosystem. This encompasses the following:

• Frequency and depth: Guidelines on how often SBOMs should be updated and the detail they should contain.

• Known unknowns: Acknowledging and documenting the limitations within the SBOM data.

• Distribution and delivery: How SBOMs are shared with stakeholders and consumers.

• Access control: Managing who can view or edit the SBOM.

• Accommodation of mistakes: Processes for correcting errors within the SBOM.

Building Trust and Transparency in Software Supply Chains with SBOMs

By understanding the elements of an SBOM, organizations can bolster their security posture, ensure compliance, and contribute to a more robust software ecosystem.

A detail-oriented approach to documenting software components, dependencies, licenses, and versioning information via SBOMs enables developers and security teams to proactively manage vulnerabilities, maintain software integrity, and foster trust within their software supply chain.

To better navigate the challenges and opportunities presented by software development and deployment, level up your generation and management of SBOMs to achieve greater transparency, security, and efficiency in building better software.

Written by Aaron Linskens
Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.