SBOM을 보고서가 아니라 배포 차단 조건으로 쓰는 방법

SBOM을 도입한 팀이 자주 겪는 실패는 두 가지다. 하나는 CI가 매번 JSON 파일을 만들지만 아무도 보지 않는 경우이고, 다른 하나는 모든 높은 CVSS 항목을 즉시 차단해 예외 티켓만 폭증하는 경우다. 둘 다 구성 요소 목록과 위험 의사결정 사이의 연결이 빠져 있다.

실무에서 SBOM은 “무엇이 들어갔는가”를 설명하는 증거다. 배포 차단은 여기에 “그 구성 요소가 실제로 실행되는가”, “외부에서 도달 가능한가”, “악용이 확인됐는가”, “수정 버전이 있는가”를 더해 결정해야 한다.

아티팩트 연결은 SLSA 프로비넌스로 빌드 산출물 신뢰를 증명하는 법, 패키지 출처 통제는 npm 의존성 혼동 공격을 막는 레지스트리 운영 원칙, 배포 시점의 서명 강제는 컨테이너 이미지 서명 정책과 함께 설계하면 빈틈이 줄어든다.

신뢰할 수 있는 SBOM의 생성 지점

소스 저장소의 잠금 파일만 읽어 생성하면 빌드 과정에서 추가된 바이너리, OS 패키지, 정적 링크 라이브러리, 컨테이너 베이스 이미지가 빠질 수 있다. 가능하면 다음 지점을 함께 사용한다.

1. 의존성 해석 직후: 직접·전이 의존성과 선언 정보를 확보한다.
2. 빌드 산출물 생성 후: 실제 번들, 바이너리, 패키지를 스캔한다.
3. 컨테이너 이미지 완성 후: OS·언어 패키지와 레이어를 확인한다.
4. 배포 직전: 서명된 아티팩트 해시와 SBOM을 연결한다.

SBOM에는 이름만 아니라 버전, 패키지 URL(purl) 또는 동등한 식별자, 공급자, 해시, 의존 관계, 라이선스, 생성 도구와 시각, 대상 아티팩트 해시가 필요하다. 버전이 unknown인 구성 요소는 취약점 매칭을 할 수 없으므로 품질 오류로 집계해야 한다.

배포 게이트는 위험 조건의 조합으로 만든다

다음과 같은 단일 조건은 피하는 편이 좋다.

CVSS >= 7.0 이면 모든 배포 차단

대신 조직의 자산과 노출을 반영한 조합을 사용한다.

block_release_when:
  - vulnerability.is_known_exploited == true
    and component.reachable == true
    and asset.internet_exposed == true
  - vulnerability.severity == "critical"
    and component.reachable == true
    and fix.available == true
    and exception.valid == false
  - sbom.coverage_percent < 95
  - artifact.digest != sbom.subject_digest

warn_only_when:
  - component.reachable == false
  - fix.available == false
  - component.dev_only == true

수치는 조직에 맞게 조정해야 한다. 핵심은 취약점 점수, 실행 경로, 자산 중요도, 수정 가능성, 예외 상태를 분리해 기록하는 것이다.

도달 가능성과 실행 맥락

패키지가 SBOM에 존재한다고 해서 취약 코드가 호출된다는 뜻은 아니다. 반대로 정적 분석에서 호출이 보이지 않아도 리플렉션, 플러그인, 설정 기반 로딩 때문에 실행될 수 있다. 도달 가능성 결과는 절대 진실이 아니라 의사결정 근거 중 하나로 취급한다.

질문	확인 방법
취약 함수가 빌드에 포함되는가	바이너리·번들 분석
실제 실행 경로에서 호출되는가	정적·동적 도달 가능성 분석
공격자가 입력을 전달할 수 있는가	데이터 흐름·엔드포인트 검토
기능이 운영에서 켜져 있는가	설정·기능 플래그 확인
보완 통제가 공격을 막는가	WAF, 권한, 네트워크 경계 검증

도달 불가 판정에는 분석 도구 버전, 대상 커밋, 근거와 재검토일을 남긴다. 근거 없는 “사용하지 않음”은 예외 사유가 아니다.

VEX와 예외 관리

