sktelecom · haksungjang · Sep 4, 2026 · Sep 4, 2026
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
@@ -184,7 +184,12 @@ This applies only when you deliver a server with an application installed on top
 
 For the OS layer, target the server's rootfs (the extracted root filesystem) or its container image. Syft reads the package database (rpm/dpkg/apk) and identifies every installed package with a real purl (`pkg:rpm/...`). The target must be the state delivered after the build, not the original base image you received, because it must include the OS packages installed during the build. Scanning a folder that only holds unpacked installation files with no package database yields empty purls and is rejected.
 
+The target must be the root of the rootfs. Point Syft at a subdirectory and it still reads the package database, but it cannot determine the distribution. Syft takes the distribution from `/etc/os-release` inside the target and writes it into each purl. A correct result looks like `pkg:rpm/rhel/bind@9.11.36-16.el8_10.6`, with the distribution between the type and the package name. When that slot is empty, the SBOM passes format validation but SK Telecom's system cannot identify the packages, so every OS package fails to match and the submission is rejected. Confirm that this file is present in the target before you scan.
+
 ```bash
+# First confirm the target carries distribution information
+cat /path/to/server-rootfs/etc/os-release
+
 # Against a rootfs directory
 syft dir:/path/to/server-rootfs -o cyclonedx-json=myserver_1.0.0_os.json
 

diff --git a/content/en/guide/supply-chain/for-suppliers/rejection-reasons.md b/content/en/guide/supply-chain/for-suppliers/rejection-reasons.md
@@ -18,6 +18,7 @@ Submitted SBOMs go through format validation and vulnerability analysis, and are
 | `pkg:generic/` PURLs | The tool could not identify the ecosystem | Regenerate with ecosystem-specific types. See the PURL section of the [Submission Requirements](../requirements/) |
 | Component versions missing | Incomplete manifests or tool configuration issues | The `version` field is required. [Submission Requirements](../requirements/) |
 | Server delivery with no OS packages | Only the application source was scanned | Scan the rootfs or image as delivered. [How to Generate an SBOM](../creation-guide/#server-delivery) |
+| OS package PURL missing the distribution | The scan target had no `/etc/os-release`, so the tool could not determine the distribution | Regenerate against the root of the rootfs or the image. [How to Generate an SBOM](../creation-guide/#server-delivery) |
 | PURL naming a different distribution or version | The tool guessed an unrelated distribution package from a file name | Regenerate from the packages actually installed. [How to Generate an SBOM](../creation-guide/#server-delivery) |
 | Unaccepted format or version | Generated in a format outside the supported range | CycloneDX JSON recommended. [Submission Requirements](../requirements/) |
 | Top-level component info missing | Delivered product name and version not recorded in the metadata | Record the product name and version in the metadata component. [Submission Requirements](../requirements/) |

diff --git a/content/en/guide/supply-chain/for-suppliers/requirements.md b/content/en/guide/supply-chain/for-suppliers/requirements.md
@@ -101,6 +101,8 @@ PURL (Package URL) is a standard URL format for uniquely identifying a software
 
 > **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.
 
+An OS package (rpm, deb, apk) must carry the distribution between the type and the package name, as in `pkg:rpm/rhel/bind@9.11.36-16.el8_10.6`. When that slot is empty the identifier looks well formed but names no specific package, so vulnerability mapping fails and the SBOM is rejected.
+
 ### PURL Examples by Language
 
 | Ecosystem | PURL Format Example |
@@ -122,6 +124,7 @@ PURL (Package URL) is a standard URL format for uniquely identifying a software
 | `actions/checkout:v3` | `pkg:github/actions/checkout@v3` |
 | `lodash@4.17.21` | `pkg:npm/lodash@4.17.21` |
 | `pkg:generic/foo@1.0` | (Change to a type appropriate for the ecosystem) |
+| `pkg:rpm/bind@9.11.36-16.el8_10.6` | `pkg:rpm/rhel/bind@9.11.36-16.el8_10.6` |
 
 > For detailed PURL specifications, refer to the [official Package URL spec](https://github.com/package-url/purl-spec).
 

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
@@ -183,7 +183,12 @@ OS 위에 애플리케이션을 올려 서버 형태로 납품하는 경우에
 
 OS 층은 서버의 rootfs(추출한 루트 파일시스템)나 그 컨테이너 이미지를 대상으로 합니다. 패키지 데이터베이스(rpm/dpkg/apk)를 읽어 설치된 패키지를 모두 실제 purl(`pkg:rpm/...`)로 식별합니다. 대상은 받아온 원본 베이스가 아니라 빌드가 끝나 납품되는 상태여야 합니다. 빌드 과정에서 설치한 OS 패키지까지 포함해야 하기 때문입니다. 설치 파일만 풀어 놓고 패키지 데이터베이스가 없는 폴더를 스캔하면 purl이 비어 반려됩니다.
 
+대상은 rootfs의 루트여야 합니다. 하위 디렉터리만 지정하면 패키지 데이터베이스는 읽혀도 배포판이 판정되지 않습니다. Syft는 대상 안의 `/etc/os-release`로 배포판을 정하고 그 값을 purl에 넣습니다. 정상이라면 `pkg:rpm/rhel/bind@9.11.36-16.el8_10.6`처럼 타입과 패키지 이름 사이에 배포판이 들어갑니다. 이 자리가 비면 형식 검증은 통과하지만 SK텔레콤 시스템이 패키지를 식별하지 못해 OS 패키지가 전량 미매칭으로 반려됩니다. 스캔 전에 대상 안에 이 파일이 있는지 확인하시기 바랍니다.
+
 ```bash
