CVSS v4.0 이해하기: 취약점 심각도와 패치 우선순위 구분

1장 CVSS란 무엇인가#

보안 취약점 정보를 보다 보면 거의 항상 다음과 같은 숫자를 만나게 됩니다.

CVSS 5.3
CVSS 7.5
CVSS 9.8
CVSS 10.0

숫자가 높을수록 심각한 취약점이라는 의미로 이해하기 쉽습니다.

큰 틀에서는 맞지만 실제 운영에서는 한 가지 중요한 점을 기억해야 합니다.

CVSS 점수는 취약점의 기술적 심각도를 표현하는 값이지, 우리 조직에서 반드시 먼저 패치해야 할 순서를 자동으로 결정하는 값은 아니다.

원문에서도 CVSS를 소프트웨어 취약점의 기술적 심각도를 공통 기준으로 표현하는 체계로 정의하고, 점수만으로 조직의 업무 위험이나 패치 순위를 확정해서는 안 된다고 설명합니다.

2장 CVSS 점수와 실제 위험은 같은 것이 아니다#

예를 들어 같은 CVSS 9점대 취약점이 두 서버에 존재한다고 하겠습니다.

서버 A#

인터넷 공개
인증 서비스
실제 운영 중
외부 사용자가 접근 가능

서버 B#

외부 접근 차단
실험용 서버
내부 테스트망
중요 데이터 없음

기술적으로 같은 취약점이라도 두 서버의 실제 위험은 같지 않을 수 있습니다.

flowchart LR
    CVE[동일한 취약점]

    A[서버 A<br/>인터넷 공개<br/>중요 인증 서비스]
    B[서버 B<br/>내부 실험 서버]

    CVE --> A
    CVE --> B

    A --> HIGH[높은 조치 우선순위 가능]
    B --> LOW[상대적으로 낮은 우선순위 가능]

원문 역시 인터넷에 공개된 인증 서버와 외부 접근이 차단된 실험 서버는 CVSS 점수가 같아도 조치 순서가 달라질 수 있다고 설명합니다.

3장 CVSS v4.0은 네 개의 메트릭 그룹으로 본다#

원문은 CVSS v4.0을 다음 네 그룹으로 구분합니다.

Base
Threat
Environmental
Supplemental

전체 구조를 보면 다음과 같습니다.

flowchart TB
    CVSS[CVSS v4.0]

    B[Base]
    T[Threat]
    E[Environmental]
    S[Supplemental]

    CVSS --> B
    CVSS --> T
    CVSS --> E
    CVSS --> S

    B --> B1[취약점의 본질적 특성]
    T --> T1[현재 위협 조건]
    E --> E1[조직 환경의 영향]
    S --> S1[추가 맥락 정보]

네 그룹은 같은 역할을 하지 않습니다.

4장 Base 메트릭이란 무엇인가#

Base는 취약점 자체의 본질적인 기술적 특성을 평가하는 영역입니다.

원문에서는 기본 메트릭에서 다음 요소를 평가한다고 설명합니다.

  • 공격 조건
  • 취약한 시스템의 영향
  • 후속 시스템의 영향

즉 다음 질문에 가깝습니다.

이 취약점 자체는 기술적으로 얼마나 공격하기 쉽고, 성공하면 어떤 영향을 줄 수 있는가?

Base는 특정 회사나 특정 서버의 현재 상황보다는 취약점 그 자체의 특성을 이해하기 위한 출발점입니다.

5장 Base Score만 보고 패치 순서를 결정하면 왜 문제가 될까#

다음 상황을 생각해보겠습니다.

취약점 A
CVSS 9.8

취약점 B
CVSS 8.1

점수만 보면 A를 먼저 처리해야 할 것처럼 보입니다.

하지만 실제 환경이 다음과 같다면 판단이 달라질 수 있습니다.

취약점 A
내부 개발 서버
외부 접근 불가

취약점 B
인터넷 공개
고객 인증 서버
실제 공격 신호 존재

이때 취약점 B를 먼저 처리하는 것이 더 합리적일 수 있습니다.

따라서 패치 우선순위는:

CVSS 점수
+
실제 노출
+
악용 여부
+
자산 중요도
+
보완 통제

를 함께 봐야 합니다.

6장 Threat 메트릭은 무엇을 보는가#

Threat는 취약점 자체가 아니라 현재 위협 상황을 반영하는 영역입니다.

원문에서는 Threat 그룹을:

