Supply Chain Security

• 1: Supplier SBOM Submission Guide
• 1.1: SBOM Submission Requirements
• 1.2: Generating an SBOM with Open Source Tools
• 1.3: BomLens
• 1.4: Generating a Server (OS + Application) SBOM
• 1.5: Submitting an SBOM for Commercial Software and Finished Products
• 1.6: Pre-Submission SBOM Validation Checklist
• 1.7: SBOM Submission Process
• 1.8: Common Rejection Reasons
• 2: Software Supply Chain Attacks and the Need for Security
• 2.1: Regulatory Trends
• 2.2: SK Telecom Supply Chain Security Policy
• 3: What Is an SBOM?
• 3.1: SBOM Concept and Necessity
• 3.2: SBOM Standards

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

Quick Start: Five Steps to Submission

1. Check the accepted formats (CycloneDX JSON recommended) and required data fields in the Submission Requirements.
2. Generate the SBOM following How to Generate an SBOM, choosing the tool that fits your delivery. If setting up a tool environment is a burden, we recommend BomLens.
3. If you deliver a server with an application on top of an OS, generate per layer and merge, following Server SBOM.
4. Verify PURLs and transitive dependency coverage with the Validation Checklist.
5. Name the file and submit it following the Submission Process.

If you supply commercial software or a finished product made by a third party and have no access to the source code, skip steps 2–3 and follow Commercial Software to obtain the SBOM from the manufacturer and submit it. If your submission is rejected, check Common Rejection Reasons for the cause and how to fix it.

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
• Servers: A system combining an OS (rootfs and installed packages) with an application and statically linked libraries
• Commercial software and finished products: packaged software or appliances made by a third party (including reseller and distributor deliveries)

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 BomLens]
    C -->|Use your own tool| E["Use open source tools<br>(cdxgen, Syft, etc.)"]
    C -->|Commercial finished product| K[Obtain the manufacturer's SBOM]
    D --> F["Data Validation (PURL Check)"]
    E --> F
    K --> F
    F --> G["Submit SBOM (Email/Designated channel)"]
    G --> H[SKT Security Review]
    H -->|Approved| I[Delivery Complete]
    H -->|Rejected| J[Remediate and Resubmit]
    J --> F

    classDef start fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
    classDef proc fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
    classDef decision fill:#FFF3CD,stroke:#E0A800,color:#5A4100,stroke-width:1.5px
    classDef good fill:#D9F0E4,stroke:#00A651,color:#0A5A32,stroke-width:1.5px
    classDef danger fill:#FDE1E7,stroke:#EA002C,color:#8A0019,stroke-width:1.5px
    classDef vendor fill:#FFF3CD,stroke:#E0A800,color:#5A4100,stroke-width:1.5px

    class A start
    class B,E,F,G proc
    class C,H decision
    class D,I good
    class J danger
    class K vendor

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

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

Requirement Levels at a Glance

The requirement level of each item. A missing required item leads to rejection. A missing recommended item does not, but including it is encouraged.

Download the example SBOM file (CycloneDX 1.6 JSON) that meets the acceptance criteria and compare its structure.

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. Record the exact version in SPDX’s versionInfo field or CycloneDX’s version field; without a version, vulnerability mapping is impossible.
• PURL (Package URL): [Required] Package identifier

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.

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. The type must identify the ecosystem; pkg:generic/ is not allowed.

PURL Examples by Language

Correct / Incorrect PURL Examples

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

4. Sample Document

CycloneDX Sample

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-04-06T10: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
• BomLens: 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, plus the validation tools (BomLens automated validation, CycloneDX Validator)
• Submission Process: Submission method and email template

1.2 - Generating an SBOM with Open Source Tools

If you are not comfortable setting up a tool environment and you have Docker installed, consider reviewing BomLens first.

Tool Selection Guide

graph TD
    A{{"Classify the supplied software"}}

    subgraph G1["Software delivery"]
      direction LR
      T1["Source code / app<br>(e.g., OSS/BSS, portals, middleware)"]
      T2["Executable / library<br>(e.g., .jar, .dll, .so)"]
      T3["Firmware with no OS<br>(e.g., bare-metal / RTOS devices)"]
    end

    subgraph G2["Delivery including an OS (e.g., Linux)"]
      direction LR
      T4["Container image<br>(e.g., CNF, containerized network function)"]
      T5["Server / VM image<br>(e.g., VNF, server appliance)"]
      T6["Firmware with an embedded OS<br>(e.g., base stations, routers, OLT/ONT, set-top boxes)"]
    end

    %% Left: source-code scan with an inner box
    subgraph M1["Scan the source code"]
      M1_Sub["cdxgen or BomLens"]
    end

    %% Right: source + OS image scan with inner boxes (stacked vertically)
    subgraph M2["Scan source + OS image"]
      direction TB
      M2_Top["OS (e.g., Linux) scan<br>(Syft or Trivy)"]
      M2_Bottom["Source code scan<br>(cdxgen or BomLens)"]
    end

    A --> G1
    A --> G2
    
    %% Connect only to the group borders (one arrow per box)
    G1 --> M1
    G2 --> M2
    
    %% Groups flow to the next step
    M1 --> P(["Submit the SBOM"])
    M2 --> P

    classDef start fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
    classDef typebox fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
    classDef submit fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
    
    %% White inner-box styles (left/right border colors)
    classDef subwhite_left fill:#ffffff,stroke:#00A651,color:#171717,stroke-width:1px
    classDef subwhite_right fill:#ffffff,stroke:#68127A,color:#171717,stroke-width:1px

    class A start
    class T1,T2,T3,T4,T5,T6 typebox
    class M1_Sub subwhite_left
    class M2_Top,M2_Bottom subwhite_right
    class P submit

    style G1 fill:#F1FAF5,stroke:#00A651,stroke-width:1px,color:#0A5A32
    style G2 fill:#FAF4FB,stroke:#68127A,stroke-width:1px,color:#4A0D57
    
    %% Outer group boxes keep their fill and border colors
    style M1 fill:#D9F0E4,stroke:#00A651,stroke-width:1px,color:#0A5A32
    style M2 fill:#EEDCF3,stroke:#68127A,stroke-width:1px,color:#4A0D57

Source code and apps, executables or libraries, and firmware with no OS are all scanned from the source code you developed with cdxgen or BomLens. Scanning a finished binary directly yields no package manager metadata, so purls are omitted and the SBOM is rejected.

When you ship an OS or base image as part of the delivery (a container image, a server, or firmware with an embedded OS), split it into two layers and scan each. Scan the image or rootfs as shipped with Syft or Trivy for the OS layer, scan the source code (the app layer) with cdxgen or BomLens, then merge and submit. The OS-layer scan target is not the original base image you received but the image or rootfs actually delivered after the build, because it must include the OS packages installed during the build. For the full procedure, see Server SBOM.

Statically linked libraries and manually vendored binaries are a blind spot that none of the scans above catch. For how to handle this case, see the statically linked libraries section of Server SBOM.

If you supply commercial software or a finished product made by a third party and have no access to the source code, obtain the SBOM from the manufacturer instead of scanning. See Commercial Software.

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.

cdxgen statically parses lockfiles and manifests. For accurate results, run it when dependencies are installed or resolved (a lockfile is present, or after a build). Scanning pure source without resolved dependencies may omit some components or purls.

Syft (recommended for container image and binary analysis)

Analyzes built container images and build artifacts that include package manager metadata to identify both OS packages and application libraries. Supports CycloneDX and SPDX formats.

• Official documentation: https://github.com/anchore/syft
• Recommended analysis targets: built Docker images, OCI images, tar files

# Recommended: scan a built image (PURL and ecosystem identified automatically)
syft <image-name>:<tag> -o cyclonedx-json=sbom.json

# Not recommended: scan an installation directory or raw files (rejected due to missing PURL)
syft dir:/root/nag_pkg   # without package manager metadata, PURL count becomes 0

A server that delivers an application on top of an OS (such as CentOS) is generated as two layers — OS (rootfs/image) and application — with statically linked libraries covered separately, then merged. As the warning above notes, the OS layer must target a rootfs or image that has a package database. For the full procedure, see Server SBOM.

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

Language-Specific Dedicated Plugins

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

Common Precautions

Verify the following before using a tool.

• Transitive dependency inclusion: Generate the SBOM after the build (package installation) is complete so that transitive dependencies are included. Missing dependencies are grounds for rejection; for the per-language build commands to run first, see the dependency scope section of the Submission Requirements.
• PURL inclusion: Verify that the generated SBOM includes a purl field for every component. SK Telecom’s system maps vulnerabilities based on PURL. For the verification commands and the regeneration procedure, see the Validation Checklist.
• 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

• Server SBOM: How to generate and merge the layers of a server that combines an OS, an application, and static-link libraries
• Submission Requirements: The required data fields that must be included in the SBOM
• Validation Checklist: Items to verify before submission
• BomLens: SK Telecom’s SBOM generation tool

1.3 - BomLens

BomLens

BomLens 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/bomlens

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

BomLens 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 no command line quick start.

• Executable: Download SBOM-Generator-*.exe (the BomLens executable) 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/bomlens/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 submitting them (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 CLI reference.

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.

1.4 - Generating a Server (OS + Application) SBOM

This document is an advanced guide for suppliers that deliver a server with an application on top of an OS. For an ordinary application delivery, How to Generate an SBOM is sufficient.

Treat the server as two layers — the OS and the application — generate each separately, then merge them. Both are produced with BomLens; only the input changes. In addition, statically linked libraries (for example an openssl built into the binary) are a blind spot that neither layer’s scan catches, so they are handled separately. Missing them is the most common cause of rejection in server delivery.

The two layers of a server

Generating each layer

The commands below use BomLens’s scan-sbom.sh script. For installing BomLens and its basics (downloading the script, the options, the web UI, and so on), see BomLens first. If you use open source tools directly instead of BomLens, scan the OS layer with Syft (or Trivy) and the application layer with cdxgen; see Using Open Source Tools for the commands.

OS layer

Scan the server’s rootfs (the extracted root filesystem) or a container image of it. The target must be the delivered, built state — not the base image you started from — because the OS packages installed during the build have to be included. The package database (rpm/dpkg/apk) is read so every installed package gets a real purl (pkg:rpm/...).

# Target a rootfs directory
scan-sbom.sh --project myserver-os --version 7 --target /path/to/server-rootfs --all --generate-only

# Or, if the server is packaged as a container image
scan-sbom.sh --project myserver-os --version 7 --target myserver:7 --all --generate-only

The target must contain the package database. A folder holding only unpacked install files, with no rpm database, yields empty purls and is rejected.

Application layer

Scan the application source after the build. With a package manager (Maven, npm, pip, Go modules, Conan, and others), transitive dependencies resolve automatically.

cd /path/to/app-source
scan-sbom.sh --project myserver-app --version 2.0.0 --all --generate-only

A pure CMake/Make application with no manifest produces a sparse component list; add --deep-license to record the first-party source licenses.

Static-link libraries (a blind spot)

Statically linked libraries are not declared by a package manager and not listed in the OS package database, so neither layer’s scan finds them. There is no fully automatic path, so combine two approaches. Analyze the delivered binary for what tooling can find, and for what it still misses, record the source and version by hand from the build script (for example openssl 1.1.1za).

scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only

A precise inventory of statically linked components comes from binary composition analysis (BDBA), which SK Telecom runs as a complementary check.

Merge into one BOM for submission

SK Telecom’s submission system registers one SBOM per product. Merge the per-layer SBOMs with --merge into a single BOM and stamp the top-level component with the delivered product name and version. --merge dedupes by purl, so a library appearing in more than one layer is counted once.

scan-sbom.sh --project myserver --version 1.0.0 \
  --merge myserver-os_7_bom.json myserver-app_2.0.0_bom.json myserver-bin_2.0.0_bom.json \
  --generate-only

If the whole server is delivered as a single container image, you can scan that image with --target to capture the OS and application layers together.

Multi-node clusters

A product in which multiple nodes form one cluster is still submitted as one SBOM per product; you do not need one per node.

• If every node has the same configuration, generate and merge the layers from one representative node.
• If the installed software differs by node role (for example, a management node and storage nodes), generate the per-layer SBOMs for each role, then merge everything into a single BOM with --merge.

Verify before submitting

Check that components carry real purls in both the per-layer SBOMs and the merged one. For the verification commands and the full check, follow the Validation Checklist.

Learn more

The detailed procedure and examples for server delivery live in the canonical BomLens documentation.

Server delivery guide

Related Documents

• BomLens: SK Telecom’s SBOM generation tool
• Using Open Source Tools: using cdxgen/Syft directly
• Submission Requirements: required data fields
• Validation Checklist: items to verify before submission

1.5 - Submitting an SBOM for Commercial Software and Finished Products

This document is for suppliers that deliver commercial software or finished products they did not develop. In this case the supplier has no access to the source code, so the source-scan approach in How to Generate an SBOM does not apply. Obtain the SBOM from the original manufacturer and submit it.

Scanning the delivered equipment or its installed image with a tool is not an alternative. The commercial software has no package manager metadata, so its components come out without purls, vulnerability matching fails, and the SBOM is rejected.

Scope

This applies when you supply third-party products in forms such as the following.

• Commercial software resale: supplying licenses for packaged software developed by a third party (resellers, distributors)
• Appliances and finished products: equipment shipped by the manufacturer with the OS and software preinstalled (e.g., storage, backup appliances, network equipment)
• Systems that include third-party products: deliveries combining in-house components with commercial products

If part of the delivery is developed in-house, generate the SBOM for that part yourself following How to Generate an SBOM, and submit the manufacturer’s SBOM for the commercial part alongside it.

Obtaining the SBOM from the manufacturer

Request an SBOM in CycloneDX or SPDX format from the original manufacturer (or developer). With regulations such as US Executive Order 14028 and the EU Cyber Resilience Act in force, most global manufacturers now have a process for providing per-product SBOMs. Including the following in your request speeds up the response.

• Format: CycloneDX JSON (recommended) or SPDX
• Target: the exact model name and version of the delivered product
• Coverage: if the product ships with an OS, the OS packages must be included

Whether and how quickly a manufacturer can provide an SBOM varies, so request it during contract review to stay on the delivery schedule.

Checking the received SBOM

An SBOM received from the manufacturer is reviewed by the same criteria as one you generate yourself. Before submitting, check the following.

1. Compliance with the Submission Requirements: standard format and version, metadata, component names and versions, purls
2. The Validation Checklist: purl coverage and the other required items
3. Version match: the top-level component in the SBOM matches the name and version of the product actually delivered

Then name the file and submit it following the Submission Process.

If the product is a cluster

A product in which multiple nodes form one cluster (for example, distributed storage) is still submitted as one SBOM per product. For how to determine the SBOM unit, see the multi-node cluster section of Server SBOM.

If the manufacturer cannot provide an SBOM

If the manufacturer replies that it cannot provide an SBOM, contact opensource@sktelecom.com before generating and submitting one by other means.

Related Documents

• Submission Requirements: required formats and data fields
• Validation Checklist: items to verify before submission
• Submission Process: naming conventions and submission channels
• Server SBOM: the SBOM unit for multi-node clusters

1.6 - Pre-Submission SBOM Validation Checklist

Essential Checklist Items

An SBOM that does not pass the checklist below may be automatically rejected by the system. Items 2 through 4 can be checked at once with BomLens automated validation under Validation Tools below.

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)

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 number of components with a PURL match (or come close to) the total component count?
• Does the PURL format follow the standard (pkg:type/namespace/name@version)?
• Are special characters within the PURL correctly encoded?

Use the commands below to check the PURL count directly. The total component count and the PURL-bearing count should be equal.

# CycloneDX — the two values should be equal
jq '.components | length' sbom.json                      # total component count
jq '[.components[] | select(.purl)] | length' sbom.json  # count with a PURL

# SPDX — number of packages that have a PURL (externalRef)
jq '[.packages[] | select(.externalRefs[]?.referenceType == "purl")] | length' sbom.json

If the PURL-bearing count is 0 or significantly lower than the total component count, do not submit. For the cause and how to regenerate, see Common Rejection Reasons.

Validation Tools

BomLens Automated Validation (Recommended)

The SBOM analysis feature of BomLens automatically checks the Submission Requirements, covering items 2 through 4 of the checklist above. Version 1.8.0 or later is required.

./scripts/scan-sbom.sh --project my-app --version 1.0.0 \
  --analyze "./sbom.json" \
  --generate-only

Running it produces a conformance report (my-app_1.0.0_conformance.html) in the my-app_1.0.0/ folder. The report automatically verifies the following items.

If the result is fail, the report lists which components fall short on which item, so you can fix those parts, regenerate the SBOM, and validate again. The same validation is available in the web UI (run with --ui and upload the SBOM).

CycloneDX Validator (Schema Check)

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

An online tool that checks whether a CycloneDX file conforms to the standard schema. It is useful for quickly checking JSON syntax and format errors (checklist item 1) without installing anything. However, it performs schema validation only — passing it does not mean items 2 through 4 (required fields, dependency completeness, PURL) are met. It cannot check SPDX files.

Related Documents

• Common Rejection Reasons: Causes and fixes for each rejection reason
• Submission Requirements: Detailed guidance on required data fields and PURL format, including an example SBOM file that meets the acceptance criteria
• Submission Process: How to submit after passing the checklist
• BomLens: A tool that generates an SBOM meeting the checklist items

1.7 - 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 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 and its version (e.g., BomLens, cdxgen)

3. Post-Submission Validation and Actions

The submitted SBOM is registered in TOSCA, the internal open source and SBOM management system, and then validated according to the procedure below. TOSCA is an internal system, so suppliers do not need access to it.

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
• Common Rejection Reasons: Identifying causes and remediating after a rejection
• Submission Requirements: SBOM format and required data fields
• Supplier Guide Home: View the full process flow

1.8 - Common Rejection Reasons

Submitted SBOMs go through format validation and vulnerability analysis, and are rejected if they fall short of the criteria. Below are the rejection reasons that come up repeatedly in actual intake. Review them together with the Validation Checklist before submitting.

Rejection Reasons at a Glance

Representative Cases

Case 1: All PURLs missing from an installation-directory scan

A supplier scanned an installation directory with syft dir:/root/nag_pkg and submitted an SBOM in which none of the 261 components had a purl; all 251 vulnerability matches failed and the SBOM was rejected outright. When you scan a location without package manager metadata (package.json, go.mod, an RPM/DEB package DB, etc.), the tool cannot identify the ecosystem.

Change the scan target to a built image or the source code, and check the purl count right after generation. The verification commands are in the Validation Checklist.

Case 2: Transitive dependencies missing from a pre-build scan

If a project has several direct dependencies but the SBOM has fewer than 10 components in total, suspect missing transitive dependencies. A typical web application yields tens to hundreds of components once transitive dependencies are included. Completing the build first (npm install, mvn package, and the like) and then generating resolves this.

What a Passing SBOM Looks Like

Download the example file that meets the acceptance criteria and compare its structure. Every component has a purl and a version, and the dependencies array captures both direct and transitive relationships.

• Download the example SBOM (CycloneDX 1.6 JSON)

Related Documents

• Validation Checklist: Pre-submission checks and verification commands
• Submission Requirements: Required data fields and PURL rules
• Submission Process: The remediation and resubmission process after a rejection

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

    classDef danger fill:#FDE1E7,stroke:#EA002C,color:#8A0019,stroke-width:1.5px
    classDef victim fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
    class A,B,C danger
    class D,E,F victim

2. Notable Attack Cases

• The SolarWinds incident (2020): The build system was hacked and a backdoor was planted in officially signed updates, affecting some 18,000 organizations worldwide including U.S. government agencies. It demonstrated that even software from a trusted vendor may not be safe.
• The Log4j vulnerability (2021): A remote code execution vulnerability in a widely used logging library exposed hundreds of millions of servers worldwide. It drove home the need for a way to know which open source components your systems use — that is, an SBOM.

3. Why Supply Chain Security?

70-90% of modern application code consists of open source components. When a single common component is compromised the damage spreads worldwide, and code compromised at the build stage is hard to catch with traditional security checks such as firewalls and antivirus. To manage this risk, SK Telecom has adopted SBOMs and enforces a supply chain security policy.

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

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

Key Provisions

• Push toward SBOM requirements: EO 14028 directed defining the minimum elements of an SBOM (data fields, automation support, etc.) and secure software development practices; the SBOM submission and self-attestation requirements for federal suppliers were detailed in subsequent OMB guidance.
• 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).

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, which is, in principle, at least five years. If the expected use period is shorter than five years, the support period matches it (Regulation (EU) 2024/2847, Article 13 and Recital 60). In other words, five years is a baseline, not a cap.
• Vulnerability reporting obligation: On becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer must submit an early warning to the coordinating CSIRT and ENISA within 24 hours, followed within 72 hours by a notification and, later, a final report (Regulation (EU) 2024/2847, Article 14).
• 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.
• Supplier security activities: Suppliers are advised to build a secure development environment, generate and provide an SBOM, and inspect for security vulnerabilities.

SK Telecom’s requirements in response to these regulatory trends are laid out in the SK Telecom Supply Chain Security Policy.

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

2.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.
• The accepted formats and required data fields are defined in the Submission Requirements.

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

3 - What Is an SBOM?

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

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.

For the practical side — actually generating, validating, and submitting an SBOM — see the Supplier Guide.

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

    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 lib

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

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

3.2 - SBOM Standards

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

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

Related Documents

• What Is an SBOM?: SBOM concepts and why they matter
• Supplier Submission Requirements: Formats and versions SK Telecom accepts

References

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison