0-day는 무섭지만 드뭅니다. 당신을 실제로 무너뜨리는 것은, 패치가 나왔는데도 적용하지 않은 n-day입니다.
들어가며: 끝나지 않는 물줄기
보안 뉴스를 한 달만 들여다보면, 한 가지 사실에 압도됩니다. 심각한 취약점이 끊임없이 발표됩니다. CVSS 9점, 때로는 만점인 10점짜리 취약점이 매주, 어떤 주에는 여러 건씩 공개됩니다. 널리 쓰이는 운영체제, 웹 서버, 프레임워크, 라이브러리, 네트워크 장비 — 그 어떤 것도 예외가 아닙니다.
이 끝없는 물줄기 앞에서 운영자가 보이는 반응은 대개 둘 중 하나입니다. 하나는 마비입니다. "이렇게 많은데 어떻게 다 따라가나" 하고 포기해 버리는 것입니다. 다른 하나는 무지입니다. 애초에 자신의 시스템에 어떤 취약점이 있는지조차 모른 채, 그저 아무 일 없기를 바라는 것입니다. 두 반응 모두 위험합니다.
3장에서 우리는 AI가 취약점의 무기화 속도를 높인다는 것을 보았습니다. 이 장은 그 무기화의 대상, 즉 CVE 그 자체를 다룹니다. CVE란 무엇이고, 그 심각도 점수를 어떻게 읽으며, 공개된 취약점이 어떻게 실제 공격으로 이어지는지, 그리고 무엇보다 이 홍수 속에서 방어자가 어떻게 우선순위를 잡고 살아남는지를 살펴봅니다.
핵심 메시지를 미리 말하면 이렇습니다. 모든 취약점을 막을 수는 없지만, 모든 취약점이 똑같이 위험한 것도 아닙니다. 방어의 기술은 전부를 막는 것이 아니라, 무엇이 진짜 위험한지를 가려내어 거기에 자원을 집중하는 것입니다. 그리고 그 핵심에는, 화려한 0-day가 아니라 평범하고 흔한 n-day가 있습니다.
4.1 CVE와 CVSS: 공통 언어 이해하기
먼저 용어를 정리하겠습니다. 이 두 약어는 보안의 일상 언어이므로 정확히 알아 둘 필요가 있습니다.
CVE란 무엇인가
CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)는 공개적으로 알려진 보안 취약점에 부여되는 고유한 식별 번호입니다. CVE-연도-일련번호 형식을 가집니다. 예를 들어 어떤 소프트웨어에서 발견된 특정 취약점에 CVE-2025-XXXXX 같은 번호가 붙는 식입니다.
CVE의 목적은 단순하지만 중요합니다. 전 세계가 같은 취약점을 같은 이름으로 부르게 하는 것입니다. 이 공통 식별자가 없다면, 같은 취약점을 두고 회사마다, 연구자마다 다른 이름을 써서 혼란이 생길 것입니다. CVE 번호 하나로, 보안 연구자, 소프트웨어 공급자, 방어자, 그리고 공격자까지 모두가 정확히 같은 취약점을 지칭할 수 있습니다.
여기서 중요한 점은, CVE는 양날의 검이라는 것입니다. 방어자가 "내가 막아야 할 취약점"을 명확히 식별하게 해 주는 동시에, 공격자에게 "내가 노릴 취약점"의 목록을 제공합니다. CVE가 공개되는 순간, 그 정보는 방어자와 공격자 모두에게 동시에 주어집니다. 이 동시성이 4.3에서 다룰 "경쟁"의 출발점입니다.
CVE 번호 하나가 손에 들어왔을 때 어디서 찾아보면 되는지부터 알아 둡시다. CVE 번호의 공식 원본은 MITRE가 운영하는 CVE.org이고, 거기에 CVSS 점수·영향받는 버전·참고 링크 등 살을 붙여 정리한 곳이 미국 표준기관 NIST의 NVD(National Vulnerability Database)입니다. 실무에서는 보통 CVE-2021-44228 같은 번호를 NVD에서 검색해 "내가 쓰는 버전이 영향 범위에 드는가"를 먼저 확인합니다. 둘 다 무료이고 회원 가입도 필요 없습니다.
CVSS란 무엇인가
CVSS(Common Vulnerability Scoring System, 공통 취약점 점수 체계)는 각 취약점의 심각도를 0부터 10까지의 숫자로 표현하는 표준 체계입니다. 점수가 높을수록 심각합니다. 대략적인 구간은 다음과 같이 나뉩니다.
- 9.0 ~ 10.0: 치명적(Critical). 즉각적이고 심각한 위협. 종종 인증 없이 원격에서 시스템을 장악할 수 있는 수준.
- 7.0 ~ 8.9: 높음(High). 심각한 위협. 우선적으로 대응해야 함.
- 4.0 ~ 6.9: 중간(Medium). 무시할 수 없으나 상대적으로 덜 급함.
- 0.1 ~ 3.9: 낮음(Low). 영향이 제한적.
CVSS 점수는 여러 요소를 종합하여 산출됩니다. 공격이 어디서 가능한지(네트워크를 통해 원격으로 가능한가, 아니면 물리적 접근이 필요한가), 공격이 얼마나 복잡한지, 공격에 권한이 필요한지, 사용자의 상호작용이 필요한지, 그리고 성공 시 기밀성·무결성·가용성에 미치는 영향이 얼마나 큰지 등입니다.
직관적으로, 가장 무서운 조합은 이렇습니다. 네트워크를 통해 원격으로, 인증 없이, 사용자 상호작용 없이, 시스템을 완전히 장악할 수 있는 취약점입니다. 이런 취약점이 만점에 가까운 점수를 받습니다. 공격자가 그저 인터넷 너머에서 패킷 몇 개를 보내는 것만으로 서버를 손에 넣을 수 있다는 뜻이기 때문입니다. 1장에서 본 자동화된 대량 스캔이 가장 사랑하는 먹잇감이 바로 이 유형입니다.
4.2 CVSS 점수의 함정: 숫자만 보면 안 되는 이유
CVSS는 유용한 공통 언어이지만, 그 숫자만 보고 우선순위를 정하면 심각한 오판에 빠질 수 있습니다. 이것은 많은 운영자가 놓치는 부분이므로 강조하겠습니다.
함정 1: 점수는 "당신의 맥락"을 모른다
CVSS 기본 점수는 취약점 자체의 일반적 특성을 평가한 것입니다. 그것은 당신의 환경에서 그 취약점이 실제로 얼마나 위험한지를 말해 주지 않습니다.
예를 들어, CVSS 10점짜리 취약점이 어떤 소프트웨어에 있다고 합시다. 그런데 그 소프트웨어가 당신의 시스템에서는 외부와 단절된 내부망에만 있고, 취약한 기능 자체가 비활성화되어 있다면, 그 10점은 당신에게는 훨씬 덜 위험합니다. 반대로, CVSS 7점짜리 취약점이라도, 그것이 당신의 가장 중요한 자산에 직접 노출된 채로 있다면, 그 7점이 다른 9점보다 당신에게는 더 급합니다.
그러므로 우선순위는 "CVSS 점수 순서"가 아니라 "당신의 맥락에서의 실제 위험 순서"여야 합니다. 점수는 출발점이지 결론이 아닙니다.
함정 2: 점수는 "실제 악용 여부"를 모른다
이것이 더 중요한 함정입니다. CVSS 점수는 취약점의 잠재적 심각도를 나타낼 뿐, 그 취약점이 현재 실제로 공격에 쓰이고 있는지를 반영하지 않습니다.
현실에서, 공개된 수많은 고득점 취약점 중 실제로 활발히 악용되는 것은 일부입니다. 어떤 9점 취약점은 익스플로잇이 공개되어 자동화 공격에 광범위하게 쓰이는 반면, 다른 9점 취약점은 이론적으로는 위험하지만 실제 공격은 거의 관찰되지 않을 수 있습니다.
방어자의 자원은 한정되어 있습니다. 그렇다면 "점수는 높지만 아무도 안 쓰는 취약점"보다 "점수는 조금 낮아도 지금 활발히 악용되는 취약점"을 먼저 막는 것이 합리적입니다. 실제로 보안 업계에서는 "현재 악용되고 있는 알려진 취약점" 목록을 별도로 관리하며 우선순위를 높입니다.
그 목록을 가장 권위 있게 공개하는 곳이 미국 사이버보안 기관 CISA의 KEV(Known Exploited Vulnerabilities, 실제 악용 취약점 카탈로그)입니다. 이름 그대로, "이론상 위험한" 것이 아니라 실제 공격에 쓰인 것이 확인된 취약점만 추려 모아 둔 목록입니다. 미국 연방기관에는 KEV에 오른 취약점을 기한 내 의무적으로 패치하도록 강제할 정도로 신뢰받는 기준입니다. 당신이 쓰는 제품 이름으로 이 목록을 한 번 검색해 보고, 거기 올라 있는 CVE가 있다면 CVSS 점수와 무관하게 최우선으로 처리하면 됩니다. 무엇이 실제로 공격받고 있는지를 아는 것이, 단순 점수보다 훨씬 실용적인 우선순위 기준입니다.
함정 3: 점수는 "연쇄"를 반영하지 못한다
공격은 종종 단일 취약점이 아니라 여러 취약점의 연쇄로 이루어집니다. 각각은 점수가 낮은 취약점이라도, 그것들을 엮으면 치명적인 공격이 될 수 있습니다. 낮은 점수의 정보 노출 취약점으로 시스템 정보를 얻고, 그것을 발판으로 중간 점수의 다른 취약점을 악용하여 권한을 얻는 식입니다. CVSS는 개별 취약점을 평가하므로, 이런 연쇄의 위험을 온전히 담지 못합니다.
종합하면: CVSS 점수는 분류의 첫 단계로는 유용하지만, 그것만으로 우선순위를 결정해서는 안 됩니다. 당신의 맥락(노출 여부, 자산의 중요도), 실제 악용 여부, 그리고 연쇄 가능성을 함께 고려해야 합니다. 4.5에서 이 우선순위화를 실용적으로 정리하겠습니다.
4.3 무기화의 타임라인: 공개에서 공격까지의 경쟁
CVE가 공개되면 무슨 일이 벌어질까요? 방어자와 공격자 사이에 시간을 둘러싼 경쟁이 시작됩니다. 이 경쟁의 구조를 이해하는 것이 패치 전략의 핵심입니다.
취약점의 생애주기
하나의 취약점은 대략 다음과 같은 단계를 거칩니다.
발견. 누군가가 취약점을 처음 발견합니다. 그 누군가가 선의의 연구자일 수도, 소프트웨어 공급자 자신일 수도, 또는 공격자일 수도 있습니다. 누가 먼저 발견하느냐가 이후 전개를 크게 좌우합니다.
비공개 기간. 선의의 연구자나 공급자가 발견한 경우, 보통 패치가 준비될 때까지 취약점을 비공개로 유지합니다(책임 있는 공개, responsible disclosure). 이 기간 동안 공급자는 수정을 개발합니다.
공개와 패치 배포. 취약점이 CVE로 공개되고, 대개 동시에 또는 직후에 패치가 배포됩니다. 이 순간이 결정적입니다. 방어자에게는 "고칠 수 있게 된 시점"이고, 공격자에게는 "표적을 알게 된 시점"입니다.
무기화. 공개된 정보를 바탕으로 실제 동작하는 익스플로잇이 만들어집니다. 때로는 연구 목적의 개념 증명(PoC)이 공개되기도 하는데, 이것이 공격자에게 무기화의 지름길을 제공합니다.
대량 악용. 무기화된 익스플로잇이 자동화 도구와 봇넷에 통합되어, 인터넷 전역의 취약한 시스템을 향해 무차별 살포됩니다. 1장에서 본 "새 CVE를 노린 정밀 타격"의 정체가 이것입니다.
0-day와 n-day의 결정적 차이
여기서 두 핵심 개념을 명확히 구분해야 합니다.
0-day(제로데이) 는 공급자가 아직 모르거나 패치가 없는 상태에서 악용되는 취약점입니다. 방어자에게 "방어할 시간이 0일"이라는 의미입니다. 패치가 존재하지 않으므로, 적용할 패치도 없습니다. 0-day는 매우 위험하지만, 동시에 드뭅니다. 0-day를 발굴하거나 구매하는 데는 큰 비용이 들기 때문에, 주로 2장에서 본 APT 같은 고역량·고자원 공격자가 가치 높은 표적에 아껴 씁니다. 평범한 조직이 0-day의 직접 표적이 될 가능성은 상대적으로 낮습니다.
n-day 는 이미 공개되고 패치가 나온 취약점입니다. "공개된 지 n일이 지난" 취약점이라는 뜻입니다. 패치가 존재하므로, 이론적으로는 막을 수 있습니다. 그런데도 여전히 위험한 이유는, 많은 시스템이 그 패치를 적용하지 않은 채 방치되기 때문입니다.
n-day가 0-day보다 당신에게 더 위험한 이유
이것이 이 장에서 가장 중요한 통찰입니다. 직관과 반대로, 대부분의 조직에게 실질적으로 더 큰 위협은 0-day가 아니라 n-day입니다.
이유는 명확합니다.
첫째, n-day는 흔하고 0-day는 드뭅니다. 매주 쏟아지는 그 모든 CVE가 곧 n-day의 풀입니다. 공격자는 굳이 비싼 0-day를 쓸 필요 없이, 패치되지 않은 채 널려 있는 n-day만 노려도 충분히 많은 표적을 얻습니다.
둘째, n-day는 무기화가 쉽습니다. 취약점의 세부 정보가 이미 공개되어 있고, 때로는 개념 증명 코드까지 있으므로, 익스플로잇을 만들기가 0-day보다 훨씬 수월합니다. 3장에서 본 AI의 가속이 가장 직접적으로 적용되는 영역이 바로 이 n-day 무기화입니다.
셋째, n-day는 대량 자동화 공격의 주력입니다. 공개된 취약점은 곧바로 자동화 도구에 통합되어 인터넷 전역을 훑습니다. 당신이 패치하지 않은 취약한 버전을 돌리고 있다면, 1장의 상시 스캐너가 당신을 정확히 그 취약점의 표적으로 식별합니다.
요컨대, 화려하고 무서운 0-day는 대부분의 조직에게 추상적인 위협인 반면, 평범하고 흔한 n-day는 지금 이 순간 당신의 서버를 두드리는 구체적인 위협입니다. 그리고 n-day는 패치 하나로 막을 수 있습니다. 막을 수 있는데 막지 않아서 뚫리는 것 — 이것이 현실에서 일어나는 침해의 압도적 다수입니다. 서문에서 말한 "10년 지난 기술을 쓰는 사이트"의 위험이 바로 이 방치된 n-day의 누적입니다.
이것은 책상 위의 이론이 아닙니다. 실제 사건들이 똑같은 이야기를 반복합니다.
- Log4Shell(CVE-2021-44228) 은 n-day의 교과서입니다. 자바 진영에서 사실상 어디에나 들어가는 로깅 라이브러리 Log4j의 원격 코드 실행 취약점인데, 2021년 말 패치가 나온 뒤에도 수년간 패치되지 않은 시스템에서 악용이 계속됐습니다. 라이브러리가 너무 깊이 박혀 있어 "내가 이걸 쓰는 줄도 몰랐다"는 경우가 많았다는 점에서, 뒤에 나올 의존성 문제와도 곧장 이어집니다.
- Citrix Bleed(CVE-2023-4966) 는 패치가 이미 있었는데도 적용을 미룬 기업들이 줄줄이 침해당한 사례입니다. 0-day가 아니라 n-day가, 그것도 패치 부재가 아니라 패치 지연 하나로 대형 피해를 냈습니다.
- MOVEit Transfer(CVE-2023-34362) 에서는 Cl0p 랜섬웨어 조직이 파일 전송 솔루션의 취약점을 대량으로 긁어, 패치가 늦은 곳들을 무차별로 털었습니다. "공개 → 자동화된 대량 악용"이라는 4.3의 타임라인이 그대로 현실이 된 장면입니다.
위 세 건은 모두 0-day가 아니라, 패치가 존재하는 n-day였습니다. 현장에서 사고를 분석해 보면, 화려한 신종 기법이 아니라 "패치가 나온 줄 몰랐다" 혹은 "다음 점검 때 하려고 미뤘다"가 원인의 절대다수입니다. 위 CVE들은 모두 NVD나 CISA KEV에서 번호로 검색하면 영향 버전과 악용 정황을 바로 확인할 수 있습니다.
골든타임: 패치는 경쟁이다
n-day의 위험은 곧 패치 속도의 중요성으로 이어집니다. 취약점이 공개되고 무기화되어 대량 악용되기까지의 시간 — 이것이 방어자의 골든타임입니다. 이 시간 안에 패치하면 안전하고, 놓치면 위험에 노출됩니다.
3장에서 강조했듯, AI는 이 골든타임을 단축시킵니다. 무기화가 빨라지면 방어자가 패치할 시간은 줄어듭니다. 과거에는 "다음 정기 점검 때 패치하지"라는 여유가 통했지만, 이제는 그 여유가 위험합니다. 고위험 취약점은 공개 직후 신속하게 대응해야 하며, 이것은 자동화된 패치 관리 체계를 요구합니다(15장, 부록 E).
4.4 공급망 공격과 의존성 지옥: 당신이 안 쓴 코드가 당신을 무너뜨린다
지금까지는 당신이 직접 운영하는 소프트웨어의 취약점을 이야기했습니다. 그러나 현대 소프트웨어의 가장 큰 취약점 표면은, 당신이 직접 작성한 코드가 아니라 당신이 끌어다 쓴 남의 코드에 있습니다.
의존성이라는 빙산
현대의 어떤 애플리케이션도 처음부터 끝까지 직접 만들지 않습니다. 프레임워크, 라이브러리, 패키지 — 수많은 외부 구성 요소를 가져다 조합하여 만듭니다. 이것은 효율적이고 합리적인 개발 방식입니다. 바퀴를 매번 새로 발명할 필요는 없으니까요.
문제는, 당신이 직접 가져온 라이브러리가 또 다른 라이브러리에 의존하고, 그 라이브러리가 또 다른 것에 의존하는 식으로, 의존성이 깊은 나무를 이룬다는 점입니다. 당신의 애플리케이션이 의존하는 코드의 대부분은, 당신이 그 존재조차 모르는 간접 의존성일 수 있습니다. 수면 위에 보이는 것은 당신이 직접 선택한 몇 개의 라이브러리뿐이지만, 수면 아래에는 수백, 수천 개의 간접 의존성이 잠겨 있습니다.
이 빙산 전체가 당신의 공격면입니다. 그 깊은 의존성 나무의 어느 한 구석에 있는 작은 라이브러리에 치명적 취약점이 발견되면, 그것을 (간접적으로) 쓰는 당신의 애플리케이션도 취약해집니다. 당신은 그 라이브러리의 이름조차 들어 본 적 없을 수 있습니다.
공급망 공격
공격자는 이 구조를 적극적으로 악용합니다. 이것을 공급망 공격(supply chain attack) 이라고 부릅니다. 핵심 발상은, 표적을 직접 공격하는 대신, 표적이 신뢰하고 가져다 쓰는 무언가를 오염시키는 것입니다.
대표적인 방식은 널리 쓰이는 라이브러리나 패키지 자체에 악성 코드를 심는 것입니다. 공격자가 인기 있는 오픈소스 패키지를 장악하거나, 그것과 비슷한 이름의 가짜 패키지를 만들어 개발자가 실수로 설치하게 유도하거나, 패키지의 업데이트에 악성 코드를 끼워 넣습니다. 그러면 그 패키지를 가져다 쓰는 모든 곳이 한꺼번에 오염됩니다.
공급망 공격이 특히 위험한 이유는 신뢰를 악용하기 때문입니다. 개발자는 자신이 가져오는 라이브러리를 기본적으로 신뢰합니다. 그 신뢰가 깨지면, 가장 안쪽까지 단번에 뚫립니다. 2장에서 본 APT가 강한 주 표적을 직접 치는 대신 약한 협력사를 노리는 것과 같은 원리가, 코드의 세계에서 펼쳐지는 것입니다.
이 발상이 얼마나 정교해질 수 있는지를 보여 준 사건이 2024년 xz-utils 백도어(CVE-2024-3094) 입니다. 리눅스 곳곳에 기본으로 깔리는 압축 라이브러리 xz에, 한 기여자가 수년에 걸쳐 신뢰를 쌓은 뒤 은밀하게 백도어를 심어 둔 것이 배포 직전에 우연히 발각됐습니다. 누군가 악성 코드를 "몰래 끼워 넣는" 정도가 아니라, 오픈소스 프로젝트의 관리 권한 자체를 사회공학으로 장악하려 한 사례라는 점에서 충격이 컸습니다. 만약 발각되지 않았다면, 그 라이브러리를 (간접적으로라도) 쓰는 셀 수 없이 많은 시스템이 한꺼번에 뚫릴 수 있었습니다 — 빙산 비유가 곧 현실이 되는 순간이었습니다.
방어: 의존성을 관리 대상으로 삼아라
의존성과 공급망 위험에 대한 방어의 출발점은, 의존성을 "한 번 설치하고 잊는 것"이 아니라 "지속적으로 관리하는 자산"으로 취급하는 것입니다.
- 무엇을 쓰는지 파악하십시오. 자신의 애플리케이션이 어떤 구성 요소에, 어떤 버전으로 의존하는지를 알아야 합니다. 보이지 않는 것은 지킬 수 없습니다(이것은 5장 공격면 지도화의 한 갈래이기도 합니다).
- 알려진 취약점을 지속적으로 점검하십시오. 의존성 중에 알려진 취약점이 있는 버전이 포함되어 있는지를 정기적으로 검사합니다. 이것은 자동화하기 좋은 작업이며, AI와 자동화 도구의 도움을 받을 수 있습니다(부록 E의 영역 2). 개발자라면 출발점은 의외로 간단합니다. 패키지 매니저에 내장된 점검 명령(예:
npm audit,pip-audit,composer audit)을 돌리면, 지금 쓰는 의존성 중 알려진 취약점이 있는 것을 즉시 알려 줍니다. 그 근거 데이터의 원천이 바로 구글이 운영하는 통합 취약점 DB OSV(osv.dev)와 GitHub Advisory Database입니다. 둘 다 어떤 패키지의 어떤 버전 범위가 취약한지를 생태계별(npm·PyPI·Composer 등)로 정리해 두므로, 특정 라이브러리 이름으로 직접 검색해 볼 수도 있습니다. GitHub 저장소라면 Dependabot 경고를 켜 두는 것만으로 이 점검이 자동으로 돌아갑니다. - 신뢰할 수 있는 출처에서 가져오십시오. 패키지를 가져올 때 출처를 확인하고, 이름이 비슷한 가짜 패키지에 속지 않도록 주의합니다.
- 불필요한 의존성을 줄이십시오. 이것은 원칙 1(공격면 축소)의 적용입니다. 쓰지 않는 라이브러리, 과도하게 많은 기능을 가진 무거운 라이브러리를 줄이면, 그만큼 빙산이 작아지고 취약점에 노출될 표면도 줄어듭니다.
- 업데이트하되 검증하십시오. 의존성을 최신으로 유지하는 것이 보안에 중요하지만, 업데이트 자체가 공급망 공격의 통로일 수 있으므로, 중요한 변경은 검증하는 절차가 필요합니다.
특히 최신 프레임워크라고 해서 안전한 것이 아닙니다. 활발히 쓰이는 현대적 프레임워크일수록 더 많은 연구자와 공격자의 주목을 받으며, 그만큼 취약점도 자주 발견되고 공개됩니다. 이것은 그 프레임워크가 나쁘다는 뜻이 아니라, 최신이든 오래되었든 모든 의존성은 지속적 관리가 필요하다는 뜻입니다. 12장에서 웹 애플리케이션 취약점을 다루며 이 주제를 다시 만나게 됩니다.
4.5 홍수에서 살아남기: 실용적 우선순위화
이제 이 장의 가장 실용적인 부분입니다. 매주 쏟아지는 CVE의 홍수 앞에서, 한정된 자원을 가진 방어자는 어떻게 우선순위를 잡아야 할까요? 마비되지도, 무지하지도 않으면서 말입니다.
다음은 우선순위를 잡는 현실적인 사고의 순서입니다.
1단계: 내가 무엇을 쓰는지 안다. 모든 것의 출발점입니다. 자신의 시스템에 어떤 소프트웨어가, 어떤 버전으로 돌아가는지, 그리고 어떤 의존성을 갖는지를 파악해야 합니다. 이것을 모르면, 어떤 CVE가 자신과 관련 있는지조차 알 수 없습니다. 인벤토리가 우선순위의 전제입니다(5장).
2단계: 나에게 해당하는 것만 추린다. 세상의 모든 CVE를 따라갈 필요는 없습니다. 당신이 실제로 쓰는 구성 요소에 영향을 주는 취약점만이 당신의 관심사입니다. 1단계의 인벤토리가 있으면, 쏟아지는 CVE 중 자신과 무관한 대다수를 즉시 걸러 낼 수 있습니다. 홍수의 대부분은 당신의 강이 아닙니다.
3단계: 노출과 악용 여부로 정렬한다. 해당하는 취약점들 중에서, 다음 두 질문으로 우선순위를 매깁니다. 첫째, 이것이 외부에 노출되어 있는가? 인터넷에 직접 노출된 시스템의 취약점이, 내부 깊숙이 단절된 것보다 급합니다. 둘째, 이것이 실제로 악용되고 있는가? 4.2에서 강조했듯, 현재 활발히 악용되는 취약점이 단순 고득점보다 우선이며, 이 "악용 여부"는 CISA KEV 카탈로그에 올라 있는지로 빠르게 확인할 수 있습니다. 이 두 질문에 모두 "예"인 취약점 — 외부 노출 + 실제 악용 — 이 최우선 대응 대상입니다.
4단계: 신속히 패치하고, 못 하면 완화한다. 우선순위가 높은 취약점은 골든타임 안에 패치합니다. 만약 즉시 패치할 수 없는 사정이 있다면(호환성 문제, 운영 중단 우려 등), 임시 완화책을 적용합니다. 취약한 기능을 비활성화하거나, 접근을 제한하거나, 추가 방어 계층을 두어 악용을 어렵게 만드는 것입니다. 완화는 패치의 대체가 아니라 패치까지의 시간을 버는 임시방편임을 기억하십시오.
5단계: 이 전체를 반복 가능한 과정으로 만든다. 이 우선순위화는 한 번 하고 끝나는 것이 아닙니다. 새 CVE는 계속 나오고, 시스템도 계속 변합니다. 그러므로 위 단계를 정기적으로 반복하는 루틴으로 만들어야 합니다(원칙 5). 그리고 이 반복적 점검이야말로 자동화와 AI가 가장 잘 도울 수 있는 영역입니다(원칙 6, 부록 E). 사람이 매주 모든 CVE를 손으로 훑는 것은 불가능하지만, 자동화된 점검이 "당신에게 해당하고, 노출되어 있고, 악용되는" 취약점을 추려서 알려 주게 만들 수 있습니다.
이 다섯 단계의 핵심 철학은, 전부를 막으려 하지 말고, 진짜 위험한 것을 가려내어 거기에 집중하라는 것입니다. 홍수를 막으려 하면 압도되어 마비되지만, 자신의 강만 골라 관리하면 감당할 수 있습니다.
4.6 이 장이 남기는 교훈
이 장에서 확인한 것을 압축합니다.
첫째, CVE와 CVSS는 보안의 공통 언어입니다. CVE는 취약점의 고유 이름이고, CVSS는 그 심각도 점수입니다. 그러나 CVE 공개는 방어자와 공격자에게 동시에 정보를 줍니다.
둘째, CVSS 점수만 보면 오판합니다. 점수는 당신의 맥락도, 실제 악용 여부도, 연쇄 가능성도 반영하지 못합니다. 점수는 출발점이지 결론이 아닙니다.
셋째, n-day가 0-day보다 당신에게 더 위험합니다. 0-day는 무섭지만 드물고 주로 고가치 표적에 쓰입니다. 당신을 실제로 무너뜨리는 것은, 패치가 나왔는데도 적용하지 않은 흔하디흔한 n-day입니다. 막을 수 있는데 막지 않아서 뚫리는 것이 침해의 다수입니다.
넷째, 패치는 시간과의 경쟁입니다. 공개에서 무기화까지의 골든타임이 곧 방어 시간이며, AI가 이 시간을 단축시키고 있으므로 패치는 더 빨라져야 합니다.
다섯째, 가장 큰 취약점 표면은 남의 코드입니다. 당신이 끌어다 쓴 의존성의 빙산 전체가 공격면이며, 공급망 공격은 그 신뢰를 악용합니다. 의존성은 한 번 설치하고 잊는 것이 아니라 지속 관리할 자산입니다.
여섯째, 홍수에서는 우선순위가 생존입니다. 전부를 막으려 하지 말고, 내가 쓰는 것 중에서, 노출되어 있고, 실제 악용되는 것에 집중하십시오. 그리고 이 과정을 반복 가능한 자동화 루틴으로 만드십시오.
이것으로 1부 "위협의 지형"을 마칩니다. 우리는 인터넷에 연결되는 순간 발견되고(1장), 다양한 공격자가 우리를 노리며(2장), AI가 그들의 공격을 가속하고(3장), 끊임없는 CVE의 홍수가 무기화된다(4장)는 것을 보았습니다. 위협의 전모를 그렸으니, 이제 방어로 넘어갈 차례입니다.
방어의 첫걸음은 화려한 도구가 아닙니다. 그것은 자신이 무엇을 가지고 있고, 무엇이 외부에 노출되어 있는지를 정확히 아는 것입니다. 보이지 않는 것은 지킬 수 없고, 모르는 것은 패치할 수 없습니다. 2부의 첫 장에서, 우리는 자신의 공격면을 지도화하는 것부터 시작합니다.
이 장의 실행 항목
- 소프트웨어 인벤토리를 만드십시오. 무엇을, 어떤 버전으로 쓰는지 모르면 어떤 CVE가 자신과 관련 있는지 알 수 없습니다. (5장)
- 의존성 목록을 파악하고 취약점을 점검하십시오. 가장 큰 공격면은 당신이 안 쓴 남의 코드에 있습니다. (4.4, 부록 E)
- "현재 악용되는 취약점"을 우선순위 기준으로 삼으십시오. 단순 CVSS 점수보다 실용적입니다. (4.2, 4.5)
- 외부 노출 자산의 취약점을 최우선으로 패치하십시오. 노출 + 악용이 겹치면 즉시 대응하십시오. (4.5)
- 패치 골든타임을 의식하십시오. "다음 점검 때"의 여유가 사라졌습니다. 자동화를 검토하십시오. (4.3, 15장)
- 이 모든 점검을 반복 가능한 루틴으로 만드십시오. 자동화와 AI 활용을 검토하십시오. (4.5, 부록 E)
다음 장: 5장 — 당신의 공격면을 지도화하라. 보이지 않는 것은 지킬 수 없습니다. 2부 "공격면"의 시작.