Supply Chain Security

• 1: Software Supply Chain Attacks and the Need for Security
• 1.1: Regulatory Trends
• 1.2: SK Telecom Supply Chain Security Policy
• 2: What Is an SBOM?
• 2.1: SBOM Concept and Necessity
• 2.2: SBOM Standards
• 3: Supplier SBOM Submission Guide
• 3.1: SBOM Submission Requirements
• 3.2: SKT SBOM Generator
• 3.3: Generating an SBOM with Open Source Tools
• 3.4: Pre-Submission SBOM Validation Checklist
• 3.5: SBOM Submission Process

1 - Software Supply Chain Attacks and the Need for Security

1. What Is a Software Supply Chain Attack?

A software supply chain attack is a cyberattack technique in which an attacker infiltrates the systems of a software developer or supplier, or the development process itself, to plant malicious code or exploit vulnerabilities.

Whereas traditional attacks directly target end users, supply chain attacks contaminate trusted software updates or development tools, thereby simultaneously infecting the many downstream companies and users that rely on them.

graph LR
    A[Attacker] -->|Infiltrate| B[Supplier Build Server]
    B -->|Inject Malware| C[Compromised Software Update]
    C -->|Distribute| D[Customer A]
    C -->|Distribute| E[Customer B]
    C -->|Distribute| F[Customer C]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#f96,stroke:#333,stroke-width:2px

2. Notable Attack Cases

The major security incidents of recent years have impressed the importance of supply chain security on the entire world.

The SolarWinds Incident (2020)

• Overview: The build system of SolarWinds Orion, a network monitoring solution, was hacked, and a backdoor was planted in legitimate update files.
• Impact: Some 18,000 organizations worldwide were affected, including U.S. government agencies and Fortune 500 companies.
• Lesson: It demonstrated that even officially signed software from a trusted vendor may not be safe.

The Log4j Vulnerability (2021)

• Overview: A critical vulnerability enabling remote code execution (RCE), known as Log4Shell, was discovered in Log4j, a Java-based logging library.
• Impact: Hundreds of millions of devices and servers worldwide that use this library directly or indirectly were exposed to risk.
• Lesson: It became a turning point that made organizations realize how important it is to understand which open source components their systems use, through an SBOM (Software Bill of Materials).

The 3CX Supply Chain Attack (2023)

• Overview: The desktop app of the VoIP software 3CX was distributed while infected with a trojan.
• Characteristics: The attackers first hacked the PC of a 3CX employee and then moved laterally into the development environment to tamper with the binaries.

3. Why Supply Chain Security?

Modern software development environments are built on top of complex, interwoven dependencies.

1. Growing open source dependencies: 70-90% of modern application code consists of open source components.
2. Ripple effect: When a single common component is compromised, the damage spreads worldwide.
3. Difficulty of detection: Code that is compromised during the development and build stages can easily bypass traditional security checks (firewalls, antivirus, etc.).

Accordingly, SK Telecom has established and enforces SBOM adoption and a rigorous supply chain security policy in order to ensure transparency across the supply chain and to manage risk.

Related Documents

• Global Regulatory Trends: Key regulatory developments such as U.S. EO 14028 and the EU CRA
• SK Telecom Supply Chain Security Policy: SK Telecom’s specific requirements
• Supplier Guide: Guidance on SBOM generation and submission for suppliers

1.1 - Regulatory Trends

1. United States: Executive Order 14028 (EO 14028)

In May 2021, the Biden administration issued the “Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028).” This was a decisive turning point at which supply chain security began to be addressed at the level of national security in the aftermath of the SolarWinds incident.

Key Provisions

• Mandatory SBOM submission: Companies that supply software to the federal government must submit an SBOM.
• NIST guideline compliance: Companies must comply with the Secure Software Development Framework (SSDF) defined by NIST (the U.S. National Institute of Standards and Technology).
• Minimum standards: The U.S. administration led standardization by defining the minimum elements of an SBOM (data fields, automation support, etc.).

2. European Union (EU): Cyber Resilience Act (CRA)

Through the Cyber Resilience Act (CRA), the EU has enacted into law security requirements spanning the entire lifecycle of digital products.

Key Provisions

• CE marking certification: All products with digital elements can only be sold within the EU if they meet the cybersecurity requirements and bear the CE mark.
• Defined security support period: Manufacturers must provide security updates throughout the expected product use period (up to 5 years).
• Vulnerability reporting obligation: Critical vulnerabilities must be reported to ENISA (the European Union Agency for Cybersecurity) within 24 hours of discovery.
• SBOM management: Manufacturers must identify and document (via an SBOM) the software components of their products.

3. South Korea: SW Supply Chain Security Guidelines

In step with the global trend, the South Korean government (the Ministry of Science and ICT, KISA, and the National Intelligence Service) has also released the “SW Supply Chain Security Guidelines” and is pursuing proof-of-concept initiatives.

Key Contents (based on v1.0)

• Recommendation to adopt SBOM: It is recommended that an SBOM be generated and utilized when developing and delivering software in both the public and private sectors.
• Definition of security activities by role:
  • Supplier (developer): Build a secure development environment, generate and provide an SBOM, and inspect for security vulnerabilities.
  • Consumer (operator): Require and verify the SBOM of delivered software, and continuously monitor for vulnerabilities.

SK Telecom’s Response

To proactively respond to these domestic and international regulatory trends, SK Telecom has established its own supply chain security policy and requires all partners to submit SBOMs that conform to global standards (SPDX, CycloneDX).

Related Documents

• Supply Chain Security Overview: Concepts and notable cases of software supply chain attacks
• SK Telecom Supply Chain Security Policy: The specific policy that SK Telecom requires of suppliers
• Supplier Guide: Guidance on SBOM generation and submission for suppliers

1.2 - SK Telecom Supply Chain Security Policy

---

NOTICE.

In accordance with internal security and document management policies, this document is a summary that excludes confidential content. Please note that it is written around high-level key points rather than the full content.

---

1. Purpose of the Policy

The purpose of this policy is to ensure the transparency of all software that SK Telecom adopts, and to identify and eliminate, in advance, the risks of known vulnerabilities and license violations.

2. Scope of Application

All suppliers that enter into a software supply contract with SK Telecom are subject to this policy.

3. Key Requirements

Suppliers must comply with the following three principles.

Principle 1: Mandatory SBOM Submission

• For every software delivery, the supplier must submit an SBOM (Software Bill of Materials) corresponding to that version.
• Accepted formats: CycloneDX (v1.3 or later) or SPDX (v2.2 or later)
• Required information: supplier name, component name, version, dependency relationships, and Package URL (PURL)

Principle 2: Vulnerability Inspection and Remediation

• Before delivery, the supplier must independently check for the latest security vulnerabilities (CVEs).
• If Critical/High severity vulnerabilities are found, the supplier must patch them or apply mitigation measures before delivery.
• If patching is not possible, the supplier must prove, through a “vulnerability justification statement,” that the vulnerability has no actual impact on the service.

Principle 3: Transparent Change Management

• If the components of the software change during the contract period (updates, patches, etc.), the supplier must immediately submit an updated SBOM.
• The supplier must warrant that it has complied with open source license obligations (notice obligations, source code disclosure obligations, etc.).

Related Documents

• Supply Chain Security Overview: Concepts and notable cases of software supply chain attacks
• Global Regulatory Trends: Domestic and international regulatory developments related to SBOM
• Supplier Guide: Detailed guidance on how to generate and submit an SBOM
• Submission Requirements: SBOM format and required data field definitions

2 - What Is an SBOM?

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.

1. Concept and Necessity: Explains what an SBOM is and the fundamental reasons why we need it now.
2. 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.
3. Generating a Project SBOM: Guides you through the practical methods for extracting an SBOM directly from a project under development.
4. CI/CD Integration: Covers how to automate SBOM generation in CI/CD pipelines such as Jenkins and GitHub Actions.
5. 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.

• Supplier Guide (For Suppliers)
• How to Generate an SBOM

2.1 - SBOM Concept and Necessity

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

Key Components of an SBOM

Component Information

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

Metadata

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

Related Documents

• SBOM Standards Comparison (SPDX vs CycloneDX)
• Supplier Guide: How to generate and submit an SBOM

References

• NTIA SBOM Minimum Elements
• CISA SBOM Sharing Lifecycle
• Linux Foundation: SBOM Guide

