Báo cáo khoảng cách về lỗ hổng bảo mật AI năm 2026 của Azul cho thấy doanh nghiệp đang vá lỗi chậm hơn các mối đe dọa AI

Báo cáo khoảng cách về lỗ hổng bảo mật AI năm 2026 của Azul cho thấy sự chênh lệch giữa tốc độ mà các lãnh đạo phụ trách bảo mật cho rằng kẻ tấn công có thể đạt được khi sử dụng AI và thời gian tổ chức của họ cần để triển khai bản sửa lỗi. Trong cuộc khảo sát 300 lãnh đạo phụ trách bảo mật tại Mỹ, 69% cho rằng kẻ tấn công có thể tạo ra một phương thức khai thác hoạt động được trong vòng ba ngày, trong khi 44% cho biết tổ chức của họ cần ít nhất bốn ngày để vá một lỗ hổng nghiêm trọng trên toàn bộ môi trường sản xuất.

Phát hiện đáng chú ý nhất của báo cáo là những trải nghiệm mà người trả lời liên hệ với tình trạng chậm trễ này: 85% cho biết từng gặp sự cố, nghi ngờ có sự cố hoặc suýt gặp sự cố do vá lỗi chậm. Con số này phản ánh trải nghiệm được báo cáo, không phải tỷ lệ vi phạm đã được xác minh độc lập — và cũng không chứng minh rằng AI đã gây ra những sự kiện đó.

Nghiên cứu do Azul ủy thác và Censuswide thực hiện, tập trung vào các tổ chức triển khai Java trên quy mô lớn. Thông điệp rộng hơn của nghiên cứu mang tính vận hành: phát hiện lỗ hổng mới chỉ là bước đầu. Bản sửa lỗi phải vượt qua khâu kiểm thử, đến được các hệ thống bị ảnh hưởng và khắc phục tình trạng phơi nhiễm trên toàn bộ môi trường mà các nhóm có thể chưa nắm rõ đầy đủ.

Hai mốc thời gian không khớp nhau

Khảo sát phân biệt kỳ vọng của các lãnh đạo về tốc độ của kẻ tấn công với khả năng triển khai bản vá của chính tổ chức họ:

• 69% cho rằng kẻ tấn công có trang bị AI có thể tạo ra phương thức khai thác trong vòng ba ngày trở xuống, trong đó 22% cho rằng thời gian này chưa đến 24 giờ.
• 56% cho biết họ có thể triển khai bản vá nghiêm trọng trên toàn bộ môi trường sản xuất trong vòng ba ngày: 13% trong chưa đầy 24 giờ và 43% trong vòng một đến ba ngày.
• 44% cần nhiều thời gian hơn: 32% cần từ bốn đến sáu ngày và 12% cần lâu hơn.

Đây là phân bố câu trả lời khảo sát, chứ không phải kết quả đo lường cuộc chạy đua giữa kẻ tấn công với từng tổ chức cụ thể trên cùng các lỗ hổng. Sự chênh lệch này củng cố mối lo ngại về mức độ sẵn sàng, nhưng không nên được hiểu là khoảng thời gian phơi nhiễm chính xác ba ngày đối với mọi doanh nghiệp.

Ở ngưỡng một ngày, sự mất cân đối tương tự cũng xuất hiện: 22% cho rằng kẻ tấn công có thể hành động nhanh đến vậy, so với 13% cho biết tổ chức của họ có thể triển khai bản sửa lỗi trong khoảng thời gian đó. Trong khi ấy, 59% thừa nhận các công cụ tấn công ứng dụng AI làm tăng mức độ phơi nhiễm, nhưng họ chưa thay đổi tư thế bảo mật.

Kiểm thử là một nguyên nhân lớn gây chậm trễ

