The Future of Software Supply Chain Security: SBOMs as a Dream or Reality?

The concept of mandatory software bill of materials (SBOM) was introduced by President Biden’s cybersecurity executive order in May 2021 to provide transparency and visibility into the components used in new software and improve the security of the software supply chain. However, two years later, the SBOM remains an elusive fantasy, with big tech lobbying groups calling for a greater understanding of how SBOMs can be generated and interpreted before agencies can be required to use them. In this report, we examine the challenges facing the SBOM project and what needs to be done to fulfill Biden’s executive order.

The Function of the SBOM

The SBOM aims to provide details on every code component included in an application, whether commercial software components, open-source software (OSS) libraries and dependencies, or any in-house developed libraries, to prioritize security patches and updates, track and manage vulnerabilities, and monitor compliance with relevant regulations and standards. The analogy that is commonly used for SBOM is a list of ingredients on a food product, allowing the purchaser to detect any risks involved in consuming the product.

The OSS Problem

The OSS is pervasive, and it is unlikely that any new application is built without using OSS components, which are free and readily available, and help developers build their new applications faster. However, the problem is that there is so much OSS, with 52 million new open-source projects on GitHub in 2022, that it is often developed by a single person or small team of collaborators generally unpaid. Moreover, developers tend to be coders and not security specialists, so in theory, the open nature of the code allows third-party researchers to examine the code for bugs, vulnerabilities, and malware. However, the same openness allows attackers to find those vulnerabilities and sometimes insert their malware.

Current State of the SBOM

There is no precise specification for what the SBOM should provide, in what format, nor how it should be interpreted and used, but perhaps the closest is the NTIA’s Minimum Elements for a Software Bill of Materials published in July 2021. One of the problems in the evolution of the SBOM is the lack of instruction, which is hampering progress on the project. However, security vendors are developing products to automate the process – firstly to generate SBOMs and secondly to receive, process, and remediate any highlighted issues.

The VEX

The VEX document is an important part of the SBOM project. The vulnerabilities must be known, provided through the VEX by the software developer, and informed to the purchasers using the SBOM. Technically, the OSS developer must inform the users of the code on any vulnerabilities discovered within the code. However, the OSS developer may not have advanced product security teams, and getting accurate vulnerability information from them is a bit too hopeful.

What Needs to Be Done?

The primary problems facing the SBOM project are more political than organizational, and the current administration will seek to ‘shape market forces’ and ‘will use Federal purchasing power and grant making’ to achieve their objective. However, the federal government cannot impose a federal requirement across all cybersecurity vendors. The solutions suggested by cybersecurity experts range from more regulatory guidance from CISA, financial incentives for adopting SBOM practices, a consortium to encourage consistency in SBOM solutions, and making it a part of some compliance or legal obligation.

The Ultimate Dream

It may be wrong to criticize CISA for the slow progress of the SBOM project. The agency has previous experience in patiently building a good idea into a valuable service, as evidenced by the KEV list. However, even when realized