A Software Bill of Materials Is Critical for Comprehensive Risk Management

Download TCIL Technical Note

In today’s world, very little software is entirely original. Software developers use existing, open-source, and commercially available software components to create new products. Programmers are not trying to reinvent the wheel; they leverage blocks of already developed code for time- and cost-efficiency. Collaboration on code development and reuse of software is a standard practice that is enabled and encouraged. On average, 75 percent of a software product is open-source code, according to the 2021 Open-Source Security and Risk Analysis Report. ¹

This presents a cyber-risk management problem. The problem is not the use of open-source software per se, but that customers generally receive software products without understanding the nested software contained within them. Customers are, in effect, purchasing a box of cereal without knowing if it contains nuts, wheat, soy, or other standard ingredients, even though those customers may have a severe allergic reaction to nuts. The customer cannot effectively manage assets and risk without knowing the software’s contents, origins, and history of changes and who made those changes.

A solution to this problem is to provide customers with a Software Bill of Materials (SBOM). An SBOM is a list of nested software components, designed to enable supply chain transparency. ² The SBOM identifies the component software and facilitates analysis and auditing of the components to determine risk and compliance. SBOMs have always been a good idea but not a requirement, and buyers often do not know to ask for them.

Luckily, that may be changing. President Joe Biden’s May 2021 executive order (E.O.) on cybersecurity, E.O. 14028, explains that “[b]uyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability.” ³

Without an SBOM, companies cannot take the first steps to secure themselves. The National Institute of Standards and Technology (NIST) Cybersecurity Framework explains that a foundational step to cybersecurity and risk management requires identifying data, personnel, and systems. ⁴ Before an organization can protect itself, before it can detect anomalies on its network and devices, the organization must identify its software and the software’s components before responding to indicators of a breach. If an organization does not know what its software contains, it should assume that the software is compromised and develop an appropriate risk management plan.

To aid the public and private sectors’ understanding of the utility of SBOMs, FDD’s Transformative Cyber Innovation Lab (TCIL) walked through the paces of developing and analyzing an SBOM. This first-hand perspective enables TCIL to provide concrete lessons learned rather than general recommendations. In this effort, TCIL collaborated with Virgil Systems, a company specializing in trusted data communications in a zero-trust world, and ION Channel, which specializes in the software supply chain. This report outlines the process used in, and the lessons learned and best practices revealed by, TCIL’s pilot project.

An important finding of the pilot is that having an SBOM is only the first step. Having a list of ingredients enables further analysis, but without that analysis, an SBOM is just a list. Critical next steps include understanding the software’s dependencies and vulnerabilities, ensuring continuous monitoring so that new risk information is ingested, and creating an immutable auditing capability to ensure the integrity of the data.