1. What is a SBOM?

As software supply chain becomes more complex and use of open-source components gets more prevalent, software has stepped into every aspect of our lives deeper than ever, ranging from smartphone applications, automotive operating systems and even medical devises at hospitals. Accompanying this emerging reliance, safety and reliability of software assurance has never been more critical. A SBOM (Software Bill of Materials) addresses such critical needs. Much like an ingredient label on packaged foods, SBOM provides a transparent list of every component that constitutes a software product. Similar to drawing a traditional BOM (Bill of Materials) when managing hardware, SBOM demonstrates details of all open-source, commercial, and library components that make up software.

   SBOM is more than a static list. It provides organizations with clear visibility into the software’s composition, allowing for structured management of components. The emergence of SBOM is a natural result of modern development practices, which rely heavily on diverse external components.

 

 

2. Why SBOM is Gaining a Global Attention

Two primary reasons why SBOM is being recognized worldwide are i) rising threats to software supply chain security and ii) strengthening of global regulations and policies.

 

1) Rising Supply Chain Security Threats

Software supply chain has emerged as a new threat to today’s software supply chain. Modern software scheme often utilizes open-source components to accelerate development and enhance efficiency. On the other hand, such efficiency possesses a dark side causing security vulnerability even with a single malicious code, resulting in unexpected hacking and data breaches.

The SolarWinds cyberattack (2020) ¹⁾ and the Apache Log4j vulnerability incident (2021) ²⁾ clearly demonstrated how supply chain weaknesses can lead to catastrophic consequences. What can SBOM to help prevent such consequences? SBOM helps mitigate such risks by recording every component and enabling rapid identification of impacted software and services when vulnerabilities are discovered. Organizations can then quickly patch or replace the affected component to minimize such damage.

 

¹⁾ SolarWinds Hacking Incident: Hackers inserted malicious code into the updated files of Orion, a network management tool developed by SolarWinds, an IT infrastructure monitoring company. When organizations downloaded the compromised updates, the malware infiltrated their internal systems.

²⁾ Apache Log4j Vulnerability Incident: A critical security vulnerability was discovered in Log4j, an open-source Java-based logging library developed by the Apache Software Foundation. This flaw allowed external attackers to gain administrator-level access to servers by exploiting the logging mechanism used for internet services and development processes.

 

2) Strengthening Global Regulations and Policies

Governments across the world are now treating software security as a matter of national security. In May 2021, Biden administration issued an Executive Order for escalating the importance of Nation’s Cybersecurity, mandating all vendors supplying software to the U.S. federal government to adopt SBOM protocols.

Similarly, the European Union Cyber Resilience Act, which took effect in December 2024, aims to strengthen software supply chain security. From December 2027 onward, digital products with critical cybersecurity vulnerabilities will be prohibited from distribution within the EU.

 

In Korea, the Digital Medical Devices Act came into effect on January 24, 2025. Article 16 of the Security Guidelines for Electronic Infringement Acts on Digital Medical Devices explicitly addresses SBOM management requirements.

 

 

3. SBOM Components and Standardization Efforts

Although SBOMs can take various forms, their effectiveness lies in standardized formats. Today, three major formats are widely recognized as below in which SPDX stands as center of the three standardized formats:

□ SPDX (Software Package Data Exchange): Managed by the Linux Foundation, this international standard is widely used across supply chains for sharing component and licensing data.

□ CycloneDX: Developed by OWASP, this lightweight standard specializes in vulnerability analysis and is optimized for automation tools.

□ SWID(Software Identification) Tags: Used for identifying and managing installed software, applicable as an SBOM format.

 

While no single unified format exists yet, each standard continues to evolve, and demands for tools supporting multiple formats are ascending rapidly. Regardless of the chosen format, the U.S. National Telecommunications and Information Administration (NTIA) has defined minimum required elements, which have become the de facto global baseline for SBOMs.

 

 

4. SBOM Tools and Common Misconceptions

Efficient SBOM generation and utilization require specialized tools. Many open-source solutions exist to generate SBOMs during the build process, integrate with package managers, and export data in standard formats. These tools can also analyze vulnerabilities or manage OSS catalogs based on license information.

However, there are misconceptions:

□ Tools are flawless: Automated tools may generate false positives or false negatives. Human review remains essential.

□ Every vulnerability must be fixed: Not all vulnerabilities require immediate remediation. Prioritization based on impact and cost is key.

□ SBOM is identical to hardware BOM: Unlike hardware, software evolves dynamically, requiring constant SBOM updates.

□ Open source is free: Maintenance, integration, compliance, and security management all incur costs.

□ Latest versions are always secure: Even with patches available, delays in applying updates leave systems vulnerable.

□ Widespread use equals higher security: Popular open-source projects may actually become more attractive targets for attackers.

 

 

5. Outlook & Recommendations of SBOM

SBOM is becoming a critical tool for ensuring software supply chain transparency and addressing escalating cybersecurity threats. While not yet legally mandated in Korea, SBOM has already become a prerequisite in global transactions. Its adoption is expected to expand to SaaS, cloud-based services, and broader IT systems in a near future.

Enterprises should proactively prepare by building the necessary infrastructure and capabilities for SBOM implementation. More importantly, SBOM should not be viewed as an end goal but as a means of improving vulnerability management and license compliance. By adopting SBOM, organizations can achieve greater visibility, proactively mitigate risks, and strengthen the resilience of the future software ecosystem.