BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News SBOM Quality and Availability Varies Greatly across Projects

SBOM Quality and Availability Varies Greatly across Projects

Bookmarks

Software Bill of Materials (SBOM) are becoming an important part of ensuring a healthy software supply chain. A recent assessment of the quality and availability of SBOMs in open-source repositories found the availability and implementation to vary widely. The OpenSSF's Open Source Software Security Mobilization Plan has a dedicated stream to improving the availability, generation, and consumption of SBOMs.

As noted by the authors of the Open Source Software Security Mobilization Plan, "just publishing SBOMs is insufficient, they need to be proactively used". However, John Speed Meyers, security data scientist at Chainguard, wonders if we also need to be focusing on ensuring high-quality generation tools exist. Meyers notes that:

[D]espite the mere existence of many SBOM generation tools (and the implied existence of many SBOMs), SBOM consumption tools would struggle to parse ill-formed and incomplete SBOMs and the goal of software transparency would still be distant.

To validate both the availability and quality of SBOMs "in the wild", Chainguard created a dataset (bom-shelter) of over fifty publicly available SBOMs. The team then applied two SBOM quality assessment tools against the dataset. The first tool, SBOM Scorecard, is an eBay open-source project. The second tool is the National Telecommunications and Information Administration's (NTIA) Conformance Checker from the SPDX community.

Meyers reports that many open-source project SBOMs are of low quality. For example, the SBOM Scorecard tool checks for the presence of package license information. Only about 20% of the assessed SBOMs had this information present.

The NTIA Conformance Checker assesses the SBOM against the NTIA "minimum elements" framework. They describe these minimum elements as "the essential pieces that support basic SBOM functionality and will serve as the foundation for an evolving approach to software transparency." The "minimum elements" include the supplier name, component name, version of the component, other unique identifiers, dependency relationships, the SBOM author, and a timestamp. None of the assessed SBOMs had all of this information present.

The Open Source Software Security Mobilization Plan presents ten action streams focused on improving the security of open-source software. Stream nine is focused on improving SBOM tooling and training to help drive the adoption of SBOMs across the ecosystem. To achieve this goal they highlight three approaches:

  1. Driving agreement on common requirements implemented across the various SBOM specifications
  2. Ensuring there are easy-to-use open-source tools that generate SBOMs based on those requirements
  3. Providing accessible education, awareness, and implementation guidance

The team notes that there are several SBOM specifications already available including SPDX and CycloneDX. The focus of the working group is not to coalesce into one format, but instead to enable "seamless interoperability" between the available formats.

A recent publication by Amélie Koran, Wendy Nather, Stewart Scott, and Sara Ann Brackett looked to clearly define the use cases for consuming SBOMs. They note that the absence of clearly defined use cases presents two main risks:

First, it risks mission creep, where policymakers might begin to frame SBOMs as a silver bullet for all supply-chain woes without clear demarcation of the problems they are designed to address.

The second risk they highlight is poor adoption resulting from the value of SBOMs being undersold. The authors identified the four main use cases as procurement, vulnerability management and threat intelligence, incident response, and ecosystem mapping.

Meyers agrees with the dual goals of improving the availability of SBOMs and their quality when he notes that "if software transparency is to be realized through SBOMs, SBOM quality will need to become a key concern." More details on what was found in the analysis of SBOMs can be found on the Chainguard blog.

About the Author

Rate this Article

Adoption
Style

BT