팀이 작을 때 늘어나는 CVE에 대응하는 방법

무엇이 바뀌었나: CVE 수치

아래 수치는 CVE Program 자체의 레코드에서 가져온 것으로, 매일 CVE 공개 동향 페이지에서 다시 계산합니다. 2026. 11. 12. UTC에 생성된 스냅샷 기준입니다.

• 2025년에 47,801건의 레코드가 공개되었으며, 전년보다 20% 많습니다.
• 2026년에는 지금까지 95,494건의 레코드가 공개되었습니다. 하루 303건으로, 2025년 일평균 대비 +131%입니다.
• 그중 하루 155건이 High 또는 Critical 등급입니다.
• 2020년 이후 전체 레코드의 17%는 할당 기관의 점수도, CISA 보강 데이터의 점수도 없는 CVSS 미평가 상태입니다. 점수 부여율은 개선되어 2026년에는 그 비율이 6%입니다.
• 505개 기관이 이 레코드를 할당했으며, 상위 20개 기관이 그중 75%를 차지합니다.

• High 또는 Critical
• 기타 심각도 및 미평가

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

각 연도에 공개된 레코드의 하루 평균이며, *는 올해 현재까지를 뜻합니다. 출처: CVE Program의 cvelistV5 레코드, 스냅샷 2026. 11. 12. UTC. 월별, 심각도별, 할당 기관별 필터: CVE 공개 동향.

이것은 일시적으로 나쁜 분기가 아닙니다. 건수는 2020년 이후 해마다 늘었고, 여러 구조적 변화가 계속 이를 끌어올리고 있습니다.

• 할당 기관이 늘고, 더 넓게 할당합니다. Linux 커널 프로젝트는 2024년 2월 CVE Numbering Authority가 되었습니다. 문서화된 정책에 따라, 수정이 안정 커널에 들어가면 취약점일 수 있는 모든 버그 수정에 CVE를 할당합니다. 수정이 반영되는 시점에는 악용 가능성이 분명하지 않은 경우가 많기 때문입니다. 커널 CNA 하나만 해도 그 후 18,221건의 레코드를 공개했습니다.
• AI 지원 발견. 2024년 11월 Google의 Project Zero와 DeepMind는 자사의 Big Sleep 에이전트가 SQLite에서 릴리스되기 전에 악용 가능한 메모리 안전성 버그를 찾았다고 발표했습니다. 이들은 AI 에이전트가 널리 쓰이는 소프트웨어에서 그런 일을 해낸 최초의 공개 사례라고 보고 있습니다. 이런 도구는 연구자 한 명이 찾을 수 있는 양을 늘립니다.
• NVD는 더 이상 모든 것을 보강할 수 없습니다. NIST에 따르면 National Vulnerability Database는 2024년 초부터 보강되지 않은 CVE가 쌓였고, 제출 건수가 계속 늘면서 이를 해소하지 못했습니다. 2026년 4월에는 위험 기반 모델로 전환했습니다. CISA의 Known Exploited Vulnerabilities 카탈로그에 있는 CVE와 연방 정부용 또는 핵심 소프트웨어의 CVE를 먼저 보강하고, 나머지는 즉시 보강 대상이 아닌 것으로 표시합니다. 한 데이터베이스의 영향받는 제품 데이터에 의존하는 프로세스는 이제 기다리거나 놓칩니다.
• 대응할 시간이 줄었습니다. Mandiant는 2018년과 2019년의 평균 악용 소요 시간을 63일로 측정했습니다. M-Trends 2026 보고서는 2025년 수치를 마이너스 7일로 추정합니다. 이제는 패치가 나오기 전에 악용이 시작되는 일이 흔합니다.
• 규제상의 기한. EU Cyber Resilience Act에 따라 제조업체는 실제로 악용되는 취약점에 대해 24시간 이내에 조기 경보를, 72시간 이내에 통지를, 수정이 제공된 후 14일 이내에 최종 보고서를 제출해야 합니다 (CRA가 요구하는 것). 이 기한은 3명인 팀에도 300명인 팀에도 똑같이 적용됩니다.

