— 스캔만으로는 부족하다. SBOM 기반 대응 체계가 필요한 이유
(Z-BOM MVP: 12월 공개 예정)
React2Shell 취약점은 Next.js 기반 서비스에서 원격 코드 실행(RCE)이 가능한 심각한 이슈로 평가되며 많은 조직을 긴급 대응 모드로 밀어 넣었습니다.
하지만 대부분의 보안팀이 마주한 가장 근본적인 질문은 동일합니다.
“지금의 임시 대응이 아니라, 반복되는 취약점에 대비할 근본적인 체계가 필요한 건 아닐까?”
이번 사건은 단순 취약점 이슈를 넘어서 SBOM 기반 대응 체계를 갖춰야 하는 이유를 명확하게 보여준 사례입니다.
1. 스캔은 “당장 패치해야 할 곳”만 알려준다
스캐너(Exploit Scan)는 취약 버전 존재 여부와 실제 공격 가능성을 빠르게 확인해줍니다.
그러나 스캔 결과만으로는 조직 전체 대응 범위를 판단할 수 없습니다. 그 이유는 기술적 한계보다 조직 운영 구조에 있습니다.
스캐너만으로 대응할 경우 반복되는 문제들
CVE가 터질 때마다 전사 서비스 전수조사 반복
SBOM이 관리되지 않아 어디까지 업데이트했는지 기록 없음
개발팀·보안팀 모두 조사 비용 증가
대응 시간이 길어져 조직이 불필요하게 위험에 노출됨
즉, 스캐너만으로는 “단기 해결”은 가능하지만, “조직적 보안 체계”를 만드는 데에는 한계가 있습니다.
2. 대응 범위를 넓히는 핵심: SBOM 구축
SBOM(Software Bill of Materials)은 조직의 전체 서비스·제품이 어떤 라이브러리/패키지/버전으로 구성되어 있는지 지속적으로 추적·관리하는 전사 인벤토리입니다.
제품/서비스는 다음 변화들을 매주 겪습니다.
신규 기능 릴리즈
버그 패치
의존성 업데이트
레거시 코드 남아 있음
즉, SBOM은 계속 변합니다.
SBOM이 없으면 CVE 발표 때마다 이렇게 됩니다:
“전체 저장소 다시 조사하세요.”
“내부 서비스까지 다 뒤져서 영향 범위 확인해주세요.”
이 모든 비용과 시간을 없애는 것이 SBOM입니다.
SBOM이 있으면 즉시 답할 수 있는 질문
취약 라이브러리가 어디에 쓰였는가?
취약 버전은 몇 개 서비스에 있는가?
내부망·테스트·레거시까지 포함해 전사적으로 몇 개가 영향받는가?
패치 우선순위는 어떻게 되는가?
SBOM은 전사 위험 범위를 한 번에 보여줄 수 있습니다.
3. 단순 버전 탐지로는 부족하다: VEX 분석
같은 취약 버전이라도 실제 공격 가능성은 구성·네트워크·코드 경로에 따라 달라집니다.
취약 코드가 실제 호출되지 않음
인증/권한 우회 경로가 없음
특정 옵션 조합에서만 취약하지만 해당 옵션이 미사용
외부 입력이 차단되어 Attack Surface 부재
이 차이를 구분하는 체계가 VEX입니다.
VEX 상태 정의
VEX의 기업적 가치
개발 리소스 낭비 방지
불필요한 패치로 인한 장애 예방
긴급 패치 우선순위 명확화
감사/컴플라이언스 대응 자동화
4. Z-BOM: SBOM 기반 대응 체계를 실제로 구현하는 도구
Z-BOM은 SBOM + VEX + Workflow를 통합해 기업이 방금 설명한 대응 체계를 실제로 운영할 수 있도록 만든 제품입니다.
Z-BOM 주요 기능은 다음과 같습니다.
SBOM 자동 생성 & 표준(SPDX/CycloneDX) 지원
AI 기반 취약점 매핑 및 위험 평가
VEX 분석 자동화
SBOM 워크플로우 자동화(조직 전체 대응)
앞으로도 React2Shell 같은 프레임워크 취약점은 반복적으로 발생합니다. 대응 속도는 SBOM 체계를 갖춘 조직과 그렇지 않은 조직을 명확히 갈라놓을 것입니다.
