[관점]
취약점 대응 회의에서 오래 쓰인 문장이 있다. 「아직 공개된 익스플로잇은 없습니다.」 이 문장은 판단을 미루는 근거가 아니라 실제로 유효한 정보였다. 공개와 악용 사이에 공격자가 분석하고 무기화하는 시간이 있었고, 그 시간이 방어자의 유예였기 때문이다.
이 글이 제시하는 사례는 그 전제를 정면으로 흔든다. 27년 묵은 결함과 16년 묵은 결함이 하루 안에, 2천 달러도 안 되는 비용으로 나왔다. 숙련된 연구진이 며칠에서 몇 주를 쓰던 작업이다.
그래서 바뀌어야 하는 것은 패치 속도가 아니다. 위험도 산정표에서 「익스플로잇 공개 여부」라는 항목이 차지하는 자리다. 국내 다수 조직의 평가 기준에 이 항목이 가중치를 갖고 들어가 있고, 그 가중치가 지금 잘못된 신호를 보내고 있다.
Pentera 는 프런티어 AI 모델이 취약점 발견과 익스플로잇 생성에서 도달한 수준을 근거로, 방어 측의 판단 기준 하나가 더 이상 작동하지 않는다고 주장한다.
변화의 실체
원문은 네 가지를 변화로 정리한다. 공개된 취약점이 즉시 무기화된다는 것, 악용 가능성은 추정이 아니라 증명되어야 한다는 것, 복잡성에 기댄 방어가 더 이상 효과를 내지 못한다는 것, 그리고 AI 기반 공격에 대응하려면 자기 환경에 대한 모델링이 전제가 된다는 것이다.
앞의 두 가지가 실무에 직접 닿는다. 「이 취약점은 악용이 어렵다」는 판단과 「알려진 익스플로잇이 없다」는 관측이 방어 신호로 쓰여 왔는데, 원문은 이 둘을 더 이상 신호로 취급하지 말라고 말한다.
근거가 된 사례
원문이 드는 사례는 오래된 결함이라는 공통점을 갖는다.
| 대상 | 결함 | 특징 |
|---|---|---|
| OpenBSD | 27년 된 서비스 거부 취약점 | 장기간 노출되어 있었으나 발견되지 않음 |
| FFmpeg | H.264 코덱의 16년 된 결함 | 수천 회의 자동 퍼징에서 발견되지 않음 |
| Linux 커널 | 다중 취약점 체인 | 메모리 해제 후 사용 · KASLR 우회 포함 |
| 브라우저 · OS | 렌더러에서 샌드박스 이탈까지 | 4단계 체인 구성 |
FFmpeg 사례가 특히 무겁다. 자동 퍼징은 지난 10여 년간 오픈소스 취약점 발견의 주력 수단이었다. 그 수단이 수천 회 돌고도 못 찾은 것을 다른 방법이 찾아냈다는 뜻이며, 「이미 충분히 검증된 코드」라는 판단의 근거가 약해진다.
단가의 변화
원문이 제시하는 수치는 두 개다. 하루 이내, 그리고 2천 달러 미만. 비교 기준은 숙련된 연구진이 며칠에서 몇 주를 쓰던 종래의 소요다.
이 수치의 의미는 「AI 가 모든 취약점을 익스플로잇으로 바꾼다」가 아니다. 무기화의 단가가 내려가면 그 대상 범위가 넓어진다는 것이다. 과거에는 숙련 인력의 시간이 아까워 손대지 않던 중간 등급 취약점까지 후보가 된다. 방어자가 「우선순위에서 뒤로 밀어도 되는 것」이라 분류해 둔 구간이 여기에 겹친다.
원문의 결론은 취약점 목록을 추적하는 방식에서 자기 환경에서 실증 가능한 공격 경로를 증명하는 방식으로 옮겨 가라는 것이다.
국내 적용 관점
위험도 산정표에서 「익스플로잇 공개 여부」 항목을 재검토해야 한다. 국내 다수 조직의 취약점 위험도 평가표에는 CVSS 점수와 별도로 익스플로잇 공개 여부, PoC 존재 여부가 가중치 항목으로 들어가 있다. 이 항목은 오랫동안 합리적이었지만 지금은 방어자를 잘못된 방향으로 이끈다. 순서는 기준표 개정이 먼저다. 도구 도입이나 조직 개편보다 앞선다. 문서 한 장을 고치는 일이고, 이것을 고치지 않으면 어떤 도구를 들여도 조치 우선순위는 같은 방식으로 산출된다. 대체 항목으로는 「자사 환경에서 도달 가능성이 검증되었는가」를 두는 편이 실효적이다.
유예를 전제한 절차가 어디에 남아 있는지 찾아야 한다. 자사 절차를 훑어보면 대개 네 곳이 확인된다. 긴급 패치를 정기 변경관리 심의 주기(주 1회 또는 격주)에 태우는 구조, PoC 공개 여부를 긴급도 판정에 쓰는 평가 기준, 외부 노출 자산과 내부 자산에 동일한 조치 기한을 적용하는 규정, 야간·주말 적용을 원칙적으로 금지하면서 예외 승인 경로를 두지 않은 운영 정책이다. 여기서 순서가 중요하다. 기한을 먼저 조이면 현장이 감당하지 못해 예외가 남발된다. 긴급 경로를 먼저 만들고 그다음에 기한을 조여야 한다. 승인권자와 소집 방식이 정해진 긴급 심의 경로 하나가 나머지 세 곳의 부담을 크게 덜어 준다.
패치가 아니라 완충 통제를 준비해야 한다. 모든 패치를 24시간 안에 적용할 수 있는 조직은 없다. 현실적인 목표는 패치 전까지 버티는 임시 통제를 미리 문서화해 두는 것이다. 준비 순서는 외부 노출 자산 목록 확보, 주요 제품군별 우회 통제 카드 작성(접근 제한·WAF 규칙·기능 비활성화), 그리고 그 카드를 실행할 승인 라인 지정이다. 이렇게 해 두면 판단해야 할 것이 「무엇을 할까」에서 「준비된 것 중 무엇을 켤까」로 바뀐다. 결정 시간이 줄어드는 지점이 여기다.
오픈소스 의존성 구간은 별도로 봐야 한다. FFmpeg 사례가 국내에 시사하는 바가 크다. 미디어 처리 라이브러리는 국내 서비스 기업의 백엔드와 모바일 앱에 광범위하게 들어가 있으면서, 대개 직접 관리 대상으로 인식되지 않는다. SBOM 을 갖췄더라도 「어느 버전이 어디에 들어가 있는가」까지만 알고, 그것을 교체할 수 있는 배포 경로는 준비되어 있지 않은 경우가 많다. 목록 보유와 교체 능력은 다른 문제다. 주요 오픈소스 구성요소 서너 개를 골라 실제 교체에 며칠이 걸리는지 한 번 측정해 두면, 다음 사고 때 그 숫자가 판단 근거가 된다.
경영진 보고에서는 프레이밍이 결과를 가른다. 「위험이 커졌다」로 시작하면 예산 요청으로 읽히고 대체로 보류된다. 「판단 기준 하나가 더 이상 작동하지 않는다」로 시작하면 기존 절차의 수정 필요성으로 읽힌다. 실제로 바꿔야 하는 것도 후자이며, 27년과 16년이라는 숫자가 이 문장의 근거로 쓰인다.
점검 항목
질문 1 위험도 산정표에 익스플로잇·PoC 공개 여부가 가중치로 들어가 있는가?
그 항목이 조치 우선순위를 실제로 바꾸는가?
질문 2 긴급 패치를 정기 변경심의 주기 밖에서 처리할 경로가 있는가?
승인권자와 소집 방식이 문서에 지정되어 있는가?
질문 3 주요 제품군별 우회 통제가 사전에 문서화되어 있는가?
질문 4 핵심 오픈소스 구성요소를 실제로 교체하는 데 며칠이 걸리는가?
측정해 본 기록이 있는가?출처 · Pentera, AI-Driven Exploit Generation: What Mythos Means for Cyber Defense (2026-04-28, Shlomo Ben-Yosef)