자주 발생하는 반려 사유
제출된 SBOM은 형식 검증과 취약점 분석을 거치며, 기준에 미달하면 반려됩니다. 아래는 실제 접수 과정에서 반복적으로 발생하는 반려 사유입니다. 제출 전에 검증 체크리스트와 함께 확인하시기 바랍니다.
반려는 SBOM의 형식이나 완전성 문제일 뿐이며, 아래 해결 방법대로 보완해 다시 제출하면 됩니다.
반려 사유 한눈에 보기
| 반려 사유 | 주요 원인 | 해결 방법 |
|---|---|---|
| PURL 전량 누락 | 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔 (syft dir: 등) | 빌드된 이미지나 소스코드를 스캔 대상으로 변경. SBOM 생성 방법 |
| 전이 의존성 누락 | 빌드(패키지 설치) 전에 소스만 스캔 | 빌드 완료 후 재생성. 제출 요구사항의 의존성 범위 절 |
pkg:generic/ PURL | 도구가 생태계를 식별하지 못함 | 생태계를 명시하는 타입으로 재생성. 제출 요구사항의 PURL 절 |
| 규격에 없는 PURL 타입 | 도구가 규격에 정의되지 않은 타입을 임의로 기재(예: pkg:applications/) | 규격에 정의된 타입으로 재생성. 제출 요구사항의 PURL 절 |
| maven 등 네임스페이스 필수 타입에 네임스페이스 누락 | 도구가 groupId와 artifactId를 점으로 이어 붙여 한 자리에 기재 | groupId를 네임스페이스 자리로 분리해 재생성. 제출 요구사항의 PURL 절 |
| 네임스페이스에 공급사 이름이나 URL 기재 | 생성 도구가 매니페스트의 벤더 문자열을 groupId 자리에 그대로 옮김 | 저장소가 쓰는 실제 식별자로 수정. 제출 요구사항의 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처럼 재생성해야 합니다.
사례 6: 형식 검사를 모두 통과했는데 purl 642건이 매칭 실패
한 공급사가 컴포넌트 8,129개짜리 CycloneDX SBOM을 제출했습니다. 모든 컴포넌트에 purl이 있어 보유율은 100%였고, pkg:generic도 없었으며, OS 패키지 배포판 누락도 0건이었습니다. 당시 체크리스트와 자동 검증 기준을 모두 통과한 파일입니다. 그런데 고유 purl 2,785건 가운데 642건이 실제 저장소 조회에서 매칭되지 않았습니다.
원인은 세 가지가 섞여 있었습니다.
- 네임스페이스 누락 663건:
pkg:maven/org.slf4j.jcl-over-slf4j@2.0.15처럼 groupId와 artifactId가 점으로 이어 붙어 한 자리에 들어갔습니다. 형식은 유효하고 스키마 검사도 통과하지만 저장소에 없는 좌표입니다. - 규격에 없는 타입:
pkg:applications/java@11.0.25처럼applications라는 임의 타입이 쓰였습니다.generic이 아니므로 기존 금지 규칙에 걸리지 않았습니다. - 네임스페이스에 벤더 문자열:
pkg:maven/The%2BApache%2BSoftware%2BFoundation/poi@5.4.1,pkg:maven/http%3A/www.jboss.org/jbossxts@1.1처럼 회사 이름이나 URL이 groupId 자리에 들어갔습니다.
세 유형 모두 스키마 검사로는 걸러지지 않으므로, 검증 체크리스트의 PURL 확인 명령으로 직접 점검한 뒤 제출해야 합니다.
같은 파일에서 pkg:maven/org.drools/org.drools.drools-core-dynamic@7.67.2.Final-redhat-00054처럼 artifactId 앞에 groupId가 한 번 더 붙은 경우도 나왔습니다. 실제 좌표는 org.drools:drools-core-dynamic입니다. 이 유형은 위 세 가지와 달리 형식으로 판정할 수 없습니다. org.drools:org.drools.updatesite나 org.apache.felix:org.apache.felix.http.jetty처럼 artifactId가 groupId로 시작하는 것이 정상인 좌표도 많기 때문입니다. Eclipse 플러그인과 OSGi 번들은 artifactId에 번들 심볼릭 이름을 그대로 쓰는 관례가 있습니다. 그래서 체크리스트에는 점검 항목을 두지 않았고, 확인하려면 해당 좌표가 저장소에 실제로 있는지 조회해야 합니다.
반려되지 않는 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.