"CVE-2021-44228"이나 "CVE-2017-5638" 같은 번호는 큰 침해 사고 기사마다 등장합니다. 이 번호가 무엇을 뜻하는지, 그리고 1인 개발자가 어떻게 현실적으로 따라잡을 수 있는지 살펴봅니다.
번호 읽는 법
CVE 식별자는 세 부분으로 이루어집니다. 번호 자체에는 심각도 의미가 전혀 없습니다(그건 별개입니다).
왜 필요한가
취약점은 끊임없이 발견됩니다. 공용 이름이 없으면 "네가 말하는 그 취약점"과 "내가 고친 취약점"이 같은 것이 아닐 수 있습니다. 공용 식별자가 있으면 뉴스, 패치, 스캐너, 데이터베이스가 모두 정확히 같은 취약점을 가리킬 수 있습니다. 그것이 모든 수정의 출발점입니다.
번호는 누가 부여하나
CVE는 미국 MITRE가 운영하고 미국 CISA가 자금을 지원하는 CVE 프로그램이 관리합니다. 번호 자체는 전 세계의 CNA(CVE Numbering Authority, 채번 기관)로 인정받은 조직이 부여합니다. 소프트웨어 벤더, 보안 연구 조직, 각국 CERT 등 모두 수백 곳이며, 일본에서는 JPCERT/CC가 그중 하나입니다.
CVE 레코드에는 상태가 있습니다. "Reserved(예약)"는 번호만 확보되고 세부 내용은 비공개인 상태, "Published(공개)"는 내용이 공개된 상태, "Rejected(거부)"는 중복이나 오류로 철회된 상태입니다. 뉴스에 번호만 나오고 세부 내용이 없다면 아직 예약 상태일 수 있습니다.
CVE vs NVD vs JVN
같은 CVE 번호라도 어디서 찾아보느냐에 따라 보이는 정보가 다릅니다.
| 이름 | 운영 | 담긴 내용 | 이럴 때 본다 |
|---|---|---|---|
| CVE (cve.org) | MITRE(CISA 지원) | 번호, 짧은 설명, 참고 링크 | 공식 번호와 개요 |
| NVD | 미국 NIST | CVE 데이터 + CVSS 점수와 영향 제품 | 점수와 어떤 제품이 해당하는지 |
| JVN | JPCERT/CC와 IPA | 일본 제품의 취약점, 일본어 설명과 대응 방법 | 일본어 상세 정보, 일본 제품 |
| KEV | 미국 CISA | 악용이 확인된 CVE와 대응 기한 | 우선순위 결정 |
CVE vs CVSS vs KEV: 각각이 알려 주는 것
이 셋은 함께 다니지만 서로 다른 질문에 답합니다. 우선순위를 정할 때 셋을 모두 씁니다.
| 용어 | 답하는 것 | 예 |
|---|---|---|
| CVE | 어떤 취약점인가(이름) | CVE-2021-44228(Log4Shell) |
| CVSS | 얼마나 심각한가(0–10) | 10.0(최악 등급) |
| KEV | 악용되고 있는가? | 악용 목록에 등재 → 최우선 |
높은 CVSS가 자동으로 최우선은 아니다
점수는 "최악의 이론값"입니다. 실무에서는 KEV(지금 악용되고 있는가)와 해당 기능을 실제로 쓰는가를 함께 따지세요. 쓰지 않는 10.0은 영향이 작고, 활발히 악용되는 중간 점수가 최우선입니다.
부여에서 수정까지
CVE는 발견 즉시 공개되는 것이 아니라 — 조정을 거칩니다.
발견·보고
예약
공개
악용(KEV)
사례: 뉴스에 자주 나오는 CVE
이 사이트에서 다룬 사고와 그 CVE 번호입니다. 번호를 외울 필요는 없습니다. 핵심은 번호로 검색하면 같은 취약점에 대한 정보가 여러 곳에서 한데 모인다는 점입니다.
| CVE 번호 | 통칭 / 제품 | 관련 사고 |
|---|---|---|
| CVE-2014-0160 | Heartbleed(OpenSSL) | Heartbleed: 서버 메모리가 유출 |
| CVE-2017-5638 | Apache Struts | Equifax: 패치 미적용으로 1억 4,700만 명의 정보 노출 |
| CVE-2018-13379 | VPN 장비 | 한다 병원(영문): 랜섬웨어 침입 경로로 보고됨 |
| CVE-2021-44228 | Log4Shell(Log4j) | Log4Shell: 아무도 몰랐던 간접 의존성으로 사용 중이었음 |
| CVE-2023-34362 | MOVEit Transfer | MOVEit: 피해가 2,700곳 이상의 조직으로 확산 |
| CVE-2024-3094 | XZ Utils | XZ Utils: 배포 파일에 백도어가 심어짐 |
번호가 공개되면 공격자도 같은 정보를 읽습니다. Equifax와 한다 병원 사고에서는 수정판이 나온 뒤 침입까지 시간이 있었습니다. 수정을 적용하기까지의 시간이 곧 공격받을 수 있는 시간입니다.
현실적으로 따라잡는 법
모든 CVE를 손으로 추적하기는 불가능하며, 그 누락이 곧 사고가 됩니다. → 수개월간 방치된 공개 CVSS 10.0
그러니 기계가 지켜보게 하세요.
흔한 실수
- 뉴스를 읽고 손으로 "아마 괜찮겠지" 판단
package.json텍스트만으로 위험 측정- 기한 없는 "언젠가 업데이트"
기계가 지켜보게
- Dependabot(GitHub): 의존성과 일치하는 CVE에 자동 PR
- osv-scanner(Google): CI에서 락파일을 한 단계로 점검
- 실제로 구동 중인 버전으로 판단(하한이 아니라)
핵심은 실제로 구동 중인 버전으로 판단하는 것입니다 — package.json의 하한은 실제로 구동 중인 버전과 다를 수 있습니다(이 오판이 어느 RCE 사고에도 일조했습니다).
내 환경에서 확인하는 방법
CVE 번호가 무엇에 관한 것인지 찾아본다
뉴스에서 본 번호를 CVE / KEV 조회에 입력하면 CVSS 점수, 악용 확률(EPSS), KEV 등재 여부를 한 번에 볼 수 있습니다.
내 의존성에 해당하는 CVE를 목록으로 뽑는다
lockfile(package-lock.json, pnpm-lock.yaml 등)을 의존성 취약점 스캐너에 넣으면 해당하는 CVE와 GHSA 목록이 나옵니다. npm 프로젝트라면 npm audit도 같은 일을 합니다.
서버와 장비는 제품명과 버전으로 대조한다
서버나 VPN 장비처럼 패키지 매니저 밖에 있는 제품은 벤더 권고를 보고 사용 중인 버전이 해당하는지 확인합니다. 해당한다면 업데이트 기한을 정하세요(→ CVE 대응 실무).
출처(1차 자료)
- CVE Program, "Process" — cve.org(CNA에 의한 부여와 CVE 레코드 상태)
- NIST, "National Vulnerability Database" — nvd.nist.gov
- JPCERT/CC·IPA, "JVN (Japan Vulnerability Notes)" — jvn.jp
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
다음으로 읽기
- 용어집: CVSS란(심각도 기준) · RCE란
- 방어: CVE 추적 루틴 만들기
- 실무: 어떤 CVE부터 고칠까(우선순위와 기한 정하기)