보안 조직이 관리해야 하는 취약점은 계속 늘어나고 있지만, 모든 취약점을 같은 우선순위로 대응하는 것은 현실적으로 불가능합니다. 정기적인 취약점 진단을 수행하는 대부분의 기업은 수천 건의 결과를 받아보지만, 실제 운영 환경에서는 어떤 취약점을 먼저 조치해야 하는지 판단하는 과정에서 많은 어려움을 겪습니다.
월요일 아침 취약점 스캔 결과를 확인하면 수천 개의 항목이 보고되고, 그중 상당수가 Critical 등급으로 분류되는 경우도 드물지 않습니다. 그러나 제한된 인력과 운영 일정 안에서 모든 취약점을 즉시 패치하는 것은 현실적으로 쉽지 않습니다. 결국 우선순위를 제대로 결정하지 못하면 실제 위험도가 높은 취약점보다 중요도가 낮은 항목에 시간을 소비하거나, 반대로 반드시 먼저 대응해야 하는 취약점을 놓치는 상황이 발생할 수 있습니다.
이처럼 취약점 관리의 핵심은 얼마나 많은 취약점을 발견했는가가 아니라 어떤 취약점을 먼저 해결해야 하는가에 있습니다. 단순히 CVSS(Common Vulnerability Scoring System) 점수만 기준으로 삼기보다 실제 악용 가능성, 자산의 중요도, 비즈니스 영향도, 서비스 노출 여부 등을 함께 고려하는 리스크 기반 취약점 우선순위 선정(Risk-Based Vulnerability Prioritization) 이 점점 더 중요한 이유입니다.
이번 글에서는 CVSS 중심의 전통적인 취약점 관리 방식이 갖는 한계를 살펴보고, TuxCare가 제안하는 리스크 기반 취약점 우선순위 선정 방법과 보다 효율적인 패치 전략을 함께 알아보겠습니다.
왜 기존의 취약점 진단 프로그램은 실패하는가?
많은 조직이 고성능 취약점 스캐너를 도입하지만, 기대한 만큼 보안 수준이 향상되지 않는 경우가 적지 않습니다. 문제는 도구 자체보다 취약점 관리 프로세스에 있습니다.
취약점 진단이 분기별 또는 반기별 일회성 작업으로 끝나면, 결과는 방대한 보고서 형태로만 남게 됩니다. 수천 개의 취약점 목록과 수백 페이지에 이르는 PDF 보고서는 현재 어떤 항목이 실제로 위험한지, 무엇부터 조치해야 하는지를 알려주지 못합니다. 이러한 환경에서는 보안팀과 운영팀 모두 경고(Alert)에 피로감을 느끼게 되고, 우선적으로 대응해야 하는 취약점까지 뒤로 밀리는 상황이 반복됩니다. 결국 취약점을 발견하는 것과 실제 위험을 줄이는 것 사이에는 상당한 간극이 생깁니다.
TuxCare 역시 취약점 관리는 일회성 프로젝트가 아니라 지속적으로 반복되는 운영 프로세스여야 한다고 설명합니다. 지속적인 스캔과 우선순위 선정, 조치, 검증이 반복되어야 실제 보안 수준을 향상시킬 수 있습니다.
기존 취약점 관리 방식의 대표적인 한계는 다음과 같습니다.
- 분기 또는 반기 단위의 일회성 취약점 진단
- 자산의 중요도와 비즈니스 맥락이 반영되지 않은 결과
- 우선순위 기준 없이 나열되는 방대한 취약점 목록
- 보안팀과 운영팀 간 조치 기준의 불일치
- 조치 이후 검증까지 이어지는 운영 프로세스의 부재
취약점 관리와 패치 관리는 같은 개념이 아니다
취약점 관리(Vulnerability Management)와 패치 관리(Patch Management)는 혼용되는 경우가 많지만, 실제로는 서로 다른 목적을 가진 운영 프로세스입니다.
취약점 관리는 자산을 식별하고, 취약점을 발견하며, 위험도를 평가하고, 우선순위를 결정한 뒤 조치 결과를 다시 검증하는 전체 라이프사이클을 의미합니다. 반면 패치 관리는 운영체제와 애플리케이션에 제공되는 보안 업데이트를 계획하고 테스트한 뒤 실제 운영 환경에 안전하게 배포하는 활동에 집중합니다.
즉, 취약점 관리는 무엇을 먼저 해결해야 하는지를 결정하는 과정이고, 패치 관리는 결정된 항목을 실제 운영 환경에 적용하는 과정이라고 이해할 수 있습니다.
| 구분 | 취약점 관리 | 패치 관리 |
| 목적 | 위험을 지속적으로 관리 | 보안 업데이트 적용 |
| 관리 범위 | 자산 식별부터 검증까지 전체 라이프사이클 | 패치 테스트 및 배포 |
| 핵심 질문 | 무엇을 먼저 해결해야 하는가? | 언제, 어떻게 적용할 것인가? |
| 결과 | 우선순위 기반 위험 감소 | 알려진 취약점 제거 |
실전 취약점 관리를 위한 운영 프로세스
효율적인 취약점 관리는 단순히 스캐너를 실행하는 것으로 끝나지 않습니다. 지속적으로 반복되는 운영 프로세스를 구축해야 하며, 크게 네 단계로 정리할 수 있습니다.
자산을 정확하게 식별한다
취약점을 관리하려면 먼저 어떤 자산이 존재하는지 알아야 합니다. 서버, 컨테이너, 클라우드 워크로드, 애플리케이션 등 관리 대상이 명확하지 않다면 취약점 우선순위 역시 올바르게 결정할 수 없습니다. 자산 인벤토리가 정확하지 않으면 중요한 시스템을 놓치거나, 이미 사용하지 않는 자산을 계속 관리 대상으로 유지하는 비효율이 발생합니다. 취약점 관리의 출발점은 항상 신뢰할 수 있는 자산 목록입니다.
인증 기반 스캔을 수행한다
취약점을 발견하는 단계에서는 인증 기반 스캔(Authenticated Scan)을 수행하는 것이 중요합니다. 인증 기반 스캔은 운영체제와 설치된 패키지, 설정 정보를 함께 확인하기 때문에 단순한 네트워크 스캔보다 훨씬 정확한 결과를 제공합니다. 또한 네트워크뿐 아니라 호스트, 컨테이너 이미지, 애플리케이션 계층까지 포함하는 지속적인 스캔 체계를 구축하는 것이 바람직합니다.
스캔 결과를 그대로 신뢰해서는 안 된다
리눅스 환경에서는 스캔 결과를 해석할 때 특히 주의해야 합니다. Red Hat, Canonical, SUSE와 같은 주요 배포판은 백포팅(Backport) 방식을 사용하기 때문에 패키지 버전이 변경되지 않더라도 보안 수정 사항이 이미 적용된 경우가 있습니다.
이러한 특성을 이해하지 못하는 스캐너는 이미 해결된 취약점까지 계속 탐지하여 불필요한 오탐(False Positive)을 발생시킬 수 있습니다.
오탐이 많아질수록 우선순위 선정 자체가 왜곡되고, 실제로 대응해야 하는 취약점을 놓칠 가능성도 커집니다. 따라서 취약점 스캔의 정확도는 스캔 주기만큼이나 중요한 요소입니다.
조치 이후 반드시 다시 검증한다
취약점 관리의 마지막 단계는 패치 이후의 검증입니다. 패치나 완화 조치를 적용한 이후에는 동일한 환경을 다시 점검하여 취약점이 실제로 해결되었는지 확인해야 합니다.
이러한 반복적인 검증 과정이 있어야 취약점 관리는 일회성 작업이 아니라 지속적인 보안 운영 프로세스로 자리 잡을 수 있습니다.
CVSS 점수와 실제 위협 리스크의 위험한 불일치
취약점 우선순위를 결정할 때 가장 널리 활용되는 기준은 CVSS(Common Vulnerability Scoring System) 입니다. CVSS는 취약점의 기술적 심각도를 표준화된 방식으로 평가하는 데 유용한 지표이지만, 실제 운영 환경에서 어떤 취약점을 먼저 대응해야 하는지까지 판단해 주지는 않습니다.
그 이유는 CVSS Base Score가 취약점 자체의 특성을 평가할 뿐, 조직의 운영 환경이나 비즈니스 맥락을 반영하지 않기 때문입니다.
예를 들어 동일한 CVSS 9.8 취약점이라도 외부 인터넷에 직접 노출된 서비스에서 발견된 경우와 내부망에서만 운영되는 시스템에서 발견된 경우는 실제 위험도가 크게 달라질 수 있습니다. 반대로 CVSS 점수가 상대적으로 낮더라도 인터넷에 공개되어 있고 이미 공격에 활용되고 있는 취약점이라면 훨씬 높은 우선순위로 대응해야 합니다.
결국 CVSS는 취약점의 심각도(Severity) 를 나타내는 기준일 뿐, 실제 위험도(Risk) 를 의미하지는 않습니다.
실무에서는 이러한 차이를 이해하지 못한 채 CVSS 점수만 기준으로 패치 우선순위를 결정하는 경우가 적지 않습니다. 그러나 실제 공격자는 CVSS 점수가 높은 취약점을 순서대로 공격하지 않습니다. 공격이 쉬운지, 인터넷에서 접근 가능한지, 이미 익스플로잇이 공개되었는지와 같은 요소를 종합적으로 고려해 공격 대상을 선택합니다.
이 때문에 최근의 취약점 관리는 CVSS를 출발점으로 활용하되, 실제 악용 가능성과 운영 환경을 함께 고려하는 리스크 기반 접근 방식(Risk-Based Vulnerability Management) 으로 빠르게 전환되고 있습니다.
리스크 기반 우선순위 선정을 위한 핵심 요소
효율적인 취약점 관리는 단순히 취약점 개수를 줄이는 것이 아니라 실제 위험을 얼마나 효과적으로 감소시켰는지를 기준으로 평가해야 합니다. 이를 위해서는 기술적인 정보뿐 아니라 자산의 중요도와 운영 환경을 함께 고려하는 리스크 기반 우선순위 선정 체계가 필요합니다.
EPSS(Exploit Prediction Scoring System)
가장 먼저 확인해야 할 요소는 실제 악용 가능성입니다. EPSS는 특정 취약점이 가까운 시일 내 실제 공격에 사용될 가능성을 예측하는 지표입니다. CVSS가 취약점 자체의 심각도를 평가한다면, EPSS는 공격자가 해당 취약점을 사용할 가능성에 초점을 맞춥니다.
CVSS 점수가 높더라도 실제 공격 가능성이 매우 낮은 취약점이 있는 반면, CVSS 점수는 상대적으로 낮지만 활발하게 악용되는 취약점도 존재합니다. 이러한 차이를 보완하기 위해 EPSS를 함께 활용하면 보다 현실적인 우선순위를 결정할 수 있습니다.
CISA KEV(Known Exploited Vulnerabilities)
미국 CISA(Cybersecurity and Infrastructure Security Agency)가 제공하는 KEV 카탈로그는 실제 공격 사례가 확인된 취약점을 지속적으로 공개하고 있습니다. KEV에 포함된 취약점은 이미 공격자가 적극적으로 활용하고 있는 사례가 확인된 만큼, 일반적인 취약점보다 우선적으로 대응하는 것이 바람직합니다.
취약점 관리 프로세스에 KEV 정보를 함께 반영하면 현재 가장 시급하게 조치해야 하는 항목을 빠르게 식별할 수 있습니다.
자산의 중요도(Asset Criticality)
동일한 취약점이라도 어떤 시스템에서 발견되었는지에 따라 우선순위는 달라집니다. 예를 들어 인증 시스템, 고객 데이터를 처리하는 서버, 핵심 업무 애플리케이션에서 발견된 취약점은 개발 환경이나 테스트 서버보다 높은 우선순위를 가져야 합니다.
따라서 취약점 관리에서는 기술적인 심각도뿐 아니라 비즈니스 영향도를 함께 고려해야 합니다.
노출 여부(Exposure)
취약점이 존재하는 시스템이 인터넷에 직접 노출되어 있는지, 내부망에서만 접근 가능한지 역시 중요한 판단 기준입니다. 외부에서 직접 접근 가능한 시스템은 공격 표면(Attack Surface)이 넓기 때문에 상대적으로 높은 위험도를 가집니다. 반대로 네트워크 분리나 접근 제어가 적용된 환경에서는 동일한 취약점이라도 실제 위험 수준이 낮아질 수 있습니다.
운영 환경(Business Context)
취약점은 조직의 운영 방식과도 밀접하게 연결됩니다. 24시간 서비스를 제공하는 금융 시스템과 개발 테스트 환경은 동일한 취약점이라도 대응 방식이 달라질 수밖에 없습니다. 서비스 중단이 허용되는지, 규제 요구사항이 있는지, 고객 서비스에 미치는 영향은 어느 정도인지 등을 함께 고려해야 현실적인 우선순위를 수립할 수 있습니다.
다양한 정보를 함께 분석해야 실제 위험을 판단할 수 있다
리스크 기반 취약점 관리는 하나의 점수만으로 우선순위를 결정하지 않습니다.
- CVSS
- EPSS
- CISA KEV
- 자산 중요도
- 인터넷 노출 여부
- 비즈니스 영향도
이러한 요소를 함께 분석해야 실제로 우선 대응해야 하는 취약점을 식별할 수 있습니다. 이 과정은 제한된 보안 인력과 운영 시간을 보다 효율적으로 활용하는 데에도 큰 도움이 됩니다.
결국 취약점 관리의 핵심은 더 많은 취약점을 찾는 것이 아니라 실제 위험이 높은 취약점을 먼저 식별하는 것입니다. 하지만 우선순위를 결정했다고 해서 문제가 모두 해결되는 것은 아닙니다. 실제 운영 환경에서는 패치를 언제, 어떻게 적용할 것인지가 또 다른 과제로 남습니다. 다음 글에서는 이러한 과제를 해결하기 위한 패치 전략과 라이브 패칭(Live Patching)에 대해 살펴보겠습니다.
원문 출처:
https://tuxcare.com/blog/vulnerability-assessment/
https://tuxcare.com/blog/vulnerability-prioritization/
https://tuxcare.com/blog/vulnerability-patching/
참고 링크:
