SBOMs should be connected with vulnerability databases to fulfill their promise of reducing risk, Google security team says.

Illustration with globe meant to convey a software supply chain ecosystem
Source: NicoElNino via Alamy

Software bills of materials (SBOMs) — a detailed list of components, modules, and libraries used to build products — are being endorsed by the National Institute of Standards and Technology (NIST) and US regulators as a way to drive down supply chain cybersecurity risks for consumers. 

But Google's Open Source Security Team points out in a blog post today that SBOM use alone isn't an effective tool for assessing exposure. Rather, the documentation should be compared with a database of known vulnerabilities to identify any known software flaws. 

"By connecting these two sources of information, consumers will know not just what's in ... their software, but also its risks and whether they need to remediate any issues," the team explains. 

The Google analysts detail how they were able to map a Kubernetes SBOM document using the Open Source Vulnerabilities (OSV) database. The OSV database offers both a standardized format for comparison across several databases, including the Github Advisory Database (GHSA) and Global Security Database (GSD), as well as aggregated data across multiple ecosystems, ranging from Python and Golang to Rust, according to the post.

"Our example queried the OSV database, but we will soon see the same success in mapping SBOM data to other vulnerability databases and even using them with new standards like VEX (Vulnerability-Exploitability eXchange), which provides additional context around whether vulnerabilities in software have been mitigated," the blog states. 

To make it easier for security teams to assess the full risk picture, the Google researchers recommend that SBOM creators begin to include a reference using a naming convention like a Purl URL for all packages in the software supply chain

"This type of identification scheme both specifies the ecosystem and also makes package identification easier, since the scheme is more resilient to small deviations in package descriptors like the suffix example above," they say. 

SBOM Evolution
Steps toward marrying the software components with known flaws will help SBOMs fulfill their intended purpose: to help manage the prospect of cyberattack, the Google security blog states. 

"Continuing on this path of widespread SBOM adoption and tooling refinement, we will hopefully soon be able to not only request and download SBOMs for every piece of software, but also use them to understand the vulnerabilities affecting any software we consume," they said. 

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights