보안 취약점 대응 순서를 CVSS 점수만으로 정하면 안 되는 이유

CVSS 점수는 취약점의 기술적 심각도를 비교하는 출발점이지, 우리 조직의 대응 순서를 자동으로 정해 주는 점수표는 아닙니다. 같은 9점대 취약점이라도 인터넷에 공개된 로그인 서버에서 이미 악용되고 있다면 내부 개발망의 높은 점수 취약점보다 먼저 막아야 합니다.

실무에서는 CVSS를 위험 신호로 사용하되 실제 악용 증거, 자산의 외부 노출, 데이터와 업무의 중요도, 적용 가능한 완화책, 복구 가능성을 함께 평가해야 합니다. 이 글의 목표는 점수를 버리는 것이 아니라 점수가 놓치는 운영 맥락을 짧은 절차로 보완하는 것입니다.

CVSS가 알려 주는 것과 알려 주지 않는 것

CVSS는 공격 경로, 필요한 권한, 사용자 상호작용, 기밀성·무결성·가용성 영향을 일정한 방식으로 표현합니다. 따라서 서로 다른 취약점을 같은 언어로 비교하고, 패치가 아직 없는 상황에서 기술적 긴급도를 설명하는 데 유용합니다. 다만 기본 점수는 특정 조직의 자산 목록이나 현재 공격 캠페인, 실제 방어 상태를 포함하지 않습니다. 점수가 높아도 취약한 제품이 설치되지 않았거나 네트워크에서 격리되어 있으면 당장의 노출은 낮을 수 있습니다. 반대로 점수가 낮더라도 공개된 관리 화면과 탈취된 계정이 결합되면 업무 중단으로 이어질 수 있습니다.

먼저 확인할 위험 신호의 순서

대응 우선순위를 정할 때 첫 질문은 “점수가 몇 점인가?”가 아니라 “지금 공격받고 있는가?”여야 합니다. 공신력 있는 악용 취약점 목록에 포함되었거나 우리 로그에서 공격 흔적이 확인되면 점수와 무관하게 긴급 트랙으로 올립니다. 그다음 인터넷에서 직접 접근 가능한지, 인증 전 단계에서 공격할 수 있는지, 어떤 자산에 배치되었는지 확인합니다. 자산이 고객 데이터, 결제, 인증, 생산 중단과 연결될수록 같은 기술 취약점의 사업 위험은 커집니다.

• 실제 악용 보고와 내부 침해 흔적이 있는지 확인합니다.

• 외부 노출, 공격 가능 경로, 방화벽과 인증 우회 여부를 확인합니다.

• 영향받는 자산이 핵심 업무·개인정보·운영 연속성과 연결되는지 표시합니다.

• 패치, 설정 변경, 격리, 기능 비활성화 중 가능한 조치를 나눕니다.

자산 맥락을 점수에 덧붙이는 방법

취약점 목록에 자산 식별자와 담당 팀만 붙여도 판단의 질이 달라집니다. 인터넷 노출 여부, 데이터 분류, 서비스의 업무 시간, 대체 가능한 경로, 마지막 백업과 복구 테스트 시점을 함께 기록합니다. 같은 라이브러리가 개발용 샌드박스와 고객 주문 서비스에 들어 있다면 하나의 취약점 티켓으로 묶지 말고 자산별 위험을 분리해야 합니다. 대응자는 각 자산에 패치 적용 시 예상 중단 시간과 사전 완화책을 적고, 임시 조치가 언제 만료되는지도 지정합니다.

팀이 합의할 수 있는 대응 단계

점수를 그대로 순위로 쓰는 대신 네 단계로 분류하면 보안팀과 서비스팀의 대화가 빨라집니다. 긴급은 악용 중이거나 핵심 자산이 외부에 노출된 경우로, 접근 차단과 패치 계획을 즉시 시작합니다. 높음은 직접 악용 증거는 없지만 공격 경로와 업무 영향이 크므로 정해진 짧은 기한 안에 수정합니다. 보통은 패치 창에 포함하되 자산 변화가 생기면 재평가합니다. 낮음은 기록과 모니터링을 유지하면서 제품 교체나 정기 업데이트에 묶습니다. 분류 이름보다 중요한 것은 각 단계의 담당자, 기한, 예외 승인자입니다.

1. 발견 시각과 영향을 받는 버전을 자산 인벤토리와 대조합니다.

2. 악용 목록·로그·탐지 규칙으로 현재 공격 여부를 확인합니다.

3. 외부 노출과 업무 영향에 따라 대응 단계를 부여합니다.

4. 패치 또는 완화책을 적용하고 검증 결과와 만료일을 기록합니다.

완료를 패치 설치로 끝내지 않기

패키지 버전이 바뀌었다는 사실만으로 대응이 끝나지 않습니다. 취약한 경로가 실제로 닫혔는지, 서비스가 새 버전을 사용 중인지, 배포되지 않은 이미지나 대기 중인 자동 확장이 남아 있지 않은지 확인해야 합니다. 이후 같은 공격 시도가 탐지되는지 로그와 경보를 살피고, 임시 완화책을 제거할 조건을 정합니다. 정기 검토에서는 자산이 새로 노출되었는지, 공격 정보가 바뀌었는지, 우선순위가 뒤집혔는지를 다시 계산합니다.

좋은 취약점 대응은 숫자가 가장 큰 항목을 기계적으로 고르는 일이 아닙니다. 점수로 기술적 위험을 출발시키고, 악용 가능성과 자산 맥락으로 순서를 조정하며, 검증 가능한 완료 조건까지 남기는 운영 과정입니다. 이 기록이 쌓이면 보안팀은 왜 먼저 막았는지 설명할 수 있고 서비스팀은 무엇을 언제 끝내야 하는지 알 수 있습니다.