이 중 어느 것도 소프트웨어의 보안이 나빠지고 있다는 뜻은 아닙니다. 팀이 살펴봐야 할 대상은 해마다 늘지만, 팀은 그대로라는 뜻입니다.

소규모 팀의 프로세스에서 무너지는 것

늘어나는 건수가 취약점 관리를 무너뜨리는 이유는 수정할 취약점이 많아져서가 아닙니다. 모든 수작업 단계가 CVE마다 반복되기 때문입니다.

수작업 단계	현재 규모에서 실패하는 이유
인벤토리를 수작업으로 작성	스프레드시트나 감사 전에 만든 SBOM은 다음 릴리스 다음 날이면 이미 낡은 정보입니다.
피드 읽기	하루 155건의 High 또는 Critical 레코드를 따라잡을 수 있는 사람은 없습니다.
엔지니어링에 "X를 쓰나요?"라고 묻기	CVE마다 같은 질문을 같은 바쁜 사람들에게 합니다. 질문 자체가 병목입니다.
CVE 하나에 리포지토리마다 티켓 하나	공유 라이브러리의 CVE 하나가 수십 개의 중복 티켓이 되어 백로그를 뒤덮습니다.
고객마다 일일이 답변	문의는 취약점 수가 아니라 고객 수에 비례해 늘어납니다.
PDF나 위키에 담긴 문서	고객의 도구는 PDF를 자사 인벤토리와 매칭할 수 없으므로, 읽는 사람마다 다시 묻습니다.
움직이지 않는 기한	악용까지 걸리는 시간은 줄어드는데, 수작업 프로세스는 규모가 커질수록 느려집니다.

인벤토리. 구성 요소 목록을 수작업으로 관리하는 팀 대부분은 감사나 고객 설문 전에 목록을 업데이트합니다. 그 사이의 기간에는 더 이상 출시되지 않는 소프트웨어를 설명하고 있는 셈입니다. 그래서 모든 CVE 질문은 릴리스에 무엇이 들어 있었는지 다시 파악하는 일부터 시작됩니다.

피드. 권고를 읽는 것은 팀이 가장 먼저 시작하는 단계이자 가장 먼저 무너지는 단계입니다. 아직도 이를 수작업으로 하는 팀의 이야기를 듣습니다. 취약점 스캔이 곧 사람이 CVE 포럼을 읽는 일인 팀도 있습니다. 어느 날 갑자기 통하지 않게 될 때까지는 통하지만, 그날을 알려 주는 신호는 없습니다.

엔지니어링에 하는 질문. "이 라이브러리를 쓰나요, 어떤 버전인가요?"라는 질문은 해당될 수 있는 CVE마다 개발자의 작업을 끊습니다. 두 명으로 이뤄진 한 제품 보안 팀은 자신들의 일이 따라잡기 위해 버튼을 누르는 일일 뿐이고, 프로세스를 개선할 시간은 남지 않는다고 말했습니다.

티켓. 공유 라이브러리에 CVE가 생기고 리포지토리마다 각자 티켓을 열면, 백로그는 같은 결정을 여러 번 셉니다. 팀은 백로그를 무시하는 법을 배우고, 결국 정말 중요한 티켓을 놓칩니다.

고객 답변. 널리 보도된 취약점이나 공급망 공격이 있은 뒤 고객은 "우리도 영향을 받나요?"라고 묻습니다. 하나하나 따로 답하는 일은 시간이 가장 부족한 날에 가장 많은 시간을 잡아먹습니다.

문서. PDF 성명이나 위키 페이지는 고객 쪽의 사람이 읽어야 합니다. 고객의 스캐너와, 점점 더 많은 규제 기관이 SBOM, VEX, 권고를 기계가 매칭할 수 있는 형식으로 받기를 기대합니다.

기한. 24시간 이내에 제출해야 하는 조기 경보나 패치보다 먼저 나타나는 익스플로잇은 대기열이 비기를 기다려 주지 않습니다.

자동화할 것, 순서대로

각 단계는 다음 단계의 작업을 덜어 주므로, 도구 선택보다 순서가 더 중요합니다.

