Code vulnerabilities are increasing in frequency and impact. As software is increasingly made up of parts from different vendors, often referred to as the software supply chain, it can be difficult to find and fix them quickly.
One solution to this problem is to use a Software Bill of Materials (SBOM). (SBOM- software bill of materials). Allan Friedman, director of cybersecurity initiatives at the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA), shared how important it is to be transparent about the inner workings of code through an SBOM.
What is SBOM?
SBOM is a set of metadata that describes the dependency tree of a software package. It includes key information such as vendor, version number and component name. Basic details such as these are critical when analyzing software for vulnerabilities, as they are based on a variety of components, as detailed in the flowchart below (Figure 1).
Figure 1: Example of SBOM elements
What is the value of an SBOM?
Transparency helps markets thrive. For example, food ingredients and labels give people the knowledge they need to make smart choices. Labels do not guarantee that people will eat healthy, but they give them the information to make healthy eating choices. Similarly, an SBOM won’t automatically solve all safety issues, but it does empower teams to resolve them more quickly and easily.
SBOMs can also tell you about a software component. For example, if you see that there are six versions of a package in an SBOM, there is a high risk that one of them is vulnerable.
Capabilities go beyond vulnerabilities to redundancy. For example, the issue of how many open source projects depend on a single component. This is described as the “Ukulele Problem”, or the project owner could simply abandon the hobby and pick up the ukulele and drop all dependent projects.
Why aren’t we doing this today?
There are many reasons why SBOMs are not standard practice today. While they are gradually gaining ground , there is still a chicken and egg problem where no one is asking for it and therefore it is not provided.
In addition, an SBOM is not necessarily easy to create in supply chains. As a new concept, the industry struggles with best practices and tools around it. For example, an SBOM requires consistent naming, where suppliers and even co-workers in the same group may assign different names to the same component.
There are also licensing and open source concerns.
How to build an SBOM
There are some guiding principles for making SBOMs with the NTIA process. The most important is to realize that you must crawl before you can walk. A baseline SBOM is needed so that teams can align around it. SBOMs created should be machine readable so they can be easily automated and then published to a known or discoverable location for easy access and analysis.
How to implement an SBOM
There are three formats for implementing an SBOM today:
SPDIX : A grassroots effort from the Linux Foundation. The program is an open standard for communicating SBOM information, including components, licenses, copyrights and security references.
CycloneDX : designed specifically for security contexts and supply chain component analysis.
SWID Tags : Composed of files that record unique information about a software component and assist with inventory management initiatives.
SBOM Example
A major proof of concept was in the healthcare industry, leveraging a bill of materials to find vulnerabilities and exploitable components. It also allowed reporting software issues with major medical devices to vendors.
Tools
While there are many tools available to do SBOM, the NTIA has a taxonomy of tools to help teams choose the right one (Figure 2 below).
Figure 2: Taxonomy of SBOM tools
The taxonomy focuses on SBOM:
- Production : It is important to take care when choosing the format of your SBOM and generating artifacts, as well as analyzing and editing existing lists.
- Consumption : good tools allow teams to read content and compare between SBOMs to detect differences.
- Transformation : various sources of SBOM and other data can be combined for auditing.
NTIA also encourages interoperability between tools so that together they can generate more awareness and increase usage.
Government recognition
As was achieved with medical devices (a matter of life and death), SBOMs should be feasible to do this for other industries and applications, as indicated in Figure 3. The current administration recognizes the importance of cybersecurity and issued an Executive Order , which describes SBOMs and their value proposition in Section 4.
Figure 3: NTIA SBOM Considerations
The future of SBOMs
Not only in the U.S. but globally, governments and industry see SBOMs as increasingly critical to safety. We see a future where SBOMs are recognized and leveraged.
There is a vision for more organizations to leverage SBOMs and help the community refine the tools to meet the broader needs of industry. SBOMs are not the solution to all your security concerns, but teams recognizing them as part of smart security decisions.
Source: Sonatype Blog
