SBOM 필드 실전 가이드：NTIA 7대 요소 너머 무엇을 채워야 하는가
7대 요소는 문턱이지 천장이 아니다
SBOM을 어떻게 작성해야 하는지 논의할 때마다, 대화는 대개 NTIA의 7대 요소 목록—공급업체, 컴포넌트 이름, 버전, 고유 식별자, 의존 관계, SBOM 작성자, 타임스탬프—에서 멈추기 일쑤다. 이 일곱 항목을 확인하고 나면 작업이 끝났다고 여기는 사람들이 적지 않다.
2021년 행정명령 EO 14028이 막 시행됐을 무렵에는 그 판단이 어느 정도 통했을지 모른다. 그러나 FDA가 2023년 3월부터 의료기기 시판 허가 신청에 완전한 SBOM 첨부를 정식으로 요구하고, EU CRA가 2027년 12월 전면 적용되어 최대 1,500만 유로 또는 전 세계 매출의 2.5%에 달하는 과징금을 부과할 수 있게 됐으며, 자동차 분야의 UN R155 / ISO 21434와 국내 강제 표준 GB 44495가 잇달아 발효된 지금, 7대 요소의 "최소 충족" 포지션은 갈수록 어색해지고 있다.
문제는 7대 요소가 틀렸다는 게 아니다. 실무에서 너무 쉽게 잘못 기입되고, 채운 뒤에도 SBOM의 실제 가치를 좌우하는 수많은 필드가 여전히 무시된다는 점이다. 이 글에서는 "필수"에서 "강력 권장"으로 이어지는 순서에 따라 필드별로 뜯어보되, 고빈도 함정을 중심으로 정리한다. SBOM을 생산하거나 소비하는 엔지니어와 컴플라이언스 담당자 모두를 독자로 상정한다.
---
필드별 해부：7대 요소의 흔한 오기 유형
1. 공급업체 이름(Supplier Name)——모호성이 가장 많은 필드
실무에서 모호성이 가장 자주 발생하는 필드다. 동일한 컴포넌트라도 업스트림에는 복수의 "공급업체" 정체성이 존재할 수 있다. 원저작자, 패키징 메인테이너, 미러 배포자, 내부 재패키징 담당자가 모두 해당된다.
대표적인 함정：패키지 레지스트리 이름(예: npmjs.com)을 공급업체 필드에 기입하거나, Git 사용자명과 법인 주체를 혼용하는 경우다. 기업 내부 fork나 사설 미러의 경우, 공급업체 필드에는 업스트림 이름을 그대로 베끼는 대신 내부 식별자를 명확히 표기해야 한다. 그렇지 않으면 취약점 대응 시 "이 컴포넌트를 실제로 누가 관리하는가"를 신속히 파악할 수가 없다.
SPDX(ISO/IEC 5962) 명세에서는 PackageSupplier가 Organization:과 Person: 접두어를 지원하며, CycloneDX(Ecma 표준으로 채택)는 supplier와 author를 더 세밀하게 구분한다. 도구 선택 시에는 다운스트림 소비자와 사전에 맞춰 파싱 모호성을 예방해야 한다.
2. 컴포넌트 버전(Version)——"버전 없음"은 공란으로 둬도 된다는 의미가 아니다
소스에서 빌드했거나 태그를 붙이지 않은 내부 컴포넌트의 경우, 버전 필드를 공란으로 두면 취약점 매칭이 완전히 실패한다. 올바른 방법은 Git commit SHA 약칭(최소 12자리)을 기입하고, 추가 필드에 버전 출처 유형을 명시하는 것이다.
3. 고유 식별자(Unique Identifier)와 해시——둘은 상호 대체 불가
고유 식별자(PURL 또는 CPE)는 "이것이 어떤 컴포넌트인가"라는 질문에 답하고, 해시는 "이것이 컴포넌트의 어떤 빌드 산출물인가"라는 질문에 답한다. 둘 다 없어서는 안 되지만, 혼동하거나 하나만 기입하는 경우가 빈번하다.
PURL(pkg: 형식)은 npm, Maven, PyPI, Cargo 등 주요 패키지 관리자를 포괄하며 에코시스템 간 상호 운용성의 사실상 표준으로 자리 잡았다. CPE는 정부 조달과 NVD 취약점 매칭 시나리오에서 여전히 대체 불가한 위치를 차지한다.
해시 알고리즘 선택도 중요하다. MD5와 SHA-1은 무결성 검증 용도로는 이미 부족하며, SHA-256이 현재 최소 요건이고, 높은 보안 등급이 요구되는 경우에는 SHA-512를 사용해야 한다. 해시 대상이 압축 파일인지 압축 해제 후의 파일 트리인지를 명확히 해야 한다. 그렇지 않으면 양단 검증이 반드시 엇갈린다. 단편(Snippet) SCA와 매니페스트 SCA의 차이는 이 지점에서 특히 중요하다. 매니페스트는 선언된 버전만 제공할 수 있지만, 해시는 실제 사용된 코드가 선언과 일치함을 증명한다.
4. 의존 관계(Dependency Relationships)——깊이가 부족하면 채우지 않은 것과 같다
7대 요소 중 정보 밀도가 가장 낮고 대충 처리되기 가장 쉬운 필드다. 직접 의존성만 선언하고 전이 의존성을 펼치지 않으면 SBOM의 취약점 커버리지가 크게 줄어든다. Log4Shell(CVE-2021-44228, 2021년 12월)이 광범위하게 확산된 것은, 대부분의 조직이 자신의 애플리케이션 스택에 몇 겹의 전이 의존성을 통해 log4j-core가 들어와 있는지 몰랐기 때문이기도 하다.
실무 권장 사항：
- 전이 의존성은 최소 3단계까지 펼치고, 보안 민감 시스템은 전량 펼치는 것을 권장한다
DYNAMIC_LINK,STATIC_LINK,CONTAINS등 관계 유형을 구분하고DEPENDS_ON으로 일괄 처리하지 않는다- 개발 의존성(devDependency)과 런타임 의존성을 반드시 별도로 표기한다. 구매자가 리스크 평가 시 집중하는 지점이 전혀 다르기 때문이다
5. SBOM 작성자와 타임스탬프——생명주기 관리의 출발점
타임스탬프는 단순히 "SBOM이 언제 생성됐는가"가 아니라, 이 SBOM이 어떤 조건에서 유효하지 않은 것으로 간주되어야 하는지를 결정한다. created(최초 생성)와 documentNamespace의 버전 식별자를 함께 기입하고, CI/CD 파이프라인과 연동해 매 빌드마다 자동으로 갱신되도록 하는 것이 좋다. 수작업으로 관리하는 일회성 문서로 취급해서는 안 된다.
---
7대 요소 너머：실제 활용 가능성을 좌우하는 필드들
7대 요소로 기초를 다진 뒤에는, 아래의 필드들이 SBOM이 기계적으로 소비 가능한지, 취약점 대응을 뒷받침할 수 있는지, 감사 요건을 충족할 수 있는지를 결정한다.
라이선스 필드(License)
SPDX License Expression은 복합 표현식(예: Apache-2.0 AND MIT)을 지원하며, DeclaredLicense(패키지 메타데이터에 선언된 것)와 ConcludedLicense(스캔 도구로 실제 확인된 것)를 모두 기입해야 한다. 둘이 일치하지 않을 때는 자동 덮어쓰기가 아닌 수동 검토가 필요하다. 라이선스 충돌 탐지 실전 방법은 별도로 깊이 다룰 가치가 있다.
생명주기 상태(Lifecycle / EOL)
Python 2는 2020년에, AngularJS는 2022년에 공식 EOL을 맞이했으며, Log4j 1.x는 이미 2015년에 유지보수가 종료됐다. 그럼에도 이 컴포넌트들은 오늘날 프로덕션 환경의 SBOM에 대량으로 등장하고 있으며, EOL 상태를 표기하는 필드는 어디에도 없다. CycloneDX의 lifecyclePhase 필드와 커스텀 속성 모두 이 정보를 담을 수 있으며, 필수 입력 항목으로 지정할 것을 권장한다. 유지보수가 중단된 오픈소스 컴포넌트 리스크는 별도로 평가할 필요가 있다.
VEX 연계 필드——취약점 악용 가능성의 맥락
VEX(Vulnerability Exploitability eXchange)는 SBOM 본체에 속하지 않지만 SBOM과 긴밀하게 결합된다. VEX가 없는 SBOM은 취약점 공고를 마주쳤을 때 소비자가 "컴포넌트에 해당 CVE가 존재한다"는 사실만 알 수 있을 뿐, "현재 배포 환경에서 실제로 악용 가능한가"는 판단할 수 없다.
VEX의 네 가지 핵심 상태—not_affected, affected, fixed, under_investigation—와 영향 서술(impact statement) 및 조치 서술(action statement)이 결합되어야 비로소 완전한 취약점 대응 체인이 구성된다. EU CRA의 보고 의무(2026년 9월 11일부터 발효)는 제조사에 악용 가능성 평가 제공을 명시적으로 요구하며, VEX는 현재 가장 성숙한 기계 가독형 수단이다.
빌드 정보와 SLSA 출처(Provenance)
컴포넌트가 어떻게 빌드됐는지, 어떤 파이프라인에서 산출됐는지, 빌드 환경이 재현 가능한지—이 정보는 공급망 오염 시나리오(예: 2024년 3월 공개된 xz 백도어 CVE-2024-3094)에서 결정적인 역추적 가치를 지닌다. CycloneDX의 externalReferences와 buildMetaData 필드를 SLSA 출처 문서와 결합하는 것이 현재 가장 실행 가능한 기입 경로다.
---
구매자와 판매자：관심 우선순위의 비대칭
SBOM의 생산자(소프트웨어 판매자)와 소비자(조달자/운영자)는 필드 우선순위 판단에서 뚜렷한 비대칭을 보이는 경우가 많다. 이 비대칭이 계약 단계에서 조율되지 않으면, 취약점 대응 시 심각한 마찰이 발생한다.
판매자가 주로 관심을 갖는 항목：
- 필드가 컴플라이언스 제출 요건(FDA, CRA, GB 44495)을 충족하는가
- 생성 툴체인의 커버리지와 자동화 수준
- 내부 민감 정보(자체 개발 컴포넌트 이름, 내부 토폴로지)의 난독화 필요 여부
구매자가 주로 관심을 갖는 항목：
- 해시가 검증 가능한가(SBOM과 실제 납품물의 불일치 방지)
- 전이 의존성이 완전히 펼쳐져 있는가
- VEX가 취약점 공고에 맞춰 지속적으로 갱신되는가, 아니면 일회성 첨부 파일인가
- EOL 컴포넌트에 명확한 표기와 교체 계획이 있는가
조달 계약 또는 기술 부속서에는 SBOM 형식 버전, 갱신 주기, VEX 대응 기한, 그리고 분쟁 여지가 있는 필드(특히 공급업체 이름과 버전)의 기입 규범을 명확히 약정할 것을 권장한다. SBOM의 컴플라이언스 요건에서 역량 구축으로의 전환 경로에서 더 완전한 거버넌스 프레임워크 참고자료를 제공한다.
바이너리로 납품받은 결과물을 처리해야 하는 구매자는 SBOM 선언 내용만으로는 실제 구성을 검증할 수 없다. CleanBinary의 바이너리 성분 분석 기능은 산출물 측에서 역방향으로 SBOM의 정확성을 검증한다. 개발 단계부터 SBOM 생산 규범을 확립하려는 팀이라면, CleanSource SCA는 600여 종의 패키지 관리 에코시스템과 3억 2천만 컴포넌트 핑거프린트를 기반으로 한 전량 의존성 파싱을 지원하며 SPDX와 CycloneDX 형식으로 직접 출력한다. 경량으로 시작하고 싶다면 CleanSource SCA CE 커뮤니티 에디션을 선택할 수 있다. PureStream은 컴플라이언스 거버넌스 레이어에서 AI 기반 정책 오케스트레이션을 제공하며, 팀 간 SBOM 품질 기준선을 통일해야 하는 환경에 적합하다.
---
결어：필드 품질이 SBOM의 실제 가치를 결정한다
SBOM의 가치는 필드의 수가 아니라, 각 필드가 얼마나 정확한지, 기계 가독형인지, 컴포넌트 생명주기 동안 지속적으로 유지 관리되는지에 달려 있다. 7대 요소는 갖췄지만 해시를 검증할 수 없고, 의존 관계가 한 단계뿐이며, 공급업체 이름이 전후로 일치하지 않는 SBOM은 취약점 대응 시 제공할 수 있는 도움이 극히 제한된다.
xz 백도어부터 Shai-Hulud npm 웜(2025년 9월)에 이르기까지 공급망 공격 기법은 끊임없이 진화하고 있으며, 방어 측의 정보 품질은 최소한 공격 면의 복잡도와 동반 상승해야 한다. SBOM을 일회성 컴플라이언스 문서에서 지속적으로 갱신되는 소프트웨어 자재명세서로 바꾸는 데 있어, 필드 규범은 출발점이고, 툴체인 자동화는 보장 수단이며, 매매 양측의 계약 약정이 연결 고리다.
SBOM 완전 체계 구축에 대해서는 《SBOM 완전 가이드》를 참고하고, 의료기기 분야의 구체적인 컴플라이언스 경로는 의료기기 SBOM 컴플라이언스 실천을 참고하기 바란다.
---
