CVSS (공통 취약점 점수체계)

1. 개요

정의: CVSS(Common Vulnerability Scoring System)는 국제 침해사고대응 포럼인 FIRST(Forum of Incident Response and Security Teams)가 관리하는 공개·표준화된 취약점 심각도 평가 체계로, 소프트웨어 취약점의 기술적 특성을 정해진 메트릭으로 측정해 0.0~10.0의 정량 점수와 등급(None·Low·Medium·High·Critical)으로 환산함으로써, 서로 다른 조직·제품·국가가 동일한 척도로 취약점의 상대적 위험도를 비교·소통할 수 있게 하는 개방형 프레임워크다.

CVSS가 등장한 배경은 취약점 정보의 공통 언어 부재에 있다. 2000년대 초 취약점 공개가 급증하면서 각 벤더가 '긴급', '중요', '보통' 같은 자체 등급을 제각기 붙였고, 동일한 결함을 두고 공급자마다 심각도 판단이 달라 수요자(보안 담당자·관리자)가 패치 우선순위를 합리적으로 정하기 어려웠다. 이 혼란을 해소하고자 미국 NIAC의 제안으로 2005년 CVSS v1이 공개되었고, FIRST가 운영을 이어받아 v2(2007), v3.0(2015), v3.1(2019)을 거쳐 2023년 11월 v4.0이 발표되었다.

두 번째 배경은 취약점 관리가 위험 기반(risk-based)으로 전환되고 있다는 현실이다. 매년 공개되는 CVE(공통 취약점 식별자)는 수만 건에 이르며, 조직의 패치 역량으로는 모두를 동시에 대응할 수 없다. 따라서 '무엇을 먼저 고칠 것인가'를 결정하는 객관적·반복가능한 기준이 필요했고, CVSS는 그 출발점으로서 취약점 심각도를 수치화해 우선순위 산정의 1차 근거를 제공한다.

세 번째 배경은 규제·표준과의 연계다. 미국 NVD(National Vulnerability Database)가 모든 CVE에 CVSS 점수를 부여하고, PCI-DSS 같은 산업 규제가 "CVSS 4.0 이상 취약점 조치"를 요구하면서 CVSS는 사실상 전 세계 취약점 관리의 공용 척도로 자리잡았다. 국내에서도 보안 솔루션·취약점 점검 보고서가 CVSS를 기본 지표로 채택하고 있어, 기술사 관점에서 반드시 숙지해야 하는 표준이다.

2. CVSS 구조 — 메트릭 그룹과 점수 산정

CVSS의 핵심은 취약점의 특성을 성격이 다른 메트릭 그룹으로 나누어 평가한다는 점이다. 그룹을 분리하는 이유는, 취약점의 '본질적 성질'과 '시간에 따라 변하는 성질', '우리 조직에서만 유효한 성질'을 섞어 버리면 점수의 의미가 흐려지기 때문이다. 아래 개념도는 CVSS(v3.1·v4.0 공통 골격)의 전체 메트릭 구조를 보여 준다.

flowchart TB
    CVSS["CVSS 점수체계(0.0~10.0)"]
    BASE["기본 메트릭(Base) - 고유·불변 특성"]
    TEMP["위협/시간 메트릭(Threat·Temporal) - 시간에 따라 변함"]
    ENV["환경 메트릭(Environmental) - 조직 맥락 반영"]
    SUPP["보조 메트릭(Supplemental, v4.0) - 참고용(점수 무영향)"]
    CVSS --> BASE
    CVSS --> TEMP
    CVSS --> ENV
    CVSS --> SUPP
    BASE --> EXP["악용 가능성(AV·AC·PR·UI 등)"]
    BASE --> IMP["영향도(기밀성·무결성·가용성)"]

기본 메트릭(Base)은 취약점 자체의 변하지 않는 본질적 특성을 평가하며, CVSS 점수의 뼈대다. 이는 다시 '악용 가능성(Exploitability)'과 '영향도(Impact)'로 나뉜다. 악용 가능성은 공격자가 얼마나 쉽게 취약점을 건드릴 수 있는가를 보는 축으로, 공격 벡터(AV: Network·Adjacent·Local·Physical), 공격 복잡도(AC: Low·High), 필요 권한(PR: None·Low·High), 사용자 상호작용(UI: None·Required)으로 구성된다. 예컨대 네트워크 원격에서(AV:N) 특별한 조건 없이(AC:L) 인증 없이(PR:N) 사용자 개입 없이(UI:N) 악용되는 취약점은 악용 가능성 점수가 최대가 되어, 웜(worm)처럼 자가 전파될 위험이 커진다.

