A Brief Discussion on SBOM (Software Bill of Materials)

What is SBOM?

SBOM stands for Software Bill of Materials, which is translated as “软件物料清单” in Chinese.

By making an analogy, SBOM can be simply understood as an ingredient list for software. Just like when we buy Nescafé instant coffee, there is an ingredient list on the outer packaging.

The US National Telecommunications and Information Administration (NTIA) issued a regulation last year. One of the requirements is that software purchased by the government must include an SBOM. That is to say, if you want to sell your software to the government, you must attach the ingredient list of this software. You can refer to SBOM. This has led to the sudden popularity of the SBOM concept in the US.

Functions and Benefits of SBOM

According to NTIA’s introduction, SBOM mainly has the following nine functions:

1. Reduce unplanned, unscheduled work
   For example, when a vulnerability is found in a certain component, with the help of SBOM, it is possible to quickly understand which software is affected, and determine the priority of the task of fixing the vulnerability according to the severity level of the vulnerability, reducing the time spent on investigation and review.

2. Reduce code bloat
   A company may reference different versions of the same (open - source) component in different software. Sometimes, it is possible to reduce the number of versions and try to reference the same version as much as possible. SBOM can help with this standardization by reducing the number of versions.

3. Adequately understand dependencies within broader complex projects
   With SBOM, developers and managers can master the software’s dependencies, including open - source components and internal company components, through the SBOM report. It also makes code refactoring easier and helps understand the software’s maintainability in the future.

4. Know and comply with the license obligations
   SBOM contains the license information of components. It can help companies more conveniently understand the license information of components and make automated compliance checks easier. This is not very obvious in China, but it is more important abroad.

5. Monitor components for vulnerabilities
   This is easy to understand. SBOM contains all the components included in the software. When a vulnerability is found in a certain component, just check if this component is in the SBOM to know if our software is affected. This step can even be automated. This can provide feedback in a very short time, which helps to enhance customers’ trust in the company.

6. End - of - life
   So many third - party components are used in a software, and some of these components may no longer be maintained. As a responsible organization, it should actively respond to this situation. SBOM can, to a certain extent, help the organization understand this information.

7. Make code easier to review
   I don’t quite understand NTIA’s explanation of this point. Here is the original text:

   Tracking components and subcomponents can make code easier to review and understand for developers, simplifying builds and reducing obstacles to getting code into production. Much of the initial security testing for avoidable harm can happen at early stages and in - context, as the code is written/assembled, weeks or months earlier than the alternative. Furthermore, this tracking enables situational awareness when an underlying dependency changes. It can also provide a better understanding of the work and time needed to make a change to the codebase.

8. A blacklist of banned components
   Some components should not be used for reasons such as reliability, performance, security, or company policies. With the help of SBOM, this can be achieved. Just check if these components are in the software’s SBOM report.

9. Provide an SBOM to a customer
   Customers may need an SBOM report due to security or regulatory requirements. If we have an SBOM report, it will be relatively easy to provide it.

The above nine points are the functions of SBOM proposed by NTIA. However, personally, in the current situation in China, only points 5 and 8 are more practical. Because there are currently no relevant laws and regulations in China, and without the drive of interests and legal requirements, enterprises do not have much motivation to implement it.

Implementation of SBOM

Although there are currently no relevant laws and regulations in China, they should be introduced in the future, especially in crucial industries such as government, healthcare, finance, and automotive software. Since SBOM has so many functions, how should we implement it within the company?

Here are some of my thoughts.

There are two prerequisites for better implementation of SBOM: 1. Relatively complete CICD tools and specifications; 2. At least one Software Composition Analysis (SCA) tool or artifact code analysis tool.

As mentioned at the beginning, SBOM is actually a bit like an ingredient list for software, that is, collecting which third - party components a software uses (in fact, it’s more than that, but let’s assume so for now, and write about the rest later). During the entire software development life cycle (SDLC), the CICD process is a suitable and easy time to collect this information, and collecting this information depends on an SCA tool (or artifact code analysis tool, only SCA tool is mentioned below), because it can obtain the list of third - party components referenced in the software.

In fact, after a certain degree of simplification, SBOM can also be said to be collecting, organizing, and presenting the results of SCA tool scans

In a relatively complete CICD process, it generally includes steps such as security scanning, compilation, testing, integration, and release. When doing security scanning, if SCA is included, the information required for implementing SBOM can often be obtained. What needs to be done next is how to export this information and manage and present it according to the requirements of SBOM.

From this perspective, if a company already has relatively complete CICD tools, specifications, and at least one SCA tool, then by processing and presenting the information obtained from the SCA tool scan, a simple SBOM system can be obtained.

Although what is said above can be regarded as an SBOM system, in practical applications, it will definitely not be that simple. The implementation of SBOM will be written about separately in the future.

Scope of SBOM

As mentioned before, SBOM is the list of third - party components used by the software. Strictly speaking, this is inaccurate.

SBOM should include the following information:

1. List of third - party components referenced by the software (including license information)
2. Information about the tools, systems, etc. used in the CICD process
3. If it is a SaaS product, it should include information about the software operating environment, such as the operating system and its version

Because all this information is very important for a software. Any security issue in the above information may lead to security problems in the software itself.