‘?? CVE’?? ??? ?? ?????? ????? ??? ?? ???, ???? ?? ?? ??? ????? ????? ?? ???? ??. Credit: Excelworld / Shutterstock 만약 벤더가 ‘제로 CVE’를 실현할 수 있다고 주장한다면, 주저 없이 자리를 벗어나는 게 상책일 수 있다. CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)를 0개로 만드는 것은 현실적으로 불가능할 뿐 아니라, 굳이 시도할 필요가 없는 목표이기 때문이다. 오히려 이 목표에 집착하는 과정에서 거시적인 보안 관점을 놓친다면 시스템의 취약성은 더 커질 수 있다. ‘제로 CVE’는 종종 사이버 보안의 이상향으로 회자된다. 소프트웨어에 알려진 보안 취약점이 전혀 없는 상태를 의미하며, 최근에는 같은 규제 강화 흐름과 일부 기술 벤더의 마케팅 전략이 맞물려 이 목표가 부각되고 있다. 그래도 “최소한 CVE를 줄이는 것이 좋지 않은가?”, “알려진 취약점이라면 항상 해결하려고 노력해야 하는 것 아닌가?”라는 생각이 들 수 있다. 그렇기도 하고 아니기도 하다. 보안 엔지니어링은 본질적으로 ‘제로섬 게임’이기 때문에, 우선순위에 맞춰 타협해야 하는 부분이 항상 생긴다. CVE 제거 집착의 함정 항상 타협할 부분이 생기는 이유는 분명하다. CNA(CVE Numbering Authority)의 에 따르면 CVE ID는 소프트웨어나 하드웨어 벤더가 해당 버그의 존재를 인정하고, 그 버그가 보안에 부정적인 영향을 준다는 사실을 확인했다는 의미이기 때문이다. 또한 해당 취약점을 보고한 측이 버그의 영향을 입증한 취약점 보고서를 공유했음을 의미할 수도 있다. 이 보고서는 해당 버그가 시스템의 보안 정책을 위반한다는 사실도 함께 설명한다. 즉, 이는 취약점이 실제로 존재하며 인지된 상태라는 의미다. 이론적으로는 당연히 패치하는 것이 합리적으로 보인다. 하지만 ‘제로 CVE’를 실현한다는 목표 자체에 근본적인 문제가 존재한다. 대규모 시스템에서 CVE를 0으로 만드는 유일한 방법은 항상 가장 최신 업스트림 코드로 업그레이드하는 것뿐이다. 최신 보안 패치를 적용할 수 있다는 장점이 있지만, 동시에 새로운 기능, 신규 버그, 회귀 오류, 비호환성, 구성 변경 등 새로운 리스크를 동반한다. 다시 말해, 코드를 수정할 때마다 새로운 취약점이나 불안정성이 유입될 가능성이 있으며, 이로 인해 기존 취약점보다 더 큰 보안 위협이 발생할 수 있다. 모든 소프트웨어 결함이 반드시 보안 위협이 되는 것은 아니다. 특히 최근 CVE 수가 급증하고 있는 현실을 감안하면 그 중 상당수는 심각한 위협이 아닐 수 있다. 예를 들어 2023년에는 약 3만 건의 CVE가 보고됐고, 2024년에는 약 4만 건으로 증가했다. CVE 인플레이션 현상에는 여러 요인이 작용한다. 개발자 수 증가, AI 기반 코드 생성기 사용 확대, 신규 코드 양의 증가, 코드 복잡성 심화, 보안 연구자와 해커 모두에게 제공되는 혜택 등이 그 예다. 특히 학생이나 보안 연구자들은 금전적 보상, 학문적 성과, 개인 명성 강화 등 여러 이득을 얻을 수 있기에 CVE를 발굴 및 보고하는 데 열정적으로 참여하고 있다. 더 우려스러운 문제는 AI 경쟁이 심화될수록 CVE 탐지 속도가 급격히 가속화될 가능성이 크다는 점이다. AI는 CVE를 발견하고 패치하는 데 모두 활용될 수 있어 결국 AI 간의 ‘무기 경쟁’이 벌어질 가능성이 있다. 이로 인해 개발 환경에서는 지나치게 빠르고 비합리적으로 코드를 변경해야 하는 상황이 벌어질 수 있다. 이미 하는 업스트림 프로젝트도 존재하며, 이런 상황은 결국 의도치 않게 개발자에게 ‘서비스 거부(DoS) 공격’처럼 작용할 수 있다. 여기에 더해, 보안 스캐닝 소프트웨어 벤더들이 자사 제품을 판매할 때 스캔 대상 소프트웨어에서 CVE와 같은 ‘문제점’을 많이 찾을수록 유리하다는 점도 지적할 만하다. 스캐너가 더 많은 문제를 발견할수록 ‘이 도구가 더 우수하다’는 인식을 심어주는 것이다. 실제로도 유효할까? 물론 아니다. 이는 가치의 ‘왜곡된 증명’에 가깝다. 현재 보안 생태계는 위험도가 매우 낮은 경우에도 더 많은 CVE를 발굴하고 이를 강조하는 방향으로 움직이고 있다. 보안 실효성과 무관한 CVE 추적 CVE에 집착하는 접근이 비생산적일 수밖에 없는 이유는 그 외에도 많다. 우선 일부 CVE는 정보가 충분하지 않거나 불완전한 데이터에 기반한다. 따라서 정확한 평가나 실제 위험도 해석에 혼선을 줄 수 있다. 또한 CVE의 위험도는 시간에 따라 바뀐다. 예를 들어, 어떤 취약점이 실제로 악용되는 사례가 확인되면 그 위험도가 높아지기도 하고, 반대로 악용이 거의 불가능한 CVE는 시간이 지나면서 무의미해질 수도 있다. 설정을 통해 해당 취약점이 무력화되기도 한다. 더욱이 CVE는 취약점이 코드 유형에 따라 영향력이 달라진다는 점을 반영하지 않는다. 셸 프로그램, 데몬, 라이브러리 등은 각기 다른 위험도를 가지며, 모든 취약점을 동일 선상에서 다루는 것은 부적절하다. CVE는 또한 다계층 방어 체계(defense in depth)의 유무, 영향을 받는 시스템의 중요도, 특정 환경에서의 악용 가능성 등도 반영하지 않는다. CVE의 중요성을 과소평가하려는 것은 아니다. 실제로 , 이른바 ‘’는 매우 심각한 취약점이었다. 이 치명적인 버그는 2013년부터 코드 안에 존재했지만 2021년이 되어서야 발견됐다. 이 8년 동안 취약한 버전의 로그4j는 광범위하게 사용되면서 공격자에게 매우 매력적인 타깃이 됐다. 이처럼 많은 CVE가 상황에 따라 매우 높은 위험 신호로 작용할 수 있다. 하지만 방대한 보안 인프라와 업계 전반이 CVE 발굴에 총력을 기울이고 있음에도 불구하고 로그4j는 수년간 누구도 찾아내지 못했다. 이는 ‘제로 CVE’라는 개념이 얼마나 허상에 가까운지를 여실히 보여준다. 발견되지 않은 취약점이 언제나 존재하는 상황에서, 우선순위가 낮은 CVE에 집착하며 다계층 방어 체계를 구축하지 않는다면 심각한 보안 실책이 될 수 있다. 핵심은 ‘다계층 방어 체계’ 보고된 취약점을 패치하는 일은 여전히 중요하다. 그러나 오늘날 조직이 마주한 다양하고 복잡한 보안 위협을 단 하나의 보안 정책이나 기술적 제어 수단만으로 막을 수는 없다. 패치는 어디까지나 광범위한 방어 체계 안의 한 계층일 뿐이다. 악용 가능성이 낮은 CVE에 집착하기보다는, 전반적인 다계층 방어 전략을 구축하는 것이 중요하다. 기업은 아직 발견되지 않은 실질적 위험 요소가 악용되지 않도록 인프라를 설계하고, 만일 악용되더라도 다른 기술적 제어 수단을 통해 피해를 최소화하거나 차단할 수 있도록 준비해야 한다. CVE를 추적하고 패치하는 것이 곧 ‘하드닝(hardening)’은 아니다. 진정한 하드닝이란 보안 위협을 최소화하거나 제거하기 위해 체계적으로 일련의 보안 제어 수단을 구현하는 것을 의미한다. 예를 들어 , 보안 강화 바이너리(, 등), 커널 보안 기능 같은 통제 조치는 취약점이 존재하더라도 그 영향을 억제하거나 악용 자체를 불가능하게 만들 수 있다. 실제로 전체 시스템을 위협할 수 있는 runc 취약점()의 악용이 셀리눅스에 의해 차단된 사례가 있다. 보안 강화의 핵심은 최선의 실천 방법을 따르는 데 있다. 특히 컨테이너 환경에서는 해당 플랫폼의 특성과, 컨테이너 기반 배포에 적합한 보안 운영 원칙을 반드시 고려해야 한다. 예를 들어 티켓 시스템, DNS, 웹서버, 위키 등 서로 다른 서비스를 하나의 컨테이너에 통합해 운영하는 방식은 피해야 한다. 또한 셸 접근을 허용하는 SSHD를 실행하지 않아야 하며, 플랫폼 자체가 셸 접근을 차단하도록 하드닝되어 있어야 한다. 만약 단일 애플리케이션이 자바 기반 웹스택으로 구성돼 있다면, 파이썬 취약점은 실제로 아무런 영향을 주지 않을 수 있다. 이런 맥락 기반의 보안 판단도 중요하다. 기술적 취약점만으로 보안을 판단해서는 안 되는 또 다른 이유는, 이를 완전히 우회할 수 있는 공격 방식들이 존재하기 때문이다. 대표적인 예가 계정 기반 및 사회 공학 공격이다. 공격자는 계정 인증정보, API 키, 세션 쿠키, 토큰 등을 노려 약한 인증 구조를 악용하거나 내부 직원을 속여 접근 권한을 얻는다. 합법적인 접근 권한을 가진 내부자의 악의적인 행동도 여전히 주요 위협으로 꼽힌다. 이제 공격자는 네트워크 연결 스토리지(NAS), 백업 시스템, 관리형 엔드포인트, 도메인 컨트롤러, 심지어는 기술 지원이 종료된 소프트웨어까지도 주요 타깃으로 삼는다. 이는 진입 지점 또는 중간 단계로 활용되며, 궁극적으로는 안전한 시스템 내부로 침투할 수 있게 만든다. 또한 잘못된 구성(Misconfiguration)은 최신 보안 패치가 적용된 시스템에서도 침해를 유발하는 주요 원인 중 하나로 꼽힌다. 보안 전략을 수립하기 아무리 많은 CVE를 추적하고 패치해도, 심지어 ‘제로 CVE’ 상태에 도달하더라도 현실적인 보안 위협을 완전히 차단할 수는 없다. 실제로 대시보드에 ‘CVE 0건’으로 표시된 소프트웨어나 컨테이너 이미지조차 안전하다는 보장은 없다. 더 큰 문제는 ‘제로 CVE’ 상태가 오히려 잘못된 안도감을 유발해 경계심을 낮추거나, 보다 실질적이고 효과적인 보안 영역에 대한 투자를 소홀하게 만들 수 있다는 점이다. 발견되지 않은 취약점은 언제나 존재하며, 이 중 일부는 이미 알려진 취약점보다 훨씬 더 위험할 수 있다. ‘제로 CVE’라는 약속은 상위 벤더의 패치를 가능한 한 빨리 적용하는 데 초점을 맞추는 것이지, 근본적인 위험 제거를 의미하는 것이 아니다. CVE 개수만을 기준으로 보안을 판단하는 방식은 지나치게 단순하며, ‘나무만 보다가 숲을 보지 못하는’ 상황으로 이어질 수 있다. 숫자를 세는 일은 쉽지만, 자신도 모르게 그 과정에 집착하게 될 수 있다. 실제로 효과적인 보안은 문서상의 체크박스를 채우는 일이 아니라 실질적인 보안 운영과 위험 완화 사이의 균형을 맞추는 ‘리스크 기반 접근 방식’이다. 기업이 ‘제로 CVE’를 달성하기 위해 투입하는 시간과 비용은, 맥락과 우선순위에 기반한 보안 전략 수립에 더 효과적으로 쓸 수 있다. 다계층 방어 체계, 강력한 ID 및 접근 관리, 안전한 구성 설정, 런타임 보호 기능은 오늘날의 보안 환경에서 반드시 갖춰야 할 핵심 요소다. ‘제로 CVE’는 일부 컴플라이언스 요건을 충족하는 데는 도움이 될 수 있지만, 기업 보안이 직면한 빠르게 진화하는 총체적 위협에 근본적인 해법이 되지는 못한다.dl-ciokorea@foundryco.com ???? ???? ??? ??? IT ??? ???? ??? ????! ??? ??? ??? ?????. ????