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

Jan Schaumann 블로그 글(2026-10-27)의 앞부분과 첫 두 사례를 읽고 옮겼어요. 뒤쪽 사례와 결론은 다 읽지 못했어요.

"임무 완수, 이제 좀 줄여 줄래요?"

10월은 사이버보안 인식의 달인데, 자신이 동시에 끄고 있는 네다섯 개의 불 중 하나를 뉴욕타임스와 NPR이 다 보도했으니 사람들은 확실히 사이버보안을 인식했다고 비꼬며 글을 시작해요.

작성자는 지금 상황이 지속 가능하지 않다고 해요. 0-day가 여기저기서 터지고, 사전 통보와 엠바고는 마케팅 목적으로 깨지고, AI 회사들은 누가 가장 많이 침범하는지 경쟁한 뒤 오픈소스 커뮤니티에 사실상 DoS를 거는 방식으로 보호를 팔려 한다고 비판해요.

왜 따라갈 수 없나요

회사들은 이만한 인력이 없고, 업계가 뭐라고 하든 AI로 이 상황을 빠져나갈 수는 없다고 해요. 취약점 발견은 근본적으로 바뀌었고, 공개 절차는 사실상 고장 났으며, 패치 관리는 몇 년째 지는 싸움이래요. 어떤 취약점이 내 환경에서 실제로 가능한지 평가하고, 관련된 공격 면을 찾고, 수정을 배포하는 데 여전히 큰 자원과 시간이 들기 때문이에요. 작성자는 수정 개발이 병목이 아니라고 거듭 강조해요.

최근 사례

• "PwnEscape"(CVE-2026-99999): 처음엔 KVM 탈출로 공개됐지만 다른 가상화와 컨테이너에도 해당돼요. 시스템 전체에 어떤 완화책이 있는지 평가하고, 직접 가져온 패치로 커널을 라이브패치할지, OS 공급자의 새 커널을 기다려 수천 대를 재부팅할지 정해야 해요. 수천 달러어치 토큰으로 최신 모델에게 익스플로잇을 만들게 해도 이미 아는 것 이상을 알려 주지 않는다고 해요.
• eMudhra 침해: 브라우저는 빨리 대응됐지만 환경 안에서 TLS를 쓰는 건 사실상 전부예요. 상세한 패키지 목록이나 SBOM이 있어도 벤더링되거나 하드코딩된 인증서까지 보여 주진 않는다고 지적해요.