Việc kiểm thử các bản cập nhật cho môi trường chạy Java khiến chu kỳ vá lỗi kéo dài thêm ít nhất bốn ngày tại 58% tổ chức tham gia khảo sát. Trong đó, 36% cho biết mất từ bốn đến sáu ngày, còn 22% cho biết mất một tuần trở lên. Thêm 33% cho biết mất từ một đến ba ngày, và 9% mất chưa đến 24 giờ. Không người trả lời nào cho biết họ bỏ qua khâu kiểm thử.

Những thay đổi đối với môi trường chạy có thể ảnh hưởng đến nhiều ứng dụng, vì vậy việc kiểm thử có mục đích thiết thực: một bản cập nhật bảo mật làm gián đoạn dịch vụ trọng yếu sẽ tạo ra thêm một vấn đề vận hành. Báo cáo cho rằng phạm vi cập nhật góp phần làm tăng gánh nặng này, bởi các bản phát hành OpenJDK hàng quý đầy đủ có thể bao gồm cả những thay đổi không liên quan đến bảo mật bên cạnh các bản sửa lỗ hổng.

Riêng Azul đã đánh giá 26 bản cập nhật OpenJDK hàng quý trong hơn sáu năm và xác định sáu bản gây ra lỗi hồi quy nghiêm trọng. Tỷ lệ 23% này là đánh giá các bản phát hành của nhà cung cấp, không phải ước tính từ khảo sát về tần suất ứng dụng của từng khách hàng gặp sự cố.

Trong số những trở ngại lớn nhất được nêu ra đối với việc vá lỗi nhanh hơn, 44% cho biết khâu kiểm thử kéo dài, 40% đề cập đến độ phức tạp hoặc tuổi đời của các hệ thống bị ảnh hưởng, và 36% nói đến khả năng quan sát hạn chế đối với các lỗ hổng đã biết. 25% đề cập đến sự chậm trễ trong việc nhà cung cấp phát hành bản vá. Xu hướng này cho thấy phần lớn thách thức khắc phục nằm ngay trong quy trình triển khai của doanh nghiệp.

Cần diễn giải riêng các báo cáo sự cố và khoảng trống kiểm kê

55% cho biết đã xảy ra sự cố được xác nhận là do vá lỗi chậm, và 53% cho biết đã suýt gặp sự cố. Người trả lời có thể chọn nhiều câu trả lời, vì vậy các con số này chồng lấn và không nên cộng lại. Con số tổng quát 85% được nêu trong tiêu đề cũng bao gồm các sự cố bị nghi ngờ.

Khảo sát không xác định được rằng tất cả những sự kiện đó đều liên quan đến lỗ hổng Java. Người tham gia làm việc tại các tổ chức sử dụng Java rộng rãi, nhưng nghiên cứu vừa có các câu hỏi về hoạt động vá phần mềm nói chung, vừa có các câu hỏi riêng về môi trường chạy Java.

Kiểm kê là một khó khăn khác. Chỉ 19% cho biết ít nhất 90% môi trường chạy Java trong hệ thống sản xuất của họ đã được cập nhật lên cấp độ bản vá bảo mật mới nhất. Điều đó có nghĩa là 81% chưa đạt ngưỡng này; không có nghĩa là 81% không có môi trường chạy nào được cập nhật. Khoảng một phần năm cho biết một nửa hoặc ít hơn môi trường của họ đã được cập nhật.

Ngoài ra, 51% thừa nhận họ chỉ nắm được một phần hoặc nắm rõ ở mức hạn chế về các môi trường chạy Java trọng yếu, bao gồm các phiên bản được nhúng, phiên bản cũ và phiên bản không được quản lý. Việc tìm một môi trường chạy có lỗ hổng bên trong ứng dụng được đóng gói hoặc vùng chứa có thể khó hơn so với việc xác định một bản cài đặt được quản lý tập trung. Bản vá không thể khắc phục tình trạng phơi nhiễm trên một hệ thống mà quy trình triển khai không bao giờ tiếp cận được.

Công nghệ của Azul bổ sung điều gì cho cuộc thảo luận này