영향도는 취약점이 성공적으로 악용되었을 때 기밀성(C)·무결성(I)·가용성(A)이 각각 얼마나 훼손되는지(None·Low·High)를 평가한다. 세 요소를 분리 평가하는 이유는, 정보 유출(기밀성)과 데이터 변조(무결성), 서비스 중단(가용성)이 조직에 주는 피해의 성격이 전혀 다르기 때문이다. v3.1에서는 여기에 범위(Scope) 개념을 두어, 취약한 구성요소의 피해가 보안 권한 경계를 넘어 다른 구성요소까지 번지는지(Changed/Unchanged)를 반영했다. 예를 들어 하이퍼바이저 취약점으로 게스트 VM에서 호스트까지 장악되면 Scope가 Changed가 되어 점수가 크게 상승한다.

시간/위협 메트릭은 시간이 지나며 변하는 특성을 보정한다. v3.1의 Temporal 그룹은 악용 코드 성숙도(E), 치료 수준(RL), 보고 신뢰도(RC)로 구성되며, PoC만 있는지 실제 익스플로잇이 공개되었는지에 따라 위험도가 달라짐을 표현한다. v4.0은 이를 위협(Threat) 메트릭으로 간소화해 '악용 성숙도(E)' 하나만 남겼는데, 이는 뒤에서 다룰 EPSS 같은 외부 위협 정보와 역할이 겹친다는 판단 때문이다.

환경 메트릭(Environmental)은 동일한 취약점이라도 우리 조직 환경에서의 실제 위험이 다르다는 점을 반영한다. 자산의 기밀성·무결성·가용성 중요도(보안 요구사항 CR·IR·AR)를 가중하고, 조직이 이미 적용한 완화책에 따라 기본 메트릭을 수정(Modified Base)할 수 있다. 예를 들어 인터넷에 노출되지 않은 폐쇄망의 DB 취약점은 공격 벡터가 사실상 제한되므로 환경 점수를 낮게 조정하는 것이 합리적이다.

점수는 악용 가능성·영향도 하위 점수를 정해진 공식으로 합산해 0.0~10.0으로 산출하고, 이를 등급으로 매핑한다. 아래 표는 v3.1/v4.0 공통 심각도 등급 구간이다.

3. 위험 기반 우선순위 산정과 EPSS·KEV 연계

CVSS 점수만으로 패치 순서를 정하는 방식에는 구조적 한계가 있다. CVSS 기본 점수는 '얼마나 심각할 수 있는가(severity)'를 재지만, '실제로 공격당할 가능성이 얼마나 되는가(likelihood)'는 말해 주지 않는다. NVD의 통계를 보면 공개 CVE의 상당수가 High·Critical로 쏠려 있어, 기본 점수만 기준으로 삼으면 '위험한 것투성이'가 되어 우선순위 기능이 사실상 마비된다. 실제로 전체 공개 취약점 중 실제 공격에 활용되는 비율은 한 자릿수 퍼센트에 불과하다는 연구가 반복적으로 보고된다.

이 한계를 메우기 위해 현대의 취약점 관리는 CVSS를 EPSS·KEV·자산 맥락과 결합한다. EPSS(Exploit Prediction Scoring System) 역시 FIRST가 운영하는 체계로, 머신러닝 모델로 특정 취약점이 향후 30일 내 실제 악용될 확률(0~1)을 예측한다. CVSS가 '피해의 크기'라면 EPSS는 '악용의 가능성'을 보완하는 축이다. KEV(Known Exploited Vulnerabilities)는 미국 CISA가 운영하는 실제 악용이 확인된 취약점 목록으로, 이름이 오르면 '이론적 위험'이 아니라 '현재 진행형 위협'임을 뜻한다.

아래 흐름도는 CVSS를 출발점으로 삼아 EPSS·KEV와 자산 맥락을 결합하는 위험 기반 우선순위 산정 프로세스를 보여 준다.

flowchart LR
    A["취약점 식별(CVE·스캐너)"] --> B["CVSS 기본점수 산정(심각도)"]
    B --> C["EPSS 적용(악용 확률 예측)"]
    C --> D["KEV 조회(실제 악용 여부)"]
    D --> E["자산 중요도·환경 메트릭 반영"]
    E --> F{"위험 우선순위 결정"}
    F -->|"높음"| G["즉시 패치·완화"]
    F -->|"낮음"| H["정기 패치 주기 편입"]

