자주 발생하는 반려 사유
제출된 SBOM은 형식 검증과 취약점 분석을 거치며, 기준에 미달하면 반려됩니다. 아래는 실제 접수 과정에서 반복적으로 발생하는 반려 사유입니다. 제출 전에 검증 체크리스트와 함께 확인하시기 바랍니다.
반려는 SBOM의 형식이나 완전성 문제일 뿐이며, 아래 해결 방법대로 보완해 다시 제출하면 됩니다.
반려 사유 한눈에 보기
| 반려 사유 | 주요 원인 | 해결 방법 |
|---|---|---|
| PURL 전량 누락 | 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔 (syft dir: 등) | 빌드된 이미지나 소스코드를 스캔 대상으로 변경. SBOM 생성 방법 |
| 전이 의존성 누락 | 빌드(패키지 설치) 전에 소스만 스캔 | 빌드 완료 후 재생성. 제출 요구사항의 의존성 범위 절 |
pkg:generic/ PURL | 도구가 생태계를 식별하지 못함 | 생태계를 명시하는 타입으로 재생성. 제출 요구사항의 PURL 절 |
| 컴포넌트 버전 누락 | 매니페스트 불완전 또는 도구 설정 문제 | version 필드 필수 기재. 제출 요구사항 |
| 서버인데 OS 패키지 미포함 | 애플리케이션 소스만 스캔 | 납품 상태의 rootfs나 이미지를 스캔. SBOM 생성 방법 |
| OS 패키지 PURL에 배포판 누락 | 스캔 대상에 /etc/os-release가 없어 도구가 배포판을 판정하지 못함 | rootfs의 루트나 이미지를 대상으로 재생성. SBOM 생성 방법 |
| OS 패키지 PURL의 배포판이 네임스페이스가 아닌 쿼리 파라미터에 표기 | 도구가 배포판을 ?distro=...처럼 부가 정보로만 기재 | 배포판을 경로(네임스페이스)로 옮겨 재생성. 제출 요구사항의 PURL 절 |
| 실제와 다른 배포판·버전의 PURL | 도구가 파일 이름으로 무관한 배포판 패키지를 추정 | 실제 설치된 패키지를 기준으로 재생성. SBOM 생성 방법 |
| 허용되지 않는 포맷·버전 | 지원 범위 밖의 포맷으로 생성 | CycloneDX JSON 권장. 제출 요구사항 |
| 최상위 컴포넌트 정보 누락 | 메타데이터에 납품 제품명과 버전 미기재 | metadata의 component에 제품명과 버전 기재. 제출 요구사항 |
| 최상위 컴포넌트 이름이 다른 제출 건과 충돌 | 생성 도구가 제품명 대신 고정값을 채움(예: 빈 값, ., /scan) | metadata의 component 이름을 장비·제품을 특정할 수 있는 고유한 값으로 수정 후 재제출. 제출 요구사항 |
대표 사례
사례 1: 설치 디렉터리 스캔으로 PURL이 전량 누락
한 공급사가 syft dir:<설치 디렉터리>로 패키지 매니저 메타데이터가 없는 위치를 스캔해 제출한 SBOM은 대부분의 컴포넌트에 purl이 하나도 없어, 취약점 매칭이 전량 실패하고 반려되었습니다. 패키지 매니저 메타데이터(package.json, go.mod, RPM/DEB 패키지 DB 등)가 없는 위치를 스캔하면 도구가 생태계를 식별하지 못합니다.
스캔 대상을 빌드된 이미지나 소스코드로 바꾸고, 생성 직후 purl 개수를 확인하십시오. 확인 명령은 검증 체크리스트에 있습니다.
사례 2: 빌드 전 스캔으로 전이 의존성 누락
직접 의존성이 수 개인 프로젝트인데 총 컴포넌트가 10개 미만이라면 전이 의존성 누락을 의심해야 합니다. 일반적인 웹 애플리케이션은 전이 의존성까지 포함하면 수십에서 수백 개의 컴포넌트가 나옵니다. npm install, mvn package 같은 빌드를 완료한 뒤 생성하면 해결됩니다.
사례 3: 생성 도구가 최상위 컴포넌트 이름을 고정값으로 채워 다른 제출 건과 충돌
한 공급사가 제조사 제공 SBOM 생성 도구로 만든 CycloneDX SBOM을 제출했는데, 이미 등록된 다른 장비의 SBOM과 이름이 겹쳐 반려되었습니다. 확인 결과 이 도구는 스캔한 장비와 무관하게 metadata.component.name을 항상 같은 고정값으로 채우고 있었습니다. 같은 도구로 다른 장비의 SBOM을 만들어도 이름이 매번 똑같이 나오기 때문에, 먼저 등록된 건과 계속 충돌합니다.
이런 도구를 사용하는 경우 SBOM을 텍스트 편집기로 열어 metadata.component.name(CycloneDX) 또는 최상단 name(SPDX) 값을 장비를 식별할 수 있는 값으로 직접 수정한 뒤 제출해야 합니다.
사례 4: OS 패키지가 빠지고 실제와 다른 배포판 PURL로 선언
RHEL 서버 제품의 SBOM이 애플리케이션 소스 트리만 대상으로 생성되어, 설치된 rpm 패키지가 하나도 포함되지 않은 채 제출되었습니다. 여기에 더해 소스에 포함된 라이브러리가 pkg:deb/debian/libpcap@1.1.1-2+squeeze1처럼 데비안 소스 패키지로 선언되어 있었습니다. 생성 도구가 소스 파일 이름을 단서로 그 파일을 담고 있는 데비안 패키지를 추정해 붙인 결과입니다.
이 유형은 형식 검증을 통과합니다. purl이 실재하는 패키지를 가리키므로 매칭도 정상 성공하고 화면에도 오류가 보이지 않습니다. 그러나 실제 서버에 설치된 것과 무관한 컴포넌트의 취약점이 보고되고, OS를 업그레이드해도 결과가 달라지지 않습니다.
납품 상태의 rootfs나 이미지를 스캔해 OS 패키지를 포함시키고, 소스에 포함된 라이브러리는 실제 버전으로 선언해야 합니다. 절차는 SBOM 생성 방법의 서버 납품 절을 참고하십시오.
사례 5: 배포판 정보가 네임스페이스가 아니라 쿼리 파라미터에 표기됨
자체 빌드 리눅스 배포판을 쓰는 한 서버 제품의 SBOM에서, rpm 패키지 PURL에 배포판 값이 물음표 뒤 쿼리 파라미터로 붙어 있었습니다(예: pkg:rpm/bind@9.11.36?distro=customdistro-1.0). 도구가 배포판 자체는 식별했지만, 이를 요구되는 네임스페이스 자리가 아니라 부가 정보 자리에 기재한 경우입니다.
이 값은 취약점 매칭에 쓰이지 않아 해당 서버의 rpm 패키지 전량이 매칭 실패로 반려되었습니다. 배포판 값을 경로(타입과 패키지 이름 사이)로 옮겨 pkg:rpm/<배포판>/bind@9.11.36처럼 재생성해야 합니다.
반려되지 않는 SBOM의 모습
합격 기준을 충족하는 예시 파일을 내려받아 구조를 비교해 보십시오. 모든 컴포넌트에 purl과 버전이 있고, dependencies 배열이 직접·전이 의존 관계를 담고 있습니다.
관련 문서
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.