docs(supply-chain): condense the guide to essentials

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.

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

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)

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.

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.
     }]
   }]
 }
-...
 ```
 
 

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,19 +70,19 @@ 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
 
 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
 

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