By ITCuli

Is Patching Dead? Vulnerability Management in the Post-Mythos Era

Is Patching Dead? Vulnerability Management in the Post-Mythos Era

Is patching really dead?

Bài của SecurityWeek không nói rằng doanh nghiệp nên ngừng vá lỗi. Ý chính là mô hình vá từng CVE theo lịch cố định đã không còn đủ nhanh trước tốc độ phát hiện và khai thác lỗ hổng bằng AI. Sự kiện nền là Gold Eagle, một sáng kiến của Nhà Trắng dùng AI tiên tiến để phát hiện, xếp hạng và phối hợp xử lý lỗ hổng trong chính phủ, hạ tầng trọng yếu và phần mềm nguồn mở. Khi chính phủ phải dùng AI để tìm và ưu tiên lỗ hổng ở quy mô quốc gia, đó là tín hiệu rằng cách làm thủ công hai thập kỷ qua đã tới giới hạn.

Điều đáng lo là khả năng tìm lỗi không chỉ nằm trong tay phòng thủ. Bài nhắc Mythos có thể phát hiện lỗ hổng rất sâu, từ lỗi crash từ xa 27 năm tuổi trong OpenBSD tới chuỗi lỗi kernel Linux leo thang quyền kiểm soát hệ thống. Khoảng 50 đối tác Project Glasswing của Anthropic đã tìm hơn 10.000 lỗ hổng mức high hoặc critical. Khi các mô hình tương tự được công khai hoặc lọt vào tay attacker, cuộc đua “đọc CVE rồi vá kịp trước khi bị khai thác” trở nên kém thực tế hơn nhiều.

Vulnerability management phải chuyển từ vá theo danh sách sang ưu tiên theo rủi ro thật

Why companies need to change vulnerability management

SecurityWeek đưa ra các con số rất đáng chú ý. Sysdig từng quan sát attacker khai thác một CVE trong vòng 20 giờ sau khi công bố, dù chưa có proof-of-concept công khai. Mandiant ước tính mean time to exploit có thể âm 7 ngày, nghĩa là nhiều khai thác xuất hiện trước khi lỗ hổng được công bố rộng rãi. Trong khi đó, Verizon DBIR 2026 nói thời gian trung vị để sửa lỗi đã bị khai thác là 43 ngày, tăng từ 32 ngày, và chỉ 26% lỗ hổng từng được vá hoàn toàn. FIRST dự báo khoảng 59.000 CVE mới trong năm 2026, hơn 160 CVE mỗi ngày, với lỗi RCE tăng 130%.

Những con số này dẫn tới kết luận thực tế: không đội nào đủ người để vá mọi thứ ngay lập tức. Câu hỏi đúng không còn là “CVE này điểm CVSS bao nhiêu” mà là “nó có nằm trên tài sản public không, có thể tự động khai thác không, có dẫn tới kiểm soát toàn phần không, và trong kiến trúc của mình attacker có đi tới dữ liệu quan trọng không”. Đây là hướng mà CISA BOD 26-04 theo đuổi khi thay cách nhìn KEV bằng mô hình ưu tiên theo rủi ro thực tế.

5 concrete points from the source

  • Gold Eagle dùng AI cho điều phối lỗ hổng cấp quốc gia. Sáng kiến có Treasury, DHS, DoD, đối tác nguồn mở và nhà vận hành hạ tầng trọng yếu.
  • Mythos cho thấy AI có thể tìm lỗi mà công cụ cũ bỏ sót. Ví dụ gồm OpenBSD, Linux kernel và nhiều lỗi high/critical trong phần mềm thiết yếu.
  • Attacker khai thác nhanh hơn lịch vá truyền thống. Có trường hợp khai thác trong 20 giờ sau khi CVE xuất hiện, không cần PoC công khai.
  • Khối lượng CVE vượt khả năng xử lý thủ công. Dự báo 59.000 CVE trong năm 2026 khiến việc xử lý từng lỗi bằng tay trở nên thiếu bền vững.
  • Ngành đang chuyển sang exposure management và adversarial exposure validation. Mục tiêu là biết thứ gì thật sự khai thác được, kiểm soát nào còn hiệu lực và đường tấn công nào chạm tài sản quan trọng.
AI làm tốc độ khai thác vượt xa lịch vá truyền thống

Action checklist for security teams

  • Đo thời gian vá thực tế trong 90 ngày gần nhất cho CVE critical, không dùng SLA trên giấy.
  • Phân loại tài sản public, tài sản chứa dữ liệu nhạy cảm, hệ thống legacy và dịch vụ ít chủ sở hữu rõ ràng.
  • Áp dụng 3 nhóm xử lý: incident response cho lỗi đang bị khai thác trên hệ public, accelerated remediation cho lỗi critical có khả năng khai thác cao, standard maintenance cho phần còn lại.
  • Kiểm tra exploit path: lỗ hổng có thật sự tới được dữ liệu hoặc quyền kiểm soát quan trọng trong môi trường của mình không.
  • Chạy tabletop exercise cho vá khẩn cấp ngoài giờ; đo thời gian phê duyệt của vận hành, pháp chế, lãnh đạo và chủ hệ thống.
  • Đánh giá scanner AppSec với code do AI tạo; thứ scanner bỏ sót là nợ kỹ thuật mới.
  • Giới hạn quyền của non-human identity như service account, API key và AI agent để giảm blast radius khi có lỗ hổng.

Implementation notes

Đổi sang risk-based vulnerability management không có nghĩa là bỏ qua lỗ hổng điểm thấp. Nó nghĩa là đội bảo mật phải có ngữ cảnh tốt hơn để quyết định thứ gì cần xử lý ngay. Một CVSS 9.8 trong thư viện không chạy, không public, không có dữ liệu nhạy cảm phía sau có thể ít khẩn cấp hơn một lỗi điểm thấp hơn nhưng nằm trên VPN, identity provider hoặc service đang bị scan hàng loạt. Muốn làm được, CMDB phải đúng hơn, cloud inventory phải gần thời gian thực hơn và dữ liệu từ EDR, WAF, ASM, scanner, CI/CD phải được nối lại.

Cũng cần nhìn sang phía phòng ngừa. Nếu AI coding assistant làm tăng tốc độ sinh code nhưng không tăng chất lượng review, pipeline sẽ nhận thêm lỗ hổng mới. Đưa phát hiện vào IDE, kiểm tra dependency, policy-as-code và test bảo mật trong CI/CD giúp giảm lỗi trước khi ship. Đây là phần SecurityWeek nhấn mạnh: tổ chức sống sót không phải tổ chức vá nhanh nhất mọi CVE, mà là tổ chức thu hẹp bề mặt tấn công, ưu tiên đúng thứ có thể bị khai thác, chứng minh kiểm soát còn hoạt động và ngăn code lỗi đi vào production.

Checklist chuyển sang vulnerability management dựa trên rủi ro

Conclusion

Patching chưa chết, nhưng vá lỗi kiểu cũ không còn đủ. AI làm cả phòng thủ lẫn tấn công tăng tốc, trong khi doanh nghiệp vẫn mất hàng chục ngày để sửa lỗi đã bị khai thác. Cách đi hợp lý là kết hợp vá nhanh cho trường hợp thật sự nguy hiểm, quản lý exposure, kiểm chứng đường tấn công, giảm quyền của tài khoản tự động và đưa bảo mật vào sớm trong phát triển phần mềm. Nếu vẫn quản lý lỗ hổng bằng bảng CVE dài và SLA chung chung, đội bảo mật sẽ luôn chậm hơn attacker.

Source: SecurityWeek