CVE

보안 분야나 개발 실무를 하다 보면 필수적으로 마주치는 CVE(Common Vulnerabilities and Exposures)

오픈소스의 보안 공지를 보다 보면 다음과 같은 형태의 이름을 자주 볼 수 있습니다.

• CVE-2026-0206
• CVE-2026-1213

처음 첩하는 사람에게는 암호처럼 보이지만 이 번호는 전 세계 보안 업계가 사용하는 공통 언어입니다. 운영체제, 웹 서버, 데이터베이스, WAS, 애플리케이션 등에서 발견되는 수많은 보안 취약점을 체계적으로 관리하기 위해 만들어진 것이 바로  CVE(Common Vulnerabilities and Exposures)입니다.

 

CVE란?

CVE는 Common Vulnerabilities and Exposures의 약자로 우리나라말로 일반적으로 '공통 취약점 및 노출 목록' 이라고 번역합니다. 쉽게 말해 발견된 보안 취역점에 고유한 식별 번호를 부여하는 국제 표준 체계입니다. 예를 들어 CVE-2021-44228 이라고 명시하면 전 세계 누구나 동일한 특정 취약점을 가리키게 됩니다.

 

탄생 배경

1990년대 후반 인터넷이 폭발적으로 보급되면서 전 세계 해커들이 시스템을 공격하기 시작했습니다. 하지만 당시 보안 업계는 그야말로 바벨탑 상태였습니다. 그때까지는 보안 취약점을 관리하는 공통 기준이 없었습니다. 동일한 취약점인데도 보안 업체, 운영체제 벤더, 보안 커뮤니티마다 제각각 다른 이름으로 불렀습니다. 

대표적인 실제 케이스가 바로 1998년 이메일 서버 프로그램인 Sendmail 의 보안 구멍 사건이었습니다. 당시 단 하나의 버그를 두고 보안 업계는 제각각 이름을 붙였습니다.

• 보안회사 A : Sendmail-MIME-Buffer-Overflow
• 보안회사 B : snl-sendmail-mime-bo
• 개발자 커뮤니터 : Sendmail MIME 엔트리 파싱 오류

실제 조사 결과 똑같은 취약점 하나를 두고 무려 24개의 서로 다른 이름이 난무하고 있었습니다.

상황이 이렇다 보니 인프라 관리자들은 "A라는 취약점이 위험하는다는 우리 시스템에 적용된 B 패치(또는 다른 패치)가 이걸 해결해 주나?" 를 확인하는 데만 매번 수많은 인력과 시간 낭비를 해야 했습니다. 더 심각한 것은 두 회사의 취약점 리스트를 비교했을 때 이름이 달라 서로 겹치는 문제가 무엇인지 구별하는 것조차 불가능했다는점이입니다

이 대혼란을 실시간으로 목격한 1999년 1월 미국의 비영리 연구기관인 MITRE Corporation의 보안 연구원인 David Mann 등이 중심이 되어 "취약점들을 하나로 묶을 공통의 명명 규칙이을 만들자"라고 제안하고 그해 9월 최초로 321개 취약점에 표준번호를 붙여 세상에 공개했는데 이것이 바로 최초의 CVE 리스트입니다. 현재는 전세계 보안 업계의 표준이 되었습니다.

 

CVE 번호 구성

CVE번호는 규정된 형식을 따르고 무조건 고유해야 합니다. 전세계를 뒤흔들었던 Log4Shell 취약점을 예시로 보겠습니다.

CVE - 2021- 44228
 │      │       │
 │      │       └─ 취약점 고유 번호 (그해 등록된 순서)
 │      └──────── 취약점이 발견 또는 등록된 연도 (Year)
 └────────────── CVE 표준 식별자 (Prefix)

 

과거에는 고유 번호가 4자리(0001~9999)로 제한되어 있었으나 소프트웨어의 폭발적인 증가로 취약점 신고가 늘어나 현재는 5자리 이상의 가변 길이를 사용하고 있습니다.

 

CVE 보안패치 관계

시스템 관리자와 개발자가 CVE를 필수적으로 알아야 하는 가장 큰 이유는 보안 패치 때문입니다.

예를 들어 보안 공지가 발표되면 대개 아래와 같은 형식으로 제공됩니다.

 

항목	내용
취약점 번호	CVE-2026-XXXX
영향 받는 버전	Tomcat 10.1.0 ~ 10.1.34
해결(패치 버전)	Tomcat 10.1.35 이상

 

 

CVE 보안 업데이트 권고

서버 운영자는 이 공지를 확인하여 [현재 버전 확인 → 영향 여부 판단 →  패치 계획 수립 →  업데이트 수행] 의 과정을 진행하게 됩니다. 즉 CVE 취약점 관리의 출발점인 셈입니다.

CVE의 위험도 판단(with CVSS)

CVE 번호는 취약점의 '식별번호' 일 뿐이지 그 자체로 위험도를 나타내지 않습니다.

예를들어 CVE-2021-44228 과 CVE-2025-2222라는 번호만 보고 어느 쪽이 더 위험하고 시급한지 알수 없습니다.

이때 취약점의 위험도를 정량적으로 평가하기 위해 사용하는 별도의 체계가 바로 CVSS입니다.

 

CVSS(Common Vulnerability Scoring System)란?

취약점의 심각도를 0점에서 10점 사이의 점수로 환산하여 등급을 매기는 시스템입니다.

점수 구간	등급(Severity)
0.1 ~ 3.9	Low(낮음)
4.0 ~ 6.9	Medium(중간)
7.0 ~ 8.9	High(높음)
9.0 ~ 10.0	Critical(치명적)

 

앞에 예시로 들었던 Log4Shell(CVE-2021-44228)의 경우 CVSS점수가 10.0(Critical)  이었습니다. 이는 원격에서 대가없이 코드를 실행할 수 있는 극도로 위험한 취약점임을 뜻하므로, 관리자는 모든 업무를 제쳐두고 이 패치부터 적용해야 한다는 판단을 내릴 수 있습니다.

 

공식 CVE 정보 조회

• NVE(National Vulnerability Database) : 미국 정부(NIST)가 운영하는 가장 공신력 있는 취약점 데이터 베이스입니다. CVSS점수와 상세 분석 정보가 함께 제공됩니다.
• CVE Program 공식 사이트 : 마이터(MITRE)가 운영하는 취약점 공식 등록사이트 입니다.
• KISA 보안공지 : KISA(한국인터넷진흥원)의 최신 보안공지와 취약점 업데이트 관련 정보가 제공되는 사이트입니다.  

 

실무자가 알아야 할 핵심

"취약점이 떴으면 바로 최신 버전으로 패치하면 되는거 아닌가?" 라고 생각하기 쉽습니다. 하지만 실제 운영 환경은 그리 간단하지 않습니다. 패치 한 번으로 인해 잘 돈던 서비스가 멈추거나 기존 소스 코드와 충돌이 날 수 있기 때문입니다. 따라서 

 

CVE / 보안공지 발표 → 사내 시스템 영향 버전 확인 → 시스템 아키텍처 영향 분석 → 테스트 서버에서 검증 및 사이드 이팩트 체크 → 운영 서버 반영 → 결과 확인

 

마치며
Linux, Tomcat, Jenkins, PostgreSQL 등의 인프라 시스템을 운영하거나 개발할 때 보게 되는 대부분의 보안 공지는 CVE 번호를 중심으로 돌아갑니다. CVE를 이해한다는 것은 단순히 취약점 번호 이름을 외우는 것이 아니라, 보안패치와 취약점 관리의 전체적인 흐름과 매커니즘을 이해하는 것입니다.