답변게시됨14 소스
취약점 공격은 빨라지는데 패치는 왜 그대로일까
버라이즌의 2026년 자료에서 취약점 완전 조치까지 걸린 기간의 중앙값은 43일이었고, 이미 악용된 것으로 알려진 취약점 중 완전히 조치된 비율은 26%였다. a16z의 아사프 에즈라와 스테파니 장은 취약점을 실제 공격에 활용하는 데 드는 수고는 줄었지만 패치는 더 빨라지지 않았다며, 패치가 준비되는 동안 시스템을 지킬 방어책이 필요하다고 주장한다.
게시자GPT-6 Luna로 편집GPT Image 2로 이미지 생성
연구 답변
주요 시사점
- 버라이즌의 2026년 자료에서 취약점 완전 조치까지 걸린 기간의 중앙값은 43일이었고, 이미 악용된 것으로 알려진 취약점 중 완전히 조치된 비율은 26%였다.
- a16z의 아사프 에즈라와 스테파니 장은 취약점을 실제 공격에 활용하는 데 드는 수고는 줄었지만 패치는 더 빨라지지 않았다며, 패치가 준비되는 동안 시스템을 지킬 방어책이 필요하다고 주장한다.
- PHP 사례는 패치를 받을 수 없는 시스템도 있다는 점을 보여준다. 임시 방어 규칙은 노출을 줄일 수 있지만, 취약한 소프트웨어를 영구적으로 고치는 일을 대신하지는 않는다.
AI 프롬프트
openai.comCreate a landscape editorial hero image for this Studio Global article: What do a16z investing partner Asaf Ezra and growth partner Stephenie Zhang argue in their November 6, 2026 report “Defense in Depth, Rebuil. Article summary: Ezra and Zhang’s central argument is that cheap AI-generated exploits break the timing assumptions behind human-run patching: defenses must protect systems while permanent fixes are still being prepared, tested and deplo. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
취약점을 찾아내고 고치는 사이, 공격자는 이미 그 취약점을 이용할 수 있다면 어떨까. a16z의 아사프 에즈라와 스테파니 장은 2026년 11월 6일 보고서에서 사이버 보안이 패치에만 기대서는 안 된다고 주장한다. 취약점 악용이 쉬워지는 속도와 소프트웨어를 수정해 배포하는 속도 사이의 틈을 메울 방어책이 필요하다는 것이다. 1
2
패치가 늦어지는 동안 생기는 보안 공백
보고서가 인용한 버라이즌의 2026년 자료에 따르면 취약점을 완전히 조치하는 데 걸린 기간의 중앙값은 43일이었다. 이미 악용된 것으로 확인된 취약점 가운데 자료에 포함된 시스템에서 완전히 조치된 것은 **26%**에 그쳤다. 취약점이 알려지고도 실제 수정이 이뤄지기까지 상당한 시간이 걸리는 셈이다. 1
에즈라와 장은 2025년과 2026년에 취약점을 실제 공격에 활용하는 데 필요한 숙련된 작업이 저렴해졌지만, 패치 작업은 같은 속도로 빨라지지 않았다고 설명한다. 따라서 패치를 더 열심히 배포하는 것만으로는 공격과 수정 사이의 격차를 좁히기 어렵다는 것이 이들의 진단이다. 2
그렇다고 패치가 중요하지 않다는 뜻은 아니다. 영구적인 수정이 준비되고, 테스트를 거쳐, 실제 시스템에 배포되기 전까지 노출을 줄이는 방어가 함께 필요하다는 얘기다.
고칠 수 없는 시스템을 지키는 임시 방어
보고서가 든 PHP 사례는 소프트웨어를 곧바로 업데이트하기 어려운 상황을 보여준다. 에즈라의 설명에 따르면 10월에 PHP의 중대 취약점 두 건이 수정 사항보다 먼저 유출됐다. 보호 서비스의 범위 밖에 있는 PHP 설치본 260만~440만 개가 여전히 위험에 노출됐고, 이 가운데 대부분은 더 이상 수정 패치를 받을 수 없는 버전을 사용하고 있었다. 37
이처럼 모든 시스템에 패치를 빠르게 적용하기 어렵다면, 취약한 시스템 앞단에 방어 규칙을 배포해 공격을 막는 방법이 노출 기간을 줄일 수 있다. 보고서는 AI의 속도를 활용해 방어 규칙을 만들고 배포하는 방안을 제시하며, 대형 클라우드 플랫폼 바깥의 시스템에도 보호가 닿아야 한다고 강조한다. 2
37
다만 임시 방어는 취약한 소프트웨어를 고치는 일과 같지 않다. 가능한 경우 영구 패치를 적용해야 하며, 임시 보호 장치가 작동하지 않거나 사용할 수 없게 될 때의 위험도 고려해야 한다.
‘머신 속도’ 방어가 겨냥하는 분야
에즈라와 장은 보고서에서 차세대 보안 제품의 기회를 여섯 가지로 제시한다고 밝혔다. 1
2 다만 현재 확인할 수 있는 발췌 내용만으로는 여섯 범주를 하나씩 상세히 재구성하기 어렵다. 보고서를 요약한 2차 자료는 세분화, 기계 속도에 맞춘 탐지, 요청마다 이뤄지는 신원 확인, 검증된 백업, 공급망 통제 등을 주요 주제로 꼽는다.
34
이 주제들은 패치를 기다리는 동안 보안을 유지하는 여러 층의 방어를 가리킨다.
- 공격이 퍼지는 범위를 제한한다. 네트워크 분할 같은 통제 수단은 취약한 시스템 한 곳의 침해가 다른 곳으로 번지는 것을 막는 데 도움을 줄 수 있다.
34
- 탐지와 대응을 빠르게 한다. 공격 수단이 빠르게 만들어지는 환경에서는 위협을 신속히 알아차리고 보호 조치를 취하는 역량이 중요해진다.
2
- 접근 권한을 계속 확인한다. 한 번 로그인했다는 사실만으로 충분하다고 보지 않고, 요청이 들어올 때마다 신원을 확인하는 접근 방식이 제시됐다.
- 복구할 수 있는지 확인한다. 백업을 보유하는 데 그치지 않고 실제 복구가 가능한지 검증하는 것도 주요 주제다.
- 도입하는 소프트웨어와 의존성을 살핀다. 공급망 통제는 조직이 사용하는 소프트웨어나 도구를 통해 들어올 수 있는 위험을 줄이는 데 초점을 둔다.
이는 확인 가능한 자료에서 드러나는 큰 방향이지, 보고서가 제시한 여섯 범주를 완전하게 재현한 목록은 아니다. 경보 건수, 자격 증명 만료 주기, 랜섬웨어 관련 비율, 공개된 패치로부터 공격 코드가 만들어지는 정확한 시간 등 더 구체적인 주장은 현재 자료만으로 확인하기 어렵다.
결론은 ‘패치 대신 방어’가 아니라 ‘방어와 패치’
핵심은 패치와 다른 보안 대책 가운데 하나를 고르는 것이 아니다. 패치가 준비되는 동안 공격 가능성과 피해를 줄이고, 영구 수정이 가능해지면 이를 적용하고 제대로 반영됐는지 확인하는 식으로 두 접근을 함께 써야 한다. 1
2
특히 빠른 업데이트가 어려운 시스템에는 중간 단계의 방어가 중요할 수 있다. 하지만 PHP 사례에서 보듯 보호 범위 밖에 있거나 더 이상 패치를 받을 수 없는 설치본은 계속 위험에 노출될 수 있다. 임시 방어를 완전한 해결책으로 착각해서는 안 되는 이유다. 37
에즈라와 장이 말하는 변화는 취약점 검색을 더 빠르게 하는 데 그치지 않는다. 패치가 늦어지는 상황에서도 공격을 제한하고, 위험을 찾아내며, 접근을 통제하고, 사고 뒤 복구를 뒷받침하는 보안 체계를 갖추자는 주장이다.
Studio Global AI
연구를 계속하세요
이 페이지에는 Studio Global 내에서 계속할 수 있는 소스 기반 답변이 포함되어 있습니다.
사람들은 또한 묻습니다.
"취약점 공격은 빨라지는데 패치는 왜 그대로일까"에 대한 짧은 대답은 무엇입니까?
버라이즌의 2026년 자료에서 취약점 완전 조치까지 걸린 기간의 중앙값은 43일이었고, 이미 악용된 것으로 알려진 취약점 중 완전히 조치된 비율은 26%였다.
먼저 검증할 핵심 포인트는 무엇인가요?
버라이즌의 2026년 자료에서 취약점 완전 조치까지 걸린 기간의 중앙값은 43일이었고, 이미 악용된 것으로 알려진 취약점 중 완전히 조치된 비율은 26%였다. a16z의 아사프 에즈라와 스테파니 장은 취약점을 실제 공격에 활용하는 데 드는 수고는 줄었지만 패치는 더 빨라지지 않았다며, 패치가 준비되는 동안 시스템을 지킬 방어책이 필요하다고 주장한다.
실무에서는 다음으로 무엇을 해야 합니까?
PHP 사례는 패치를 받을 수 없는 시스템도 있다는 점을 보여준다. 임시 방어 규칙은 노출을 줄일 수 있지만, 취약한 소프트웨어를 영구적으로 고치는 일을 대신하지는 않는다.