Các giải pháp cập nhật bảo mật của Azul giới hạn một số bản phát hành ở các bản sửa lỗi bảo mật trên nền OpenJDK đã được ổn định trước đó. Công ty cung cấp các bản cập nhật hàng quý, hàng tháng có mục tiêu và ngoài chu kỳ, nhằm giảm lượng thay đổi không liên quan mà doanh nghiệp phải đánh giá khi triển khai một bản sửa lỗi khẩn cấp.

Đây là một biện pháp can thiệp kỹ thuật có phạm vi hẹp hơn so với việc loại bỏ nhu cầu kiểm soát thay đổi. Việc giới hạn các thay đổi mã có thể giảm phạm vi kiểm định, nhưng các bước kiểm tra dành riêng cho từng ứng dụng, trách nhiệm triển khai và việc chuẩn bị khôi phục phiên bản trước vẫn rất quan trọng. Azul là nhà tài trợ của báo cáo và bán các sản phẩm giải quyết những vấn đề mà báo cáo đo lường.

Các công cụ kiểm kê Java và phát hiện lỗ hổng của công ty giải quyết khía cạnh còn lại của quy trình: xác định môi trường chạy, phiên bản và mức độ phơi nhiễm để có thể đối chiếu một thông tin công bố mới với các hệ thống bị ảnh hưởng. Báo cáo không đưa ra phép so sánh có kiểm soát để chứng minh các tổ chức được khảo sát sẽ cải thiện được bao nhiêu nếu áp dụng những sản phẩm đó.

“Nghiên cứu của chúng tôi cho thấy các lãnh đạo phụ trách bảo mật hiểu rõ mối đe dọa: nhận thức không còn là khoảng trống; vấn đề nằm ở khâu thực thi,” Scott Sellers, đồng sáng lập kiêm CEO của Azul, cho biết.

Biến chủ trương vá lỗi thành quy trình có thể đo lường

Trong năm tới, 32% xác định việc vá lỗi nhanh hơn và thường xuyên hơn là chiến lược chính để giảm mức độ phơi nhiễm, trong khi 26% ưu tiên cải thiện việc kiểm kê phần mềm và môi trường chạy. Thêm 17% ưu tiên phát hiện và ứng phó thay vì vá lỗi nhanh hơn.

Nghiên cứu đề xuất theo dõi toàn bộ quy trình từ khi công bố thông tin đến khi khắc phục: những hệ thống nào bị ảnh hưởng, ai chịu trách nhiệm, cần kiểm thử những gì và liệu bản sửa lỗi đã thực sự được đưa vào môi trường sản xuất hay chưa. Thời hạn chỉ hữu ích khi các nhóm có thể xác minh việc hoàn tất trên toàn bộ hệ thống liên quan.

Các phát hiện tại Mỹ dựa trên nghiên cứu thực địa được tiến hành từ ngày 3–7 tháng 8 năm 2026, với sự tham gia của các lãnh đạo phụ trách bảo mật tại những tổ chức có ít nhất 1.000 nhân viên và sử dụng Java/JVM đáng kể trong môi trường sản xuất. Đây là các câu trả lời tự báo cáo từ một nhóm đối tượng xác định, chứ không phải kết quả điều tra toàn bộ doanh nghiệp hay phép đo trực tiếp hoạt động phát triển mã khai thác.

Báo cáo Khoảng cách về lỗ hổng AI năm 2026 cung cấp chi tiết về các phát hiện và phương pháp nghiên cứu. Hàm ý rõ ràng nhất là tốc độ vá lỗi và khả năng quan sát môi trường chạy cần được cải thiện đồng thời: bản sửa lỗi nhanh sẽ chỉ có giá trị hạn chế nếu tổ chức không thể xác định mọi hệ thống triển khai bị ảnh hưởng hoặc xác nhận bản cập nhật đã được áp dụng cho các hệ thống đó.