What Is an SBOM?
Guides developers and administrators through the core concepts of an SBOM and the industry standards.
Overview
This section is a learning guide for those encountering an SBOM (Software Bill of Materials) for the first time. It covers what an SBOM is, why it is needed, and how the industry-standard formats differ from each other.
Guide Structure
- Concept and Necessity: Explains what an SBOM is and the fundamental reasons why we need it now.
- Standards Comparison (SPDX vs CycloneDX): Understand the differences between the industry-standard formats so you can choose the format that fits the nature of your project.
For the practical side — actually generating, validating, and submitting an SBOM — see the Supplier Guide.
1 - SBOM Concept and Necessity
Explains the definition of an SBOM as a software bill of materials and the three core purposes of adopting it (security, licensing, and management).
Definition of an SBOM
An SBOM (Software Bill of Materials) is a formalized specification that describes the list of all components, libraries, modules, and so on that make up a piece of software, along with the dependency relationships among them. It applies the manufacturing concept of a BOM (Bill of Materials), used to manage a product’s parts list, to software engineering.
graph TD
A[Software Product] --> B[Direct Dependencies]
B --> C[Library A v1.2.3]
B --> D[Library B v2.0.1]
B --> E[Library C v3.1.0]
C --> F[Transitive Dependencies]
F --> G[Library D v1.0.0]
F --> H[Library E v2.5.0]
D --> F
classDef root fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
classDef direct fill:#D9F0E4,stroke:#00A651,color:#0A5A32,stroke-width:1.5px
classDef trans fill:#EEDCF3,stroke:#68127A,color:#4A0D57,stroke-width:1.5px
classDef lib fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
class A root
class B direct
class F trans
class C,D,E,G,H libKey Components of an SBOM
An SBOM document carries the following information.
- Component information: name, version, supplier, license
- Unique identifiers: standardized identifiers that pinpoint a component. Package URL (purl) is the most widely used (e.g.,
pkg:maven/org.springframework/spring-core@5.3.20) - Dependency relationships: direct dependencies (used by the project itself) and transitive dependencies (what the direct dependencies depend on)
- Metadata: generation tool, generation time, author
For submissions to SK Telecom, which items are required and in what form is defined by the Submission Requirements.
Why Is It Needed?
An SBOM is not merely a document; it is core data for software transparency.
1. Rapid Identification of Security Vulnerabilities
When a new vulnerability is disclosed (e.g., the Log4j incident), you can immediately determine where in your services the affected library is being used. Without an SBOM, you would have to conduct an exhaustive inspection of every server and codebase one by one, and you would miss the golden window for response.
2. License Risk Management
Open source license violations can lead to legal disputes. Through an SBOM, you can identify all licenses included in a project and block, in advance, the use of incompatible licenses (e.g., combining GPL with commercial code).
3. Software Quality and Obsolescence Management
By identifying old and unsupported (EOL, End-of-Life) components, you can manage technical debt and maintain the health of your software.
Against this backdrop, regulations in the United States, Europe, and elsewhere are also moving toward mandatory SBOM submission. See Regulatory Trends for details.
References
2 - SBOM Standards
Compares the characteristics of SPDX and CycloneDX, the two leading SBOM standards, and presents criteria for choosing the one that fits your project.
The Practical Takeaway First
For SBOMs submitted to SK Telecom, we recommend the CycloneDX (JSON) format. Check the accepted formats and versions in the Submission Requirements. The rest of this page is a detailed comparison for those who want to understand the two standards in depth.
Major SBOM Standards
Two standards are in wide use today, and both are accepted for submission to SK Telecom. They differ in their origins and primary focus areas.
- SPDX (Software Package Data Exchange): A standard led by the Linux Foundation (ISO/IEC 5962). Developed to exchange open source license information, it expresses license and copyright information in detail and can carry information down to the individual file level.
- CycloneDX: A security-focused standard developed by OWASP (ECMA-424). Designed from the start for vulnerability management, it has a compact structure and integrates well with security tools.
SPDX vs CycloneDX
| Aspect | SPDX | CycloneDX |
|---|
| Governing body | Linux Foundation | OWASP |
| Standard certification | ISO/IEC 5962 | ECMA-424 |
| Primary purpose | License compliance | Security vulnerability management |
| Structural complexity | High (detailed) | Low (compact) |
| File-level tracking | Supported | Limited |
| Vulnerability information | Optional | Built in |
| Tool ecosystem | Mature | Growing fast |
| File formats | JSON, RDF/XML, YAML, Tag-Value | JSON, XML |
| Typical users | Legal teams, open source program offices | Security teams, DevOps engineers |
| SKT recommendation | When license verification is the main goal | When vulnerability management is the main goal |
Whichever format you use, acceptance is decided by content, not format. Pick the format your generation tool supports and meet the required fields in the Submission Requirements.
Converting Between the Two
Conversion tools are available between SPDX and CycloneDX.
SPDX to CycloneDX
# Using cyclonedx-cli
cyclonedx convert --input-file sbom.spdx.json \
--output-file sbom.cdx.json --input-format spdx \
--output-format json
CycloneDX to SPDX
# Using spdx-tools
java -jar tools-java-1.1.0-jar-with-dependencies.jar \
Convert bom.cdx.json bom.spdx.json
References