An whole stream of the OpenSSF’s Open Source Software Security Mobilization Plan is devoted to enhancing SBOM availability, production, and consumption.
In order to maintain a strong software supply chain, Software Bill of Materials (SBOM) are becoming increasingly significant. The implementation and accessibility of SBOMs in open source repositories were recently evaluated, and it was discovered that both factors were highly variable.
The Open Source Software Security Mobilization Plan’s authors stated that “just publishing SBOMs is insufficient, they need to be proactively used”. John Speed Meyers, a security data scientist at Chainguard, questions whether we should also be emphasising the availability of high-quality generating tools.
Meyer states: “Despite 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”.
Chainguard developed a dataset (bom-shelter) containing more than fifty openly accessible SBOMs to validate the availability and quality of SBOMs “in the wild”. The team then used the dataset to apply two SBOM quality assessment techniques. The first tool is an open-source project from eBay called SBOM Scorecard. The second tool comes from the SPDX community and is called the National Telecommunications and Information Administration (NTIA) Conformance Checker.
Meyers claims that the SBOMs for many open source projects are of poor quality. The SBOM Scorecard tool, for instance, looks for package licence information. Only roughly 20% of the evaluated SBOMs contained this data.
The NTIA Conformance Checker evaluates the SBOM using the NTIA’s framework of “minimal elements.” These fundamental components, according to its description, “provide basic SBOM functionality and will act as the cornerstone for a growing approach to software transparency.” The supplier name, component name, component version, other unique identifiers, dependency relationships, the SBOM author, and a timestamp are examples of the “minimal elements.” None of the evaluated SBOMs contained all of this data.
Ten action streams for enhancing open source software security are presented in the Open Source Software Security Mobilization Plan. The goal of stream nine is to enhance SBOM tooling and training to encourage the ecosystem’s adoption of SBOMs. They emphasise three strategies in order to accomplish this goal:
- Promoting consensus on needs that are shared by all of the SBOM specs.
- Making sure there are simple, open-source tools that produce SBOMs in accordance with those specifications.
- Offering easily accessible information, knowledge, and implementation advice.
The team points out that SPDX and CycloneDX are just two of the SBOM specifications that are already in existence. The working group’s goal is to promote “seamless interoperability” between the existing formats rather than unifying under a single format.