2.2 - SBOM Standards

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

1. 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

2. 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

1. It was designed from the ground up for security vulnerability management.

• Vulnerabilities
• Security Analysis results
• Threats

2. Compared to SPDX, its structure is concise and easy to understand.

• Focus on essential information
• JSON and XML format support
• Small file size

3. 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

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

SK Telecom Recommendation

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

Related Documents

• What Is an SBOM?: The concept and necessity of an SBOM
• Supplier Submission Requirements: Formats and versions accepted by SK Telecom

References

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison

3 - Supplier SBOM Submission Guide

To strengthen the transparency and security of its software supply chain, SK Telecom asks suppliers to submit an SBOM (Software Bill of Materials) for all software components and dependencies they deliver. This guide explains how suppliers can generate and submit an SBOM in a format that meets SK Telecom’s security policy.

Scope of Application

All suppliers (including developers and resellers) that deliver the following types of software are subject to these guidelines.

• Source code: Applications written in Java, Python, JavaScript, Go, C/C++, etc.
• Container images: Docker images or OCI-compliant containers
• Executables: Compiled binaries (.jar, .dll, .so) and libraries
• Embedded systems: Firmware images, RootFS, device drivers

SBOM Submission Process

We ask suppliers to follow the procedure below, from the time of contract through final delivery.

flowchart TD
    A[Contract Review] --> B["Software Development/Build"]
    B --> C{Generate SBOM}
    C -->|Use SKT-provided tool| D[Use SKT SBOM Generator]
    C -->|Use your own tool| E["Use open source tools<br>(cdxgen, Syft, etc.)"]
    D --> F["Data Validation (PURL Check)"]
    E --> F
    F --> G["Submit SBOM (Email/Portal)"]
    G --> H[SKT Security Review]
    H -->|Approved| I[Delivery Complete]
    H -->|Rejected| J[Remediate and Resubmit]
    J --> F

Guide Structure

This section is organized as follows.

1. Submission Requirements: Defines the required formats (CycloneDX, SPDX) and data fields that SK Telecom requires.
2. SKT SBOM Generator: Explains how to use SK Telecom’s SBOM generation tool.
3. Using Open Source Tools: Explains how to generate an SBOM using general-purpose open source tools (cdxgen, Syft, etc.).
4. Validation Checklist: Provides a checklist of essential items to verify before submission.
5. Submission Process: Explains the naming conventions and submission channels for the generated SBOM file.

Related Documents

• SK Telecom Supply Chain Security Policy: Background and principles of the mandatory SBOM submission policy
• Global Regulatory Trends: Domestic and international regulatory landscape related to SBOM

3.1 - SBOM Submission Requirements

1. Standard Data Formats

SK Telecom supports both formats that have become established as global standards. Suppliers may choose and submit the format supported by the tool they use.

Note: Both formats are recognized equally, but CycloneDX (JSON) format is recommended for internal system interoperability.

2. Required Information

The SBOM document you submit must include the following information. Missing information may result in rejection.

2.1 Metadata

Information about the document itself and the generation tool.

• Timestamp: Generation date and time (ISO 8601 format)
• Tool Info: Vendor, name, and version of the generation tool (e.g., CycloneDX-Maven-Plugin v2.7.9)
• Component Info: Name and version of the top-level software being delivered

Generation Tool Specification Format

Generation tool information must be recorded in the following fields depending on the format.

• SPDX: Record the tool name and version in the creationInfo.creators field with the Tool: prefix
• CycloneDX: Record vendor, name, and version in the metadata.tools array

// SPDX creationInfo example
"creationInfo": {
  "created": "2026-04-06T03:22:00Z",
  "creators": ["Tool: Syft-0.98.0", "Organization: VendorName"]
}

2.2 Components

Information about the individual libraries that make up the software.

• Name: Component name (e.g., commons-lang3)
• Version: Component version (e.g., 3.12.0) — Required: Vulnerability mapping is impossible without the version
• PURL (Package URL): [Required] Package identifier

Version information must be included. Each package/component must record its exact version in SPDX’s versionInfo field or CycloneDX’s version field. Without a version, mapping to the vulnerability database is impossible, so security analysis cannot be performed.

2.3 Dependency Scope

Important: Transitive dependencies must be included.

