자주 발생하는 반려 사유
제출된 SBOM은 형식 검증과 취약점 분석을 거치며, 기준에 미달하면 반려됩니다. 아래는 실제 접수 과정에서 반복적으로 발생하는 반려 사유입니다. 제출 전에 검증 체크리스트와 함께 확인하시기 바랍니다.
반려 사유 한눈에 보기
| 반려 사유 | 주요 원인 | 해결 방법 |
|---|---|---|
| PURL 전량 누락 | 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔 (syft dir: 등) | 빌드된 이미지나 소스코드를 스캔 대상으로 변경. SBOM 생성 방법 |
| 전이 의존성 누락 | 빌드(패키지 설치) 전에 소스만 스캔 | 빌드 완료 후 재생성. 제출 요구사항의 의존성 범위 절 |
pkg:generic/ PURL | 도구가 생태계를 식별하지 못함 | 생태계를 명시하는 타입으로 재생성. 제출 요구사항의 PURL 절 |
| 컴포넌트 버전 누락 | 매니페스트 불완전 또는 도구 설정 문제 | version 필드 필수 기재. 제출 요구사항 |
| 서버의 일부 층만 포함 | OS 층 또는 애플리케이션 층 중 하나만 스캔 | 층별로 생성해 병합. 서버 SBOM 생성 |
| 허용되지 않는 포맷·버전 | 지원 범위 밖의 포맷으로 생성 | CycloneDX JSON 권장. 제출 요구사항 |
| 최상위 컴포넌트 정보 누락 | 메타데이터에 납품 제품명과 버전 미기재 | metadata의 component에 제품명과 버전 기재. 제출 요구사항 |
대표 사례
사례 1: 설치 디렉터리 스캔으로 PURL이 전량 누락
한 공급사가 syft dir:/root/nag_pkg로 설치 디렉터리를 스캔해 제출한 SBOM은 261개 컴포넌트 중 purl이 하나도 없어, 취약점 매칭 251건이 모두 실패하고 전량 반려되었습니다. 패키지 매니저 메타데이터(package.json, go.mod, RPM/DEB 패키지 DB 등)가 없는 위치를 스캔하면 도구가 생태계를 식별하지 못합니다.
스캔 대상을 빌드된 이미지나 소스코드로 바꾸고, 생성 직후 purl 개수를 확인하십시오. 확인 명령은 검증 체크리스트에 있습니다.
사례 2: 빌드 전 스캔으로 전이 의존성 누락
직접 의존성이 수 개인 프로젝트인데 총 컴포넌트가 10개 미만이라면 전이 의존성 누락을 의심해야 합니다. 일반적인 웹 애플리케이션은 전이 의존성까지 포함하면 수십에서 수백 개의 컴포넌트가 나옵니다. npm install, mvn package 같은 빌드를 완료한 뒤 생성하면 해결됩니다.
반려되지 않는 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.