취약점 공개의 속도를 방어자가 따라갈 수 없습니다

AI 요약

취약점 패치가 나와도 방어자가 즉시 대응하지 못하는 이유는 패치 개발보다 자산 파악과 영향 평가, 실제 배포에 시간이 더 걸리기 때문입니다. 글쓴이는 여러 취약점이 한꺼번에 공개되는 상황에서 보안팀이 각 시스템의 공격 표면과 완화책을 확인하고 패치를 적용해야 한다고 설명합니다. 인력과 자산 목록이 부족하면 같은 소수의 숙련자에게 대응이 집중되고, 사고마다 맥락을 다시 파악하느라 중요한 정보를 놓치거나 적용 여부가 불확실한 조치를 서두를 수 있습니다.

취약점 공개가 대응 업무를 압도합니다

글쓴이는 최근 며칠 사이의 사례로 가상화 환경과 컨테이너에 영향을 미치는 것으로 설명된 PwnEscape(CVE-2026-99999)를 듭니다. 커널을 실시간 패치할지, 운영체제 배포판의 업데이트를 기다릴지 판단한 뒤 수천 대의 시스템을 재부팅해야 할 수 있습니다. 취약점을 고친 코드가 있어도 각 시스템의 구성과 완화책을 파악하고 배포하는 과정은 남습니다.

또 다른 사례는 TLS 인증서 묶음입니다. 브라우저 업데이트가 빠르게 이뤄져도 여러 소프트웨어가 별도로 포함하거나 하드코딩한 CA 신뢰 목록은 패키지 목록이나 SBOM에서 찾기 어렵습니다. 글쓴이는 시스템의 모든 소프트웨어에서 이런 인증서 묶음을 확인하는 일이 단순한 패치 적용보다 어렵다고 지적합니다. PHP 취약점 두 건(CVE-2026-109618, CVE-2026-109619)은 엠바고가 깨지면서 사전 대응 시간이 줄었고, 보안 업체들의 선점 경쟁과 검증이 부족한 익스플로잇 게시물이 대응팀의 주의를 분산시켰다고 설명합니다. Node.js의 Brotli 디코더 취약점(CVE-2026-111497)도 실제 영향이 Node.js에 그치지 않아 여러 스택에 흩어진 Brotli 구현을 찾아야 하는 사례로 듭니다.

AI가 늘리는 보고서와 대응 부담

글쓴이는 AI 기업들이 취약점 발견과 공격을 자사 성과로 내세우며 대량 공개를 부추긴다고 비판합니다. 공격자도 Linux 커널 커밋 메시지 등을 모델에 넣어 취약점을 찾는다고 설명하며, 엠바고가 대규모 악용을 막는 효과는 제한적일 수 있다고 봅니다. 방어 측에서는 AI가 만든 취약점 보고서가 지나치게 길고 심각도를 부풀리는 경우가 있다고 합니다. 담당자가 내용을 충분히 이해하지 못한 채 보고서를 다시 모델에 넣어 만든 PoC를 실행해도, 실제 환경과 코드가 다르면 재현에 실패할 수 있습니다. 실행 조건과 작동 원리를 간결하게 설명해 달라고 요청하면 7,000단어짜리 README가 돌아오는 사례도 듭니다.

이런 동시다발적 대응은 보안 담당자뿐 아니라 엔지니어와 홍보, 법무팀을 소진시키고, 반복되는 업무 전환은 판단 오류를 키웁니다. 글쓴이는 AI가 모든 취약점을 찾아 고칠 것이라는 기대에 동의하지 않습니다. AI가 만든 패치가 문제를 해결하지 못하거나 새 취약점을 만들고 애플리케이션 동작을 바꾸는 경우가 절반을 넘는다는 수치도 제시합니다. 패치 자동 배포와 안전한 재부팅 체계를 갖추는 데도 시간이 들고, 보안 인력을 늘리기 어렵다고 봅니다.

제안은 피해 범위 제한입니다

글쓴이는 뚜렷한 단기 해법을 제시하지 않습니다. 대신 침해를 전제로 탐지 체계를 마련하고, 외부 노출과 내부 이동, 권한 상승의 범위를 줄이는 데 투자해야 한다고 주장합니다. 이런 방어는 과거 Zero Trust라는 이름으로도 불렸지만, 실제 예산은 자산을 빠뜨릴 수 있는 AI 기반 보안 대시보드로 향한다고 비판합니다. 오픈소스 프로젝트에 알려진 취약점이 있는 채로 배포하는 업체에 책임을 물어야 한다는 의견도 덧붙이지만, 오픈소스에 어떻게 적용할지와 대량 공개 문제를 해결할지는 분명하지 않다고 인정합니다.

