The Ministry of Science and ICT (Korea Internet & Security Agency), the National Intelligence Service, and the Digital Platform Government Committee recently released the ‘Software (SW) Supply Chain Security Guideline 1.0’ jointly, and many companies and institutions are likely holding internal discussions on SBOM together with supply chain security. Integrating vulnerability information attributes into the SBOM standard specification defined in the published SW Supply Chain Security Guideline 1.0, however, is something that software developers, suppliers, and operators all need to understand well. With this as a reference, it is hoped that efficient software supply chain security will take root in Korea among developers, suppliers, and operators.
SBOM Specifications > Specifications of International and Domestic SBOM Standard Formats
An SBOM contains information about the open source present in software, and the internationally known standard formats are represented by CycloneDX, SPDX, and SWID.
In Korea, the TTA (Telecommunications Technology Association) standardizes the SBOM specification through the Open Source SBOM Governance Management Guideline” (TTAK.KO-11.0322), and the NIS (National Intelligence Service) publishes the NIS-SBOM specification through the SW Supply Chain Security Guideline 1.0.
The SBOM attribute specification presented by the TTA consists of 20 attributes, and items (19) and (20) indicate vulnerability information. The NIS SBOM attribute specification consists of 15 attributes, and items (13), (14), and (15) specify the attribute specification that indicates vulnerability information.
Issues > Including vulnerability information in the SBOM attribute specification can be inefficient for operating an SBOM.
Fixing vulnerability attributes into the SBOM specification can cause some problems at the stage of operating and managing SBOMs. When the cycle of SBOM creation and change management is compared with the cycle at which vulnerability information becomes known, most SBOMs are created when the software is first developed. Even so, how many companies or institutions update their SBOMs?
In other words, putting a vulnerability attribute into the SBOM specification means updating every SBOM that is held whenever a vulnerability is disclosed.
Alternatively, if there is an environment in which SBOM information and vulnerability information for all software in operation can be created and change-managed in real time, putting a vulnerability attribute into the SBOM specification can be desirable. (Only then would it be possible to know frequently whether known open source or 3’rd Party SW has security vulnerabilities.)
It is therefore necessary to consider the practical question of whether every company and institution can create and maintain SBOMs for all software in real time. The SBOM specification should be composed of attributes that can hold as much information as possible about open source, and information on vulnerabilities that are disclosed from time to time should be kept in a separate information store so that the SBOM and the vulnerability information are separated. That separation is judged to make SBOM operation and management for software supply chain security effective.
Leading Practices > How, then, are the SBOM specifications of leading practices composed?
SPDX, whose development began in 2011, and CycloneDX, whose development began in 2017
The internationally well-known SBOM formats are represented by SPDX and CycloneDX. The Linux Foundation began developing SPDX in 2011, and improvement work has continued through version 2.2. CycloneDX started as an OWASP project in 2017 and has been developed to the currently published version 1.5. The SPDX and CycloneDX SBOM specifications differ in some respects, but they basically include the seven minimum elements of an SBOM presented by the NTIA (National Telecommunications and Information Administration) under the U.S. Department of Commerce, which served as a focal point for software supply chain security, and they add various attributes to the SBOM specification according to purpose.
The seven minimum elements of an SBOM presented by the NTIA are shown in the table below.
| Attribute Name | Attribute Description |
|---|---|
| Component Name | Name of the software component |
| Version of the Component | Version of the component |
| Unique Identifier | Unique identifier of the component |
| Dependency Relationship | Dependency relationship between components |
| Author of the SBOM Data | Person or organization that authored the SBOM data |
| Supplier of the Component | Supplier of the component |
| Timestamp | Time at which the SBOM data was generated |
SBOM Specifications of CycloneDX and SPDX
The SBOM specifications, based on the latest versions of CycloneDX and SPDX, are as follows.
Because different organizations created the SBOM specifications, each has developed them to fit its own purpose. A comparison of only the basic points is as follows.
| Category | SPDX | CycloneDX |
|---|---|---|
| Sponsor | Linux Foundation (The Linux Foundation) | OWASP(Open Web Application Security Project) |
| Focus | An SBOM standard centered on license compliance | A security-centered SBOM standard that includes security vulnerability information and dependency information |
| Format | RDF, Tag-Value, JSON, YAML, and others | JSON, XML, Protocol Buffers, and others |
| Vulnerability Information | Does not include security vulnerability information directly, and structures the specification so that vulnerability information can be provided indirectly through external references | Includes a vulnerability information section so that security vulnerabilities can be documented directly, or structures the specification so that they can be updated continuously in conjunction with automated tools |
Separating the SBOM specification from vulnerability information is effective for SBOM operation and management.
Considering who creates an SBOM and when it is created, including a vulnerability information attribute in the SBOM specification means that, unless the SBOM is updated whenever vulnerability information is disclosed, the vulnerability attribute of that SBOM remains an SBOM in which newly known vulnerabilities are not reflected. Therefore, in an environment where an SBOM cannot be created and maintained in real time, a structure that separates the vulnerability information attribute from the SBOM specification is effective from the standpoint of SBOM maintenance.
The CycloneDX SBOM, in version 1.5, supports external references (Compononts > External References) and can also provide a link that points to the latest vulnerability data without including vulnerability information directly in the SBOM.
The SPDX SBOM likewise provides external references (External References) so that vulnerability data can be linked.