악용 성숙도 등의 위협 조건

으로 설명합니다.

운영에서는 다음을 함께 확인해야 합니다.

실제 공격이 관찰되고 있는가
공격 코드가 존재하는가
공격이 현실적으로 가능한가
평가 시점은 언제인가

즉 Base가 상대적으로 정적인 정보라면 Threat는 시간에 따라 변할 수 있는 정보에 가깝습니다.

7장 같은 취약점이라도 Threat는 시간이 지나며 바뀔 수 있다#

처음에는 다음 상태일 수 있습니다.

취약점 공개
↓
실제 공격 확인 안 됨

하지만 시간이 지나:

공격 코드 공개
↓
실제 악용 사례 증가

상태가 될 수 있습니다.

flowchart LR
    A[취약점 공개]
    B[공격 코드 등장]
    C[실제 악용 증가]

    A --> B --> C

    A --> R1[상대적으로 낮은 위협]
    B --> R2[위협 상승]
    C --> R3[긴급 대응 필요성 증가]

그래서 원문은 Threat를 볼 때 실제 공격 신호와 평가 시점을 함께 확인하라고 강조합니다.

8장 Environmental 메트릭은 왜 중요한가#

Environmental은 취약점이 존재하는 조직의 실제 환경을 반영합니다.

원문에서는 다음을 확인하도록 제시합니다.

  • 자산
  • 통제
  • 영향

같은 취약점이라도 어떤 시스템에 존재하는지에 따라 중요도는 크게 달라질 수 있습니다.

예를 들어:

운영 결제 서버

와:

폐쇄된 테스트 서버

는 동일하게 평가하기 어렵습니다.

9장 Environmental에서 자산 중요도를 본다#

조직에서는 모든 시스템의 중요도가 같지 않습니다.

예:

고객 인증 시스템
결제 시스템
내부 위키
개발 테스트 서버

이 네 시스템에 같은 취약점이 존재해도 업무 영향은 다릅니다.

flowchart TB
    V[동일한 취약점]

    AUTH[고객 인증 시스템]
    PAY[결제 시스템]
    WIKI[내부 위키]
    DEV[개발 테스트 서버]

    V --> AUTH
    V --> PAY
    V --> WIKI
    V --> DEV

따라서 CVSS 자체의 심각도와 별개로 해당 자산이 조직에서 얼마나 중요한지를 봐야 합니다.

10장 보완 통제가 이미 있는지도 확인한다#

취약점이 존재하더라도 추가 통제가 위험을 줄일 수 있습니다.

예:

외부 접근 차단
WAF
네트워크 분리
MFA
IP 제한
최소 권한

이런 통제가 존재하면 실제 공격 가능성이나 업무 영향이 달라질 수 있습니다.

반대로 CVSS 점수는 같더라도 아무런 보완 통제가 없는 서버는 더 우선적으로 대응해야 할 수 있습니다.

11장 Supplemental 메트릭은 무엇인가#

Supplemental은 추가적인 맥락 정보를 전달하는 영역입니다.

원문에서 중요한 점을 하나 명확히 합니다.

Supplemental 메트릭은 추가 정보를 제공하지만 최종 점수 계산에는 영향을 주지 않는다.

즉 Supplemental은:

점수를 높이고 낮추는 요소

라기보다:

취약점 판단에 필요한 부가 정보

로 이해하는 것이 좋습니다.

12장 네 메트릭 그룹을 비교하면#

그룹 핵심 의미 운영에서 확인할 점
Base 취약점 자체의 기술적 특성 버전·전체 벡터
Threat 현재 위협·악용 상태 실제 공격·평가 시점
Environmental 조직 환경에서의 영향 자산·통제·업무 영향
Supplemental 추가 맥락 점수와 별도로 참고

이 구분은 원문의 비교 기준을 바탕으로 정리한 것입니다.

13장 CVSS 숫자만 저장해서는 부족하다#

예를 들어 다음과 같이 저장했다고 하겠습니다.

CVE-XXXX-XXXX
CVSS 8.8

몇 달 뒤 다시 보면 문제가 생길 수 있습니다.

어떤 CVSS 버전인가?

어떤 벡터로 평가한 것인가?

누가 평가한 값인가?

를 알 수 없기 때문입니다.

원문에서는 반드시:

점수
버전
벡터
평가 출처

를 함께 저장하라고 권장합니다.

14장 CVSS 벡터 문자열이 중요한 이유#

