AI đang thay đổi quy trình xử lý lỗ hổng bảo mật như thế nào?

Trí tuệ nhân tạo (AI) đang mang đến cho các nhà nghiên cứu bảo mật những phương thức mới để kiểm tra mã nguồn, truy vết các hành vi bất thường và xác định những lỗ hổng mà các công cụ truyền thống có thể bỏ sót. Áp lực này đặc biệt rõ rệt đối với các lỗ hổng Zero-day; một phân tích gần đây của Minimus đã xem xét cách thức cấu trúc container, hồ sơ phụ thuộc (dependency records) và tốc độ xây dựng lại ảnh hưởng đến phản ứng sau khi một lỗ hổng chưa xác định bị phơi bày. Việc phân tích nhanh hơn chỉ thực sự hữu ích khi các tổ chức có thể xác định được phần mềm dễ bị tổn thương đang chạy ở đâu.

AI đang tìm ra những lỗ hổng mà các công cụ truyền thống có thể bỏ lỡ

Vào tháng 5 năm 2026, Google Threat Intelligence Group đã báo cáo trường hợp đầu tiên mà họ tin rằng một tác nhân đe dọa đã sử dụng AI để hỗ trợ phát triển một mã khai thác Zero-day. Mã khai thác này xuất hiện trong một tập lệnh Python và vượt qua xác thực hai yếu tố trên một công cụ quản trị hệ thống mã nguồn mở được sử dụng rộng rãi khi đã có sẵn thông tin xác thực hợp lệ.

Các nhà nghiên cứu cho biết họ có độ tin cậy cao rằng một mô hình AI đã hỗ trợ cả việc phát hiện và vũ khí hóa lỗ hổng. Đánh giá của họ dựa trên các chú thích hướng dẫn chi tiết bất thường trong tập lệnh, điểm số lỗ hổng được tạo giả và phong cách lập trình có cấu trúc cao vốn gắn liền với kết quả đầu ra do AI tạo ra. Google không khẳng định rằng toàn bộ hoạt động này là tự động hoặc quy kết mã nguồn cho một mô hình cụ thể nào.

Bản thân lỗ hổng này là điều khiến vụ việc trở nên quan trọng. Nó liên quan đến một giả định tin cậy được mã hóa cứng (hard-coded trust assumption) thay vì lỗi treo máy, lỗi bộ nhớ hoặc đầu vào không an toàn. Các công cụ Fuzzer và phân tích tĩnh rất phù hợp để tìm ra nhiều vấn đề thực thi thông thường. Một mô hình ngôn ngữ cũng có thể kiểm tra cách các quyền, chức năng và hành vi dự kiến tương tác trên toàn bộ cơ sở mã. Điều đó tạo ra một con đường khác để tìm ra những mâu thuẫn logic mà không để lại dấu vết kỹ thuật rõ ràng.

Dữ liệu rộng hơn của Google cho thấy đây không phải là mối lo ngại cá biệt. Theo phân tích năm 2025 của Google Threat Intelligence Group, các nhà nghiên cứu đã theo dõi 90 lỗ hổng Zero-day bị khai thác trong thực tế trong năm 2025, so với 78 lỗ hổng vào năm 2024. Phần mềm và thiết bị doanh nghiệp chiếm 43 trường hợp, tương đương 48% tổng số. Cả hai con số này đều là mức kỷ lục trong tập dữ liệu của Google.

Các container phức tạp khiến việc truy vết sự phơi nhiễm trở nên khó khăn hơn

Khi một lỗ hổng được công khai, các đội ngũ bảo mật trước tiên phải xác định xem nó đang chạy ở đâu. Điều đó có thể rất khó khăn trong môi trường container. Một ảnh (image) có thể chứa các gói hệ điều hành, thư viện ứng dụng và các phụ thuộc được kế thừa từ ảnh cơ sở, cùng với các shell hoặc tiện ích ít liên quan đến mục đích hiển thị của khối lượng công việc.

Do đó, một thành phần dễ bị tổn thương có thể nằm sâu dưới ứng dụng vài lớp. Nó có thể xuất hiện trên vô số ảnh ngay cả khi tổ chức chưa bao giờ thêm nó vào một cách trực tiếp.

Log4Shell đã phơi bày vấn đề này trên quy mô lớn vào năm 2021. Thư viện Log4j bị ảnh hưởng đã được tích hợp vào hàng loạt sản phẩm và dịch vụ. Đối với nhiều tổ chức, việc có được bản vá chỉ mới là sự khởi đầu. Họ vẫn phải xác định từng máy chủ, ứng dụng và container chứa phiên bản dễ bị tổn thương trước khi có thể hoàn tất việc khắc phục.

