SBOM 이 컴플라이언스 보고서가 아니라 운영 도구가 되는 시점

처음에 우리에게 SBOM (Software Bill of Materials) 은 감사용 PDF 였다. 분기 1회 생성, 보안팀이 보관, 그게 끝. 6개월 후, SBOM 은 인시던트 응답의 1차 도구 가 됐다. 어떤 CVE 가 발표되면 5분 안에 "우리 영향 받는 서비스 수" 답이 나옴.

이 글은 PDF → 운영 도구 변환의 4 단계다.

단계 1 — PDF SBOM

처음 단계. 분기 1회 생성, 검토, 보관. 감사 통과 용도. 인시던트 발생 시 그 PDF 를 사람이 grep 하거나, 그것이 최신인지 확인 하는 데 30분.

이 단계의 SBOM 은 컴플라이언스 산출물 이지 운영 자산 이 아님.

단계 2 — 빌드마다 자동 생성

다음 단계. 빌드 파이프라인 에 SBOM 생성 (syft, cyclonedx) 박음. 각 이미지마다 그 시점의 SBOM 이 artifact 로 저장.

이게 큰 변화. 더 이상 분기 1회가 아니라 빌드마다. 인시던트 시 어떤 빌드가 어떤 의존성을 포함했는지 가 artifact 에서 직접 답된다.

작업 시간 — 2주.

단계 3 — 검색 가능한 인덱스

다음 단계. SBOM artifact 들을 중앙 인덱스 (예: dependency-track) 에 푸시. 어떤 CVE 가 발표되면, 인덱스에 질의 만 하면 영향 받는 빌드 / 이미지 / 서비스 가 즉시 나옴.

이게 진짜 운영 도구 가 되는 지점. CVE-XXXX 가 발표되면 우리 시스템에 영향 인지의 답이 5분 → 즉시.

작업 시간 — 6주 (인덱스 셋업 + 모든 SBOM 백필 + 운영 정착).

단계 4 — 알람 + 자동 트리거

마지막 단계. 인덱스가 NVD / OSV 와 자동 sync 되어, 새 CVE 가 우리 SBOM 과 매칭 되면 자동 알람. 알람이 Severity 에 따라:

• Critical → 즉시 page
• High → 24시간 내 PR 자동 생성 (Renovate 통합)
• Medium → 분기 보고서

작업 시간 — 4주. 이 단계가 완료되면 보안팀의 분기 감사가 1시간 → 5분.

4 단계의 비용 vs 가치

단계 | 작업 시간 | 누적 가치 (인시던트 응답 시간 절감)
────┼──────────┼─────────────────────────────────────
1   | 0 (기본) | 0
2   | 2주      | 인시던트당 ~25분 절감
3   | +6주     | 인시던트당 ~5시간 절감 (검색 가능)
4   | +4주     | 인시던트당 *자동 검출*, 사람 개입 90% 감소

단계 3 → 4 의 변환이 가장 큼. 단계 1 → 2 는 기반, 2 → 3 은 진짜 변환, 3 → 4 는 최적화.

우리 케이스 — 한 CVE 로 검증

작년 12월, 한 logging 라이브러리에 Critical CVE 발표. 우리 응답:

12:14  CVE 공개 (NVD 게시)
12:14  우리 SBOM 인덱스가 자동 매칭 — 알람 발생
12:14  영향 서비스 자동 식별: 11 개 이미지, 3 개 서비스
12:15  Renovate 가 PR 자동 생성 (3 PR)
12:18  SRE 가 PR 검토, 머지
12:24  배포 완료

10분 안에 풀린 인시던트. 단계 1 의 SBOM 으로는 몇 시간 걸렸을 작업.

어디서 멈출지

위 4 단계를 모두 갈 필요는 없다. 조직 단계별 권장:

• 50명 미만: 단계 2 까지 충분
• 50~200: 단계 3 권장
• 200+ 또는 규제 산업: 단계 4 권장

단계 3 까지의 총 작업 시간 8주 가 대부분 조직의 sweet spot. 단계 4 는 추가 4주 + 운영 부담 이라 명확한 ROI 가 있을 때만.

SBOM 이 아직 감사용 PDF 라면 뭐부터 해야 하나

SBOM 이 아직 분기 1회 PDF (단계 1) 라면, 빌드마다 자동 생성하는 단계 2 로 가는 2주 작업 이 가장 큰 ROI 다. 어떤 형태로든 SBOM 을 만들고 있는 보안 / DevOps 리드에게 다음 결정의 시작점은 지금 어느 단계에 있는가 하나다. 그 답이 나오면 위 단계별 비용 표가 나머지를 정해준다.