CVSS는 최종 점수만 제공하는 것이 아닙니다.

벡터는 어떤 조건을 바탕으로 점수가 계산되었는지를 표현합니다.

따라서:

CVSS 9.1

만 보는 것보다:

버전
+
점수
+
벡터 문자열

을 함께 확인하는 편이 안전합니다.

flowchart LR
    SCORE[CVSS 점수]
    VERSION[CVSS 버전]
    VECTOR[벡터 문자열]
    INTERPRET[정확한 해석]

    SCORE --> INTERPRET
    VERSION --> INTERPRET
    VECTOR --> INTERPRET

15장 CVSS v3.1과 v4.0을 같은 방식으로 읽으면 안 된다#

원문은 특히 이 부분을 주의합니다.

v3.1 벡터와 v4.0 벡터를 같은 형식으로 해석하면 사용자 상호작용 등의 차이를 놓칠 수 있습니다.

즉 숫자가 비슷해 보여도:

CVSS v3.1

과:

CVSS v4.0

은 반드시 버전을 확인하고 해당 버전의 정의에 따라 해석해야 합니다.

16장 패치 우선순위는 어떻게 정해야 할까#

원문의 핵심은 여기입니다.

CVSS 점수만으로 정하지 않고 다음 요소를 함께 봅니다.

CVSS
실제 악용 여부
외부 노출 여부
자산 중요도
보완 통제
패치 장애 위험

이를 구조화하면 다음과 같습니다.

flowchart TB
    C[CVSS 기술적 심각도]
    E[실제 악용]
    X[외부 노출]
    A[자산 중요도]
    M[보완 통제]
    P[패치 장애 위험]

    PRIORITY[패치 우선순위]

    C --> PRIORITY
    E --> PRIORITY
    X --> PRIORITY
    A --> PRIORITY
    M --> PRIORITY
    P --> PRIORITY

17장 예제 1: 인터넷 공개 인증 서버#

다음 서버가 있다고 하겠습니다.

용도
고객 로그인·인증

노출
인터넷 공개

취약점
CVSS 8.7

실제 악용
확인됨

이 경우 기술 점수가 10점이 아니더라도 우선순위는 매우 높아질 수 있습니다.

이유는 다음과 같습니다.

외부 접근 가능
+
중요한 인증 자산
+
실제 악용 신호

가 동시에 존재하기 때문입니다.

18장 예제 2: 외부에서 차단된 실험 서버#

다른 서버를 보겠습니다.

용도
개발 실험

노출
내부 전용

취약점
CVSS 9.5

실제 악용
확인되지 않음

점수는 더 높지만 실제 업무 위험은 첫 번째 사례보다 낮을 수 있습니다.

원문이 설명하는 것도 바로 이런 차이입니다.

19장 CVSS와 패치 우선순위는 이런 관계다#

flowchart LR
    CVSS[CVSS]

    CONTEXT[환경 맥락]

    PRIORITY[패치 우선순위]

    CVSS --> PRIORITY

    CONTEXT --> PRIORITY

    CONTEXT --> A[인터넷 노출]
    CONTEXT --> B[악용 여부]
    CONTEXT --> C[자산 중요도]
    CONTEXT --> D[보완 통제]

CVSS는 중요한 입력값입니다.

하지만 최종 판단 그 자체는 아닙니다.

20장 실제 악용 여부는 매우 중요한 신호다#

취약점이 공개되었다는 것과 실제 공격에 사용되고 있다는 것은 다릅니다.

취약점 존재

보다:

취약점 존재
+
실제 공격 중

인 상황은 훨씬 긴급하게 볼 수 있습니다.

따라서 원문에서도 패치 순위를 정할 때 실제 악용 여부를 추가하라고 명확히 설명합니다.

21장 외부 노출 여부도 반드시 확인한다#

다음 두 서버가 같은 취약점을 가지고 있다고 하겠습니다.

서버 A
Internet → Server 가능

서버 B
Internet → Firewall → 차단

구조:

flowchart LR
    INTERNET[Internet]

    A[운영 서버 A]
    FW[Firewall]
    B[내부 서버 B]

    INTERNET --> A
    INTERNET --> FW
    FW -. 차단 .-> B

외부 공격자의 접근 가능성이 다르므로 대응 우선순위도 달라질 수 있습니다.

22장 보완 통제가 있다는 이유로 패치를 무기한 미뤄도 되는 것은 아니다#