Danh mục vật tư phần mềm (Software bills of materials) cung cấp hồ sơ rõ ràng hơn về những gì mỗi ảnh chứa đựng. Các ảnh nhỏ hơn cũng có thể giảm bớt phạm vi tìm kiếm bằng cách loại trừ các gói mà khối lượng công việc không cần đến. Minimus xem xét vấn đề này thông qua việc giảm thiểu gói, khả năng hiển thị phụ thuộc và việc xây dựng lại các ảnh sau khi một thành phần bị ảnh hưởng được công bố.

Lợi ích này đơn giản hơn việc ngăn chặn hoàn toàn các lỗ hổng Zero-day. Một ảnh tối giản vẫn có thể chứa một lỗ hổng chưa xác định. Nó giúp các đội ngũ có ít gói cần điều tra hơn, ít điểm phơi nhiễm tiềm ẩn hơn và ít phần mềm cần thay thế hoặc kiểm tra lại hơn khi vấn đề được biết đến.

Các bản vá do AI tạo ra vẫn cần ngữ cảnh phần mềm

AI cũng đang được sử dụng để rút ngắn thời gian giữa việc công bố và phát triển bản vá. Các mô hình có thể kiểm tra mã nguồn, so sánh các báo cáo lỗ hổng với hồ sơ gói và đề xuất thay đổi cho các phiên bản bị ảnh hưởng. Không điều nào trong số đó thực sự hữu ích khi hồ sơ gói đã lỗi thời hoặc không ai biết ảnh nào chứa thành phần dễ bị tổn thương.

Các bài viết trước đây về một tác nhân AI được thiết kế để tự động hóa việc sửa lỗi lỗ hổng đã trình bày chi tiết cách CodeMender của Google DeepMind đóng góp 72 bản vá bảo mật cho các dự án mã nguồn mở uy tín trong sáu tháng đầu tiên. Hệ thống này kết hợp khả năng suy luận của mô hình với phân tích tĩnh, kiểm thử thời gian thực và fuzzing để tạo ra và đánh giá các bản vá được đề xuất.

Những bản vá đó không được chấp nhận một cách tự động. Các nhà nghiên cứu là con người đã xem xét từng thay đổi trước khi nó được gửi đi, kiểm tra các lỗi hồi quy và xác nhận rằng nó giải quyết nguyên nhân gốc rễ thay vì chỉ là triệu chứng bề ngoài.

Ngay cả một thay đổi mã đã được phê duyệt cũng không hoàn thành công việc. Các đội ngũ phải xác định các ảnh bị ảnh hưởng, xây dựng lại chúng với phụ thuộc đã được sửa và kiểm tra kết quả trước khi triển khai. Trong một môi trường thiếu tài liệu, việc định vị mọi trường hợp có thể mất nhiều thời gian hơn cả việc tạo ra bản vá.

Các danh mục chính xác cung cấp cho các công cụ tự động những dữ liệu cụ thể để làm việc. Chúng kết nối một lỗ hổng mới được công bố với phiên bản gói, ảnh và khối lượng công việc thực sự cần được xử lý.

Tìm ra lỗ hổng có thể không còn là bước chậm nhất nữa

AI đang đẩy nhanh quá trình phân tích mã cho cả kẻ tấn công và người phòng thủ, nhưng nhiều sự chậm trễ vẫn xảy ra sau khi lỗ hổng đã được xác định. Một đội ngũ có thể mất hàng giờ để mở các ảnh và kiểm tra danh sách gói theo cách thủ công. Một đội ngũ khác có thể tìm kiếm trong danh mục hiện tại và thấy ngay lập tức khối lượng công việc nào chứa phiên bản bị ảnh hưởng.

Sự khác biệt đó không liên quan nhiều đến độ tinh vi của công cụ phát hiện. Nó đến từ các quyết định được đưa ra trước đó về danh mục phần mềm, cấu trúc ảnh và cách các container được xây dựng và thay thế. Khi nghiên cứu lỗ hổng diễn ra nhanh hơn, lợi thế thực tế sẽ thuộc về các tổ chức có thể xác định sự phơi nhiễm và triển khai bản sửa lỗi đã được kiểm tra mà không cần phải cố gắng tái cấu trúc lại những gì hệ thống của họ đang chứa.