"CVE-2021-44228", "CVE-2017-5638" — 큰 침해 사고마다 헤드라인을 장식하는 그 번호들입니다. 이것이 실제로 무엇인지, 그리고 1인 개발자가 어떻게 현실적으로 따라잡을 수 있는지 살펴봅니다.
번호 읽는 법
CVE 식별자는 세 부분으로 이루어집니다. 번호 자체에는 심각도 의미가 전혀 없습니다(그건 별개입니다).
왜 필요한가
취약점은 끊임없이 발견됩니다. 공용 이름이 없으면 "네가 말하는 그 구멍"과 "내가 고친 이 구멍"이 같은 것이 아닐 수 있습니다. 공용 식별자가 있으면 뉴스, 패치, 스캐너, 데이터베이스가 모두 정확히 같은 취약점을 가리킬 수 있습니다. 그것이 모든 수정의 출발점입니다.
CVE vs CVSS vs KEV — 혼동하지 마라
이 셋은 함께 다니지만 서로 다른 질문에 답합니다. 우선순위를 정할 때 셋을 모두 씁니다.
| 용어 | 답하는 것 | 예 |
|---|---|---|
| CVE | 어떤 취약점인가(이름) | CVE-2021-44228(Log4Shell) |
| CVSS | 얼마나 심각한가(0–10) | 10.0(최악 등급) |
| KEV | 악용되고 있는가? | 악용 목록에 등재 → 최우선 |
높은 CVSS가 자동으로 최우선은 아니다
점수는 "최악의 이론값"입니다. 실무에서는 KEV(지금 악용되고 있는가)와 해당 기능을 실제로 쓰는가를 함께 따지세요. 쓰지 않는 10.0은 영향이 작고, 활발히 악용되는 중간 점수가 최우선입니다.
부여에서 수정까지
CVE는 발견 즉시 공개되는 것이 아니라 — 조정을 거칩니다.
발견·보고
예약
공개
악용(KEV)
현실적으로 따라잡는 법
모든 CVE를 손으로 추적하기는 불가능하며, 그 누락이 곧 사고가 됩니다. → 수개월간 방치된 공개 CVSS 10.0
그러니 기계가 지켜보게 하세요.
흔한 실수
- 뉴스를 읽고 손으로 "아마 괜찮겠지" 판단
package.json텍스트만으로 위험 측정- 기한 없는 "언젠가 업데이트"
기계가 지켜보게
- Dependabot(GitHub): 의존성과 일치하는 CVE에 자동 PR
- osv-scanner(Google): CI에서 락파일을 한 단계로 점검
- 실제로 구동 중인 버전으로 판단(하한이 아니라)
핵심은 실제로 구동 중인 버전으로 판단하는 것입니다 — package.json의 하한은 거짓말을 합니다(이 오판이 어느 RCE 사고에도 일조했습니다).
다음으로 읽기
- 용어집: CVSS란(심각도 기준) · RCE란
- 방어: CVE 추적 루틴 만들기
FAQ
QCVE 번호는 어떻게 읽나요?
'CVE-연도-일련번호' 형식입니다. 예를 들어 CVE-2025-12345는 2025년에 부여된 것입니다. 번호 자체에는 심각도 의미가 없으며 — 심각도는 CVSS로 따로 표현됩니다. 일련번호는 네 자리로 고정된 것이 아니라 필요에 따라 늘어납니다.
QCVE, CVSS, KEV의 차이는 무엇인가요?
CVE는 이름(어떤 취약점인가), CVSS는 0–10의 심각도 점수(얼마나 나쁜가), KEV는 실제 야생에서 악용이 관측된 취약점 목록입니다. 우선순위를 정할 때는 높은 CVSS만큼이나 KEV(지금 공격받고 있는가)를 무겁게 두세요.
Q1인 개발자가 모든 CVE를 추적하는 건 불가능하지 않나요?
손으로는 불가능하며 — 그 누락이 곧 사고가 됩니다. 그러니 기계가 지켜보게 하세요: Dependabot(GitHub)이나 osv-scanner가 당신의 의존성과 일치하는 CVE를 자동으로 알려줍니다.