예를 들어 WAF가 특정 공격을 차단하고 있다고 하겠습니다.

이는 위험을 낮추는 데 도움이 될 수 있습니다.

하지만:

취약점 자체가 사라진 것은 아니다.

따라서 보완 통제는:

패치를 하지 않아도 되는 이유

라기보다:

정식 수정 전 위험을 줄이는 임시 대책

으로 사용하는 경우도 많습니다.

원문 역시 임시 차단 조치를 기록해야 한다고 설명합니다.

23장 패치 자체의 장애 위험도 봐야 한다#

모든 패치를 발견 즉시 운영 서버에 적용하는 것도 위험할 수 있습니다.

예:

라이브러리 호환성 문제
애플리케이션 실행 실패
DB 연결 오류
서비스 재시작 필요

따라서 패치 우선순위는 보안 위험뿐 아니라 패치 적용으로 인한 서비스 위험도 함께 봐야 합니다.

원문에서도 패치 장애 위험을 우선순위 판단 요소로 포함합니다.

24장 그래서 패치 절차가 필요하다#

개념적인 흐름은 다음과 같습니다.

flowchart LR
    A[취약점 확인]
    B[우선순위 평가]
    C[테스트 환경 패치]
    D[서비스 검증]
    E[운영 적용]
    F[재스캔]
    G[완료 확인]

    A --> B --> C --> D --> E --> F --> G

원문 역시 패치 적용 후 재스캔과 서비스 검증을 수행해야 한다고 강조합니다.

25장 패치가 설치됐다고 취약점이 해결됐다고 단정하면 안 된다#

패치 설치가 성공했다고 표시되어도 다음을 확인해야 합니다.

취약한 버전이 실제 교체되었는가
서비스가 새 버전을 사용하고 있는가
재시작이 필요한가
재스캔 결과는 정상인가
서비스 기능은 정상인가

즉:

패치 설치
≠
취약점 조치 검증 완료

입니다.

26장 재스캔이 필요한 이유#

취약점 관리 도구에서 패치 전:

CVE 발견

되었다고 하겠습니다.

패치를 적용한 뒤에는:

다시 Scan

하여 취약점이 실제로 사라졌는지 확인해야 합니다.

flowchart LR
    SCAN1[초기 스캔]
    PATCH[패치]
    SCAN2[재스캔]
    CHECK{취약점 제거?}

    SCAN1 --> PATCH --> SCAN2 --> CHECK

    CHECK -->|Yes| CLOSE[종료]
    CHECK -->|No| REVIEW[원인 재검토]

27장 서비스 검증도 함께 해야 한다#

보안팀 입장에서는 취약점이 사라지는 것이 중요합니다.

운영팀 입장에서는 서비스가 정상 동작하는 것도 중요합니다.

따라서:

재스캔
+
서비스 테스트

를 함께 수행해야 합니다.

예:

로그인 정상
결제 정상
API 정상
배치 정상
모니터링 정상

까지 확인하는 구조가 좋습니다.

28장 낮은 CVSS 점수는 무시해도 될까#

원문의 FAQ는 이 질문에 아니라고 답합니다.

여러 취약점을 연결하면 권한 상승이나 데이터 유출 같은 더 큰 공격 경로가 만들어질 수 있기 때문입니다.

예를 들어:

취약점 A
낮은 심각도

+

취약점 B
낮은 심각도

가 연결되어:

권한 상승

으로 이어질 수 있습니다.

29장 공격 경로 Attack Path를 함께 봐야 한다#

flowchart LR
    A[낮은 점수 취약점 A]
    B[낮은 점수 취약점 B]
    C[권한 획득]
    D[중요 데이터 접근]

    A --> B --> C --> D

각 취약점을 독립적으로 보면 낮은 위험으로 보이지만 연결 관계까지 보면 결과가 달라질 수 있습니다.

따라서 원문처럼 점수뿐 아니라 공격 경로와 업무 환경을 함께 확인해야 합니다.

30장 CVSS는 위험관리와 연결해서 사용해야 한다#

CVSS는 취약점 관리의 중요한 입력값이지만 전체 위험관리에서 보면 한 부분입니다.

flowchart LR
    V[취약점 발견]
    C[CVSS]
    CONTEXT[환경 분석]
    RISK[위험 평가]
    FIX[대응]
    VERIFY[검증]

    V --> C
    C --> CONTEXT
    CONTEXT --> RISK
    RISK --> FIX
    FIX --> VERIFY

