취약점 우선순위 지정: 무엇부터 수정할지 정하는 법

심각도만으로는 부족한 이유

기본 방식은 CVSS로 정렬해 Critical부터 차례로 처리하는 것입니다. 객관적으로 느껴지지만 세 가지 이유로 실패합니다.

CVSS는 위험이 아니라 심각도를 측정합니다. 취약점이 악용되었을 때 얼마나 나쁠지를 나타낼 뿐, 누군가 실제로 악용하고 있는지, 자사 제품에 중요한지는 알려 주지 않습니다.
목록의 너무 많은 항목이 긴급합니다. 공개된 CVE 중 다수가 High 또는 Critical 점수를 받기 때문에, CVSS로 정렬한 대기열은 수백 개의 발견 사항을 맨 위에 올려놓고 그중에서 고를 방법을 주지 않습니다.
목록의 품질은 인벤토리의 품질을 넘지 못합니다. 잠금 파일을 읽는 스캐너는 출시되지 않는 개발 종속성을 보고하고, 빌드가 패키지 관리자 밖에서 다운로드한 패키지는 놓칩니다. 두 가지 모두 순위를 매기기도 전에 결과를 왜곡합니다.

우선순위 지정은 빠진 질문을 더합니다. 지금 악용되고 있는가, 악용될 가능성은 얼마나 되는가, 악용되면 자사에 어떤 일이 생기는가. 하지만 순위 지정은 눈앞의 목록을 정렬할 뿐이므로, 먼저 노이즈를 줄이세요. 출시하지 않는 구성 요소에 대한 발견 사항, 중복, 담당자가 없는 발견 사항이 그 대상입니다.

신호

신호	답하는 질문	출처
CVSS	악용되면 얼마나 심각한가? 0~10점.	FIRST(표준), NVD와 공급업체가 점수 공개
EPSS	향후 30일 내에 악용될 가능성은? 0~1 사이의 확률.	FIRST, 매일 업데이트, 무료
CISA KEV	이미 실제 환경에서 악용되고 있는가?	CISA의 Known Exploited Vulnerabilities 카탈로그
SSVC	악용 여부, 영향, 조직의 임무를 고려할 때 무엇을 해야 하는가: Track, Attend, Act?	CERT/CC와 CISA의 의사결정 트리
자사의 맥락	취약한 버전이 출시되는가? 노출되어 있는가? 제품이 얼마나 중요한가? 수정 버전이 있는가?	자사의 인벤토리, 아키텍처, 자산 기록

공개 신호는 취약점을 설명합니다. 자사의 위험을 설명하는 것은 자사의 맥락뿐이며, 대부분의 팀은 바로 이 부분을 가장 신뢰하기 어려운 출처에서 얻습니다.

실용적인 우선순위 지정 방법

대부분의 프로그램은 결국 다음과 같은 단계 구분을 어떤 형태로든 사용하게 됩니다. 기한은 자사 정책과 고객 요구에 맞게 정하세요.

즉시 수정: 출시하는 소프트웨어에 있는 이미 악용된 취약점. KEV 목록에 있거나 다른 악용 증거가 있으면서 릴리스된 빌드에 존재하는 모든 취약점입니다. 참고로 CISA의 BOD 26-04는 미국 연방 기관에 공개적으로 노출된 시스템의 KEV 항목에 대해 최단 3일의 기한을 부여합니다.
다음으로 수정: 악용 가능성이 높고 심각한 취약점. 출시되고 노출된 구성 요소에서 EPSS 점수가 높고 CVSS가 High 또는 Critical인 경우입니다. 팀이 실제로 처리할 수 있는 대기열이 되도록 EPSS 임곗값을 정하세요.
정기적으로 수정: 출시되는 나머지 모든 것. 각 발견 사항을 사고처럼 처리하지 말고 정기적인 종속성 업그레이드에 묶어 처리합니다.
문서화: 영향 없음. 취약한 패키지가 있지만 취약한 코드가 사용되지 않거나, 구성 요소가 출시되지 않는 경우입니다. 그 근거를 VEX 문서로 기록하면 같은 발견 사항이 다시 검토 대상으로 돌아오지 않고, 문의하는 고객도 그 이유를 확인할 수 있습니다.

그리고 순위를 지속적으로 다시 매기세요. 3단계에 있던 취약점도 KEV에 추가되거나 EPSS 점수가 급등하면 하룻밤 사이에 1단계로 올라갈 수 있습니다.

순위조차 매겨지지 않는 취약점

모든 우선순위 지정 방법은 눈앞에 있는 발견 사항의 순위를 매깁니다. 스캐너가 보지 못한 취약한 패키지는 발견 사항을 만들지 않으므로 CVSS 점수도, EPSS 점수도, KEV 일치도 얻지 못합니다. 낮은 순위가 매겨지는 것이 아니라 아예 순위가 매겨지지 않으며, 그래도 그대로 출시됩니다.

이런 일은 생각보다 자주 일어납니다. 대부분의 스캐너가 소프트웨어 구성을 파일, 즉 잠금 파일, 매니페스트, 빌드 산출물에서 추론하기 때문입니다. 빌드가 다운로드하지만 어떤 잠금 파일에도 없는 것은 숨겨진 종속성이며, 파일 기반 도구는 이를 놓칩니다.

설치 훅. npm preinstall 및 postinstall 스크립트가 다운로드하는 코드로, Shai-Hulud 웜이 사용한 경로입니다.
빌드 스크립트. 예를 들어 빌드 시점에 코드를 다운로드하는 Rust 빌드 스크립트입니다.
베이스 이미지. 컨테이너 빌드의 베이스 이미지와 그 운영 체제 레이어입니다.
캐시. 잠금 파일에서 설치하는 대신 CI 캐시에서 복원된 패키지입니다.

나중에 산출물을 스캔해도 이 공백은 메워지지 않습니다. 완성된 바이너리, 특히 Rust 같은 컴파일된 코드는 무엇이 들어갔는지 스캐너가 추측하게 만듭니다. 또한 빌드는 기본적으로 재현 가능하지 않으므로, 나중에 같은 커밋을 다시 빌드해도 같은 종속성이 사용된다는 보장이 없습니다.

빌드 시점 SBOM은 반대쪽에서 출발합니다. CRACI는 GitHub Actions 작업을 실행하고 각 빌드로 들어오는 트래픽을 보기 때문에, 숨겨진 종속성을 포함해 작업이 실제로 가져온 모든 패키지를 기록합니다. 각 SBOM에는 보이지 않은 부분이 있을 때 이를 알려 주는 완전성 상태가 포함됩니다. 실제로 CRACI는 Snyk와 Aikido가 구성 요소를 놓쳐 보고하지 못한 취약한 패키지를 발견한 바 있습니다. 바로 이런 발견 사항이 우선순위 지정 방법이 순위를 매길 기회조차 얻지 못하는 것들입니다.

맥락: 스캐너가 대신 점수를 매길 수 없는 부분

취약한 버전이 실제로 출시되는가?

가장 많은 노이즈를 걷어 내는 질문입니다. 잠금 파일 속 테스트 프레임워크, 릴리스되지 않는 브랜치에 고정된 패키지, 폐기되는 컨테이너 스테이지는 모두 고객에게 도달하지 않습니다. 빌드 중에 기록된 SBOM은 리포지토리가 선언한 내용이 아니라 릴리스 빌드가 실제로 사용한 것을 바탕으로 이 질문에 답합니다.

어떤 릴리스에, 언제부터 포함되어 있는가?

고객에게 출시하는 제품에 있고 지난봄 이후의 모든 릴리스가 영향을 받는 발견 사항은 내부 도구에 있는 같은 발견 사항보다 우선합니다. 노출 기간을 알면 무엇을 공개해야 하는지도 알 수 있습니다.

취약한 코드에 도달할 수 있는가?

도달 가능성 분석은 자사 코드가 종속성의 취약한 함수를 호출할 수 있는지 추적합니다. 여러 SCA 도구가 이를 제공하며, 도달할 수 없는 발견 사항을 목록 아래로 내리는 데 효과적입니다. 다만 하나의 입력으로만 취급하세요. 분석이 따라갈 수 있는 코드 경로만 볼 수 있으며, 도달 가능한 함수가 곧 악용 가능한 함수인 것은 아닙니다.

노출되어 있는가, 수정 버전이 있는가?

인터넷에 노출된 서비스는 사설 네트워크의 배치 작업보다 우선합니다. 수정 버전이 있는 취약점은 완화 조치가 필요한 취약점보다 해결 비용이 적습니다. 두 가지 모두 처리 여부가 아니라 처리 순서를 바꿉니다.

위험 기반 취약점 관리

위험 기반 취약점 관리는 같은 아이디어를 프로그램 수준에서 부르는 이름입니다. 악용 증거, 가능성, 심각도, 비즈니스 맥락으로 순위를 매기고, 가장 위험한 발견 사항이 얼마나 빨리 해결되는지 측정하며, 위험이 낮은 발견 사항은 열린 채로 남을 수 있음을 받아들입니다. 지표도 함께 바뀝니다. 열린 취약점의 총수 대신, 출시된 소프트웨어에서 이미 악용된 취약점이 몇 개 열려 있고 얼마나 오래 열려 있는지 추적합니다.

취약점 우선순위 지정 도구

현재 순위 매기기의 대부분은 세 종류의 도구가 담당합니다.

Tenable, Qualys, Rapid7 같은 인프라 취약점 관리 플랫폼은 악용 인텔리전스를 바탕으로 한 자체 위험 등급으로 호스트, 엔드포인트, 클라우드 자산에 점수를 매깁니다.
Snyk, Endor Labs, Semgrep 같은 SCA 및 애플리케이션 보안 도구는 종속성 발견 사항의 순위를 매기며, 그중 여러 도구가 도달 가능성 분석을 제공합니다.
발견 사항과 함께 EPSS 및 KEV 데이터를 보고하는 Grype, SBOM을 지속적으로 분석하는 Dependency-Track 같은 오픈 소스 도구가 있습니다.

취약점 관리 도구 비교에서 각 도구를 하나씩 살펴봅니다.

CRACI의 우선순위 지정 지원

CRACI는 순위 매기기가 가장 자주 잘못되는 지점인 인벤토리에서 시작합니다. GitHub Actions 작업을 실행하고, 전이적 종속성, 캐시에서 복원된 패키지, 어떤 잠금 파일에도 없는 숨겨진 종속성을 포함해 각 작업이 실제로 다운로드한 패키지를 기록합니다.

출시된 것에 대한 발견 사항. 모니터링 중인 SBOM은 지속적으로 재평가되며, 조직 뷰에서 빌드와 리포지토리 전반의 발견 사항을 집계합니다. 각 패키지에는 심각도가 포함된 보안 권고와 해당 패키지를 가져오는 패키지가 표시됩니다.
노출 기간. 빌드 기록은 과거의 어떤 빌드에 직접 또는 전이적인 취약한 종속성이 포함되었는지 보여 주므로, 어떤 릴리스가 얼마나 오래 영향을 받았는지 알 수 있습니다.
분류와 전달. 보안팀은 발견 사항을 분류해 각각을 수정을 담당하는 팀에 전달합니다. CRACI는 취약점이 제품에 영향을 주지 않는다는 사실을 기록하는 VEX를 지원합니다.
게이트. 정책 게이트는 특정 CVE가 포함된 빌드를 비롯해 발견 사항이 있는 빌드를 차단할 수 있습니다.

CRACI는 도달 가능성 분석을 제공하지 않습니다. 그것이 가장 필요한 신호라면 이를 제공하는 SCA 도구 중 하나를 선택하세요. 전체 기능은 취약점 추적을 참고하세요.

취약점 우선순위 지정: 자주 묻는 질문

취약점 우선순위 지정이란 무엇입니까?

취약점 우선순위 지정은 알려진 취약점 중 무엇을 먼저 수정하고, 무엇을 미룰 수 있으며, 무엇이 전혀 영향을 주지 않는지 결정하는 것입니다. 심각도만이 아니라 악용 가능성과 자사 환경에서 입을 피해 규모에 따라 발견 사항의 순위를 매깁니다.

취약점의 우선순위는 어떻게 정합니까?

실제로 출시되는 소프트웨어의 취약점에 순위를 매길 수 있도록 정확한 인벤토리에서 시작하세요. CISA의 Known Exploited Vulnerabilities 목록에 있는 항목을 맨 앞에 두고, 나머지는 악용 가능성(EPSS)과 심각도(CVSS)로 순위를 매긴 뒤 노출 정도, 제품의 중요도, 수정 버전 존재 여부 같은 자사 맥락에 맞게 조정합니다. 영향을 주지 않는 취약점은 VEX 문서로 기록합니다.

CVSS만으로 취약점 우선순위를 정할 수 있습니까?

아니요. CVSS는 취약점이 얼마나 심각한지를 측정할 뿐, 악용될 가능성이나 자사에 얼마나 중요한지는 측정하지 않습니다. CVSS만으로 순위를 매기면 백로그의 상당 부분이 High 또는 Critical로 표시되며, 그 대부분은 실제로 악용되지 않습니다.

위험 기반 취약점 관리란 무엇입니까?

위험 기반 취약점 관리는 CVSS 점수나 경과 기간 순으로 처리하는 대신, 악용 증거, 가능성, 심각도, 비즈니스 맥락을 종합해 조직에 미치는 위험에 따라 취약점의 순위를 매기고 수정하는 방식입니다.

EPSS와 KEV의 차이는 무엇입니까?

EPSS는 예측입니다. CVE가 향후 30일 내에 악용될 것으로 추정되는 확률입니다. KEV는 기록입니다. 실제 환경에서 악용된 증거가 있는 취약점을 담은 CISA의 카탈로그입니다. KEV 항목은 사실이고 EPSS 점수는 가능성입니다. KEV를 먼저 사용하고, 나머지의 순위는 EPSS로 매기세요.

도달 가능성 분석이 우선순위 지정을 대체합니까?

아니요, 입력이 하나 더 늘어나는 것입니다. 도달 가능성 분석은 자사 코드가 종속성의 취약한 함수를 호출할 수 있는지 확인합니다. 트리거될 수 없는 발견 사항을 제거하지만 악용 가능성에 대해서는 아무것도 알려 주지 않으며, 분석이 따라갈 수 있는 코드만 다룹니다.