실무에서는 예컨대 "CVSS 9.0 이상이면서 KEV에 등재되었거나 EPSS 0.5 이상"인 취약점을 즉시 조치 대상으로, 그 외 Critical·High는 SLA 기반 정기 패치로 분류하는 식의 정책을 운영한다. 이렇게 하면 수천 건의 Critical 중에서도 '지금 당장 위험한' 수십 건에 자원을 집중할 수 있어, 한정된 보안 인력의 효율이 극적으로 개선된다.

구체 사례로 2021년의 Log4Shell(CVE-2021-44228)은 CVSS v3.1 기준 10.0(Critical)(AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)으로, 원격에서 인증 없이 임의 코드 실행이 가능하고 영향이 다른 시스템까지 번져(S:C) 최고점을 받았으며, 공개 직후 KEV에 즉시 등재되어 전 세계가 긴급 대응에 들어갔다. 반대로 CVSS는 높지만 EPSS·KEV가 낮은 취약점도 많아, 세 지표를 함께 보는 것이 과대·과소 대응을 모두 피하는 길이다.

4. 버전 비교 — v3.1과 v4.0, 유사 체계

CVSS v4.0은 v3.1에 제기된 비판을 정면으로 수용해 개편되었다. 가장 큰 변화는 범위(Scope) 메트릭의 폐지로, 모호하다는 지적이 많았던 Scope 대신 취약 시스템 영향(VC·VI·VA)과 후속 시스템 영향(SC·SI·SA)을 명시적으로 분리해 피해 전파를 더 정밀하게 표현한다. 또한 공격 성공에 특정 조건이 필요한지를 보는 공격 요구사항(AT) 메트릭이 신설되었고, 사용자 상호작용(UI)이 None·Passive·Active로 세분화되었다.

두 번째 변화는 보조 메트릭(Supplemental) 그룹의 추가다. 안전(Safety)·자동화 가능성(Automatable)·복구(Recovery)·가치 밀도(Value Density) 등 운영 판단에 도움이 되는 정보를 담되, 점수에는 영향을 주지 않는 참고용 지표로 둔 점이 특징이다. 세 번째로 v4.0은 명명 규칙을 도입해 CVSS-B(기본만), CVSS-BT(기본+위협), CVSS-BE(기본+환경), CVSS-BTE(전체)처럼 어떤 메트릭까지 반영한 점수인지 투명하게 표기하도록 했다. 이는 "대부분의 조직이 기본 점수만 쓰고 시간·환경 메트릭을 활용하지 않아 점수가 과대평가된다"는 오랜 비판에 대한 응답이다.

CVSS는 CVE·CWE·EPSS 등 다른 보안 표준과 역할이 구분된다. CVE가 '어떤 취약점인가(식별)', CWE가 '어떤 유형의 결함인가(분류)'를 다룬다면, CVSS는 '얼마나 심각한가(평가)'를 담당한다. 또한 공급망 보안에서 [[sbom]]으로 구성요소를 파악하고 [[vex-vulnerability-exploitability-exchange]]로 "그 취약점이 우리 제품에 실제 영향을 주는가"를 판별한 뒤, CVSS로 심각도를 매기는 식으로 여러 표준이 사슬처럼 연계된다.

5. 심화: 최신 동향과 실무 적용

최근 취약점 관리의 패러다임은 '심각도 중심'에서 '악용 가능성·노출 중심'으로 이동하고 있다. 이는 CVSS 단독 사용의 한계가 널리 인식된 결과로, 가트너 등은 조직이 CVSS·EPSS·위협 인텔리전스·자산 중요도를 통합한 위험 기반 취약점 관리(RBVM)와 지속적 위협 노출 관리(CTEM)로 전환할 것을 권고해 왔다(세부 수치·시점은 보고서 판마다 다르므로 일반화해 이해해야 한다). 실제로 미국 정부의 SSVC(Stakeholder-Specific Vulnerability Categorization)처럼, 점수 하나로 줄 세우는 대신 '악용 여부·자동화 가능성·임무 영향'을 질의응답식으로 판단해 조치/추적/주시 등으로 분류하는 의사결정 모델도 확산되고 있다.