CVSS에서 끝나는 것이 아니라 조직 환경의 실제 위험으로 변환하는 과정이 필요합니다.

31장 운영 환경에서 사용할 수 있는 우선순위 판단 예#

다음은 개념적인 판단 예입니다.

요소 확인 질문
CVSS 기술적 심각도가 높은가
인터넷 노출 외부에서 직접 접근 가능한가
실제 악용 공격이 관찰되고 있는가
자산 중요도 핵심 업무 시스템인가
데이터 민감정보를 처리하는가
보완 통제 WAF·방화벽·MFA 등이 있는가
패치 영향 적용 시 장애 위험이 큰가

하나의 값만 보는 것이 아니라 여러 요소를 함께 평가합니다.

32장 단순한 패치 우선순위 예#

예를 들어 세 취약점이 있다고 하겠습니다.

취약점 CVSS 노출 실제 악용 자산
A 9.8 내부 없음 테스트
B 8.5 인터넷 있음 인증 서버
C 7.2 인터넷 없음 일반 웹

점수만 보면:

A → B → C

순서입니다.

하지만 실제 운영에서는:

B → C → A

와 같은 우선순위가 나올 수도 있습니다.

이 표는 판단 원리를 설명하기 위한 예시입니다.

33장 패치 우선순위를 결정하는 전체 흐름#

flowchart TB
    V[취약점 발견]

    C[CVSS 확인]
    VER[버전·벡터 확인]
    EXP[외부 노출 확인]
    THREAT[실제 악용 여부]
    ASSET[자산 중요도]
    CONTROL[보완 통제]
    PATCH[패치 장애 위험]

    PRIORITY[패치 우선순위]

    V --> C
    C --> VER
    VER --> EXP
    EXP --> THREAT
    THREAT --> ASSET
    ASSET --> CONTROL
    CONTROL --> PATCH
    PATCH --> PRIORITY

이 흐름이 원문의 핵심적인 운영 접근입니다.

34장 실무에서 자주 하는 실수#

CVSS 10이면 무조건 최우선이라고 생각한다#

실제 노출과 자산 중요도도 확인해야 합니다.

CVSS가 낮으면 무시한다#

공격 경로에서 다른 취약점과 연결될 수 있습니다.

CVSS 버전을 기록하지 않는다#

v3.1과 v4.0을 같은 기준으로 해석하면 안 됩니다.

벡터를 저장하지 않는다#

점수만 남으면 평가 근거를 추적하기 어렵습니다.

패치만 하고 재스캔하지 않는다#

실제로 취약점이 제거됐는지 확인할 수 없습니다.

보완 통제가 있으니 영구적으로 패치를 미룬다#

임시 통제와 근본적인 취약점 제거는 구분해야 합니다.

35장 취약점 관리 목록에 무엇을 기록하면 좋을까#

원문의 원칙을 실무 형태로 확장하면 다음과 같은 필드를 생각할 수 있습니다.

CVE
CVSS 버전
CVSS 점수
CVSS 벡터
평가 출처

영향 자산
인터넷 노출 여부
실제 악용 여부
보완 통제

패치 가능 여부
패치 영향
임시 조치

담당자
목표 완료일

재스캔 결과
서비스 검증 결과

핵심은 점수만 관리하지 않는 것입니다.

36장 임시 차단 조치도 기록해야 한다#

정식 패치를 즉시 적용할 수 없는 경우가 있습니다.

예:

패치 호환성 문제
서비스 중단 위험
벤더 패치 미제공

그럴 때는:

WAF Rule
방화벽 차단
기능 비활성화
접근 경로 제한

같은 임시 조치를 사용할 수 있습니다.

원문도 이런 임시 차단 조치를 기록하도록 제안합니다.

37장 임시 조치는 만료 조건까지 관리하는 것이 좋다#

임시 조치만 적용한 뒤 잊어버리면 취약점이 장기간 남을 수 있습니다.

따라서 개념적으로:

임시 조치
+
정식 패치 예정일
+
재평가 조건

을 함께 관리하는 것이 좋습니다.

flowchart LR
    V[취약점]
    M[임시 완화]
    P[정식 패치]
    R[재검증]

    V --> M --> P --> R

38장 CVSS 기반 취약점 관리 실전 순서#

1단계 취약점을 확인한다#

CVE와 영향을 받는 제품·버전을 확인합니다.

