소프트웨어 공급망 보안에서 SBOM은 완성된 답안이 아니라 부품 목록이다. 어떤 라이브러리가 들어갔는지 알아도 그 부품이 신뢰할 수 있는 빌드 과정에서 만들어졌는지, 공개된 취약점이 실제 제품에서 실행 가능한지, 수정판이 같은 절차로 배포됐는지는 별도로 증명해야 한다. 2026년의 정책 과제는 목록을 많이 받는 것에서 목록·빌드 출처·악용 가능성·사고보고를 연결하는 것으로 옮겨가고 있다.
미국 사이버보안·인프라보안국(CISA)의 2025년 SBOM 최소요소 개정안은 각 소프트웨어 버전과 업데이트마다 SBOM을 만들고, 직접 의존성뿐 아니라 전이 의존성까지 포함하도록 요구한다. 알 수 없는 구성요소는 비어 있는 칸으로 숨기지 말고 ‘알려진 미확인 항목’으로 표시해야 한다. 이는 SBOM의 존재보다 완전성과 버전 일치가 더 중요하다는 뜻이다.
목록이 있어도 빌드 경로가 바뀌면 다른 제품이다
같은 소스코드와 같은 라이브러리 목록이라도 빌드 서버, 컴파일러, 환경변수, 서명키가 다르면 결과물은 달라질 수 있다. 공격자가 CI/CD 계정이나 패키지 저장소를 탈취하면 SBOM에는 정상 부품이 적혀 있어도 배포파일에 악성 코드가 삽입될 수 있다. 따라서 제품 해시, 빌드 시점, 소스 저장소, 빌드 작업자와 서명정보를 연결한 출처 증명이 필요하다.
NIST SP 800-204D는 클라우드 네이티브 CI/CD 단계에 아티팩트, 증명, 출처, SBOM 통제를 통합하는 전략을 제시한다. 중요한 점은 문서를 출시 뒤에 수작업으로 만드는 것이 아니라 빌드·시험·패키징·배포 과정에서 자동 생성하고 검증하는 것이다. 그래야 목록과 실제 배포물이 어긋나는 시간을 줄일 수 있다.
취약점 개수보다 실제 영향 여부를 판별해야 한다
SBOM을 취약점 데이터베이스와 대조하면 수많은 경고가 생긴다. 그러나 취약한 함수가 제품에서 호출되지 않거나, 특정 설정에서만 노출되거나, 다른 통제로 차단된 경우도 있다. 모든 경고를 동일 우선순위로 처리하면 중요한 패치가 늦어진다. 반대로 공급자의 ‘영향 없음’ 주장만 믿으면 위험을 놓칠 수 있다.
따라서 VEX 같은 악용 가능성 정보를 SBOM과 함께 제공하고, 영향 없음의 근거와 검증일을 기록해야 한다. 새 공격기법이나 설정 변경이 나오면 판정도 갱신돼야 한다. 구매자는 취약점 0개라는 숫자보다 판정 근거, 패치 기한, 지원 종료일과 연락 가능한 공개정책을 확인해야 한다.
자기확인과 제3자 검증은 위험도에 따라 달라야 한다
NIST의 공급망 지침은 일반적으로 안전개발관행에 대한 공급자의 자기확인을 허용하되, 제품의 중요도와 위험이 높으면 제2자 또는 제3자 검증을 요구할 수 있다고 설명한다. 모든 제품에 최고 수준 감사를 적용하면 중소 개발사의 비용이 급증한다. 반대로 핵심 인프라와 광범위한 권한을 가진 플랫폼까지 자기선언만 받는 것은 부족하다.
합리적인 구조는 위험을 계층화하는 것이다. 단순 도구는 표준 자기확인과 자동 검증을 적용하고, 관리자 권한·개인정보·산업제어를 다루는 제품에는 재현 가능한 빌드, 침투시험, 독립감사를 추가한다. 감사보고서 원문에 영업비밀이 포함되면 구매자에게 필요한 결론과 범위, 예외사항을 구조화해 제공할 수 있다.
EU 사고보고가 공급망 장부와 만나는 지점
EU 사이버복원력법(CRA)에 따라 2026년 9월 11일부터 제조사는 실제 악용된 취약점과 심각한 제품 보안사고를 ENISA 단일보고플랫폼에 신고해야 한다. 한 번의 신고로 관련 CSIRT와 당국에 전달되는 구조다. 이때 정확한 제품 버전과 영향 구성요소를 신속히 식별하려면 SBOM과 빌드 출처가 최신 상태여야 한다.
보고 속도만 강조하면 불완전한 초기정보가 확산될 수 있으므로 사실, 추정, 미확인 범위를 구분해야 한다. 공급자는 최초 신고 뒤 조사결과와 완화조치를 갱신하고, 고객은 자신이 사용하는 버전과 배포경로를 대조할 수 있어야 한다. 플랫폼도 신고 건수보다 수정까지 걸린 시간과 영향을 받은 고객 통지의 완결성을 평가해야 한다.
전망: 보안 문서에서 검증 가능한 운영기록으로
앞으로 조달 경쟁력은 SBOM 파일을 제출했는지가 아니라 목록이 실제 바이너리와 일치하고, 빌드 증명이 검증되며, 취약점 판정과 사고보고가 같은 제품 식별자를 사용하는지에 달릴 것이다. 기업은 SBOM 생성률, 서명 검증률, 미확인 의존성 비율, 패치 소요시간을 함께 관리해야 한다.
정책 당국은 형식 하나를 강제하기보다 상호운용 가능한 식별자와 갱신 절차, 위험기반 검증 수준을 명확히 해야 한다. 공급망 보안의 목적은 서류를 늘리는 것이 아니라 공격이 발생했을 때 어떤 제품이 왜 영향을 받았고 누가 언제 고칠지를 빠르게 증명하는 데 있다.
출처 및 확인 시각
- CISA, “Minimum Elements for a Software Bill of Materials (SBOM)”, 2025년 8월 — 2026년 8월 14일 15시 58분(한국시간) 확인
- NIST, “SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines”, 2024년 2월 12일 — 2026년 8월 14일 15시 58분(한국시간) 확인
- NIST, “Software Supply Chain Security Guidance: Attesting to Conformity with Secure Software Development Practices”, 2022년 2월 4일 갱신 — 2026년 8월 14일 15시 58분(한국시간) 확인
- ENISA, “Single Reporting Platform (SRP)”, FAQ 2026년 7월 17일 갱신 — 2026년 8월 14일 15시 58분(한국시간) 확인
의견을 남겨주세요