1. 무엇을 출시하는지 파악하세요. 모든 빌드의 SBOM이 "우리도 영향을 받나요?"를 조회 한 번으로 바꿉니다.
2. 여러 출처와 지속적으로 매칭하세요. 새 CVE를 저장된 모든 SBOM과 대조하므로 아무도 피드를 읽지 않아도 됩니다.
3. 노이즈를 줄이세요. 출시하지 않는 것에 대한 발견 사항과 중복은 사람에게 닿지 않습니다.
4. 반자동으로 분류하세요. 사실 정보는 채워지고, 결정은 사람이 내립니다.
5. 모든 것을 기계 판독 가능하게 만드세요. 각 결정은 한 번 내려지고 모든 독자가 재사용합니다.
6. 한 번, 공개적으로 답하세요. 오지 않는 문의에는 비용이 들지 않습니다.

1. 모든 빌드에서 SBOM을 자동으로 생성하기

대체하는 것: 스프레드시트, 그리고 엔지니어링에 하는 질문. 빌드 시점에 생성한 SBOM은 빌드가 실제로 사용한 것을 설명하며, 출시한 버전마다 하나씩 보관하면 main뿐 아니라 작년 릴리스에 대해서도 답할 수 있습니다. 고객은 오래된 버전을 실행하므로 인벤토리도 그 버전들을 포함해야 합니다.

최소 버전: 모든 릴리스 빌드에서 CI로 생성하고 릴리스 아티팩트 옆에 저장하는 SBOM. 더 나은 방법: 나중에 잠금 파일에서 추론하는 대신 빌드 자체에서 기록한 SBOM. 그래야 패키지 관리자 밖에서 가져온 구성 요소도 포함됩니다(빌드 시점 SBOM, SBOM 자동화).

비용: 최소 버전은 파이프라인 작업 하루나 이틀, 그 뒤로는 릴리스마다 추가 비용이 없습니다. 제대로 작동한다는 신호: 어떤 릴리스든 누구에게도 묻지 않고 구성 요소를 나열할 수 있습니다.

2. 여러 취약점 출처와 지속적으로 매칭하기

대체하는 것: 피드 읽기. 매칭은 기계가 할 일입니다. 방금 실행된 빌드의 SBOM만이 아니라, 저장된 모든 SBOM을 새 CVE 하나하나와 대조합니다. 출시 당시에는 문제가 없던 오래된 릴리스도 그 구성 요소에 대한 CVE가 공개되는 날 영향을 받게 됩니다.

출처 하나로는 부족합니다. NVD의 보강 적체 때문에 영향받는 제품 데이터가 늦게 오거나 아예 오지 않을 수 있습니다. GitHub Advisory Database와 OSV 같은 생태계 권고는 대개 더 빠르고, 영향받는 패키지 버전을 해당 생태계의 용어로 알려 줍니다. ENISA의 EU Vulnerability Database는 EU 관점의 맥락을 더합니다.

최소 버전: 저장된 모든 SBOM을 매일 통합 출처와 다시 스캔하고 새 매칭을 보고하는 예약 작업. 제대로 작동한다는 신호: 고객이 알려 주기 전에 릴리스가 영향을 받는다는 사실을 알게 됩니다. CRACI에서 이것이 어떻게 보이는지는 취약점 추적을 참조하세요.

3. 누군가 보기 전에 노이즈 줄이기

대체하는 것: 중요하지 않은 발견 사항의 수작업 검토. 노이즈 대부분은 상류에서 만들어집니다. 출시하지 않는 것을 나열하는 인벤토리, 같은 CVE를 보고하는 여러 도구, 아무도 필요로 하지 않는 종속성 때문입니다. 인벤토리를 바로잡고, 각 발견 사항을 패키지 URL(PURL), 버전, CVE 기준으로 한 번만 세고, 출시하는 종속성을 줄인 다음, CISA KEV, EPSS, VEX로 악용 가능성 맥락을 더하세요. 취약점 노이즈를 줄이는 방법에서 이 수단들을 하나씩 다룹니다. 제대로 작동한다는 신호: 출시 릴리스당 발견 사항이 줄고, 그 이유가 기록으로 남습니다.

4. 반자동으로 분류하기

