Improve Supply Chain Security through Visualization of Software Components Using SBOM

1. Increasing Supply Chain Security Risk

Like the Log4Shell vulnerability, the risk of supply chain security attacks that target software by exploiting the vulnerabilities of OSS libraries used in many software has been increasing worldwide. In the "10 Major Security Threats 2023"^*1 published by the IPA (Information-technology Promotion Agency, Japan), "Attacks Exploiting Supply Chain Weaknesses" ranked second, and the number of vulnerabilities reported by NIST (National Institute of Standards and Technology, U.S.) has been increasing steadily from 2016 to 2024^*2.

To deal with the increasing supply chain security risks, the adoption of SBOM for vulnerability response has been promoted in both the public and private sectors. In the United States, following the Executive Order on improving the nation's cybersecurity issued in May 2021, NIST and other authorities issued guidelines for leveraging SBOM^*3. In Japan, led by the METI (Ministry of Economy, Trade, and Industry), demonstration experiments were carried out in anticipation of the introduction in each industrial sector^*4.

Given these situations, software developers and system suppliers are required to establish a system for appropriately generating, managing, and utilizing SBOM for vulnerability response.

• *1 IPA, 10 Major Security Threats 2023
  https://www.ipa.go.jp/security/10threats/t6hhco000000bc3m-att/setsumei_2023_soshiki_en.pdf
• *2 NIST, NATIONAL VULNERABILITY DATABASE
  https://nvd.nist.gov/vuln/search
• *3 NIST, Software Security in Supply Chains: Software Bill of Materials (SBOM)
  https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1
• *4 Ministry of Economy, Trade and Industry, Task Force for Studying Software Management Methods for Cyber Physical Security
  https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_bunyaodan/software/index.html

2. What is SBOM (Software Bill of Materials)?

SBOM, as shown in Figure 1, refers to configuration information that lists libraries and modules contained in the software. One characteristic of SBOM is that it can describe another library that a library depends on. Many of today's software contains components hierarchically, and it is common that components in deep layers are hard to be recognized from the upper layers. SBOM allows us to visualize complex dependencies and verify whether libraries with vulnerabilities or tampered libraries are included in the package.

Figure 1: Component structure represented by SBOM and example of actual SBOM^*5

• *5 NTIA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), quoted from Figure 1 and Table 2
  https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf

As shown in Figure 2, SBOM is typically generated using analysis tools classified into SCA (Software Composition Analysis). SAST (Static Application Security Testing) can typically identify most vulnerabilities written during the coding stage in user source code, but vulnerabilities in third-party or OSS libraries are exceptions. Therefore, SCA tool should be used to generate SBOM to match with a list of vulnerable components and reveal library vulnerabilities. In this regard, SAST and SCA perform complementary roles in security testing.

Figure 2: SBOM generation in application development flow

Currently, several organizations have proposed their own formats of SBOM and are driving towards standardization including specification and integration into tools (*6). Since SBOM is in its early stage, there is no perfect methodology at this point. It is desirable to research the predominant SBOM format in your industry and supply chain, define SBOM management requirements, introduce the tools, and build systems and processes for vulnerability management and response in a phased manner.

• *6 Here, we present CycloneDX and SPDX as representative SBOM formats:
  CycloneDX: Project led by the OWASP (Open Worldwide Application Security Project)
  https://cyclonedx.org/
  SPDX: Project under the Linux Foundation
  https://spdx.dev/

3. Main Requirements for Leveraging SBOM

As mentioned above, SBOM is only software configuration information, so you cannot say that just generating SBOM completes vulnerability management. The requirements to demonstrate the real value of SBOM and to utilize it for identifying and responding to embedded vulnerabilities are the following functionalities as shown in Figure 3 and below.

1. Periodically generate SBOM and import it into a manageable environment
   You need to generate the SBOM in the format required in the supply chain and import it into the management environment. General SCA tools have a function to scan automatically when software is modified in cooperation with CI/CD tools. Using these tools together also contributes to the realization of DevSecOps.
2. Match imported SBOM component information with vulnerability information and monitor it
   While commercial SCA tools have function to identify vulnerabilities when scanning the components, only configuration information may be output in the case of free SCA tools. It is necessary to obtain vulnerability information from external database and assess the component for vulnerabilities.
3. Promptly notify the developers of detected vulnerabilities
   If the software consists of a component with a vulnerability, it needs to be promptly notified to the software developers. If information on mitigation measures such as the library versions that are no longer affected is provided at the same time, developers will be able to respond quickly.
4. Report SBOM and vulnerability response status
   Depending on the rules of developers and the requirements from customers, reporting of SBOM and vulnerability management status may be required at any time. An export function for delivery will be required in anticipating the legalization of SBOM submissions to stakeholders in the supply chain.

The requirements listed above are just examples of how to effectively respond to vulnerabilities based on SBOM. Depending on developers, SBOM may be generated manually rather than automatically, or some management flow may be outsourced. Moreover, integrating the execution results of security scanners like the SCA tool as well as SAST and DAST can avoid information silos and make vulnerability response more efficient.

Figure 3: Requirements for identifying and responding to vulnerabilities from SBOM data

4. Practice of Integrated Vulnerability Management

SBOM-related technology includes commercial solutions as well as many useful OSS tools supported by the security community, such as OWASP Dependency-Track^*7 and OWASP DefectDojo^*8. These solutions make it possible to realize the functions above for utilizing SBOM.

If you are considering implementing SBOM in the future, we strongly recommend conducting research activities and demonstration experiments, which help accumulate know-how on SBOM management procedures and adapt SBOM to current software development tools.

NTT DATA, foreseeing a future where SBOM is mandatory for everyone, has been engaged in verifying the effective operation methods of SBOM as security governance for vulnerability response that exist in internal development projects. We are also conducting PoCs (Proof of Concept) for SBOM management in collaboration with global innovative companies in cybersecurity. We have developed an SBOM integrated management platform, shown in Figure 4, and are in the process of establishing best practices for how vulnerability responses should be implemented utilizing SBOM. We are preparing to provide consistent advisory and managed services as a comprehensive protection service for supply chain security, including SBOM management and vulnerability management, for our clients.

Figure 4: Example of vulnerability management by combining OWASP DefectDojo and SCA Tools

• *7 OWASP Dependency-Track
  https://dependencytrack.org/
• *8 OWASP DefectDojo
  https://owasp.org/www-project-defectdojo/

5. Conclusion

As compromise incidents of widely used OSS libraries and IT operations management solutions rapidly increase, there is an urgent need to address the growing security risks in software supply chain. SBOM, which is attracting attention as a solution for this problem, requires the establishment of methodologies for leveraging it and integration into traditional software development processes to be effectively managed. The requirements we introduced for SBOM implementation and the realization of DevSecOps lead to the resilience of supply chain security.