+# 대상 안에 배포판 정보가 있는지 먼저 확인
+cat /path/to/server-rootfs/etc/os-release
+
 # rootfs 디렉터리를 대상으로
 syft dir:/path/to/server-rootfs -o cyclonedx-json=myserver_1.0.0_os.json
 

diff --git a/content/ko/guide/supply-chain/for-suppliers/rejection-reasons.md b/content/ko/guide/supply-chain/for-suppliers/rejection-reasons.md
@@ -18,6 +18,7 @@ description: >
 | `pkg:generic/` PURL | 도구가 생태계를 식별하지 못함 | 생태계를 명시하는 타입으로 재생성. [제출 요구사항](../requirements/)의 PURL 절 |
 | 컴포넌트 버전 누락 | 매니페스트 불완전 또는 도구 설정 문제 | `version` 필드 필수 기재. [제출 요구사항](../requirements/) |
 | 서버인데 OS 패키지 미포함 | 애플리케이션 소스만 스캔 | 납품 상태의 rootfs나 이미지를 스캔. [SBOM 생성 방법](../creation-guide/#서버-납품) |
+| OS 패키지 PURL에 배포판 누락 | 스캔 대상에 `/etc/os-release`가 없어 도구가 배포판을 판정하지 못함 | rootfs의 루트나 이미지를 대상으로 재생성. [SBOM 생성 방법](../creation-guide/#서버-납품) |
 | 실제와 다른 배포판·버전의 PURL | 도구가 파일 이름으로 무관한 배포판 패키지를 추정 | 실제 설치된 패키지를 기준으로 재생성. [SBOM 생성 방법](../creation-guide/#서버-납품) |
 | 허용되지 않는 포맷·버전 | 지원 범위 밖의 포맷으로 생성 | CycloneDX JSON 권장. [제출 요구사항](../requirements/) |
 | 최상위 컴포넌트 정보 누락 | 메타데이터에 납품 제품명과 버전 미기재 | metadata의 component에 제품명과 버전 기재. [제출 요구사항](../requirements/) |

diff --git a/content/ko/guide/supply-chain/for-suppliers/requirements.md b/content/ko/guide/supply-chain/for-suppliers/requirements.md
@@ -101,6 +101,8 @@ PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위
 
 > **PURL은 반드시 `pkg:` 접두어로 시작하는 표준 형식이어야 합니다.** `name:version`, `org/repo:tag` 등 자유 텍스트는 허용되지 않으며, 이 경우 취약점 매핑이 불가능해 반려됩니다. 타입은 생태계를 특정해야 하며 `pkg:generic/`은 허용되지 않습니다.
 
+OS 패키지(rpm, deb, apk)는 타입과 패키지 이름 사이에 배포판을 넣어야 합니다(`pkg:rpm/rhel/bind@9.11.36-16.el8_10.6`). 이 자리가 비면 형식은 유효해 보여도 패키지를 특정할 수 없어 취약점 매핑이 되지 않고 반려됩니다.
+
 ### 언어별 PURL 예시
 
 | 생태계 | PURL 형식 예시 |
@@ -122,6 +124,7 @@ PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위
 | `actions/checkout:v3` | `pkg:github/actions/checkout@v3` |
 | `lodash@4.17.21` | `pkg:npm/lodash@4.17.21` |
 | `pkg:generic/foo@1.0` | (생태계에 맞는 타입으로 변경) |
+| `pkg:rpm/bind@9.11.36-16.el8_10.6` | `pkg:rpm/rhel/bind@9.11.36-16.el8_10.6` |
 
 > PURL에 대한 자세한 사양은 [Package URL 공식 스펙](https://github.com/package-url/purl-spec)을 참고하시기 바랍니다.