대체하는 것: 발견 사항마다 사람이 사실 정보를 모으는 일. 작업을 정확하게 나누세요.

• 자동: 심각도, 악용이 알려져 있는지 여부, 구성 요소가 들어 있는 제품과 버전, 담당 팀, 제안 우선순위와 기한.
• 사람: 결정. 수정, 완화, 만료일을 정한 수용, 또는 근거를 붙인 영향 없음 처리.

자동화해서는 안 되는 것: 기록된 근거 없이 발견 사항을 영향 없음으로 종료하는 일. 그것은 은폐이며 감사나 사고 때 다시 돌아옵니다. 순위 규칙은 취약점 우선순위 지정에서 다룹니다.

최소 버전: 이미 정렬되고 정보가 채워진 대기열을 하루 15분 검토. 제대로 작동한다는 신호: 모든 결정에 기록된 근거가 있고, 누군가 무언가를 찾아볼 때까지 기다리는 항목이 없습니다.

5. 모든 것을 기계 판독 가능하게 만들기

대체하는 것: 사람이 읽어야 하는 PDF, 위키 페이지, 이메일. SBOM은 CycloneDX 또는 SPDX로 (CycloneDX와 SPDX 비교), 영향 없음 결정은 VEX로, 권고는 CSAF로 게시하세요. 그러면 고객의 스캐너와 규제 기관이 사람 없이 이를 활용할 수 있으므로, 각 결정은 한 번 내려지고 묻는 모든 사람이 재사용합니다.

소규모 팀의 최소 버전: 고정된 위치에서 요청 시 제공하는 SBOM과 VEX, 고객이 요청하기 시작하면 CSAF. 제대로 작동한다는 신호: 이미 답한 내용을 고객의 도구가 더 이상 경고하지 않습니다.

6. 한 번, 공개적으로 답하기

대체하는 것: 고객마다 하나씩 이어지는 이메일 스레드. 중요한 CVE마다 영향받는 버전과 수정된 버전을 담은 권고나 상태 페이지를 게시하고, 그 링크를 담은 답변 템플릿을 준비해 두세요. "이 CVE의 영향을 받나요?"에 답하는 가이드에서 답을 찾는 방법을 설명합니다. 답변 자체의 템플릿은 공급망 공격 후 고객에게 답하는 방법에 있습니다. 가장 저렴한 문의는 아예 오지 않는 문의입니다. 제대로 작동한다는 신호: 대부분의 문의에 링크 하나로 답합니다.

그다음 수정

자동 종속성 업데이트 풀 리퀘스트가 일상적인 작업을 계속 진행시킵니다. 검토 부담이 감당할 만하도록 주 단위나 릴리스 단위로 묶으세요. 상위 패키지 하나를 업그레이드하면 취약한 전이적 종속성 여러 개가 한 번에 해결되는 경우가 많고, 하나씩 패치하는 것보다 저렴합니다 (자동화된 취약점 수정). 그런 다음 빌드를 차단하는 정책 게이트로 알려진 문제 구성 요소가 다시 들어오지 못하게 막으세요.

팀 규모별 계획

시간은 계획을 위한 설명용 추정치이며 벤치마크가 아닙니다.

	파트타임 담당자 1명	2~5명 규모의 보안 또는 PSIRT 조직	더 큰 팀
먼저 자동화할 것	1단계와 2단계: 빌드별 SBOM과 지속적인 매칭	1~3단계, 그다음 4단계의 담당자 지정	여섯 단계 모두, 모든 파이프라인에 정책 게이트 적용
수작업으로 남는 것	High 또는 Critical 발견 사항 각각에 대한 결정, 템플릿을 활용한 고객 답변	결정, VEX 근거, 중요한 CVE에 대한 권고	결정, 예외, 그리고 프로세스 자체
주간 소요 시간(설명용)	2~4시간	1인당 4~8시간	피드가 아니라 결정의 양에 따라 정해짐

이미 PSIRT를 운영하고 있다면 같은 순서가 적용됩니다. 전체 프로세스 모델은 취약점 관리 라이프사이클에서 볼 수 있습니다. CVE마다 늘어나는 고객 문의는 PSIRT 확장하기에서 다룹니다.

