이대로는 지속 가능하지 않다 - 취약점 공개 속도를 따라가지 못하는 보안 대응

취약점 발견과 공개 속도가 방어 조직의 대응 능력을 넘어섰으며, AI로 패치를 생성하는 것만으로는 이 문제를 해결할 수 없음 실제 병목은 패치 개발이 아니라 적용 과정에 있음. 조직별 공격 표면과 악용 가능성을 파악하고, 완화책을 검토하고, 수정을 배포하는 데 상당한 시간과 자원이 필요함 가상화, TLS, PHP, Brotli 취약점 대응에서는 처음 알려진 범위보다 넓은 영향과 불완전한 소프트웨어 목록 때문에 수정본이 있어도 대응이 끝나지 않음 대량 취약점 공개가 오픈소스 공동체와 방어 조직에 서비스 거부 공격처럼 부담을 주고 있음. 마케팅 목적의 엠바고 위반과 장황한 AI 보고서, 검증되지 않은 공격 코드가 같은 핵심 인력의 소진을 가속함 모든 취약점을 따라잡기 어렵다면 침해를 전제로 피해 범위를 제한해야 함. 악용 탐지, 노출 축소, 횡적 이동과 권한 상승 제한 같은 오래된 보안 과제가 여전히 필요함 취약점 발견보다 느린 방어 체계 같은 주에 최소 네댓 건의 보안 사고가 겹쳤고, 그중 PHP 취약점은 New York Times와 NPR까지 다룰 만큼 파장이 컸음 제로데이 공개가 쏟아지는 상황에서 마케팅 목적의 사전 통지 규칙과 엠바고 위반까지 발생하며, 대량 취약점 공개는 오픈소스 공동체에 서비스 거부 공격과 같은 부담을 줌 의존성에서 대량의 취약점을 발견한 뒤 사전 통지를 유료 서비스로 판매하는 방식도 비판의 대상임 기업의 인력은 이런 속도를 감당하도록 구성돼 있지 않으며, 취약점 발견 방식의 변화와 무너진 공개 절차 속에서 패치 관리도 방어자가 따라가기 어려운 일이 됨 환경별 악용 가능성 평가, 관련 공격 표면 조사, 수정 배포에는 여전히 큰 비용이 듦 앞서 다룬 병목도 수정 코드 작성 자체가 아니었음 PwnEscape: 커널 수정 이후에도 남는 작업 PwnEscape, CVE-2026-99999는 처음에는 “KVM 탈출”로 공개됐지만, 다른 가상화 환경과 컨테이너에도 영향을 줌 대응하려면 전체 시스템의 기존 완화책을 확인하고, 업스트림 패치를 가져와 커널 라이브 패치를 적용할지, 운영체제 공급자의 새 커널을 기다릴지 결정해야 함 새 커널을 배포하는 경로에서는 수천 대의 시스템 재부팅이 뒤따를 수 있음 2026년 10월 27일 기준으로 최초 공개 후 12일이 지났지만, Canonical은 심각도를 중간으로 분류하고 수정 커널을 제공하지 않은 상태였음 고급 AI 모델에 수천 달러의 토큰 비용을 쓰며 자체 ...