실무 적용 사례로, 대형 금융사나 클라우드 사업자는 수만 대 자산의 스캐너 결과에 CVSS 기본 점수를 기본 필터로 걸고, 그 위에 EPSS 확률과 KEV 등재 여부를 결합한 가중 위험 점수를 자체 산출해 패치 SLA(예: KEV 등재는 24시간, Critical은 7일, High는 30일)를 운영한다. 이렇게 하면 CVSS가 만들어 낸 수천 건의 Critical 더미에서 벗어나, 실제로 조직에 위협이 되는 소수에 집중할 수 있다. 또한 [[devsecops]] 파이프라인에서는 빌드 단계의 의존성 스캔 결과에 CVSS 임계값(예: 7.0 이상 발견 시 빌드 차단) 게이트를 걸어, 취약점이 운영에 반영되기 전에 걸러 내는 방식으로 활용한다.

출제 관점에서 CVSS는 "취약점 평가·관리 체계를 설명하라", "위험 기반 취약점 관리 방안", "CVSS의 한계와 보완 방안(EPSS·KEV 연계)" 같은 문항과 강하게 연계된다. 답안 구성 시에는 ① CVSS 메트릭 구조(기본·위협·환경)로 개념을 정의하고, ② v4.0의 개선점으로 최신성을 보이며, ③ CVSS 단독 사용의 한계를 지적하고, ④ EPSS·KEV·자산 맥락을 결합한 위험 기반 우선순위 산정으로 실무 해법을 제시하는 흐름이 효과적이다.

6. 고려사항 및 시사점

기술사 관점에서 CVSS는 '점수 그 자체'가 아니라 위험 기반 의사결정의 입력값으로 다루어야 하며, 다음을 종합적으로 고려한다.

• 적용 전략(단독 사용 금지): CVSS 기본 점수만으로 우선순위를 정하면 과도한 Critical 더미에 압도되므로, EPSS(악용 확률)·KEV(실제 악용)·자산 중요도를 결합한 위험 기반 취약점 관리(RBVM) 정책을 수립하고, 조직 특성에 맞는 환경 메트릭을 반드시 반영해야 한다.
• 트레이드오프(정밀성 vs 운영 비용): 시간·환경 메트릭까지 정밀 평가하면 점수의 현실성은 높아지나 자산별 수작업 부담이 커진다. 전사 일괄 정밀 평가는 비현실적이므로, 핵심 자산·외부 노출 구간부터 선별적으로 심층 평가하고 나머지는 자동화된 기본 점수로 관리하는 계층적 접근이 현실적이다.
• 점수 인플레이션·오남용 경계: CVSS는 '최악의 시나리오'를 가정해 설계되어 점수가 높게 나오는 경향이 있고, 벤더가 책임 회피를 위해 고의로 점수를 부풀리거나 낮추는 왜곡도 발생한다. 따라서 NVD·벤더 점수를 맹신하지 말고 자체 환경 메트릭으로 재평가하며, v4.0의 CVSS-BTE 표기처럼 어떤 메트릭까지 반영한 점수인지 확인해야 한다.
• 거버넌스·규제 정합성: PCI-DSS 등 규제가 요구하는 CVSS 임계값을 패치 SLA·[[isms-p]] 통제항목과 정합하게 설계하고, 취약점 조치 이력과 근거(점수·EPSS·KEV)를 기록해 감사 추적성을 확보해야 한다.
• 전망·연계 기술: CVSS는 [[sbom]]·[[vex-vulnerability-exploitability-exchange]]·[[mitre-attack]]·[[threat-modeling]]과 결합할 때 공급망 전반의 위험을 체계적으로 다룰 수 있으며, 향후 SSVC·CTEM 같은 의사결정 중심 모델과 AI 기반 악용 예측이 결합되어 '점수 줄 세우기'를 넘어 맥락 인지형 위험 관리로 진화할 것으로 전망된다.

참고자료

• FIRST, "CVSS v4.0 Specification Document". https://www.first.org/cvss/v4-0/specification-document
• FIRST, "Common Vulnerability Scoring System SIG". https://www.first.org/cvss/
• FIRST, "EPSS — Exploit Prediction Scoring System". https://www.first.org/epss/
• CISA, "Known Exploited Vulnerabilities Catalog". https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NIST NVD, "Vulnerability Metrics". https://nvd.nist.gov/vuln-metrics/cvss

한 줄 요약: CVSS는 FIRST가 관리하는 표준 취약점 심각도 평가 체계로, 기본·위협·환경 메트릭으로 0.0~10.0 점수를 산출하며, 심각도만 재는 한계를 EPSS(악용 확률)·KEV(실제 악용)·자산 맥락과 결합한 위험 기반 우선순위 산정으로 보완해야 실무적 가치를 갖는다.