VEX는 특정 제품이 알려진 취약점의 영향을 받는지, 받지 않는다면 왜 그런지를 기계가 읽을 수 있게 표현하는 데 유용하다. 다만 VEX 문서를 자동으로 신뢰하면 안 된다. 공급자 서명, 제품 버전, 근거, 발행일을 확인하고 내부 배포 아티팩트와 일치시키는 절차가 필요하다.

예외에는 다음 필드를 강제한다.

• 취약점 ID와 영향받는 구성 요소·버전
• 자산·서비스 소유자와 승인자
• 도달 가능성 및 노출 근거
• 패치 불가 사유와 보완 통제
• 만료일과 다음 검토일
• 제거 또는 업그레이드 작업 링크
• 예외가 허용되는 정확한 아티팩트 해시

버전 범위 전체에 대한 영구 예외보다 특정 해시와 짧은 기간에 묶인 예외가 안전하다. 새 빌드가 나오면 기존 예외를 자동 승계하지 않는 것이 기본값이어야 한다.

흔한 실패 모드

실패 모드	증상	교정 방법
SBOM이 소스와만 연결됨	배포 이미지와 목록이 다름	산출물 해시를 subject로 기록
구성 요소 식별자 불완전	취약점 매칭 누락·오탐	purl, CPE, 공급자 정보를 보강
개발 의존성까지 일괄 차단	불필요한 예외 증가	runtime/dev/build 범위 구분
베이스 이미지가 오래됨	앱 패치 후에도 OS 취약점 잔존	이미지 재빌드 주기와 digest 고정
예외가 만료되지 않음	위험이 영구 승인됨	만료·재승인·자동 알림
스캐너 결과만 보관	왜 배포했는지 설명 불가	정책 판단·승인·근거를 함께 보관

운영 지표와 탐지 신호

• 배포 아티팩트 중 SBOM 연결 비율
• 버전·식별자 미확인 구성 요소 비율
• 마지막 생성 후 경과 시간과 배포 시각 차이
• 알려진 악용 취약점의 미해결 수와 평균 대응 시간
• 예외 총수, 만료 초과 수, 소유자 없는 예외 수
• 동일 구성 요소가 여러 서비스에 퍼진 범위
• SBOM 생성 도구·포맷 변경 후 구성 요소 수의 급격한 변동
• 배포 digest와 SBOM subject digest 불일치

구성 요소 수가 갑자기 줄면 의존성이 정리된 것일 수도 있지만 생성 실패일 수도 있다. 이전 빌드 대비 차이를 품질 검사로 다루는 이유다.

단계적 도입 순서

1. 인터넷 노출 서비스 한두 개를 선택한다.
2. SBOM 품질 기준을 먼저 통과시킨다.
3. 알려진 악용 취약점과 명확한 수정 버전이 있는 항목만 차단한다.
4. 경고 결과와 실제 개발 부담을 2~4주 관찰한다.
5. 도달 가능성·자산 중요도·예외 만료를 정책 엔진에 추가한다.
6. 컨테이너, 서버리스, 모바일, 펌웨어 등 산출물 유형별로 확장한다.

초기에는 거짓 양성을 줄이는 것이 중요하다. 개발팀이 게이트를 우회하는 습관을 들이면 나중에 정책을 강화해도 통제가 되지 않는다.

사고 대응 활용

새 취약점이 공개되면 먼저 어떤 저장소가 패키지를 선언했는지가 아니라 어떤 배포 아티팩트가 해당 구성 요소를 포함하는지 검색한다. 이후 인터넷 노출, 실행 여부, 데이터 민감도, 보완 통제를 기준으로 우선순위를 정한다. SBOM이 충분히 정확하면 수 시간 안에 영향을 좁힐 수 있고, 그렇지 않으면 모든 팀에 수동 확인을 요청하게 된다.

참고 기준

• NIST Secure Software Development Framework SP 800-218
• CISA Software Bill of Materials
• CycloneDX Specification
• SPDX Specifications
• SLSA Specification v1.2

결론

좋은 SBOM은 긴 목록이 아니라 특정 배포물의 구성과 출처를 재현할 수 있는 목록이다. 좋은 릴리스 게이트는 취약점 숫자가 아니라 실제 악용 경로와 수정 가능성을 설명한다. 먼저 SBOM 정확도를 측정하고, 그 다음 제한된 차단 규칙을 적용하며, 마지막에 예외 만료와 사고 대응까지 연결하는 순서가 가장 안전하다.