취약점 노이즈를 줄이는 5단계 방법

취약점 노이즈는 어디에서 오는가

백로그 하나를 가져와 각 발견 사항이 어디에서 왔는지로 정렬해 보세요. 아래 숫자는 벤치마크가 아닌 설명용이지만, 범주는 팀이 자사 백로그를 표본 조사할 때 실제로 발견하는 것들입니다.

발견 사항의 출처	1,000건 중(설명용)	이를 없애는 단계
출시하지 않는 구성 요소: 잠금 파일과 매니페스트 항목, 빌더 레이어, 개발 및 테스트 도구	300	1. 인벤토리 바로잡기
여러 도구가 보고하거나 리포지토리마다 한 번씩 보고되는 같은 CVE	250	2. 모든 발견 사항을 한 번만 세기
잘못된 매칭: CPE 이름 충돌, 배포판 백포트	80	1. 인벤토리 바로잡기
자사 제품에서는 악용될 수 없는 실제 발견 사항	150	4. 악용 가능성 맥락 더하기
아직 수정 버전이 없는 실제 발견 사항	70	5. 만료일을 정한 정책 결정
담당자가 없는 발견 사항	50	5. 담당자에게 전달
순위를 매기고 수정할 남은 것	100	우선순위 지정

한 가지 구분을 해 두면 이 페이지의 나머지가 쉬워집니다. 이 발견 사항 중 일부는 오탐입니다. 구성 요소가 없거나 해당 버전이 영향을 받지 않으므로 발견 사항 자체가 틀린 것입니다. 다른 일부는 노이즈입니다. 발견 사항은 맞지만 이번 주에 할 일을 바꾸지 않습니다. 둘은 해결책이 다르며, 이를 혼동하면 팀이 실제 발견 사항을 숨기거나 틀린 발견 사항을 두고 논쟁하게 됩니다.

오탐: 발견 사항이 틀림	노이즈: 맞지만 긴급하지 않음
구성 요소가 출시하는 것에 들어 있지 않음	취약한 코드가 자사 제품에서 도달되거나 실행될 수 없음
매칭이 틀림: CPE 충돌, 또는 버전 번호에 가려진 백포트 수정	아직 수정 버전이 없거나, 제품이 내부용이라 노출되지 않음
인벤토리와 매칭을 바로잡아 해결	맥락, 기록된 결정, 담당자로 해결

1단계. 인벤토리를 출시하는 것과 일치시키기

이후의 모든 단계가 인벤토리의 오류를 곱절로 키우기 때문에, 이것이 가장 큰 단일 수단입니다. 목록에는 있지만 출시되지 않는 구성 요소는 모든 스캐너, 모든 리포지토리, 모든 릴리스에서 발견 사항을 만듭니다.

빌드에서 기록하세요. 매니페스트나 완성된 아티팩트의 스캔이 아니라 릴리스 빌드가 실제로 사용한 것으로 인벤토리를 만드세요. 빌드 시점 SBOM에는 어떤 잠금 파일에도 나오지 않는 것을 포함해 작업이 가져온 것이 담깁니다.
PURL로 구성 요소를 식별하세요. pkg:npm/[email protected] 같은 패키지 URL은 생태계, 패키지, 버전을 정확히 지정합니다. OSV의 생태계 권고처럼 PURL을 키로 하는 권고와 매칭하면, 제품 이름으로 CPE를 추측해서 생기는 잘못된 매칭이 사라집니다.
OS 패키지에는 배포판을 인식하는 매칭을 사용하세요. Debian 등의 배포판은 업그레이드 대신 출시한 버전에 보안 수정을 백포트하므로, 버전 번호가 업스트림 수정보다 오래된 것처럼 보일 수 있습니다. 업스트림 버전 범위가 아니라 배포판 자체의 보안 트래커와 매칭하세요.
완전성을 추적하세요. 인벤토리가 완전하다고 가정하지 말고, 무언가를 볼 수 없었던 경우를 파악하세요. 누락된 구성 요소는 노이즈가 많은 구성 요소보다 나쁩니다. 아예 발견 사항을 만들지 않기 때문입니다.