제대로 작동하는지 아는 방법

• 제품별로 CVE 공개부터 "영향 있음" 또는 "영향 없음" 판단까지 걸리는 시간.
• 공개된 자료로 답한 고객 문의의 비율.
• 스캔당이 아닌 출시 릴리스당 발견 사항.
• 기록된 근거가 있는 결정의 비율.
• 취약점 작업에 쓰는 주간 시간과 그 감소 여부.

먼저 자사의 기준선을 측정하세요. 이 지표에 대한 신뢰할 만한 업계 벤치마크는 없으며, 저희도 인용하지 않습니다.

채용할 것인가, 도구를 살 것인가, 프로세스를 바꿀 것인가?

• 채용은 자사 코드의 취약점을 수정하는 일이거나, 판단이 필요한 고객 대상 보안 업무일 때 하세요.
• 도구 구매는 CVE마다 반복되는 단계, 즉 1, 2, 3, 5단계를 위한 것입니다.
• 프로세스 변경은 소유권과 기한, 즉 누가 언제까지 결정하는지에 관한 것입니다.

마지막 항목에 대해서는 솔직해야 합니다. 담당자 없는 도구는 아무도 보지 않는 대시보드를 만들 뿐입니다.

CRACI의 역할

CRACI는 GitHub Actions에서 빌드하는 소프트웨어에 대해 1단계와 2단계, 그리고 3단계와 4단계의 일부를 자동화합니다. GitHub 호스팅 러너를 대체하며, 각 작업이 실행될 때 CI 캐시에서 복원된 패키지와 어떤 잠금 파일에도 나오지 않는 숨은 종속성을 포함해 작업이 실제로 가져온 패키지를 기록합니다.

• 모든 빌드의 SBOM. 각 작업의 SBOM은 모든 구성 요소를 PURL로 식별하고 완전성 상태를 담으므로, 무언가를 볼 수 없었던 경우를 알 수 있습니다. 빌드 이력은 과거의 모든 빌드를 SBOM과 함께 보관하므로, 어떤 빌드에 직접 또는 전이적인 취약한 종속성이 들어 있었는지 확인할 수 있습니다.
• 지속적인 매칭. 모니터링 중인 SBOM은 지속적으로 재평가되고, 발견 사항은 빌드와 리포지토리 전반에서 집계됩니다. 그래서 공유 라이브러리의 CVE는 40개가 아니라 하나의 문제로 나타납니다.
• 알림과 게이트. CRACI는 관련 담당자에게 취약점과 그 심각도를 알리며, 정책 게이트는 특정 CVE가 포함된 빌드를 포함해 빌드를 실시간으로 중단할 수 있습니다.
• 분류와 배정. 보안 팀은 CRACI에서 발견 사항을 분류하고, 각 항목을 수정 담당 팀에 배정합니다.
• 기계 판독 가능한 SBOM. SBOM은 CycloneDX 또는 SPDX로 내보낼 수 있으며, CRACI는 VEX를 지원합니다.

CRACI는 권고를 게시하지 않고, 도달 가능성 분석을 제공하지 않으며, 자사 코드를 스캔하지 않습니다. 요금은 빌드 시간에만 부과됩니다. vCPU-분당 $0.002(기본 2 vCPU 러너는 $0.004)이며 초 단위로 계량하고, 월 요금, SBOM당 요금, 라이선스 요금은 현재 없습니다. 요금을 확인하세요.

처음 두 단계를 오늘 자동화하세요: CRACI에서 빌드를 실행해 보세요. 정식 출시 전까지 모든 팀의 온보딩을 저희가 직접 돕고 있습니다.

CRACI가 답이 아닌 경우

• 소프트웨어를 GitHub Actions에서 빌드하지 않는 경우. GitLab CI와 Jenkins는 로드맵에 있습니다.
• 노출이 주로 서버, 엔드포인트, 클라우드 구성 같은 인프라에 있는 경우. 인프라 취약점 관리 도구가 더 적합합니다.
• 직접 빌드하지 않는 서드파티 펌웨어를 통합하는 경우. 바이너리 분석 도구가 더 적합합니다.
• 백로그가 대부분 자사 코드의 실제로 악용 가능한 발견 사항인 경우. 이는 자동화의 문제가 아니라 수정 역량의 문제입니다.