SK Telecom analyzes vulnerabilities based on the submitted SBOM. An SBOM that includes only direct dependencies may miss hidden vulnerabilities and may therefore be rejected.

What are transitive dependencies?

For example, if a project uses library-A directly, and library-A internally uses library-B, then library-B is a transitive dependency. Even if library-B has a vulnerability, it cannot be detected unless it is included in the SBOM.

MyApp
  └─ library-A v1.0 (direct dependency)  ← explicitly declared by the supplier
       └─ library-B v2.3 (transitive dependency)  ← must be included in the SBOM
            └─ library-C v0.9 (transitive dependency)  ← must be included in the SBOM

Prerequisites for generating a correct SBOM

For transitive dependencies to be included accurately, the SBOM must be generated with the build (or package installation) completed. When only source code is present, transitive dependencies may be omitted.

• Java (Maven): Generate after running mvn package or mvn dependency:resolve
• Java (Gradle): Generate after running ./gradlew dependencies
• Python: Generate after pip install -r requirements.txt (with the virtual environment activated)
• Node.js: Generate after running npm install or yarn install
• Go: Generate after running go mod download

For how to include transitive dependencies with each tool, refer to the Using Open Source Tools guide.

3. Package URL (PURL) Compliance

PURL (Package URL) is a standard URL format for uniquely identifying a software package. SK Telecom’s vulnerability analysis system operates based on PURL, so a valid PURL must be included for every component.

A PURL must be in the standard format beginning with the pkg: prefix. Free text such as name:version or org/repo:tag is not allowed; in such cases vulnerability mapping is impossible and the SBOM will be rejected.

PURL Examples by Language

PURL Type Restrictions

The purl must be of a type that can identify the ecosystem.

Correct / Incorrect PURL Examples

For detailed PURL specifications, refer to the official Package URL spec.

4. Sample Document

CycloneDX Sample

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2023-10-15T10:30:00Z",
    "tools": [{
      "vendor": "Example Corp",
      "name": "cyclonedx-maven-plugin",
      "version": "2.7.9"
    }],
    "component": {
      "type": "application",
      "name": "PaymentModule",
      "version": "2.1.0",
      "purl": "pkg:maven/com.example/payment-module@2.1.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"
      }
    }]
  }]
}
...

References

• CycloneDX Specification
• SPDX Specification
• Package URL Specification

Related Documents

• Supplier Guide Home
• SKT SBOM Generator: SK Telecom’s SBOM generation tool
• Using Open Source Tools: Guidance on open source tools such as cdxgen and Syft
• Validation Checklist: Items to verify before submission
• Submission Process: Submission method and email template

3.2 - SKT SBOM Generator

SKT SBOM Generator

The SKT SBOM Generator is an open source tool that lets suppliers generate deliverables that meet SK Telecom policy in a Docker environment. You do not need to install per-language tools locally; it analyzes multiple languages and produces a CycloneDX (JSON) deliverable.

This page covers only the quick start. For installation, the full set of options, language-specific guides, input scenarios, the web UI, and other details, see the official repository documentation.

github.com/sktelecom/sbom-tools

Bug reports, feature suggestions, and Pull Request contributions are welcome.

Deliverables Generated

A single run generates the following three deliverables together (the --all option).

Prerequisites

The SBOM Generator runs on Docker. Install and run Docker Engine 20.10 or later. On Windows without Docker, we recommend Rancher Desktop, which is free. The first run downloads a scanner image (about 3–4 GB), so it takes roughly 5–15 minutes.

Getting Started on Windows (No Command Line)

If you are not comfortable with the command line, you can generate an SBOM in one of two ways. For the full procedure, see the Windows quick start guide.

• Executable: Download SBOM-Generator-*.exe from the latest release and double-click it. The file is not yet code-signed, so if Windows SmartScreen warns, click “More info” and then “Run anyway”.
• Repository ZIP: From the repository’s Code button, choose Download ZIP, unzip it, and double-click scripts\sbom-ui.bat; the browser opens http://localhost:8080.

In the web UI, the progress log is shown in real time on the right, and you can download the deliverables when it finishes.

Quick Start (CLI)

On macOS and Linux, download and run the script from a shell.

curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh
cd /path/to/my-project
/path/to/scan-sbom.sh --project "MyApp" --version "1.0.0" --all --generate-only

• --generate-only creates files only locally, without uploading them to the portal (recommended until submission).
• For the web UI, run ./scan-sbom.sh --ui (the browser opens http://localhost:8080).
• On Windows, run the same commands through scripts\scan-sbom.bat (it forwards them via Git Bash, so Git for Windows is required).
• For other input forms such as a GitHub URL, source ZIP, Docker image, firmware, or binary, and the full set of options, see the Usage Guide.

Learn More

The authoritative source for using the tool is the repository documentation.

Next Steps

After generating the SBOM, verify the file with the Validation Checklist and submit it following the Submission Process. For the required data fields, see the Submission Requirements; to use tools such as cdxgen or Syft directly instead of the SKT tool, see Using Open Source Tools.

3.3 - Generating an SBOM with Open Source Tools

If you cannot use the SKT-provided tool, or you already have your own build pipeline, you can use open source tools directly. Below is a list of the major open source tools validated by SK Telecom, along with links to their official documentation.

If you are not comfortable setting up a tool environment and you have Docker installed, consider reviewing the SKT SBOM Generator first.

Tool Selection Guide

graph TD
    A[Identify analysis target] --> B{Is it source code?}
    B -- Yes --> C[cdxgen recommended]
    B -- No --> D{Is it a Docker image?}
    D -- Yes --> E[Syft or Trivy recommended]
    D -- No --> F[Binary/Firmware]
    F --> G[Syft recommended]

Major Tools

cdxgen (recommended for source code analysis)

Automatically analyzes projects in various languages such as Java, Python, Node.js, and Go, and generates an SBOM in CycloneDX format.

• Official documentation: https://cdxgen.github.io/cdxgen
• GitHub: https://github.com/CycloneDX/cdxgen
• Supported languages: Java (Maven/Gradle), Python, Node.js, Go, Ruby, PHP, Rust, .NET, C/C++, etc.

Syft (recommended for container image and binary analysis)

Analyzes Docker images, file systems, and binary files to identify both OS packages and application libraries. Supports CycloneDX and SPDX formats.

• Official documentation: https://github.com/anchore/syft
• Supported targets: Docker images, OCI images, tar files, file system directories

Trivy (container image analysis)

An all-in-one tool that can perform container image analysis and vulnerability scanning together.

• Official documentation: https://aquasecurity.github.io/trivy/
• GitHub: https://github.com/aquasecurity/trivy

Security Warning — Trivy Supply Chain Attack Incident (2026)

In March 2026, a supply chain attack occurred in which an attacker re-pointed existing release tags of aquasecurity/trivy to inject malware. The GitHub release v0.69.4 (3/19) and the DockerHub images v0.69.5 and v0.69.6 (3/22) have been confirmed as compromised, so please stop using them.

To use Trivy safely, follow these principles.

• GitHub Actions: Use a pinned commit SHA or a verified version tag instead of mutable tags (@master, @latest, @v1, etc.).

  # Recommended: pin to a verified version
  - uses: aquasecurity/trivy-action@0.35.0
  # Safer: pin to a commit SHA
  - uses: aquasecurity/trivy-action@<commit-sha>
  

• Docker images: Specify a particular version tag, or pin to an image digest (@sha256:...).

  docker run aquasecurity/trivy:<verified-version> image <target-image>
  

• Official channels: Check the latest security advisories through the GitHub Security Advisory.

This incident shows that if you do not pin versions when adopting an open source tool, you can be exposed to a supply chain attack at any time. Always specify the version of every external tool and verify its integrity before use.

Language-Specific Dedicated Plugins

Using a build tool plugin lets you extract more accurate dependency information.

Verifying Transitive Dependency Inclusion

An SBOM submitted to SK Telecom must include transitive dependencies.

Transitive dependencies are libraries that the project does not declare directly, but on which the libraries it uses depend internally. If these are omitted, hidden vulnerabilities cannot be detected and the SBOM may be rejected.

Key principle: Generate the SBOM after the build (package installation) is complete.

When only source code is present, transitive dependencies may be omitted. Refer to the table below and complete the prerequisite steps before generating the SBOM.

Transitive Dependency Support by Tool

Recommendation: When delivering as a Docker image, scanning the built image with Syft can include more complete transitive dependencies than source code analysis.

Common Precautions

Verify the following before using a tool.

• Transitive dependency inclusion: Refer to the table above and complete the prerequisite steps before generating the SBOM. Missing dependencies are grounds for rejection.
• PURL inclusion: Verify that the generated SBOM includes a purl field for every component. SK Telecom’s system maps vulnerabilities based on PURL.
• Output format: CycloneDX JSON format is recommended. (Use -o cyclonedx-json or an equivalent option)
• Project information: Verify that the metadata accurately records the name and version of the delivered project.

Related Documents

• Submission Requirements: The required data fields that must be included in the SBOM
• Validation Checklist: Items to verify before submission
• SKT SBOM Generator: SK Telecom’s SBOM generation tool

3.4 - Pre-Submission SBOM Validation Checklist

Essential Checklist Items

An SBOM that does not pass the checklist below may be automatically rejected by the system.

1. File Integrity

• Is the file extension .json or .xml? (Not an archive file)
• Is the file size at least 1KB, and the content not empty?
• Are there any JSON syntax errors? (Verification with jq or similar is recommended)

2. Required Data Fields

• bomFormat: Is CycloneDX or SPDX specified?
• Metadata: Are the name and version of the top-level component (the delivered project) accurate?
• Components: Does the list of included libraries match the actual ones?

3. Dependency Completeness Check

Missing transitive dependencies are the most common reason for rejection. Be sure to verify the items below.

• Are all direct dependencies (libraries explicitly declared by the project) included?
• Are transitive dependencies (libraries that the direct dependencies use internally) included?
• Did you complete the build (or package installation) before generating the SBOM? (e.g., npm install, mvn package, pip install)
• Is the number of components reasonable? (If a project with only a few direct dependencies has fewer than 10 total components, transitive dependencies have likely been omitted)

Dependency count guideline: A typical web application, including transitive dependencies, contains dozens to hundreds of components. If the component count in your SBOM is significantly lower than expected, treat it with suspicion.

4. Identifier (PURL) Check

SK Telecom’s system maps vulnerabilities by PURL. This is the most important item.

• Does every component (components) object contain a purl field?
• Does the PURL format follow the standard (pkg:type/namespace/name@version)?
• Are special characters within the PURL correctly encoded?

Online Validation Tool

• CycloneDX Validator: https://cyclonedx.github.io/cyclonedx-web-tool/validate

Related Documents

• Submission Requirements: Detailed guidance on required data fields and PURL format
• Submission Process: How to submit after passing the checklist
• SKT SBOM Generator: A tool that generates an SBOM meeting the checklist items

3.5 - SBOM Submission Process

1. When to Submit

• At initial delivery after concluding a software contract
• When a major or minor version of the software is updated
• When a regular submission schedule specified in the contract arrives

2. How to Submit

The SBOM file is submitted to SK Telecom’s business unit and security team representatives via email or a designated system.

Submission Method

• Deliver the SBOM file to the business unit and security team representatives via email or a channel designated by the representative.
• Email subject: [SBOM Submission] SupplierName_ProjectName_Version
• Attachment: The generated SBOM file (password-protected archive files are not allowed)

Required information in the body:

1. Delivery contract number
2. Representative information (name, department, contact)
3. Project information (system name, detailed version)
4. Tool used (e.g., SKT SBOM Generator v1.0)

TOSCA Registration Obligation of the Business Unit Representative

The SK Telecom business unit representative who receives an SBOM from a supplier must register that SBOM in TOSCA, the internal open source and SBOM management system.

TOSCA (SK Telecom Open Source & SBOM Management System) https://tosca.sktelecom.com

• TOSCA is an SK Telecom internal system, accessible only to company employees.
• [For SKT Members] Supplier SBOM registration and report output guide: https://confluence.tde.sktelecom.com/x/bYNULw

3. Post-Submission Validation and Actions

After being registered in TOSCA, the submitted SBOM is validated according to the procedure below.

The validation results and action requests are communicated to the supplier and the security team representative through the business unit representative.

Related Documents

• Validation Checklist: Essential items to verify before submission
• Submission Requirements: SBOM format and required data fields
• Supplier Guide Home: View the full process flow