SBOM Concepts

SBOM Concepts #

Improving Transparency #

When the dependencies of a software asset are enumerated in an SBOM, it becomes possible to track where artifacts are deployed when new vulnerabilities are discovered. This is especially useful when the SBOM is stored in a searchable database (such as Codenotary Trustcenter).

A software bill of materials is an important part of software supply chain security, because it surfaces the various artifacts that are bundled with a given software asset and enables developers to quickly identify and remove vulnerable components.

Beyond the security applications of SBOMs, they also play a role in licensing and regulatory compliance. For example, the Software Package Data Exchange (SPDX) is a major standard SBOM format which communicates “the components, licenses, and copyrights associated with a software package,” and most developers have probably already encountered SPDX license identifiers in their projects (e.g. MIT or GPL-3.0-or-later).

Taking an Inventory of Software Dependencies #

Ideally, every software project and build artifact would come with an SBOM attached. While that may not always be feasible, any developer can create an SBOM for their project which enumerates the dependencies of their project—and defines the relationship between those dependencies and the project.

Dependency Relationships

From Software Bill of Materials Elements and Considerations by the National Telecommunications and Information Administration, US Department of Commerce:

[T]he “dependency relationship” generally refers to the idea that one component is included in another component, but could be expanded to also include referencing standards, which tools were used, or how software was compiled or built. […] As one SBOM document notes, “[c]omponent identification is fundamental to SBOM and needs to scale globally across diverse software ecosystems, sectors, and markets.” 

Documenting the Software Supply Chain #

Although the relationship between a project and its dependencies generally refers to which components are included in a piece of software, the relationships between two components in an SBOM can be defined in any number of ways that describe various points in the creation of an artifact.

For example, the SPDX specification not only provides a mechanism for defining relations such as DEPENDS_ON and RUNTIME_DEPENDENCY_OF, but also allows for defining relationships with the DOCUMENTATION_OF a project or the BUILD_TOOL_OF of a given build artifact.

Enumerating Dependencies #

Tools such as Syft and CodeNotary’s cas CLI can scan container images and codebases for libraries and other dependencies included within. When the SBOMs generated by these tools are shared with downstream consumers of a software project, they can be included in the SBOM for that project to track the provenance of each component in the entire dependency tree.

Structuring SBOMs #

A software bill of materials is typically structured according to an interchange format for SBOMs, such as SPDX or CycloneDX. The information architecture of an SBOM varies depending on the tool that is used to generate it, as well as the purpose of the SBOM and the needs of downstream consumers, but the basic set of properties is generally consistent between formats.

Baseline Component Information

The “baseline component information” of an SBOM, according to Software Bill of Materials Elements and Considerations by the NTIA:

  • Supplier name
  • Component name
  • Version of the component
  • Cryptographic hash of the component
  • Any other unique identifier
  • Dependency relationship
  • Author of the SBOM data

An SBOM should include information that uniquely associates it with the software artifact it describes, typically the name and version identifier of the asset, along with a cryptographic hash of the files that constitute the asset. Beyond that, to be used in any sort of meaningful way, an SBOM should include information about the relationship between the asset and its dependencies.

Last topic: ← Introduction
Next topic: SPDX Documents →