취약점 관리 자동화: 자주 묻는 질문

왜 지금 CVE가 이렇게 많이 늘었습니까?

CVE를 할당하는 기관이 늘었고, 일부는 넓게 할당합니다. Linux 커널은 2024년 CVE Numbering Authority가 되어 취약점일 수 있는 모든 버그 수정에 CVE를 할당합니다. AI 지원 도구는 연구자 한 명당 더 많은 버그를 찾습니다. 2025년에 47,801건의 레코드가 공개되었고, 2026년에는 하루 303건 속도입니다. 이 추세는 수년째 이어지고 있습니다.

소규모 팀이 새 CVE를 어떻게 따라잡을 수 있습니까?

읽지 않는 것으로 따라잡습니다. 모든 빌드에서 SBOM을 생성하고, 새 CVE를 저장된 모든 SBOM과 자동으로 매칭하고, 노이즈를 줄인 다음, 남은 것에 대해서만 사람이 결정하게 하세요. 소규모 팀은 더 빨리 일해서가 아니라 CVE마다 반복되는 단계를 없애서 따라잡습니다.

취약점 관리에서 무엇을 먼저 자동화해야 합니까?

인벤토리입니다. 모든 릴리스 빌드에서 CI로 SBOM을 생성해 릴리스와 함께 저장하세요. 이후의 모든 단계가 여기에 의존하며, "우리도 영향을 받나요?"를 엔지니어링에 묻는 질문에서 조회 한 번으로 바꿉니다. 그 SBOM과의 지속적인 매칭이 두 번째입니다.

취약점을 처리하려면 보안 팀이 필요합니까?

처음에는 필요 없습니다. 인벤토리, 매칭, 노이즈 줄이기가 자동화되어 있다면 프로세스를 맡은 한 사람이 파트타임으로 운영할 수 있습니다. 팀보다 지정된 담당자와 기한이 더 필요합니다. 업무가 자사 코드 수정이나 고객 대상 보안 업무가 되면 채용하세요.

어떤 새 CVE가 우리 제품에 영향을 주는지 어떻게 알 수 있습니까?

출시한 모든 버전의 SBOM을 보관하고, 새 CVE가 공개될 때마다 둘 이상의 취약점 출처를 기준으로 모두 다시 확인하세요. CVE가 실제로 출시하는 구성 요소와 버전에 매칭되면 영향을 받는 것입니다. 그다음 악용 가능성 맥락과 VEX가 그것이 중요한지를 알려 줍니다.

SBOM, VEX, 권고에서 "기계 판독 가능"이란 무슨 뜻이며, 왜 중요합니까?

도구가 파싱할 수 있는 표준 구조화 형식을 뜻합니다. SBOM은 CycloneDX 또는 SPDX, 영향 없음 진술은 VEX, 권고는 CSAF입니다. 고객의 스캐너가 누구도 읽지 않고 이를 자사 인벤토리와 매칭할 수 있으므로, 한 번 내린 결정을 모든 고객과 도구가 재사용합니다.

분류 작업은 어디까지 안전하게 자동화할 수 있습니까?

사실 정보 수집까지입니다. 심각도, 악용 상태, 구성 요소가 들어 있는 제품과 버전, 담당자, 제안 우선순위와 기한이 그것입니다. 결정 자체는 사람에게 맡겨야 합니다. 기록된 근거 없이 발견 사항을 자동으로 영향 없음으로 종료해서는 절대 안 됩니다.

치명적인 CVE에 대응할 시간은 얼마나 됩니까?

대부분의 프로세스가 가정하는 것보다 짧습니다. Mandiant의 M-Trends 2026은 2025년의 평균 악용 소요 시간을 마이너스 7일로 추정합니다. 패치가 나오기 전에 악용된다는 뜻입니다. EU Cyber Resilience Act에서는 실제로 악용되는 취약점에 대해 24시간 이내에 조기 경보가 필요합니다. 심각도와 악용 여부에 따라 자체 기한을 정하고, 그 기준으로 측정하세요.