2단계 CVSS 버전과 점수를 확인한다#

숫자만 보지 않고 버전을 함께 확인합니다.

3단계 벡터 문자열을 확인한다#

어떤 조건에서 점수가 산출되었는지 봅니다.

4단계 실제 노출 환경을 확인한다#

인터넷에 공개되어 있는지 확인합니다.

5단계 실제 악용 여부를 확인한다#

현재 위협 환경을 봅니다.

6단계 자산 중요도를 확인한다#

업무 중단과 데이터 영향을 봅니다.

7단계 보완 통제를 확인한다#

현재 위험을 줄이고 있는 통제가 있는지 봅니다.

8단계 패치 위험을 평가한다#

서비스 장애 가능성을 확인합니다.

9단계 우선순위를 정한다#

10단계 패치 또는 임시 대응을 적용한다#

11단계 재스캔한다#

12단계 서비스 정상 여부를 검증한다#

39장 이 과정을 하나의 그림으로 보면#

flowchart TB
    A[취약점 발견]
    B[CVSS v4.0 확인]
    C[버전·벡터 확인]
    D[외부 노출 확인]
    E[실제 악용 확인]
    F[자산 중요도 분석]
    G[보완 통제 확인]
    H[패치 장애 위험 분석]
    I[우선순위 결정]
    J[패치·임시조치]
    K[재스캔]
    L[서비스 검증]

    A --> B --> C --> D --> E --> F --> G --> H --> I --> J --> K --> L

40장 CVSS v4.0 FAQ#

CVSS란 무엇인가#

소프트웨어 취약점의 기술적인 심각도를 공통 기준으로 표현하는 체계입니다.

CVSS 점수가 높으면 무조건 먼저 패치해야 하나#

아닙니다. 실제 악용 여부·외부 노출·자산 중요도·보완 통제·패치 장애 위험 등을 함께 확인해야 합니다.

CVSS v4.0에는 어떤 메트릭 그룹이 있나#

Base, Threat, Environmental, Supplemental 그룹으로 구분합니다.

Supplemental 메트릭도 최종 점수에 영향을 주나#

원문 기준으로 Supplemental 메트릭은 추가 맥락을 제공하지만 최종 점수 계산에는 영향을 주지 않습니다.

CVSS 점수와 함께 무엇을 저장해야 하나#

버전·벡터·평가 출처를 함께 저장해야 합니다.

CVSS v3.1과 v4.0 점수를 그대로 비교해도 되나#

버전별 메트릭 구조와 해석 방식에 차이가 있으므로 벡터와 버전을 함께 확인해야 합니다. 원문은 특히 사용자 상호작용 같은 차이를 놓치지 말라고 강조합니다.

점수가 낮은 취약점은 무시해도 되나#

아닙니다. 여러 취약점이 연결되어 권한 상승이나 정보 유출 같은 공격 경로를 만들 수 있습니다.

패치 후 무엇을 해야 하나#

재스캔으로 취약점 제거 여부를 확인하고 서비스 기능도 정상인지 검증해야 합니다.

핵심 정리#

CVSS v4.0은 취약점의 기술적인 심각도를 이해하기 위한 중요한 기준입니다.

하지만:

CVSS 점수
=
패치 우선순위

라고 단순하게 생각하면 안 됩니다.

CVSS v4.0은 다음 네 그룹을 구분합니다.

flowchart LR
    CVSS[CVSS v4.0]

    B[Base]
    T[Threat]
    E[Environmental]
    S[Supplemental]

    CVSS --> B
    CVSS --> T
    CVSS --> E
    CVSS --> S

그리고 실제 패치 우선순위는 다음 요소를 함께 판단해야 합니다.

CVSS 기술적 심각도
+
인터넷 노출
+
실제 악용 여부
+
자산 중요도
+
보완 통제
+
패치 장애 위험

특히 원문이 강조하는 세 가지 운영 원칙은 다음과 같습니다.

점수와 함께
버전·벡터·평가 출처를 기록한다.

외부 노출과
실제 악용 신호를 반영한다.

패치 이후
재스캔과 서비스 검증을 수행한다.

결국 CVSS의 역할은 조직 대신 결정을 내려주는 것이 아닙니다.

취약점의 기술적 심각도를 공통 언어로 제공하고, 조직이 실제 노출·위협·자산·통제 상황과 결합해 합리적인 조치 우선순위를 결정하도록 돕는 것이 핵심입니다.

이 페이지의 목차