CVSS 4.0과 3.1 채점 방식 차이 분석
이 글은 공개된 1차 자료(FIRST 규격 문서·사용자 가이드)와 여러 2차 분석을 교차 정리해 우리 말로 다시 쓴 것입니다. 특정 문장을 그대로 옮기지 않았고, 소스코드 인용이나 패치 비교는 하지 않습니다. 정확한 수치·계산 절차는 하단 참고자료의 원문을 직접 확인하시기 바랍니다.
Security · 취약점 관리 · 스코어링 개념 [정보성]
취약점 점수는 “이 버그가 얼마나 위험한가”를 한 줄 숫자로 압축하는 도구입니다. 그런데 압축 규칙이 바뀌면, 같은 버그라도 다른 숫자가 나오거나, 같은 숫자라도 의미가 달라집니다. CVSS 3.1에 익숙한 손이 4.0 벡터를 받아들 때 헷갈리기 쉬운 지점을 네 축으로 나눠 보겠습니다.
개요 — 언제, 무엇이 바뀌었나
CVSS는 FIRST(Forum of Incident Response and Security Teams, 사고 대응 및 보안팀 포럼)가 관리합니다. 4.0은 2023년에 공식 발표됐고, 2019년에 나온 3.1의 후속입니다.
바뀌지 않은 것부터 짚겠습니다. 점수 범위 0.0~10.0과 정성 심각도 밴드(None / Low / Medium / High / Critical)는 3.1과 똑같이 유지됩니다. 즉 “9.8이면 Critical”이라는 감각 자체는 그대로 쓸 수 있습니다. 달라진 건 그 숫자에 도달하는 길입니다.
핵심 사실 요약
메트릭 그룹 구조가 재편됐다
3.1은 Base · Temporal · Environmental 세 묶음으로 나뉘었습니다. 4.0은 네 묶음입니다. Base · Threat · Environmental · Supplemental.
- 3.1의 Temporal(시간) 그룹이 4.0에서 Threat(위협) 그룹으로 이름이 바뀌었습니다.
- Supplemental(부가) 그룹은 4.0에서 새로 생겼습니다. 3.1에는 아예 없던 묶음입니다.
Supplemental은 뒤(6절)에서 따로 다루겠습니다. 핵심은, 점수를 읽을 때 “이게 어느 그룹까지 반영한 숫자냐”를 먼저 확인하는 습관이 4.0에서 더 중요해졌다는 점입니다.
Base 메트릭이 달라진 지점 (트리아지에 바로 닿는다)
Base 그룹은 취약점 자체의 고유 성질을 재는 묶음입니다. 여기가 바뀌면 트리아지 첫 판단이 바뀝니다.
신규 메트릭 — Attack Requirements(AT, 공격 요구조건). 공격이 성립하려면 필요한 배치·실행 전제조건을 담는 값입니다. 값은 None(N)과 Present(P) 두 가지입니다. 3.1에는 없던 개념으로, “조건이 맞아떨어져야만 터지는 버그”를 점수에 반영할 수 있게 됐습니다.
User Interaction(UI, 사용자 상호작용)이 세분화됐습니다. 3.1에서는 None / Required 두 값이었는데, 4.0은 None(N) / Passive(P) / Active(A) 세 값으로 나뉩니다. 사용자가 아무것도 안 해도 되는지, 평범하게 쓰다 걸리는지, 적극적으로 속아 넘어가야 하는지를 구분합니다.
Scope(S) 메트릭이 폐지됐습니다. 3.1의 Scope는 “영향이 원래 경계를 넘느냐”를 한 비트로 눌러 담았는데, 해석이 모호하다는 지적이 많았습니다. 4.0은 이걸 없애고, 영향을 두 대상으로 쪼갰습니다.
- 취약 시스템(Vulnerable System) — 버그가 직접 들어 있는 시스템.
- 후속 시스템(Subsequent System) — 그 버그 때문에 뒤이어 영향을 받는 다른 시스템.
그래서 영향도 메트릭이 여섯 개로 쪼개집니다. 취약 시스템 쪽 VC / VI / VA 와 후속 시스템 쪽 SC / SI / SA 입니다. 각각 기밀성(Confidentiality) · 무결성(Integrity) · 가용성(Availability)을 뜻합니다. 연쇄로 번지는 영향을 모호한 한 비트가 아니라 별도 축으로 명시해서 점수에 담는 구조입니다.
Threat(구 Temporal) 그룹이 메트릭 하나로 줄었다
3.1 Temporal 그룹에는 Exploit Code Maturity · Remediation Level(RL, 수정 수준) · Report Confidence(RC, 보고 신뢰도) 셋이 있었습니다. 4.0 Threat 그룹에는 Exploit Maturity(E, 익스플로잇 성숙도) 하나만 남았습니다. RL과 RC는 제거됐습니다.
Exploit Maturity의 값도 정리됐습니다. 4.0 값은 Not Defined(X) / Attacked(A) / Proof-of-Concept(P) / Unreported(U) 입니다.
- Attacked(A) — 이 취약점을 노린 공격(시도 또는 성공)이 보고됐거나, 악용을 쉽게 해 주는 해법(예: 익스플로잇 툴킷)이 공개·비공개로 제공되는 상태. 둘 중 하나만 해당해도 Attacked입니다.
- Proof-of-Concept(P) — 익스플로잇 코드는 공개됐지만 실제 악용 사례는 확인되지 않은 상태.
- Unreported(U) — 공개된 PoC 코드도 없고, 악용 시도 보고도 없으며, 공개된 익스플로잇 해법도 없는 상태. (PoC 코드조차 없다는 점에서 Proof-of-Concept와 구분됩니다.)
3.1에서 따로 있던 High(H)와 Functional(F)이 4.0에서 Attacked(A) 하나로 합쳐졌습니다. 참고로 Not Defined(X)는 실제 상태값이 아니라 “지정 안 함”을 뜻합니다. 그래서 실질적으로 고르는 상태는 세 개(A / P / U)로 보는 서술과, X를 포함해 네 개로 세는 서술이 함께 쓰이는데 혼동일 뿐 모순은 아닙니다.
채점 엔진이 바뀌었고, “Base만 쓰기”가 더 위험해졌다
3.1은 메트릭 값을 정해진 선형 공식에 넣어 점수를 뽑았습니다. 4.0은 MacroVector(매크로벡터) 방식을 씁니다. 가능한 벡터들을 등가 클래스(equivalence class) 묶음으로 나누고, 그 안에서 보간(interpolation)으로 심각도 순위를 매기는 방식입니다. 손으로 공식을 암산하던 감각은 더 이상 잘 맞지 않고, 계산기에 의존하게 됩니다.
여기서 트리아지에 가장 직접적으로 닿는 변화가 나옵니다. FIRST 사용자 가이드는 Base 점수(CVSS-B)가 취약점의 심각도를 재는 값일 뿐이며, 위험(risk) 평가에 단독으로 쓰여서는 안 된다고 명시합니다. Base는 환경 분석(Environmental)과 시간에 따라 변하는 속성(Threat)으로 보완돼야 한다는 것입니다.
그런데 Threat와 Environmental 메트릭을 지정하지 않으면, 계산기는 이 값들을 “가장 높은 심각도를 가정하는 기본값”으로 조합합니다. Exploit Maturity의 최고 심각도 값이 Attacked(A)이므로, 아무것도 지정하지 않으면 사실상 “야생에서 악용되는 중”이라고 가정한 상태로 점수가 나옵니다.
- 참고(1차 근거): FIRST v4.0 규격 문서는 Exploit Maturity의 Not Defined(X)가 “점수 계산 목적상 최악의 경우를 가정해 Attacked(A)와 동등하게” 처리된다고 명시합니다. 즉 “E:X는 점수 계산에서 E:A로 다뤄진다”는 서술은 2차 단순화가 아니라 1차 문서에 직접 적힌 내용입니다.
실무 함의는 분명합니다. Base만 보고 넘기면 모든 취약점이 “최악 가정” 점수로 과대평가되기 쉽습니다. 4.0은 이걸 막으려고 Threat·Environmental 반영을 더 강하게 권합니다.
그리고 명명법(nomenclature)이 이 반영 수준을 라벨로 강제합니다. 어디까지 메트릭을 넣었는지에 따라 네 가지 이름이 붙습니다.
- CVSS-B — Base만.
- CVSS-BT — Base + Threat.
- CVSS-BE — Base + Environmental.
- CVSS-BTE — 세 그룹 전부.
점수 옆에 붙은 이 라벨만 봐도 “이 숫자가 얼마나 다듬어진 값이냐”를 바로 알 수 있습니다.
Supplemental 그룹 — 점수는 안 바꾸고 맥락만 준다
4.0에서 새로 생긴 Supplemental 그룹에는 여섯 메트릭이 있습니다. Safety(안전), Automatable(자동화 가능성), Provider Urgency(공급자 긴급도), Recovery(복구), Value Density(가치 밀도), Vulnerability Response Effort(대응 노력)입니다.
이 그룹은 최종 점수(CVSS-BTE)를 바꾸지 않습니다. 대신 대응 판단에 쓸 부가 맥락을 전달합니다. 특히 운영기술(OT) · 산업제어(ICS) · 사물인터넷(IoT)처럼 물리적 안전이 걸린 환경에서 Safety 같은 축이 의사결정에 도움이 되도록 설계됐습니다.
짧은 논평 — 점수가 “더 높아졌나”는 단정하지 않는다
4.0이 3.1보다 점수를 더 높게 주는 경향이 있는지에 대해서는 출처 간 서술이 엇갈립니다.
- 한쪽에서는 4.0이 일부 취약점에 3.1보다 더 높은 점수를 주는 경향이 있다는 인상이 거론되기도 합니다. (⚠️미확인 — 구체적 수치나 전반적 상향 경향을 뒷받침하는 1차·2차 출처를 확인하지 못했습니다. 실제로 일부 2차 예시는 하향 변동도 보여 방향이 일정하지 않습니다.)
- 다른 쪽은 4.0이 3.x의 “점수 인플레이션”(너무 많은 취약점이 Critical로 몰리는 문제)을 더 균형 잡힌 분포로 완화하려 설계됐다고 서술합니다.
두 서술은 긴장 관계이고, 벤더별 취약점 표본과 점수 구간에 따라 결론이 달라지는 것으로 보입니다. 그래서 이 글은 “4.0이 전반적으로 더 높다/낮다”를 단정하지 않습니다. 트리아지 실무에서 중요한 건 평균의 방향이 아니라, 앞에서 본 네 축(영향 분할 · Threat 축소 · 미지정 worst-case · 명명법)이 개별 벡터의 의미를 바꾼다는 점입니다.
References / 참고자료
- FIRST.org, “CVSS v4.0 Specification Document” — 메트릭 그룹·값·Supplemental·명명법의 1차 규격. https://www.first.org/cvss/v4.0/specification-document
- FIRST.org, “CVSS v4.0 User Guide” — Base 단독 사용 금지·미지정 시 worst-case 기본값 등 트리아지 지침 1차 출처. https://www.first.org/cvss/v4.0/user-guide
- Help Net Security, “CVSS 4.0 released, to help assess real-time threat and impact of vulnerabilities” — 2023년 7월 공개 테스트(정식 출시 전 프리뷰) 단계를 다룬 보도. 정식 출시는 2023-11-01. https://www.helpnetsecurity.com/2023/07/13/first-cvss-4-0-released/
- Nucleus Security, “A First Look at CVSS V4.0 Next To CVSS V3.1” — Temporal → Threat 명칭 변경 등 3.1 대비 비교, 벤더 공표 점수가 High·Critical(7.0+)로 몰리는 경향 서술(논평절 “인플레이션” 서사의 근거). https://nucleussec.com/blog/first-look-cvss-v40-vs-cvss-v31
- Snyk, “What’s new in CVSS 4.0” — Exploit Maturity 값 변경(Functional 제거·Attacked는 High의 개명) 및 심각도 분포 granularity 서술. https://snyk.io/blog/cvss-4/
- Finite State, “First Impressions of the CVSS 4.0 Preview” — Exploit Maturity 값 정의(Attacked/PoC/Unreported). https://finitestate.io/blog/all-you-need-is-exploit-maturity-first-impressions-of-the-cvss-4.0-preview
- Rapid7, “What’s New in CVSS v4” — 더 넓은 취약점 점수 분포(greater score distribution) 서술. https://www.rapid7.com/blog/post/2023/08/14/whats-new-in-cvss-v4/
이 글은 위 공개 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장을 그대로 옮기지 않았으며, 정확한 계산 절차와 수치는 원문(특히 1·2번 FIRST 1차 문서)을 참고하세요.