Lobsters 반응

• @decentstates — 저자가 언급한 SBOM의 한계, 즉 각종 vendored 또는 하드코딩된 CA 인증서 묶음이 목록에 나오지 않는다는 대목이 흥미롭습니다. 링크를 따라가면 Nix 시스템의 패키지 폐쇄 집합에서 TLS 인증서를 포함한 패키지를 찾는 nix-cacert-scan을 볼 수 있습니다. 어떤 패키지가 인증서를 포함하는지 확인하고 오버레이로 고치거나 파이프라인에서 손상된 인증서를 자동으로 찾을 수 있습니다. NixOS의 장점인데 보안에 더 집중하지 않는 점이 아쉽습니다. nixpkgs에는 서명된 커밋이나 내장 커널 강화, musl 빌드 같은 기능이 없습니다. 거대한 nixpkgs에서 안전한 핵심 영역을 분리하면 좋겠습니다.
  • @l0b0 — Nixpkgs 작업 대부분은 여전히 자원봉사자가 합니다. 기존의 거대한 작업과 별개인 일을 하려면 시간과 의지가 있는 사람이 맡아야 합니다. 돈과 동기가 있는 회사가 사람을 전담 고용하면 원하는 보안 기능을 거의 무엇이든 만들 수 있습니다. 다만 자금이 많은 회사에서 NixOS를 많이 쓰지는 않습니다. 그런 회사는 변화가 느리고, Nix와 NixOS가 얼마나 큰 전환인지 말하는 소수의 시스템 관리자에게 귀 기울이지 않을 겁니다.
  • @novedevo — 보안에 더 집중하지 않는 점에 동의합니다. 지원 중인 안정 버전 NixOS 26.05의 최신 리비전을 쓰는데도, 링크한 도구에 따르면 시스템 폐쇄 집합에 eMudhra 인증서를 신뢰하는 패키지가 다섯 개 있습니다. 각 패키지는 상위 프로젝트에서 이미 수정됐지만 nixpkgs 관리자가 아직 수정 사항을 백포트하지 않은 것 같습니다. nixpkgs 팀을 높이 평가하지만 uv 설치가 쉽게 중간자 공격을 받을 수 있다는 점도 아쉽습니다.
• @landon — 안전성이 나아질 때까지 매질은 계속됩니다.
• @lproven — 크고 복잡한 스택에서 자동화된 취약점 탐지에 대응하는 방법은 크고 복잡한 스택을 더 작고 단순한 스택으로 바꾸는 것이라고 생각합니다. 기능이 크게 줄어드는 경우도 받아들여야 합니다. 원래 기능의 필수적인 최소 부분만 할 수 있으면서 정확성을 증명할 만큼 작고 단순한 도구가 남을 때까지 계속해야 합니다. 솔직히 좋은 생각입니다.
  • @freddyb — 저도 그렇게 생각했습니다. 추론하기 쉬운 작은 구성 요소로 나눠야 합니다. 항상 최신 릴리스를 쓰고 업데이트를 엄격히 적용해, 안정적으로 작동하는지보다 최신 상태인지를 우선해야 합니다. 안정성과 대체 수단, 서비스의 점진적 기능 저하를 거듭 개선하면 애플리케이션 스택에 맞춰 취약점의 맥락을 파악하는 부담을 줄일 수 있습니다. cattle과 pets도 참고할 만합니다.
• @thisalex — 침해를 전제로 탐지하고 노출과 측면 이동, 권한 상승을 제한하라는 말은 건전한 보안 프로세스의 정의 아닌가요? 여기서 말하는 예산은 전문 인력의 급여를 뜻하나요, 아니면 계층이 잘 나뉜 프로젝트 아키텍처를 만드는 비용인가요? 모든 문제를 막지는 못해도 피해 범위는 제한하겠죠.
• @shabbyrobe — 글을 즐겁게 읽었습니다. 저도 eMudhra 인증서가 어디에 남았는지 샅샅이 뒤지는 일을 맡았지만 글쓴이만큼 비관적이지는 않습니다. 이 상황은 afl-fuzz와 Heartbleed가 등장한 시기를 떠올리게 합니다. 지금 우리가 쓰는 소프트웨어에는 살아남은 것만 남는 생존 편향이 있습니다. 2014년처럼 소프트웨어의 안전성을 시험하는 새로운 방법이 급증하고 있습니다. 그때 많은 소프트웨어가 병들었지만 사라지지는 않았고, 살아남은 것은 더 튼튼해졌습니다. 이번에도 한동안 지나면 잠잠해지겠지만 잡음의 바닥은 영구히 높아질 것 같습니다.

원문: Netmeister blog / 번역·요약: Trawling