Evaluating standards for Software Bills of Materials

Gunnar Braun at the Synopsys Software Integrity Group explores the different software inventory formats that  exist and argues that creating an SBOM alone is insufficient for documenting the security of software products

 

Following the issuance of the White House’s Executive Order 14028 in May 2021, greater attention has been paid to Software Bills of Materials (SBOMs) – inventories of software components.

 

While an SBOM is technically only required for organisations delivering software to the US Federal Government, the ruling has also inspired a wave of change across many private companies and suppliers around the world. The global business ecosystem is highly interconnected, making it crucial that organisations maximise transparency and maintain the security of their supply chain.

 

However, despite this demand for SBOMs, we have yet to reach a consensus on the best way to move forward.  

 

While the two most prominent standards for SBOM documentation are SPDX and CycloneDX, which offer a way to format the list of a particular product’s software components, this method only works if these components are easily assignable, which is often not the case. 

 

In fact, the process of identifying software components is far from standardised, especially due to common use of open-source code. Some software producers may use different identifying formats than others. Some formats include CPE (Common Platform Enumerator), SWID (Software Identification Tags), PURL (Package URL), hash formats, or even UUIDs (Universal Unique Identifiers).

 

This causes quite the confusion for security professionals who are looking to manage and/or categorise software vulnerabilities.

 

Standardising components

While SPDX and CycloneDX standardise the document format for an SBOM, they do not specify how the software components themselves are identified. Because software component names are not standardised, unambiguous "coordinates" are needed to check if the same component is being used across various SBOMs. It is also important that components and vulnerabilities have unique identifiers so there is no confusion. 

 

As a quick fix, SPDX and CycloneDX use other standards for this purpose, such as CPE, SWID, PURL, etc. The problem is that these formats are not binding, which means the producer of an SBOM could also use completely different formats such as hashes or UUIDs in addition to or instead of formats like CPE. This not only makes it difficult to compare two SBOMs, but also severely limits the interoperability of various software tools.

 

Recognising vulnerability

That is not to say that SBOMs aren’t great as inventory lists or for providing transparency—they are! If various components within an SBOM can be clearly assigned, this document would then be able to help create the basis for risk assessment of software products, including the risks of any security vulnerabilities. 

 

However, it is important to note that SBOMs alone are not sufficient to communicate security vulnerabilities. This is for two reasons. 

 

One, the security of a piece of software may change even if the software itself remains the same. New vulnerabilities are constantly being found. This is known as “software rot,” which is the degradation of software over time, where it becomes more riddled with vulnerabilities.

 

As a result, the software and the components used must be checked continuously. This can be done by querying corresponding vulnerability databases. 

 

The second reason is that software is not affected by every vulnerability of an installed component. Whether it is affected or not depends on how the component in question is being used. This means that the software manufacturer must check if and how their software is affected by the installed components. They must then communicate this finding across the supply chain. This can be done with VEX.

 

Consult vulnerability databases + VEX

To identify new vulnerabilities in an SBOM, consumers of the SBOM must consult corresponding databases, known as Vulnerability DBs. These include the National Vulnerability Database (NVD), the Open-Source Vulnerability Database (OSV), and specific software databases as well.

 

The issue with these databases as a resource for finding vulnerabilities is that the number of entries, the depth of content, and the format for entry are all inconsistent across the board. This adds to the confusion.

 

Further, Vulnerability DBs provide information about vulnerabilities in open-source software components, but do not consider the context how a component is used in the product. Depending on how the component is used, an security vulnerability in the component may or may not affect the product.

 

The Vulnerability Exploitability eXchange (VEX) intends to close this gap. According to CISA, the goal of VEX “is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.”

 

Additionally, VEX documents enable software manufacturers to proactively communicate the results of their security analysis. VEX documents are also machine-readable. This means that they formalize the description of whether a product is affected by a vulnerability, why this is so, and what measures are recommended. This is different from the free text information found in security advisories.

 

The drive toward transparency

While the lack of standardisation of software and component vulnerabilities is causing quite the headache, we are headed in a fantastic direction. As transparency and visibility increase across the board, the security and software industry at large will be in a much better place to prevent vulnerabilities.

 

But first, we must focus on properly standardising software components and vulnerabilities. The rest will follow.

 

---

 

Gunnar Braun is Technical Account Manager for Application Security Solutions at the Synopsys Software Integrity Group

 

Main image courtesy of iStockPhoto.com