What Is an SBOM?
Guides developers and administrators through the full lifecycle of an SBOM, from its core concepts to generation, integration, and management.
Overview
This section is a practical SBOM (Software Bill of Materials) guide for members of the organization. Beyond simply complying with policy, it covers how to use SBOMs to improve the security of projects and the efficiency of dependency management.
Guide Structure
This guide is organized step by step, from the adoption of SBOMs to their operation.
- 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.
- Generating a Project SBOM: Guides you through the practical methods for extracting an SBOM directly from a project under development.
- CI/CD Integration: Covers how to automate SBOM generation in CI/CD pipelines such as Jenkins and GitHub Actions.
- SBOM Management: Introduces strategies for storing generated SBOMs in a central repository and managing them by version.
graph TD
A[Start Development] --> B[Add Dependencies]
B --> C{Build/Deploy}
C -->|Automation| D[Generate SBOM]
D --> E[Upload to Repository]
E --> F[Vulnerability Analysis]
F --> G[Security Remediation]SBOM Generation
For detailed SBOM generation methods and technical guidance, please refer to the following documents.
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 --> FKey Components of an SBOM
Includes basic information about each software component.
- Name: The official name of the component
- Version: The exact version number
- Supplier: The organization or individual that provided the component
- License: The applicable open source license
Unique Identifiers
Standardized identifiers are used to clearly identify components.
Package URL (purl)
This is the most commonly used identifier format.
pkg:maven/org.springframework/spring-core@5.3.20
pkg:npm/express@4.18.2
pkg:pypi/django@4.1.0
CPE (Common Platform Enumeration)
Used to integrate with security vulnerability databases.
cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*
Dependency Relationships
Specifies the dependency relationships among components.
- Direct Dependencies: Libraries that the project uses directly
- Transitive Dependencies: Libraries that the direct dependencies, in turn, depend on
Includes information about the SBOM itself.
- Generation tool: The name and version of the tool that generated the SBOM
- Generation time: The date and time the SBOM was generated
- Author: The organization or individual that generated the SBOM
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.
4. Regulatory Compliance
Various organizations, including the U.S. federal government, are mandating SBOM submission.
- U.S. Executive Order 14028 (federal government suppliers)
- EU Cyber Resilience Act
- FDA approval for medical devices
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.
Major SBOM Standards
There are currently two major standard formats that split the market between them. Both formats are widely used, but they differ in their origins and primary focus areas.
- SPDX: Software Package Data Exchange
- CycloneDX: A security-focused SBOM standard led by OWASP
SPDX (Software Package Data Exchange)
Overview
SPDX is an open source project led by the Linux Foundation, developed to represent the license and copyright information of software packages in a standardized way. (ISO/IEC 5962:2021)
Key Characteristics
- SPDX was originally developed to exchange open source license information, so it expresses license-related information in detail.
- Standardized license identifiers (SPDX License List)
- License expressions (e.g., Apache-2.0 OR MIT)
- Copyright information and per-file licenses
- It can include not only package-level information but also individual file-level information.
- Per-file hash values
- Per-file licenses
- Per-file copyright information
SPDX Document Structure
{
"SPDXID": "SPDXRef-DOCUMENT",
"spdxVersion": "SPDX-2.3",
"name": "Example-SBOM",
"documentNamespace": "https://example.com/sbom-2023-001",
"creationInfo": {
"created": "2023-01-15T10:30:00Z",
"creators": ["Tool: SPDX-Tools-2.3"]
},
"packages": [
{
"SPDXID": "SPDXRef-Package-1",
"name": "spring-core",
"versionInfo": "5.3.20",
"licenseDeclared": "Apache-2.0",
"externalRefs": [
{
"referenceType": "purl",
"referenceLocator": "pkg:maven/org.springframework/spring-core@5.3.20"
}
]
}
]
}
Advantages
- Officially recognized as an ISO international standard
- Detailed license information
- Traceable down to the file level
- A mature tooling ecosystem
Disadvantages
- Security vulnerability information is optional
- The structure is somewhat complex
- May be insufficient for security-focused projects
CycloneDX
Overview
CycloneDX is an SBOM standard developed by OWASP (Open Web Application Security Project), with a focus on application security.
Key Characteristics
- It was designed from the ground up for security vulnerability management.
- Vulnerabilities
- Security Analysis results
- Threats
- Compared to SPDX, its structure is concise and easy to understand.
- Focus on essential information
- JSON and XML format support
- Small file size
- It provides extensions that support a variety of use cases.
- SaaS BOM
- Hardware BOM
- AI/ML BOM
- Cryptography BOM
CycloneDX Document Structure
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2023-01-15T10:30:00Z",
"tools": [
{
"name": "cyclonedx-maven-plugin",
"version": "2.7.9"
}
],
"component": {
"type": "application",
"name": "MyApp",
"version": "1.0.0"
}
},
"components": [
{
"type": "library",
"name": "spring-core",
"version": "5.3.20",
"purl": "pkg:maven/org.springframework/spring-core@5.3.20",
"licenses": [
{
"license": {
"id": "Apache-2.0"
}
}
]
}
]
}
Advantages
- Includes security vulnerability information by default
- A concise structure that is easy to understand
- Excellent integration with security tools
- An active community and ongoing tool development
Disadvantages
- Not an ISO standard (a de facto standard)
- File-level information is limited
- License expression is simpler than in SPDX
SPDX vs CycloneDX Comparison
| Category | SPDX | CycloneDX |
|---|
| Governing body | Linux Foundation | OWASP |
| Standard certification | ISO/IEC 5962 | De facto standard |
| Primary purpose | License compliance | Security vulnerability management |
| Structural complexity | High (detailed) | Low (concise) |
| File-level tracking | Supported | Limited |
| Vulnerability information | Optional | Included by default |
| Tooling ecosystem | Mature | Growing rapidly |
| File formats | JSON, RDF/XML, YAML, Tag-Value | JSON, XML |
| Primary users | Legal teams, open source management organizations | Security teams, DevOps engineers |
| SKT recommendation | When license verification is the main goal | When security vulnerability management is the main goal |
Selection Guide
When CycloneDX Is the Right Choice
CycloneDX is recommended in the following cases.
- Security first: Vulnerability management is the primary goal
- Quick start: Rapid adoption thanks to a concise structure
- DevSecOps: Automation through integration into CI/CD
- Modern applications: Cloud and container environments
When SPDX Is the Right Choice
SPDX is recommended in the following cases.
- Emphasis on license compliance: Detailed license information is required
- File-level tracking: Per-source-file information is required
- ISO standard compliance: Official standard certification is required
- Legacy systems: Existing SPDX tools are already in use
For SK Telecom’s internal projects, the CycloneDX (JSON) format is recommended by default. This is because CycloneDX offers better interoperability with the internal vulnerability management system. That said, compatibility is also supported when an external partner submits SPDX.
Interconversion
Conversion tools are available between SPDX and CycloneDX.
Converting from SPDX to CycloneDX
# Using cyclonedx-cli
cyclonedx convert --input-file sbom.spdx.json \
--output-file sbom.cdx.json --input-format spdx \
--output-format json
Converting from 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