diff --git a/content/en/guide/supply-chain/_index.md b/content/en/guide/supply-chain/_index.md index 289048ce3..806cb7f5f 100644 --- a/content/en/guide/supply-chain/_index.md +++ b/content/en/guide/supply-chain/_index.md @@ -18,15 +18,11 @@ If you are a supplier delivering software to SK Telecom, start right away with t ## New to Supply Chain Security? -In recent years, alongside license compliance, security vulnerability management and software supply chain security have emerged as critical challenges in the open source ecosystem. As regulations tighten in the United States and Europe, SBOM (Software Bill of Materials) management and systematic vulnerability response have become essential. - -To learn the background step by step, we recommend the following order. +As regulations tighten in the United States and Europe, SBOM (Software Bill of Materials) management and systematic vulnerability response have become essential. To learn the background step by step, we recommend the following order. 1. [What Is Supply Chain Security?](overview/): Explains supply chain attack cases, why security matters, the global regulatory landscape, and SK Telecom's policy. 2. [What Is an SBOM?](sbom/): Covers SBOM concepts and standards (SPDX, CycloneDX). -Related standards such as ISO/IEC 18974 (OpenChain Security Assurance), SPDX (ISO/IEC 5962), CycloneDX (ECMA-424), and NIST SSDF, as well as regulatory trends such as U.S. EO 14028 and the EU Cyber Resilience Act, are introduced on the [Regulatory Trends](overview/regulations/) page. - ## Contact If you have any questions regarding supply chain security, please refer to the following. diff --git a/content/en/guide/supply-chain/for-suppliers/_index.md b/content/en/guide/supply-chain/for-suppliers/_index.md index dc3e8297e..c42caca84 100644 --- a/content/en/guide/supply-chain/for-suppliers/_index.md +++ b/content/en/guide/supply-chain/for-suppliers/_index.md @@ -17,7 +17,7 @@ To strengthen the transparency and security of its software supply chain, SK Tel 4. Verify PURLs and transitive dependency coverage with the [Validation Checklist](checklist/). 5. Name the file and submit it following the [Submission Process](submission/). -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](commercial-software/) to obtain the SBOM from the manufacturer and submit it. +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](commercial-software/) to obtain the SBOM from the manufacturer and submit it. If your submission is rejected, check [Common Rejection Reasons](rejection-reasons/) for the cause and how to fix it. ## Scope of Application @@ -30,8 +30,6 @@ All suppliers (including developers and resellers) that deliver the following ty * 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) -For commercial software and finished products made by a third party, submit the manufacturer's SBOM following [Commercial Software](commercial-software/) instead of generating one yourself. - ## SBOM Submission Process @@ -70,19 +68,6 @@ flowchart TD ``` -## Guide Structure - -This section is organized as follows. - -1. [Submission Requirements](requirements/): Defines the required formats (CycloneDX, SPDX) and data fields that SK Telecom requires. -2. [How to Generate an SBOM](creation-guide/): Explains how to choose a tool for each delivery type and generate an SBOM using general-purpose open source tools (cdxgen, Syft, etc.). -3. [BomLens](skt-scanner/): Explains how to use SK Telecom's SBOM generation tool. -4. [Server SBOM](server-delivery/): Explains how to generate the OS, application, and static-link layers separately and merge them into one. -5. [Commercial Software](commercial-software/): Explains how to obtain an SBOM from the manufacturer and submit it when supplying commercial software or finished products made by a third party. -6. [Validation Checklist](checklist/): Provides a checklist of essential items to verify before submission. -7. [Submission Process](submission/): Explains the naming conventions and submission channels for the generated SBOM file. -8. [Common Rejection Reasons](rejection-reasons/): Causes and fixes for each rejection reason, with a passing example file. - ## Related Documents - [SK Telecom Supply Chain Security Policy](/en/guide/supply-chain/overview/policy/): Background and principles of the mandatory SBOM submission policy diff --git a/content/en/guide/supply-chain/for-suppliers/checklist.md b/content/en/guide/supply-chain/for-suppliers/checklist.md index 01715e1ca..a5048e84d 100644 --- a/content/en/guide/supply-chain/for-suppliers/checklist.md +++ b/content/en/guide/supply-chain/for-suppliers/checklist.md @@ -28,8 +28,6 @@ Missing transitive dependencies are the most common reason for rejection. Be sur - [ ] 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? @@ -48,7 +46,7 @@ jq '[.components[] | select(.purl)] | length' sbom.json # count with a PURL 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. This usually happens when you scan an installation directory or raw files that have no package manager metadata. Change the scan target to a built image or a location with a package manager context, or switch tools and regenerate. For details, see [How to Generate an SBOM](../creation-guide/). +> 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](../rejection-reasons/). ## Online Validation Tool * CycloneDX Validator: [https://cyclonedx.github.io/cyclonedx-web-tool/validate](https://cyclonedx.github.io/cyclonedx-web-tool/validate) diff --git a/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md b/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md index 12bb04419..bb4b11fc7 100644 --- a/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md +++ b/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md @@ -108,8 +108,7 @@ package manager metadata (`package.json`, `go.mod`, `*.jar`, RPM/DEB package DB, identify the ecosystem and produces an **SBOM with empty PURLs**. Because SK Telecom's system maps vulnerabilities by PURL, such an SBOM fails matching entirely and is rejected. -In one real case, a supplier scanned an installation directory with `syft dir:/root/nag_pkg`, and the -submitted SBOM had no PURL on any of its 261 components, so all 251 vulnerability matches failed. +For a real case rejected this way, see [Common Rejection Reasons](../rejection-reasons/). Run Syft against the following targets. @@ -172,17 +171,11 @@ Using a build tool plugin lets you extract more accurate dependency information. | Node.js | @cyclonedx/cyclonedx-npm | [Link](https://github.com/CycloneDX/cyclonedx-node-npm) | | Go | cyclonedx-gomod | [Link](https://github.com/CycloneDX/cyclonedx-gomod) | -## Verifying Transitive Dependency Inclusion - -Whichever tool you use, one principle holds: generate the SBOM after the build (package installation) is complete so that transitive dependencies are included. Generating from source code alone can omit transitive dependencies and lead to rejection. When delivering as a Docker image, scanning the built image with Syft can include more complete transitive dependencies than source code analysis. - -For the dependency-scope requirements and the per-language build commands to run first, see the dependency scope section of the [Submission Requirements](../requirements/). - ## Common Precautions Verify the following before using a tool. -- Transitive dependency inclusion: Follow the build-first principle above. Missing dependencies are grounds for rejection. +- 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](../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](../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. diff --git a/content/en/guide/supply-chain/for-suppliers/requirements.md b/content/en/guide/supply-chain/for-suppliers/requirements.md index 1fc4c6712..f52f24587 100644 --- a/content/en/guide/supply-chain/for-suppliers/requirements.md +++ b/content/en/guide/supply-chain/for-suppliers/requirements.md @@ -62,15 +62,9 @@ Generation tool information must be recorded in the following fields depending o ### 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 +* 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 -> **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. - -| Item | Additional Requirement | -|------|-------------| -| Version specification | Required — Vulnerability mapping is impossible without the version | - ### 2.3 Dependency Scope > **Important: Transitive dependencies must be included.** @@ -87,13 +81,6 @@ SK Telecom analyzes vulnerabilities based on the submitted SBOM. An SBOM that in 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. @@ -110,7 +97,7 @@ For transitive dependencies to be included accurately, the SBOM must be generate 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. +> **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 @@ -125,15 +112,6 @@ PURL (Package URL) is a standard URL format for uniquely identifying a software | GitHub (Actions / source hosting) | `pkg:github/actions/checkout@v3` | | OS package (RPM) | `pkg:rpm/centos/glibc@2.17-317.el7?arch=x86_64` | -### PURL Type Restrictions - -The purl must be of a type that can identify the ecosystem. - -| Item | Requirement | -|------|---------| -| purl type | **Do not use** `pkg:generic/`. You must use a type that specifies the ecosystem | -| Allowed types | `pkg:rpm/`, `pkg:deb/`, `pkg:apk/`, `pkg:npm/`, `pkg:maven/`, `pkg:pypi/`, `pkg:cargo/`, `pkg:golang/`, `pkg:gem/`, `pkg:nuget/`, `pkg:github/` (source components hosted on GitHub), etc. | - ### Correct / Incorrect PURL Examples | Incorrect | Correct | @@ -180,7 +158,6 @@ The purl must be of a type that can identify the ecosystem. }] }] } -... ``` diff --git a/content/en/guide/supply-chain/for-suppliers/server-delivery.md b/content/en/guide/supply-chain/for-suppliers/server-delivery.md index ff3546eda..8a73f0cbe 100644 --- a/content/en/guide/supply-chain/for-suppliers/server-delivery.md +++ b/content/en/guide/supply-chain/for-suppliers/server-delivery.md @@ -9,9 +9,7 @@ description: > 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](../creation-guide/) is sufficient. -A delivered server is not a single source tree. It is an operating system, the application installed on top of it, and libraries statically linked into the binaries during the build. Scanning only one of these misses the others, which is a common reason a server SBOM is rejected. - -Treat the server as two layers — the OS and the application — generate each separately, then merge them. Both are produced with [BomLens](../skt-scanner/); only the input changes. Statically linked libraries, which neither layer's scan catches, are handled separately as a blind spot. +Treat the server as two layers — the OS and the application — generate each separately, then merge them. Both are produced with [BomLens](../skt-scanner/); 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 rejection cause. ## The two layers of a server @@ -20,8 +18,6 @@ Treat the server as two layers — the OS and the application — generate each | OS | The OS and its installed packages (e.g. CentOS plus everything in the rpm database) | OS vulnerabilities missing | | Application | The delivered application and its package-manager dependencies, direct and transitive | Application dependencies missing | -Beyond the two layers, **statically linked libraries** (for example an openssl or liblfds built into the binary) are a blind spot: a package manager does not declare them and the OS package database does not list them, so neither layer's scan finds them. They must be detected and recorded separately, and missing them is the most common rejection cause. - ## 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](../skt-scanner/) first. To use cdxgen/Syft directly, see [Using Open Source Tools](../creation-guide/). @@ -53,7 +49,7 @@ A pure CMake/Make application with no manifest produces a sparse component list; ### Static-link libraries (a blind spot) -Source scanners do not see libraries statically linked into a binary, and the OS package database does not list them either — the blind spot the two layers leave. 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`). +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`). ```bash scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only @@ -74,7 +70,7 @@ scan-sbom.sh --project myserver --version 1.0.0 \ 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. {{% alert title="Keep the per-layer SBOMs for review" color="info" %}} -The official submission is the merged single BOM, but the per-layer SBOMs show at a glance which layer is missing or vulnerable, so they are useful for your own review and for responding to rejections. Keep them. The merged BOM unions each layer's dependency graph (so it keeps transitive-dependency information) and records each component's source layer, so you can still filter by layer. +The official submission is the merged single BOM, but the per-layer SBOMs show at a glance which layer is missing or vulnerable, so they are useful for your own review and for responding to rejections. Keep them. {{% /alert %}} ## Multi-node clusters @@ -82,11 +78,11 @@ The official submission is the merged single BOM, but the per-layer SBOMs show a 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`. The merge dedupes by purl, so packages common to several roles are counted once. +* 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. A large gap between the total component count and the PURL-bearing count means many components lack a purl, usually from a raw-directory scan. For the verification commands and the full check, follow the [Validation Checklist](../checklist/). +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](../checklist/). ## Learn more diff --git a/content/en/guide/supply-chain/for-suppliers/submission.md b/content/en/guide/supply-chain/for-suppliers/submission.md index 694718ca6..020403405 100644 --- a/content/en/guide/supply-chain/for-suppliers/submission.md +++ b/content/en/guide/supply-chain/for-suppliers/submission.md @@ -16,9 +16,6 @@ description: > The SBOM file is submitted to SK Telecom's business unit and security team representatives via email (or a channel designated by the representative). -### 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) @@ -29,13 +26,9 @@ Required information in the body: 3. Project information (system name, detailed version) 4. Tool used and its version (e.g., BomLens, cdxgen) -### Internal Registration After Receipt - -The SK Telecom business unit representative who receives an SBOM from a supplier registers it in TOSCA, the internal open source and SBOM management system. TOSCA is an internal system, so suppliers do not need access to it; the registration procedure follows the internal guide. - ## 3. Post-Submission Validation and Actions -After being registered in TOSCA, the submitted SBOM is validated according to the procedure below. +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. | Stage | Description | Processing Deadline | | --- | --- | --- | diff --git a/content/en/guide/supply-chain/overview/_index.md b/content/en/guide/supply-chain/overview/_index.md index d567ce62a..6f001b97f 100644 --- a/content/en/guide/supply-chain/overview/_index.md +++ b/content/en/guide/supply-chain/overview/_index.md @@ -33,31 +33,12 @@ graph LR ## 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. +- 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? -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. +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 diff --git a/content/en/guide/supply-chain/overview/regulations.md b/content/en/guide/supply-chain/overview/regulations.md index eb453f8f7..1f799c406 100644 --- a/content/en/guide/supply-chain/overview/regulations.md +++ b/content/en/guide/supply-chain/overview/regulations.md @@ -10,12 +10,11 @@ description: > ## 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. +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 and secure software development practices; the SBOM submission and self-attestation requirements for federal suppliers were detailed in subsequent OMB guidance. +- 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). -- 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) @@ -33,13 +32,9 @@ In step with the global trend, the South Korean government (the Ministry of Scie ### 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. +- 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 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). +SK Telecom's requirements in response to these regulatory trends are laid out in the [SK Telecom Supply Chain Security Policy](../policy/). ## Related Documents diff --git a/content/en/guide/supply-chain/sbom/_index.md b/content/en/guide/supply-chain/sbom/_index.md index e1be6ca07..4f99f36dd 100644 --- a/content/en/guide/supply-chain/sbom/_index.md +++ b/content/en/guide/supply-chain/sbom/_index.md @@ -4,7 +4,7 @@ linkTitle: "What Is an SBOM?" weight: 3 type: docs description: > - Guides developers and administrators through the full lifecycle of an SBOM, from its core concepts to generation, integration, and management. + Guides developers and administrators through the core concepts of an SBOM and the industry standards. --- ## Overview @@ -17,25 +17,3 @@ This section is a learning guide for those encountering an SBOM (Software Bill o 2. [Standards Comparison (SPDX vs CycloneDX)](standards/): 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](../for-suppliers/). - -Below is the full lifecycle an SBOM flows through, from development to security remediation. - -```mermaid -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] - - 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 - - class A start - class B,E,F proc - class C decision - class D,G good -``` diff --git a/content/en/guide/supply-chain/sbom/standards.md b/content/en/guide/supply-chain/sbom/standards.md index 84d7da4f8..89278abd5 100644 --- a/content/en/guide/supply-chain/sbom/standards.md +++ b/content/en/guide/supply-chain/sbom/standards.md @@ -13,200 +13,33 @@ For SBOMs submitted to SK Telecom, we recommend the CycloneDX (JSON) format. Che ## 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 - -```json -{ - "SPDXID": "SPDXRef-DOCUMENT", - "spdxVersion": "SPDX-2.3", - "name": "Example-SBOM", - "documentNamespace": "https://example.com/sbom-2026-001", - "creationInfo": { - "created": "2026-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 - -```json -{ - "bomFormat": "CycloneDX", - "specVersion": "1.6", - "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", - "version": 1, - "metadata": { - "timestamp": "2026-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 +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. -- 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 -- Internationally standardized as ECMA-424 by Ecma International +- 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. -### Disadvantages +## SPDX vs CycloneDX -- File-level information is limited -- License expression is simpler than in SPDX - -## SPDX vs CycloneDX Comparison - -| Category | SPDX | CycloneDX | -|------|------|-----------| +| Aspect | SPDX | CycloneDX | +|------|------|-----------| | Governing body | Linux Foundation | OWASP | | Standard certification | ISO/IEC 5962 | ECMA-424 | | Primary purpose | License compliance | Security vulnerability management | -| Structural complexity | High (detailed) | Low (concise) | +| Structural complexity | High (detailed) | Low (compact) | | File-level tracking | Supported | Limited | -| Vulnerability information | Optional | Included by default | -| Tooling ecosystem | Mature | Growing rapidly | +| Vulnerability information | Optional | Built in | +| Tool ecosystem | Mature | Growing fast | | 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 - -### SK Telecom Recommendation +| Typical users | Legal teams, open source program offices | Security teams, DevOps engineers | +| SKT recommendation | When license verification is the main goal | When vulnerability management is the main goal | -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. +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](/en/guide/supply-chain/for-suppliers/requirements/). -## Interconversion +## Converting Between the Two Conversion tools are available between SPDX and CycloneDX. -### Converting from SPDX to CycloneDX +### SPDX to CycloneDX ```bash # Using cyclonedx-cli @@ -215,7 +48,7 @@ cyclonedx convert --input-file sbom.spdx.json \ --output-format json ``` -### Converting from CycloneDX to SPDX +### CycloneDX to SPDX ```bash # Using spdx-tools @@ -225,8 +58,8 @@ java -jar tools-java-1.1.0-jar-with-dependencies.jar \ ## Related Documents -- [What Is an SBOM?](../what-is-sbom/): The concept and necessity of an SBOM -- [Supplier Submission Requirements](/en/guide/supply-chain/for-suppliers/requirements/): Formats and versions accepted by SK Telecom +- [What Is an SBOM?](../what-is-sbom/): SBOM concepts and why they matter +- [Supplier Submission Requirements](/en/guide/supply-chain/for-suppliers/requirements/): Formats and versions SK Telecom accepts ## References diff --git a/content/en/guide/supply-chain/sbom/what-is-sbom.md b/content/en/guide/supply-chain/sbom/what-is-sbom.md index 900d4758b..675478140 100644 --- a/content/en/guide/supply-chain/sbom/what-is-sbom.md +++ b/content/en/guide/supply-chain/sbom/what-is-sbom.md @@ -35,51 +35,14 @@ graph TD ## Key Components of an SBOM -### Component Information +An SBOM document carries the following information. -Includes basic information about each software component. +- 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 -- 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 +For submissions to SK Telecom, which items are required and in what form is defined by the [Submission Requirements](/en/guide/supply-chain/for-suppliers/requirements/). ## Why Is It Needed? @@ -94,13 +57,7 @@ Open source license violations can lead to legal disputes. Through an SBOM, you ### 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 +Against this backdrop, regulations in the United States, Europe, and elsewhere are also moving toward mandatory SBOM submission. See [Regulatory Trends](/en/guide/supply-chain/overview/regulations/) for details. ## Related Documents diff --git a/content/ko/guide/supply-chain/_index.md b/content/ko/guide/supply-chain/_index.md index f011aafd1..4bacd4ebd 100644 --- a/content/ko/guide/supply-chain/_index.md +++ b/content/ko/guide/supply-chain/_index.md @@ -18,15 +18,11 @@ SK텔레콤에 소프트웨어를 납품하는 공급사라면 [공급사 가이 ## 공급망 보안이 처음이라면 -최근 오픈소스 생태계에서는 라이선스 컴플라이언스와 함께 보안 취약점 관리와 소프트웨어 공급망 보안이 중요한 과제로 부상하였습니다. 미국과 유럽의 규제 강화에 따라 SBOM(Software Bill of Materials) 관리와 체계적인 취약점 대응이 필수가 되었습니다. - -배경부터 차근차근 배우려면 다음 순서를 권합니다. +미국과 유럽의 규제 강화에 따라 SBOM(Software Bill of Materials) 관리와 체계적인 취약점 대응이 필수가 되었습니다. 배경부터 차근차근 배우려면 다음 순서를 권합니다. 1. [공급망 보안이란?](overview/): 공급망 공격 사례와 보안의 필요성, 글로벌 규제 동향, SK텔레콤의 정책을 설명합니다. 2. [SBOM 이란?](sbom/): SBOM의 개념과 표준(SPDX, CycloneDX)을 다룹니다. -ISO/IEC 18974(OpenChain Security Assurance), SPDX(ISO/IEC 5962), CycloneDX(ECMA-424), NIST SSDF 등 관련 표준과 미국 EO 14028, EU Cyber Resilience Act 등 규제 동향은 [규제 동향](overview/regulations/) 페이지에서 소개합니다. - ## 문의 공급망 보안과 관련하여 문의사항이 있으시면 아래를 참고하세요. diff --git a/content/ko/guide/supply-chain/for-suppliers/_index.md b/content/ko/guide/supply-chain/for-suppliers/_index.md index bad8c2a66..c6afdb13a 100644 --- a/content/ko/guide/supply-chain/for-suppliers/_index.md +++ b/content/ko/guide/supply-chain/for-suppliers/_index.md @@ -17,7 +17,7 @@ SK텔레콤은 소프트웨어 공급망의 투명성과 보안성을 강화하 4. [검증 체크리스트](checklist/)로 PURL과 전이 의존성 포함 여부를 점검합니다. 5. [제출 절차](submission/)에 따라 파일명을 정하고 제출합니다. -타사가 제조한 상용 소프트웨어나 완제품을 공급해 소스코드에 접근할 수 없다면, 2~3단계 대신 [상용 소프트웨어 공급](commercial-software/)에 따라 제조사로부터 SBOM을 받아 제출합니다. +타사가 제조한 상용 소프트웨어나 완제품을 공급해 소스코드에 접근할 수 없다면, 2~3단계 대신 [상용 소프트웨어 공급](commercial-software/)에 따라 제조사로부터 SBOM을 받아 제출합니다. 제출한 SBOM이 반려되면 [자주 발생하는 반려 사유](rejection-reasons/)에서 원인별 해결 방법을 확인합니다. ## 적용 대상 @@ -30,8 +30,6 @@ SK텔레콤은 소프트웨어 공급망의 투명성과 보안성을 강화하 * 서버: OS(rootfs와 설치 패키지) 위에 애플리케이션과 정적 링크 라이브러리가 결합된 시스템 * 상용 소프트웨어·완제품: 타사가 제조한 패키지 소프트웨어 또는 어플라이언스 장비 (리셀러·총판 공급 포함) -이 중 타사가 제조한 상용 소프트웨어·완제품은 직접 생성하는 대신 [상용 소프트웨어 공급](commercial-software/)에 따라 제조사 SBOM을 받아 제출합니다. - ## SBOM 제출 프로세스 @@ -70,19 +68,6 @@ flowchart TD ``` -## 가이드 구성 - -본 섹션은 다음과 같이 구성되어 있습니다. - -1. [제출 요구사항](requirements/): SK텔레콤이 요구하는 필수 포맷(CycloneDX, SPDX)과 데이터 필드를 정의합니다. -2. [SBOM 생성 방법](creation-guide/): 납품 형태별 도구 선택 기준과 범용 오픈소스 도구(cdxgen, Syft 등)를 활용한 생성 방법을 안내합니다. -3. [BomLens](skt-scanner/): SK텔레콤이 제공하는 SBOM 생성 도구 사용법을 안내합니다. -4. [서버 SBOM 생성](server-delivery/): OS·애플리케이션·정적 링크 세 층으로 나눠 생성하고 하나로 합치는 방법을 안내합니다. -5. [상용 소프트웨어 공급](commercial-software/): 타사가 제조한 상용 소프트웨어·완제품을 공급하는 경우 제조사로부터 SBOM을 받아 제출하는 방법을 안내합니다. -6. [검증 체크리스트](checklist/): 제출 전 반드시 확인해야 할 필수 항목 점검표를 제공합니다. -7. [제출 절차](submission/): 생성된 SBOM 파일의 명명 규칙과 제출 채널을 안내합니다. -8. [자주 발생하는 반려 사유](rejection-reasons/): 반려 사유별 원인과 해결 방법, 합격 예시 파일을 제공합니다. - ## 관련 문서 - [SK텔레콤 공급망 보안 정책](/guide/supply-chain/overview/policy/): SBOM 제출 의무화 정책 배경 및 원칙 diff --git a/content/ko/guide/supply-chain/for-suppliers/checklist.md b/content/ko/guide/supply-chain/for-suppliers/checklist.md index 3dcd2ee40..ba1f6072b 100644 --- a/content/ko/guide/supply-chain/for-suppliers/checklist.md +++ b/content/ko/guide/supply-chain/for-suppliers/checklist.md @@ -28,8 +28,6 @@ description: > - [ ] SBOM 생성 전 빌드(또는 패키지 설치)를 완료하였는가? (예: `npm install`, `mvn package`, `pip install`) - [ ] 컴포넌트 수가 합리적인가? (직접 의존성만 몇 개인 프로젝트에서 총 컴포넌트 수가 10개 미만이라면 전이적 의존성이 누락되었을 가능성이 높음) -> 의존성 수 기준 가이드: 일반적인 웹 애플리케이션은 전이적 의존성까지 포함하면 수십~수백 개의 컴포넌트가 포함됩니다. SBOM의 컴포넌트 수가 예상보다 현저히 적다면 누락을 의심해 보시기 바랍니다. - ### 4. 식별자 (PURL) 확인 SK텔레콤 시스템은 PURL로 취약점을 매핑합니다. 가장 중요한 항목입니다. - [ ] 모든 컴포넌트(`components`) 객체 안에 `purl` 필드가 존재하는가? @@ -48,7 +46,7 @@ jq '[.components[] | select(.purl)] | length' sbom.json # purl 보유 수 jq '[.packages[] | select(.externalRefs[]?.referenceType == "purl")] | length' sbom.json ``` -> purl 보유 수가 0이거나 전체 컴포넌트 수보다 현저히 적으면 제출하지 마십시오. 이는 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔했을 때 주로 발생합니다. 스캔 대상을 빌드된 이미지나 패키지 매니저 컨텍스트가 있는 위치로 바꾸거나 도구를 바꿔 재생성하시기 바랍니다. 자세한 내용은 [SBOM 생성 방법](../creation-guide/)을 참고하십시오. +> purl 보유 수가 0이거나 전체 컴포넌트 수보다 현저히 적으면 제출하지 마십시오. 원인과 재생성 방법은 [자주 발생하는 반려 사유](../rejection-reasons/)를 참고하십시오. ## 온라인 검증 도구 * CycloneDX Validator: [https://cyclonedx.github.io/cyclonedx-web-tool/validate](https://cyclonedx.github.io/cyclonedx-web-tool/validate) diff --git a/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md b/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md index bd6d49cee..4d1064e96 100644 --- a/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md +++ b/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md @@ -107,8 +107,7 @@ Java, Python, Node.js, Go 등 다양한 언어 프로젝트를 자동 분석하 없는 설치 디렉터리나 바이너리 모음을 스캔하면, Syft가 생태계(ecosystem)를 식별하지 못해 **purl이 비어 있는 SBOM**이 생성됩니다. SK텔레콤 시스템은 purl로 취약점을 매핑하므로, 이런 SBOM은 매칭이 전량 실패하여 반려됩니다. -실제로 한 공급사가 `syft dir:/root/nag_pkg`로 설치 디렉터리를 스캔해 제출한 SBOM은 261개 컴포넌트 중 purl이 -하나도 없어, 취약점 매칭 251건이 모두 실패했습니다. +이렇게 반려된 실제 사례는 [자주 발생하는 반려 사유](../rejection-reasons/)를 참고하십시오. Syft는 다음 대상으로 실행하시기 바랍니다. @@ -171,17 +170,11 @@ Trivy를 안전하게 사용하려면 다음 원칙을 따르시기 바랍니다 | Node.js | @cyclonedx/cyclonedx-npm | [링크](https://github.com/CycloneDX/cyclonedx-node-npm) | | Go | cyclonedx-gomod | [링크](https://github.com/CycloneDX/cyclonedx-gomod) | -## 전이적 의존성 포함 확인 - -어떤 도구를 쓰든 핵심 원칙은 하나입니다. 빌드(패키지 설치)가 완료된 상태에서 SBOM을 생성해야 전이적 의존성까지 포함됩니다. 소스코드만 있는 상태에서 생성하면 전이적 의존성이 누락되어 반려될 수 있습니다. Docker 이미지로 납품하는 경우, 빌드된 이미지를 Syft로 스캔하면 소스코드 분석보다 더 완전한 전이적 의존성을 포함할 수 있습니다. - -의존성 범위 요구사항과 언어별 빌드 선행 명령은 [제출 요구사항](../requirements/)의 의존성 범위 절을 참고하세요. - ## 공통 주의사항 도구를 사용하기 전 아래 사항을 확인하시기 바랍니다. -- 전이적 의존성 포함 여부: 빌드 완료 후 생성 원칙을 지킵니다. 의존성 누락은 반려 사유가 됩니다. +- 전이적 의존성 포함 여부: 빌드(패키지 설치)가 완료된 상태에서 생성해야 전이적 의존성까지 포함됩니다. 의존성 누락은 반려 사유가 되며, 언어별 빌드 선행 명령은 [제출 요구사항](../requirements/)의 의존성 범위 절을 참고하세요. - PURL 포함 여부: 생성된 SBOM에 모든 컴포넌트의 `purl` 필드가 포함되어 있는지 확인합니다. SK텔레콤 시스템은 PURL을 기반으로 취약점을 매핑합니다. 확인 명령과 재생성 절차는 [검증 체크리스트](../checklist/)를 참고하세요. - 출력 포맷: CycloneDX JSON 형식을 권장합니다. (`-o cyclonedx-json` 또는 동등한 옵션 사용) - 프로젝트 정보: 메타데이터에 납품 프로젝트의 이름과 버전이 정확히 기입되었는지 확인합니다. diff --git a/content/ko/guide/supply-chain/for-suppliers/requirements.md b/content/ko/guide/supply-chain/for-suppliers/requirements.md index d6055fc19..9e48684f3 100644 --- a/content/ko/guide/supply-chain/for-suppliers/requirements.md +++ b/content/ko/guide/supply-chain/for-suppliers/requirements.md @@ -62,15 +62,9 @@ SK텔레콤은 글로벌 표준으로 자리 잡은 두 가지 형식을 모두 ### 2.2 컴포넌트 정보 (Components) 소프트웨어를 구성하는 개별 라이브러리 정보입니다. * Name: 컴포넌트 이름 (예: `commons-lang3`) -* Version: 컴포넌트 버전 (예: `3.12.0`) — **필수**: 버전 없이는 취약점 매핑 불가 +* Version: 컴포넌트 버전 (예: `3.12.0`) — 필수. SPDX는 `versionInfo`, CycloneDX는 `version` 필드에 정확한 버전을 기재합니다. 버전이 없으면 취약점 매핑이 불가능합니다. * PURL (Package URL): [필수] 패키지 식별자 -> **버전 정보는 반드시 포함해야 합니다.** 각 패키지(package/component)는 SPDX의 `versionInfo` 또는 CycloneDX의 `version` 필드에 정확한 버전을 기재해야 합니다. 버전이 없으면 취약점 데이터베이스와의 매핑이 불가능하여 보안 분석을 수행할 수 없습니다. - -| 항목 | 추가 요구사항 | -|------|-------------| -| 버전 명시 | 필수 — 버전 없이는 취약점 매핑 불가 | - ### 2.3 의존성 범위 (Dependency Scope) > **중요: 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.** @@ -87,13 +81,6 @@ SK텔레콤은 제출된 SBOM을 기반으로 취약점을 분석합니다. 직 예를 들어 프로젝트가 `library-A`를 직접 사용하고, `library-A`가 내부적으로 `library-B`를 사용하는 경우, `library-B`가 전이적 의존성입니다. `library-B`에 취약점이 있어도 SBOM에 포함되지 않으면 탐지할 수 없습니다. -``` -MyApp - └─ library-A v1.0 (직접 의존성) ← 공급사가 명시적으로 선언 - └─ library-B v2.3 (전이적 의존성) ← SBOM에 반드시 포함되어야 함 - └─ library-C v0.9 (전이적 의존성) ← SBOM에 반드시 포함되어야 함 -``` - **올바른 SBOM 생성을 위한 전제 조건** 전이적 의존성이 정확하게 포함되려면 빌드(또는 패키지 설치)가 완료된 상태에서 SBOM을 생성해야 합니다. 소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다. @@ -110,7 +97,7 @@ MyApp PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위한 표준 URL 형식입니다. SK텔레콤의 취약점 분석 시스템은 PURL을 기준으로 동작하므로, 모든 컴포넌트에 유효한 PURL이 포함되어야 합니다. -> **PURL은 반드시 `pkg:` 접두어로 시작하는 표준 형식이어야 합니다.** `name:version`, `org/repo:tag` 등 자유 텍스트는 허용되지 않으며, 이 경우 취약점 매핑이 불가능해 반려됩니다. +> **PURL은 반드시 `pkg:` 접두어로 시작하는 표준 형식이어야 합니다.** `name:version`, `org/repo:tag` 등 자유 텍스트는 허용되지 않으며, 이 경우 취약점 매핑이 불가능해 반려됩니다. 타입은 생태계를 특정해야 하며 `pkg:generic/`은 허용되지 않습니다. ### 언어별 PURL 예시 @@ -125,15 +112,6 @@ PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위 | GitHub (Actions·소스 호스팅) | `pkg:github/actions/checkout@v3` | | OS 패키지 (RPM) | `pkg:rpm/centos/glibc@2.17-317.el7?arch=x86_64` | -### purl 타입 제한 - -purl은 생태계를 특정할 수 있는 타입이어야 합니다. - -| 항목 | 요구사항 | -|------|---------| -| purl 타입 | `pkg:generic/` **사용 금지**. 생태계를 명시하는 타입 사용 필수 | -| 허용 타입 | `pkg:rpm/`, `pkg:deb/`, `pkg:apk/`, `pkg:npm/`, `pkg:maven/`, `pkg:pypi/`, `pkg:cargo/`, `pkg:golang/`, `pkg:gem/`, `pkg:nuget/`, `pkg:github/` (GitHub에 호스팅된 소스 컴포넌트) 등 | - ### 올바른 / 잘못된 PURL 예시 | 잘못된 예 | 올바른 예 | @@ -180,7 +158,6 @@ purl은 생태계를 특정할 수 있는 타입이어야 합니다. }] }] } -... ``` diff --git a/content/ko/guide/supply-chain/for-suppliers/server-delivery.md b/content/ko/guide/supply-chain/for-suppliers/server-delivery.md index 577603380..21f07f265 100644 --- a/content/ko/guide/supply-chain/for-suppliers/server-delivery.md +++ b/content/ko/guide/supply-chain/for-suppliers/server-delivery.md @@ -9,9 +9,7 @@ description: > 이 문서는 OS 위에 애플리케이션을 얹어 서버 형태로 납품하는 공급사를 위한 심화 가이드입니다. 일반 애플리케이션 납품이라면 [SBOM 생성 방법](../creation-guide/)만으로 충분합니다. -납품 서버는 단일 소스 트리가 아닙니다. 운영체제가 있고, 그 위에 설치된 애플리케이션이 있으며, 빌드 과정에서 바이너리에 정적 링크된 라이브러리가 있습니다. 이 중 하나만 스캔하면 나머지가 빠지고, 이것이 서버 SBOM이 반려되는 흔한 원인입니다. - -서버는 두 층(OS와 애플리케이션)으로 보고 각 층을 따로 생성한 뒤 하나로 합칩니다. 두 층 모두 [BomLens](../skt-scanner/)로 만들 수 있고, 층마다 입력만 바꾸면 됩니다. 여기에 더해, 정적 링크된 라이브러리는 두 층의 스캔이 모두 놓치는 사각지대라 별도로 다룹니다. +서버는 두 층(OS와 애플리케이션)으로 보고 각 층을 따로 생성한 뒤 하나로 합칩니다. 두 층 모두 [BomLens](../skt-scanner/)로 만들 수 있고, 층마다 입력만 바꾸면 됩니다. 여기에 더해, 정적 링크된 라이브러리(빌드 시 바이너리에 포함된 openssl 등)는 두 층의 스캔이 모두 놓치는 사각지대라 별도로 다룹니다. 이를 빠뜨리는 것이 가장 흔한 반려 원인입니다. ## 서버를 이루는 두 층 @@ -20,8 +18,6 @@ description: > | OS | 운영체제와 설치된 패키지 전체 (예: CentOS와 rpm 데이터베이스의 모든 패키지) | OS 취약점 누락 | | 애플리케이션 | 납품 애플리케이션과 패키지 매니저 의존성(직접·전이) | 앱 의존성 누락 | -여기에 더해, **정적 링크된 라이브러리**(빌드 시 바이너리에 포함된 openssl·liblfds 등)는 패키지 매니저가 선언하지 않고 OS 패키지 데이터베이스에도 올라 있지 않아 두 층의 스캔이 모두 놓치는 사각지대입니다. 별도로 탐지·기재해야 하며, 이를 빠뜨리는 것이 가장 흔한 반려 원인입니다. - ## 층별 생성 아래 명령은 BomLens의 실행 스크립트 `scan-sbom.sh`를 사용합니다. BomLens 설치와 기본 사용법(스크립트 내려받기, 옵션, 웹 UI 등)은 [BomLens](../skt-scanner/)를 먼저 참고하세요. cdxgen·Syft를 직접 쓰려면 [오픈소스 도구 활용](../creation-guide/)을 참고합니다. @@ -53,7 +49,7 @@ scan-sbom.sh --project myserver-app --version 2.0.0 --all --generate-only ### 정적 링크 라이브러리 (사각지대) -소스 스캐너는 바이너리에 정적 링크된 라이브러리를 보지 못하고, OS 패키지 데이터베이스에도 올라 있지 않습니다. 이것이 두 층이 남기는 사각지대입니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다. 도구가 찾을 수 있는 만큼은 납품 바이너리를 분석하고, 그래도 빠지는 부분은 빌드 스크립트에서 소스와 버전(예: `openssl 1.1.1za`)을 직접 기재합니다. +정적 링크된 라이브러리는 패키지 매니저가 선언하지 않고 OS 패키지 데이터베이스에도 올라 있지 않아, 어느 층의 스캔도 잡지 못합니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다. 도구가 찾을 수 있는 만큼은 납품 바이너리를 분석하고, 그래도 빠지는 부분은 빌드 스크립트에서 소스와 버전(예: `openssl 1.1.1za`)을 직접 기재합니다. ```bash scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only @@ -74,7 +70,7 @@ scan-sbom.sh --project myserver --version 1.0.0 \ 서버 전체를 하나의 컨테이너 이미지로 납품한다면, 그 이미지를 `--target`으로 한 번에 스캔해 OS와 애플리케이션 층을 동시에 담을 수도 있습니다. {{% alert title="검토용으로 층별 SBOM을 함께 보관하세요" color="info" %}} -공식 제출물은 병합된 단일 BOM이지만, 층별 SBOM은 어느 층이 누락·취약한지 바로 보여 주므로 자체 검토와 재제출 대응에 유용합니다. 함께 보관하시기 바랍니다. 병합본도 각 층의 의존성 그래프를 합쳐 전이 의존성 정보를 보존하고, 각 컴포넌트에 출처 층을 기록하므로 층별로 걸러 볼 수 있습니다. +공식 제출물은 병합된 단일 BOM이지만, 층별 SBOM은 어느 층이 누락·취약한지 바로 보여 주므로 자체 검토와 재제출 대응에 유용합니다. 함께 보관하시기 바랍니다. {{% /alert %}} ## 클러스터·다중 노드 구성이라면 @@ -82,11 +78,11 @@ scan-sbom.sh --project myserver --version 1.0.0 \ 여러 대의 노드가 하나의 클러스터를 이루는 제품도 제출 단위는 동일하게 제품당 SBOM 하나입니다. 노드 대수만큼 만들 필요는 없습니다. * 모든 노드가 동일 구성이라면, 대표 노드 1대를 기준으로 층별 생성과 병합을 진행합니다. -* 노드 역할에 따라 설치된 소프트웨어가 다르다면(예: 관리 노드와 스토리지 노드), 역할별로 층별 SBOM을 만든 뒤 전체를 `--merge`로 합쳐 하나로 제출합니다. 병합은 purl 기준으로 중복을 제거하므로 여러 역할에 공통인 패키지가 중복 집계되지 않습니다. +* 노드 역할에 따라 설치된 소프트웨어가 다르다면(예: 관리 노드와 스토리지 노드), 역할별로 층별 SBOM을 만든 뒤 전체를 `--merge`로 합쳐 하나로 제출합니다. ## 제출 전 검증 -층별 SBOM과 병합본 모두 컴포넌트가 실제 purl을 갖는지 확인해야 합니다. 전체 컴포넌트 수와 purl 보유 수의 차이가 크면 purl 없는 컴포넌트가 많다는 뜻이고, 보통 원시 디렉터리 스캔이 원인입니다. 확인 명령과 점검 항목은 [검증 체크리스트](../checklist/)를 따르십시오. +층별 SBOM과 병합본 모두 컴포넌트가 실제 purl을 갖는지 확인해야 합니다. 확인 명령과 점검 항목은 [검증 체크리스트](../checklist/)를 따르십시오. ## 더 알아보기 diff --git a/content/ko/guide/supply-chain/for-suppliers/submission.md b/content/ko/guide/supply-chain/for-suppliers/submission.md index 730f7a294..7a4a891e5 100644 --- a/content/ko/guide/supply-chain/for-suppliers/submission.md +++ b/content/ko/guide/supply-chain/for-suppliers/submission.md @@ -16,9 +16,6 @@ description: > SBOM 파일은 SK텔레콤 사업부서 및 보안부서 담당자에게 이메일(또는 담당자가 지정한 채널)로 제출합니다. -### 제출 방법 - -- 사업부서 및 보안부서 담당자에게 이메일 또는 담당자가 지정한 채널로 SBOM 파일을 전달합니다. - 이메일 제목: `[SBOM 제출] 공급사명_프로젝트명_버전` - 첨부파일: 생성된 SBOM 파일 (비밀번호 걸린 압축 파일 금지) @@ -29,13 +26,9 @@ SBOM 파일은 SK텔레콤 사업부서 및 보안부서 담당자에게 이메 3. 프로젝트 정보 (시스템명, 상세 버전) 4. 사용 도구 및 버전 (예: BomLens, cdxgen) -### 접수 후 사내 등록 - -공급사로부터 SBOM을 접수한 SK텔레콤 사업부서 담당자는 사내 오픈소스 & SBOM 관리 시스템(TOSCA)에 해당 SBOM을 등록합니다. TOSCA는 사내 시스템이므로 공급사가 접근할 필요는 없으며, 등록 방법은 사내 가이드를 따릅니다. - ## 3. 제출 후 검증 및 조치 -제출된 SBOM은 TOSCA에 등록된 후 아래 절차에 따라 검증됩니다. +제출된 SBOM은 사내 오픈소스 & SBOM 관리 시스템(TOSCA)에 등록된 후 아래 절차에 따라 검증됩니다. TOSCA는 사내 시스템이므로 공급사가 접근할 필요는 없습니다. | 단계 | 내용 | 처리 기한 | | --- | --- | --- | diff --git a/content/ko/guide/supply-chain/overview/_index.md b/content/ko/guide/supply-chain/overview/_index.md index b5d1ba6ea..57991dc7a 100644 --- a/content/ko/guide/supply-chain/overview/_index.md +++ b/content/ko/guide/supply-chain/overview/_index.md @@ -33,31 +33,12 @@ graph LR ## 2. 주요 공격 사례 -최근 몇 년간 발생한 대형 보안 사고들은 공급망 보안의 중요성을 전 세계에 각인시켰습니다. - -### SolarWinds 사태 (2020) -- 개요: 네트워크 모니터링 솔루션인 SolarWinds Orion의 빌드 시스템이 해킹당해, 정상적인 업데이트 파일에 백도어가 심어졌습니다. -- 피해: 미국 정부 기관, 포춘 500대 기업 등 전 세계 18,000여 개 조직이 피해를 입었습니다. -- 시사점: 신뢰하는 벤더의 정식 서명된 소프트웨어조차 안전하지 않을 수 있음을 보여주었습니다. - -### Log4j 취약점 (2021) -- 개요: 자바 기반 로깅 라이브러리인 Log4j에서 원격 코드 실행(RCE)이 가능한 치명적인 취약점(Log4Shell)이 발견되었습니다. -- 피해: 이 라이브러리를 직간접적으로 사용하는 전 세계 수억 대의 디바이스와 서버가 위험에 노출되었습니다. -- 시사점: SBOM(Software Bill of Materials)을 통해 우리 시스템이 어떤 오픈소스를 사용하고 있는지 파악하는 것이 얼마나 중요한지 깨닫게 된 계기입니다. - -### 3CX 공급망 공격 (2023) -- 개요: VoIP 소프트웨어 3CX의 데스크톱 앱이 트로이 목마에 감염된 상태로 배포되었습니다. -- 특징: 공격자는 3CX 직원의 PC를 먼저 해킹한 후 개발 환경으로 침투(Lateral Movement)하여 바이너리를 변조했습니다. +- SolarWinds 사태 (2020): 빌드 시스템이 해킹당해 정식 서명된 업데이트에 백도어가 심어졌고, 미국 정부 기관을 포함해 전 세계 18,000여 개 조직이 피해를 입었습니다. 신뢰하는 벤더의 소프트웨어조차 안전하지 않을 수 있음을 보여 주었습니다. +- Log4j 취약점 (2021): 널리 쓰이는 로깅 라이브러리에서 원격 코드 실행 취약점이 발견되어 전 세계 수억 대의 서버가 노출되었습니다. 우리 시스템이 어떤 오픈소스를 쓰는지 파악하는 수단, 즉 SBOM의 필요성을 각인시킨 계기입니다. ## 3. 왜 공급망 보안인가? -현대 소프트웨어 개발 환경은 복잡하게 얽힌 의존성(Dependency) 위에 구축되어 있습니다. - -1. 오픈소스 의존성 증가: 현대 애플리케이션 코드의 70~90%는 오픈소스 컴포넌트로 구성됩니다. -2. 파급력: 하나의 공통 컴포넌트가 오염되면 전 세계적인 피해로 확산됩니다. -3. 탐지의 어려움: 개발 및 빌드 단계에서 오염된 코드는 전통적인 보안 검사(방화벽, 백신 등)를 우회하기 쉽습니다. - -이에 따라 SK텔레콤은 공급망의 투명성을 확보하고 리스크를 관리하기 위해 SBOM 도입과 철저한 공급망 보안 정책을 수립하여 시행하고 있습니다. +현대 애플리케이션 코드의 70~90%는 오픈소스 컴포넌트로 구성됩니다. 공통 컴포넌트 하나가 오염되면 피해가 전 세계로 확산되고, 빌드 단계에서 오염된 코드는 방화벽이나 백신 같은 전통적인 보안 검사로 잡기 어렵습니다. 이런 위험을 관리하기 위해 SK텔레콤은 SBOM 도입과 공급망 보안 정책을 시행하고 있습니다. ## 관련 문서 diff --git a/content/ko/guide/supply-chain/overview/regulations.md b/content/ko/guide/supply-chain/overview/regulations.md index c7f29c78d..d4c8e11ef 100644 --- a/content/ko/guide/supply-chain/overview/regulations.md +++ b/content/ko/guide/supply-chain/overview/regulations.md @@ -10,12 +10,11 @@ description: > ## 1. 미국: 행정명령 14028 (EO 14028) -2021년 5월, 바이든 행정부는 '국가의 사이버 보안 개선에 관한 행정명령(Executive Order 14028)'을 발표했습니다. 이는 SolarWinds 사태 이후 공급망 보안을 국가 안보 차원에서 다루기 시작한 결정적 계기입니다. +2021년 5월, 바이든 행정부는 '국가의 사이버 보안 개선에 관한 행정명령(Executive Order 14028)'을 발표했습니다. ### 핵심 내용 -- SBOM 요구 추진: EO 14028은 SBOM의 최소 요소 정의와 안전한 소프트웨어 개발 관행을 지시했고, 연방 납품 기업의 SBOM 제출과 자기증명 의무는 후속 OMB 지침으로 구체화됐습니다. +- SBOM 요구 추진: EO 14028은 SBOM의 최소 요소(데이터 필드, 자동화 지원 등) 정의와 안전한 소프트웨어 개발 관행을 지시했고, 연방 납품 기업의 SBOM 제출과 자기증명 의무는 후속 OMB 지침으로 구체화됐습니다. - NIST 가이드라인 준수: NIST(미국 국립표준기술연구소)가 정의한 '보안 소프트웨어 개발 프레임워크(SSDF)'를 준수해야 합니다. -- 최소 기준 제시: 미 행정부는 SBOM의 최소 요소(데이터 필드, 자동화 지원 등)를 정의하여 표준화를 주도했습니다. ## 2. 유럽연합(EU): 사이버 복원력 법안 (CRA) @@ -33,13 +32,9 @@ EU는 Cyber Resilience Act (CRA)를 통해 디지털 제품의 전체 생명주 ### 주요 내용 (v1.0 기준) - SBOM 도입 권고: 공공 및 민간 분야에서 SW 개발 및 납품 시 SBOM을 생성하고 활용할 것을 권고합니다. -- 역할별 보안 활동 정의: - - 공급사(개발사): 안전한 개발 환경 구축, SBOM 생성 및 제공, 보안 취약점 점검. - - 수요사(운영사): 납품받은 SW의 SBOM 요구 및 검증, 지속적인 취약점 모니터링. +- 공급사 보안 활동: 안전한 개발 환경 구축, SBOM 생성 및 제공, 보안 취약점 점검을 권고합니다. -### SK텔레콤의 대응 - -SK텔레콤은 이러한 국내외 규제 흐름에 선제적으로 대응하기 위해 자체적인 공급망 보안 정책을 수립하였으며, 모든 협력사에 대해 글로벌 표준(SPDX, CycloneDX)에 부합하는 SBOM 제출을 의무화하고 있습니다. +이러한 규제 흐름에 대응하는 SK텔레콤의 요구사항은 [SK텔레콤 공급망 보안 정책](../policy/)에 정리되어 있습니다. ## 관련 문서 diff --git a/content/ko/guide/supply-chain/sbom/_index.md b/content/ko/guide/supply-chain/sbom/_index.md index 67f82af58..acd5ec570 100644 --- a/content/ko/guide/supply-chain/sbom/_index.md +++ b/content/ko/guide/supply-chain/sbom/_index.md @@ -4,7 +4,7 @@ linkTitle: "SBOM 이란?" weight: 3 type: docs description: > - 개발자와 관리자가 알아야 할 SBOM의 핵심 개념부터 생성, 통합, 관리까지의 전체 라이프사이클을 안내합니다. + 개발자와 관리자가 알아야 할 SBOM의 핵심 개념과 업계 표준을 안내합니다. --- ## 개요 @@ -16,26 +16,4 @@ description: > 1. [개념 및 필요성](what-is-sbom/): SBOM이 무엇이며, 왜 지금 우리에게 필요한지 근본적인 이유를 설명합니다. 2. [표준 비교 (SPDX vs CycloneDX)](standards/): 업계 표준 포맷의 차이점을 이해하고, 프로젝트 성격에 맞는 포맷을 선택할 수 있습니다. -SBOM을 실제로 생성하고 검증해 제출하는 실무 방법은 [공급사 가이드](../for-suppliers/)에서 다룹니다. - -아래는 개발부터 보안 조치까지 SBOM이 흐르는 전체 라이프사이클입니다. - -```mermaid -graph TD - A[개발 시작] --> B[의존성 추가] - B --> C{빌드/배포} - C -->|자동화| D[SBOM 생성] - D --> E[저장소 업로드] - E --> F[취약점 분석] - F --> G[보안 조치] - - 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 - - class A start - class B,E,F proc - class C decision - class D,G good -``` \ No newline at end of file +SBOM을 실제로 생성하고 검증해 제출하는 실무 방법은 [공급사 가이드](../for-suppliers/)에서 다룹니다. \ No newline at end of file diff --git a/content/ko/guide/supply-chain/sbom/standards.md b/content/ko/guide/supply-chain/sbom/standards.md index b301d6a06..4dfacb04b 100644 --- a/content/ko/guide/supply-chain/sbom/standards.md +++ b/content/ko/guide/supply-chain/sbom/standards.md @@ -13,154 +13,10 @@ SK텔레콤 제출용 SBOM은 CycloneDX (JSON) 형식을 권장합니다. 허용 ## 주요 SBOM 표준 -현재 시장을 양분하고 있는 두 가지 주요 표준 형식이 있습니다. 두 형식 모두 널리 사용되지만, 탄생 배경과 주력 분야에 차이가 있습니다. - -- SPDX: Software Package Data Exchange -- CycloneDX: OWASP 주관의 보안 중심 SBOM 표준 - - -## SPDX (Software Package Data Exchange) - -### 개요 - -SPDX는 Linux Foundation이 주관하는 오픈소스 프로젝트로, 소프트웨어 패키지의 라이선스 및 저작권 정보를 표준화된 방식으로 표현하기 위해 개발되었습니다. (ISO/IEC 5962:2021) - -### 주요 특징 - -1. SPDX는 원래 오픈소스 라이선스 정보 교환을 위해 개발되어, 라이선스 관련 정보를 상세하게 표현합니다. - -- 표준화된 라이선스 식별자 (SPDX License List) -- 라이선스 표현식 (예: Apache-2.0 OR MIT) -- 저작권 정보 및 파일별 라이선스 - -2. 패키지뿐만 아니라 개별 파일 레벨의 정보도 포함할 수 있습니다. - -- 파일별 해시값 -- 파일별 라이선스 -- 파일별 저작권 정보 - -### SPDX 문서 구조 - -```json -{ - "SPDXID": "SPDXRef-DOCUMENT", - "spdxVersion": "SPDX-2.3", - "name": "Example-SBOM", - "documentNamespace": "https://example.com/sbom-2026-001", - "creationInfo": { - "created": "2026-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" - } - ] - } - ] -} -``` - -### 장점 - -- ISO 국제 표준으로 공식 인정 -- 라이선스 정보가 상세함 -- 파일 레벨까지 추적 가능 -- 성숙한 도구 생태계 - -### 단점 - -- 보안 취약점 정보가 선택사항 -- 구조가 다소 복잡 -- 보안 중심 프로젝트에는 부족할 수 있음 - -## CycloneDX - -### 개요 - -CycloneDX는 OWASP(Open Web Application Security Project)에서 개발한 SBOM 표준으로, 애플리케이션 보안에 중점을 둡니다. - - -### 주요 특징 - -1. 처음부터 보안 취약점 관리를 위해 설계되었습니다. - -- 취약점 정보 (Vulnerabilities) -- 보안 분석 결과 (Security Analysis) -- 위협 정보 (Threats) - -2. SPDX에 비해 구조가 간결하고 이해하기 쉽습니다. - -- 필수 정보에 집중 -- JSON, XML 형식 지원 -- 작은 파일 크기 - -3. 다양한 사용 사례를 지원하는 확장 기능을 제공합니다. - -- SaaS BOM -- Hardware BOM -- AI/ML BOM -- Cryptography BOM - -### CycloneDX 문서 구조 - -```json -{ - "bomFormat": "CycloneDX", - "specVersion": "1.6", - "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", - "version": 1, - "metadata": { - "timestamp": "2026-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" - } - } - ] - } - ] -} -``` - -### 장점 +현재 널리 쓰이는 표준은 두 가지이며, 둘 다 SK텔레콤 제출에 사용할 수 있습니다. 탄생 배경과 주력 분야가 다릅니다. -- 보안 취약점 정보 기본 포함 -- 구조가 간결하고 이해하기 쉬움 -- 보안 도구와의 통합이 우수 -- 활발한 커뮤니티 및 도구 개발 -- ECMA International의 ECMA-424로 국제 표준화 - -### 단점 - -- 파일 레벨 정보는 제한적 -- 라이선스 표현이 SPDX보다 단순 +- SPDX (Software Package Data Exchange): Linux Foundation이 주관하는 표준(ISO/IEC 5962)입니다. 오픈소스 라이선스 정보 교환을 위해 개발되어 라이선스·저작권 정보 표현이 상세하고, 개별 파일 레벨의 정보까지 담을 수 있습니다. +- CycloneDX: OWASP가 개발한 보안 중심 표준(ECMA-424)입니다. 처음부터 취약점 관리를 위해 설계되어 구조가 간결하고, 보안 도구와의 통합이 우수합니다. ## SPDX vs CycloneDX 비교 @@ -177,30 +33,7 @@ CycloneDX는 OWASP(Open Web Application Security Project)에서 개발한 SBOM | 주요 사용자 | 법무팀, 오픈소스 관리 조직 | 보안팀, DevOps 엔지니어 | | SKT 권장 | 라이선스 검증이 주 목적일 때 | 보안 취약점 관리가 주 목적일 때 | - -## 선택 가이드 - -### CycloneDX 선택이 적합한 경우 - -다음과 같은 경우 CycloneDX를 권장합니다. - -- 보안이 최우선: 취약점 관리가 주요 목적 -- 빠른 시작: 간결한 구조로 빠르게 도입 -- DevSecOps: CI/CD에 통합하여 자동화 -- 현대적인 애플리케이션: 클라우드, 컨테이너 환경 - -### SPDX 선택이 적합한 경우 - -다음과 같은 경우 SPDX를 권장합니다. - -- 라이선스 컴플라이언스 중시: 상세한 라이선스 정보 필요 -- 파일 레벨 추적: 소스코드 파일별 정보 필요 -- ISO 표준 준수: 공식 표준 인증 필요 -- 레거시 시스템: 기존 SPDX 도구 사용 중 - -### SK텔레콤 권장사항 - -SK텔레콤의 내부 프로젝트는 CycloneDX (JSON) 형식을 기본 권장합니다. 이는 내부 취약점 관리 시스템과의 연동성이 CycloneDX가 더 우수하기 때문입니다. 단, 외부 파트너사가 SPDX를 제출하는 경우에도 호환성을 지원합니다. +어느 형식을 쓰든 제출 가능 여부는 형식이 아니라 내용이 가릅니다. 생성 도구가 지원하는 형식을 선택하고, [제출 요구사항](/guide/supply-chain/for-suppliers/requirements/)의 필수 필드를 충족하면 됩니다. ## 상호 변환 diff --git a/content/ko/guide/supply-chain/sbom/what-is-sbom.md b/content/ko/guide/supply-chain/sbom/what-is-sbom.md index e0e4facd6..b274ec736 100644 --- a/content/ko/guide/supply-chain/sbom/what-is-sbom.md +++ b/content/ko/guide/supply-chain/sbom/what-is-sbom.md @@ -35,51 +35,14 @@ graph TD ## SBOM의 주요 구성 요소 -### 컴포넌트 정보 +SBOM 문서에는 다음 정보가 담깁니다. -각 소프트웨어 컴포넌트에 대한 기본 정보를 포함합니다. +- 컴포넌트 정보: 이름, 버전, 공급자, 라이선스 +- 고유 식별자: 컴포넌트를 명확히 식별하는 표준 식별자. Package URL(purl)이 가장 널리 쓰입니다. (예: `pkg:maven/org.springframework/spring-core@5.3.20`) +- 의존성 관계: 직접 의존성(프로젝트가 직접 사용)과 전이적 의존성(직접 의존성이 다시 의존) +- 메타데이터: 생성 도구, 생성 시각, 생성자 -- 이름(Name): 컴포넌트의 공식 명칭 -- 버전(Version): 정확한 버전 번호 -- 공급자(Supplier): 컴포넌트를 제공한 조직 또는 개인 -- 라이선스(License): 적용되는 오픈소스 라이선스 - -### 고유 식별자 - -컴포넌트를 명확히 식별하기 위한 표준화된 식별자를 사용합니다. - -Package URL (purl) - -가장 일반적으로 사용되는 식별자 형식입니다. - -``` -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) - -보안 취약점 데이터베이스와 연동하기 위해 사용됩니다. - -``` -cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:* -``` - -### 의존성 관계 - -컴포넌트 간의 의존성 관계를 명시합니다. - -- 직접 의존성(Direct Dependencies): 프로젝트가 직접 사용하는 라이브러리 -- 전이적 의존성(Transitive Dependencies): 직접 의존성이 다시 의존하는 라이브러리 - -### 메타데이터 - -SBOM 자체에 대한 정보를 포함합니다. - -- 생성 도구: SBOM을 생성한 도구의 이름과 버전 -- 생성 시각: SBOM이 생성된 날짜와 시간 -- 생성자: SBOM을 생성한 조직 또는 개인 +SK텔레콤에 제출할 때 각 항목의 필수 여부와 형식은 [제출 요구사항](/guide/supply-chain/for-suppliers/requirements/)이 규정합니다. ## 왜 필요한가? @@ -94,13 +57,7 @@ SBOM은 단순한 문서가 아니라 소프트웨어 투명성을 위한 핵심 ### 3. 소프트웨어 품질 및 노후화 관리 오래되고 지원이 중단된(EOL, End-of-Life) 컴포넌트를 식별하여 기술 부채를 관리하고 소프트웨어의 건전성을 유지할 수 있습니다. -### 4. 규제 준수 - -미국 연방 정부를 비롯한 다양한 조직에서 SBOM 제출을 의무화하고 있습니다. - -- 미국 행정명령 14028 (연방 정부 공급사) -- EU Cyber Resilience Act -- 의료기기 FDA 승인 +이런 배경에서 미국·유럽 등의 규제도 SBOM 제출을 의무화하는 방향으로 강화되고 있습니다. 자세한 내용은 [규제 동향](/guide/supply-chain/overview/regulations/)을 참고하세요. ## 관련 문서