실제 예시. 한 Node.js 서비스의 잠금 파일에는 테스트 및 빌드 도구가 의존하는 glob 매칭 라이브러리 [email protected]가 들어 있습니다. 잠금 파일 스캔은 4.0.8에서 수정된 정규 표현식 서비스 거부 취약점 CVE-2024-4067을 보고합니다. 릴리스 작업은 npm ci --omit=dev로 프로덕션 종속성만 설치하므로 micromatch는 출시되는 빌드에 들어가지 않습니다. 그 빌드의 기록에는 micromatch가 없고, 발견 사항은 백로그에 닿지 않습니다. CVE는 실재하지만, 이 제품에서 그 발견 사항은 오탐입니다.

2단계. 모든 발견 사항을 한 번만 세기

같은 CVE가 SCA 도구, 컨테이너 스캐너, SBOM 플랫폼에서 들어오고, 그 라이브러리를 쓰는 리포지토리마다 또 한 번씩 들어옵니다. 하나의 키로 중복을 제거하세요: 패키지 URL, 버전, CVE. 예를 들어 pkg:npm/[email protected]과 CVE-2024-45296은 몇 개의 도구가 보고하든 하나의 발견 사항입니다.

스캐너당 하나가 아니라 출시 아티팩트당 하나의 발견 사항으로 세세요.
빌드와 리포지토리 전반에서 집계하세요. 그러면 공유 라이브러리의 CVE는 티켓 40개가 아니라 모든 곳에 적용되는 하나의 결정이 됩니다.
겹치는 스캐너를 통합하세요. 간단한 규칙은 이렇습니다. 종속성 발견 사항은 하나의 SCA 또는 SBOM 출처에서, 이미지 발견 사항은 하나의 컨테이너 스캐너에서, 자사 코드의 발견 사항은 하나의 SAST 도구에서 받습니다. 두 도구가 같은 신호를 보고하면 출시되는 것에 더 가까운 쪽을 남기세요(SAST와 SCA 비교).

3단계. 덜 출시하기

출시하지 않는 종속성 하나하나는 처리할 필요가 없는 발견 사항의 출처입니다.

사용하지 않는 종속성을 제거하세요. 대부분의 프로젝트에는 더 이상 아무것도 가져오지 않는 패키지가 몇 개 있습니다.
취약한 패키지를 끌어오는 패키지를 업그레이드하세요. Express 4.19.2는 [email protected]와 [email protected]을 고정하며, 이들에는 CVE-2024-45590과 CVE-2024-45296이 있습니다. 오버라이드 없이는 이들만 따로 업데이트할 수 없습니다. 2024년 9월에 릴리스된 Express 4.20.0은 수정된 버전에 의존하므로, 업그레이드 한 번으로 둘 다 해결됩니다 (전이적 종속성).
최소 베이스 이미지를 사용하세요. slim 및 distroless 이미지는 운영 체제 패키지가 적어서 적용되는 권고도 적습니다. 이미지에 특화된 수단은 컨테이너 스캔에서 다룹니다.
의도적으로 고정하고 업데이트하세요. 잠금 파일과 다이제스트는 빌드 간 인벤토리를 안정적으로 유지합니다.
알려진 취약 버전이 포함된 빌드를 차단하세요. 빌드를 중단하는 정책 게이트는 취약한 라이브러리가 누군가 분류해야 하는 발견 사항이 되기 전에 막아 줍니다.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

4단계. 악용 가능성 맥락 더하기

1~3단계를 거치고 남은 것은 실재합니다. 그중 무엇이 긴급한지는 맥락이 결정합니다.

VEX. "영향 없음"을 근거와 함께 VEX 진술로 한 번 기록하고, 릴리스와 고객 전반에서 재사용하세요. 고객이 귀사 제품을 직접 스캔한 결과를 전달해 올 때도 같은 기록으로 답할 수 있습니다. PSIRT 확장하기와, 답변 템플릿은 공급망 공격 후 고객에게 답하는 방법을 참고하세요.
도달 가능성은 도구가 제공하는 경우, 자사 코드가 취약한 함수를 호출할 수 있는지 보여 줍니다. 한계 안에서 도움이 됩니다(도달 가능성 분석).
악용 신호. CISA KEV는 취약점이 실제 환경에서 악용되고 있음을 알려 주고, EPSS는 향후 30일 내에 악용될 가능성을 추정합니다.
노출. 인터넷에 노출된 제품은 사설 네트워크의 내부 도구보다 우선합니다.

5단계. 정책에 따라 발견 사항을 담당자에게 전달하기

임곗값을 정책으로 작성하세요. 심각도와 악용 가능성 임곗값을 한 사람이 적용한 대시보드 필터가 아니라 제품이나 리포지토리별 정책으로 정하세요.
담당자를 지정하세요. 리포지토리나 팀 단위로 지정해 모든 발견 사항에 결정할 사람이 있게 하세요.
"수정 버전 없음"을 명시적으로 결정하세요. 만료일을 정해 수용하거나, 완화하거나, 구성 요소를 교체합니다. 수정 버전이 없는 발견 사항이 아무 결정 없이 열려 있어서는 안 됩니다.

개발자가 발견 사항을 무시하는 이유는 네 가지입니다. 담당자가 없거나, 맥락이 없거나, 기한이 없거나, 채널이 잘못된 경우입니다. 저희가 이야기를 나눈 팀들은 결과가 너무 시끄러워 읽을 수 없어서 엔지니어링이 스캐너를 꺼 버린 경험을 말합니다. 각 이유를 해결하세요. 리포지토리별 담당자, 4단계의 맥락 첨부, 정책에 따른 기한, 그리고 팀이 이미 일하는 곳으로의 전달입니다.

노이즈 줄이기와 위험 숨기기의 차이

백로그가 작아진 것은 올바른 이유로 줄어들었을 때만 나아진 것입니다.

근거와 만료일이 없는 숨김 처리는 숨은 부채입니다. 감사나 사고 때 다시 돌아오며, 그때는 이유를 기억하는 사람이 아무도 없습니다.
심각도 하한선은 틀린 발견 사항을 없애는 것이 아니라 가립니다. "CVSS 7 미만은 제외"하면 CVSS 6의 오탐은 사라지지만 CVSS 9의 오탐은 그대로 남습니다.
수정하지 않기로 한 모든 결정에는 기록이 필요합니다. 고객이 요구하고, 제조업체가 제품의 지원 기간 내내 취약점을 처리하도록 요구하는 EU Cyber Resilience Act 같은 규제도 요구합니다.

측정하는 방법

출시 릴리스당 발견 사항(스캔당이 아님).
조치된 발견 사항의 비율: 수정, 완화 또는 결정됨.
VEX 기록과 함께 영향 없음으로 종료된 건과 기록 없이 숨겨진 건의 비교.
빌드부터 담당자까지의 시간: 새 발견 사항이 담당자가 정해질 때까지 기다리는 시간.
도구 간 중복률.

오후 한나절에 할 수 있는 50건 표본 조사. 열린 발견 사항 50건을 무작위로 고르세요. 각각에 대해 구성 요소가 릴리스에 포함되어 출시되는지, 다른 도구나 리포지토리가 같은 발견 사항을 보고하는지, 매칭이 맞는지, 자사 제품에서 악용 가능한지, 수정 버전이 있는지, 담당자가 누구인지 기록합니다. 그 수치가 어느 단계부터 시작할지 알려 줍니다. 한 분기 뒤에 같은 표본 조사를 다시 하세요. 이를 뒷받침하는 1차 출처가 없으므로, 저희는 이 수치에 대한 업계 벤치마크를 인용하지 않습니다.

CRACI의 역할

CRACI는 GitHub Actions에서 빌드하는 소프트웨어에 대해 1단계와 2단계, 3단계의 빌드 게이트, 그리고 4단계와 5단계의 일부를 담당합니다.

인벤토리. CRACI는 GitHub 호스팅 러너를 대체하고, 각 작업이 실제로 가져온 패키지를 구성 요소별 PURL과 SBOM별 완전성 상태와 함께 기록합니다. CRACI SBOM의 모든 구성 요소는 빌드에 실제로 있었던 것입니다. 이 정확성은 SBOM의 구성 요소에 관한 것이며, 매칭된 CVE가 자사 제품에 영향을 주지 않을 수는 있습니다. 이를 위한 것이 VEX이며, CRACI는 VEX를 지원합니다.
하나의 발견 사항, 여러 빌드. 발견 사항은 빌드와 리포지토리 전반에서 집계되며, 모니터링 중인 SBOM은 새 취약점이 공개될 때마다 지속적으로 재평가됩니다.
게이트. 정책 게이트는 특정 CVE가 포함된 빌드를 포함해 발견 사항에 따라 빌드를 실시간으로 중단할 수 있습니다.
분류와 배정. 보안 팀은 CRACI에서 발견 사항을 분류하고, 각 항목을 수정 담당 팀에 배정합니다.
알림. CRACI는 관련 담당자에게 취약점과 그 심각도를 알립니다.

CRACI는 도달 가능성 분석, SAST, MTTR 대시보드를 제공하지 않습니다. 전체 기능은 취약점 추적을 참조하거나, 빌드에 실제로 무엇이 들어 있는지 확인하세요.

CRACI가 답이 아닌 경우

노이즈 대부분이 자사 코드의 SAST 발견 사항인 경우. 이는 SAST 튜닝의 문제입니다.
백로그가 대부분 출시 코드의 실제로 악용 가능한 발견 사항인 경우. 이는 노이즈의 문제가 아니라 수정 역량의 문제입니다.
프로덕션 워크로드의 런타임 맥락이 필요한 경우. CNAPP나 런타임 보안 도구가 답합니다.

더 넓은 계획은 CVE 건수가 계속 늘어날 때 자동화할 것을, 실시간 수치는 CVE 공개 동향을 참조하세요.

취약점 노이즈 줄이기: 자주 묻는 질문

취약점 알림 수를 어떻게 줄일 수 있습니까?

원천에서 순서대로 줄이세요. 인벤토리를 출시하는 것과 일치시키고, 패키지 URL, 버전, CVE로 발견 사항의 중복을 제거하고, 종속성을 덜 출시하고, VEX, KEV, EPSS 같은 악용 가능성 맥락을 더하고, 남은 것을 문서화된 정책에 따라 담당자에게 전달하세요. 그다음 우선순위를 정합니다.

스캐너가 왜 수천 개의 취약점을 보고하며, 그중 어떤 것이 중요합니까?

대개 출시하지 않는 구성 요소를 보고하고, 같은 CVE를 도구와 리포지토리마다 한 번씩 보고하며, 일부 매칭을 잘못 추측하기 때문입니다. 중요한 것은 릴리스에 실제로 포함된 구성 요소에 있고, 자사 제품에서 악용 가능하며, 악용이 알려졌거나 악용될 가능성이 높은 것입니다.

여러 보안 도구의 발견 사항 중복을 어떻게 제거합니까?

모든 발견 사항을 패키지 URL, 버전, CVE를 키로 삼고, 출시 아티팩트당 하나의 발견 사항으로 세세요. 리포지토리 전반에서 집계해 공유 라이브러리가 하나의 결정이 되게 하세요. 그다음 신호의 종류마다 하나의 도구를 맡겨, 두 스캐너가 같은 것을 보고하지 않게 하세요.

수정 버전이 없는 취약점은 숨겨야 합니까?

조용히 숨겨서는 안 됩니다. 명시적으로 결정하세요. 문서화된 근거와 만료일을 정해 위험을 수용하거나, 완화하거나, 구성 요소를 교체합니다. 그리고 수정 버전이 나오면 다시 검토하세요. 근거와 만료일이 없는 숨김 처리는 숨은 부채입니다.

1년 동안 아무도 수정하지 않은 취약점은 여전히 노이즈입니까?

반드시 그렇지는 않습니다. 오래되었다는 것은 위험에 대해 아무것도 말해 주지 않습니다. 출시되고 악용 가능하다면 결정과 담당자가 필요합니다. 자사 제품에 영향이 없다면 VEX 진술로 기록해 다시 돌아오지 않게 하세요. 어느 쪽이든 결정 없이 열려 있어서는 안 됩니다.

개발자가 보안 발견 사항을 무시하지 않게 하려면 어떻게 해야 합니까?

모든 발견 사항에 담당자, 조치에 필요한 맥락, 문서화된 정책에 따른 기한을 부여하고, 팀이 이미 일하는 곳으로 전달하세요. 먼저 노이즈를 없애세요. 대부분의 발견 사항이 중요하지 않은 채널은 개발자가 읽지 않게 됩니다.

열린 취약점은 몇 개가 적당합니까?

신뢰할 만한 벤치마크는 없으며, 단순 건수는 잘못된 척도입니다. 출시 릴리스당 발견 사항, 조치된 비율, 기록된 근거와 함께 종료된 비율, 그리고 알려진 악용 취약점이 출시 소프트웨어에서 얼마나 오래 열려 있는지를 추적하세요.