In December 2021, a zero-day vulnerability that turned the world upside down was revealed. This is a Log4Shell zero-day vulnerability discovered in Log4, a JAVA-based logging library. CVSS's severity score is 10 out of 10 with CVE-2021-44228.

This vulnerability can be protected by updating the latest version. To do this, it is necessary to know whether to use log4j and what version and where, but few companies are properly aware of this. This issue showed the need for a software bill of materials (SBOM).

An SBOM is a specification containing all software information used to complete software and services used by end customers. It also includes traditional concept packaged software that users install and use themselves, operating systems, and frameworks or libraries used to develop other software. The goal is to display a configuration list of the supplied software and create an environment where suppliers and users can use it to make decisions based on this.

The Biden administration made it mandatory for companies that have signed a business agreement with the federal government to submit an SBOM so that anyone can learn about open source, licenses, and security vulnerabilities used in the SW development phase. Domestic public institutions and defense companies are making efforts such as forming TF teams to create SBOM or establishing their own SBOM standards. In addition, the Ministry of Science and ICT (Korea Internet & Communications Agency), the National Intelligence Service, and the Digital Platform Government Committee have jointly announced the “SW Supply Chain Security Guidelines” so that the government, public institutions, and companies can develop their own SW supply chain security management capabilities.

The minimum requirements for SBOM announced by NTIA (National Telecommunications and Information Administration) in the United States are as follows:

1. data field
   1. It must include the supplier name, timestamp, copyright holder, component name, version, unique identifier, and dependency relationships.

2. Automation support

3. Includes practice and process areas
   1. It defines six requirements relating to how and when the SBOM must be updated and delivered.

To create an SBOM, I will introduce two officially recognized SBOM standards for defining an integrated structure and sharing it with end users or customers. This defines a specific and integrated structure for SBOM creation and also determines how to share it with customers and users in the software supply chain.

1. SPDX

It is a project run by the Linux Foundation, which was developed in 2011 as an open source license management tool. Currently, a common data exchange format is provided for information related to software packages for sharing and collection. It is the only ISO-certified SBOM standard that satisfies all standardization and quality assurance requirements defined by ISO. Major companies such as Intel, Microsoft, and Sony have adopted and used this standard.

The standard can consist of fields and data such as document generation information, package information, file information, snippet information, license information, relationship information, and comments.

• Document generation information: Used for compatibility with previous and later versions when using analysis tools

• Package information: used to describe objects such as products, containers, and components

• File information: includes metadata such as name, license, and copyright information

In addition, various file formats such as XML, RDF, XLSX, JSON, and YAML can be used, and can be read by humans and can also be interpreted by machines. Various languages are supported to enable automated analysis. However, it also has the disadvantage that initial setup is complicated because it is very comprehensive and can accommodate many cases.

2. Cyclone DX (CDX)

It was designed to focus more on security and compliance than SPDX. An SBOM that makes it easy to analyze software supply chain components for cybersecurity. Specify the component inventory information and relationships with external services that make up the software. This is an OWASP open source project established to strengthen software security. It is relatively lightweight and clear because it focuses on software security.

These standards include software components, versions, license information, security vulnerabilities, and dependencies.

• Security vulnerabilities: Known vulnerabilities inherited from third parties and open source software and possible exploits

• Dependencies: Dependency information about components included in software, relationships between components, and the ability to identify dependencies that have gone through multiple stages

CDX makes it easy to manage security vulnerabilities and track licenses. For example, when a new security vulnerability is discovered in a particular open source library, you can identify all software projects that include that library. This makes it possible to immediately identify all applications exposed to these vulnerabilities and take necessary security measures, such as updates. It also provides license information for all components, so you can determine whether you are complying with specific license requirements. It provides only necessary information so users can easily understand and use it. However, it has not received ISO standardization, and the disadvantage is that the range of information provided is limited compared to SPDX.

Each SBOM standard clearly has advantages and disadvantages, so it is important to select the right standard based on specific requirements. Requirements must be clearly defined and standards must be selected based on various criteria such as technical maturity, comprehensiveness, flexibility, applicability, and lightness. As malicious actors are exploiting attack vectors faster and more actively, the need for an SBOM to manage the transparency and security of software supply chains continues to rise.