Google dùng AI xử lý lỗ hổng Chrome: Số lượng sửa lỗi trong tháng 6 vượt tổng 2 năm qua

30 tháng 7, 2026

Cách Chrome sử dụng AI để cải thiện việc phát hiện, phân loại và vá lỗ hổng bảo mật.

Đội ngũ Bảo mật Chrome

Chúng ta đang trải qua một sự thay đổi lớn trong ngành bảo mật phần mềm. Các Mô hình Ngôn ngữ Lớn (LLM) đang mở ra những khả năng chưa từng có cho việc tự động phát hiện lỗ hổng, vượt xa giới hạn của chuyên môn bảo mật con người, đồng thời đòi hỏi những phương pháp tiếp cận mới để luôn đi trước những kẻ tấn công.

Điều này đồng nghĩa với việc triển khai các mô hình AI trên quy mô lớn để tìm và sửa hàng trăm lỗi bảo mật, nhanh hơn bao giờ hết, với mục tiêu đạt được khả năng phục hồi tốt hơn và khắc phục toàn diện.

Đây là cách chúng tôi thực hiện điều đó.

Vòng đời của một lỗi bảo mật

Một số lỗi phần mềm có ảnh hưởng đến bảo mật. Trong khi một lỗi chức năng thuần túy có thể gây ra tình trạng treo giao diện khó chịu, thì một lỗi bảo mật (hay lỗ hổng) có thể bị lợi dụng để tạo ra mã khai thác (exploit). Các mã khai thác cho phép kẻ tấn công thực hiện những hành động độc hại trên máy tính của nạn nhân, chẳng hạn như đọc dữ liệu cá nhân hoặc kiểm soát máy tính của họ mà họ không hề hay biết.

Khi một lỗi bảo mật xâm nhập vào cơ sở mã (codebase), vòng đời của nó sẽ diễn ra như sau:

Mục tiêu của chúng tôi là làm cho mỗi bước này diễn ra nhanh nhất có thể.

Phát hiện lỗ hổng

Đội ngũ Bảo mật Chrome đã sử dụng LLM trong nhiều năm. Năm 2023, chúng tôi đã phát triển các phương pháp sử dụng LLM để tăng độ bao phủ và hiệu suất của kỹ thuật fuzzing bảo mật. Năm 2024, chúng tôi đã hợp tác với Project Zero trong dự án Naptime, cung cấp cho các LLM những công cụ chuyên dụng để nghiên cứu lỗ hổng. Và vào năm 2025, chúng tôi đã hợp tác với DeepMind và Project Zero trong dự án Big Sleep, một tác nhân AI phát hiện lỗ hổng đã tìm thấy thành công các lỗi trong công cụ V8 JavaScript và ngăn xếp đồ họa.

Đầu năm 2026, chúng tôi đã xây dựng một hệ thống tác nhân sử dụng Gemini để tìm kiếm lỗ hổng trên toàn bộ cơ sở mã Chrome với hiệu quả cao hơn và tỷ lệ cảnh báo sai thấp hơn. Một trong những lỗi chúng tôi tìm thấy là lỗi thoát sandbox (sandbox escape), cho phép một trình kết xuất (renderer) bị xâm nhập đánh lừa trình duyệt để đọc các tệp tin cục bộ — một lỗi đã tồn tại âm thầm trong cơ sở mã của chúng tôi hơn 13 năm! Đối với nhiều người trong chúng tôi, khoảnh khắc này đã khẳng định tiềm năng của việc phát hiện lỗ hổng bằng AI.

Từ đó, chúng tôi đã cải tiến hệ thống tác nhân phát hiện lỗ hổng của mình bằng cách:

Chúng tôi đã xây dựng tất cả những điều này với sự chú trọng đến tính an toàn và thiết lập các rào chắn để giảm thiểu rủi ro khi AI hoạt động ngoài ý muốn. AI của chúng tôi phân tích mã nguồn ở trạng thái tĩnh, vận hành trên các máy tính được khóa chặt, không có quyền truy cập internet thông thường. Chúng tôi cũng sử dụng một thiết lập chuyên dụng cho các quá trình quét nội bộ này để chặn tất cả các yêu cầu mạng, áp dụng danh sách cho phép (allowlist) nghiêm ngặt dựa trên ứng dụng khởi tạo và đích đến, nhằm chặn mọi hoạt động đáng ngờ của mô hình. Hơn nữa, chúng tôi không bao giờ chạy các mô hình ở chế độ không hạn chế và kiểm soát chặt chẽ việc các tác nhân phụ sửa đổi hệ thống cục bộ hoặc truy cập các tệp tin bên ngoài các thư mục mã nguồn được chỉ định.

Việc phát hiện lỗ hổng bằng AI bổ sung cho cơ sở hạ tầng kiểm thử bảo mật hiện có của chúng tôi. Ví dụ, kỹ thuật fuzzing vẫn đặc biệt hiệu quả trong việc tìm ra các lỗi phát sinh từ sự tương tác tầm xa giữa các phần khác nhau trong cơ sở mã, hoặc những lỗi đòi hỏi sự kết hợp của các thao tác tưởng chừng như không liên quan.

Chúng tôi cũng muốn tiếp tục khen thưởng các nhà nghiên cứu bên ngoài vì chuyên môn và sự sáng tạo của họ trong việc tìm ra những lỗ hổng thách thức và có tác động lớn nhất thông qua Chương trình Phần thưởng Lỗ hổng (VRP) của Chrome. Đầu năm 2026, chúng tôi nhận thấy sự gia tăng dần dần trong tất cả các danh mục báo cáo lỗi, nhưng đến tháng 3, sự thay đổi đã trở nên rõ rệt: chúng tôi nhận được nhiều báo cáo lỗi hơn so với tổng số của cả năm 2025. Điều này khiến chúng tôi thay đổi VRP để tập trung các nhà nghiên cứu vào việc gửi các lỗi bổ sung cho những gì chúng tôi đang tìm thấy nội bộ, và dễ dàng được xử lý bởi các quy trình tự động mới của chúng tôi.

Phân loại lỗ hổng

Khi khám phá thêm nhiều lỗ hổng bảo mật bằng các công cụ hỗ trợ AI, chúng tôi đồng thời sử dụng AI để mở rộng quy mô và tự động hóa việc xác thực, phân loại và sửa lỗi. Trước đây, việc phân loại một báo cáo bảo mật đơn lẻ mất từ 5 đến 30 phút hoặc lâu hơn, và chủ yếu dựa vào chuyên môn của con người. Chúng tôi đang ngày càng chuyển dịch quy trình phân loại sang phương pháp tự động, kết hợp các hệ thống dựa trên quy tắc với AI để tăng lưu lượng xử lý và độ chính xác.

Quy trình phân loại tự động được chia thành bốn giai đoạn chính:

Mặc dù khó đo lường chính xác, chúng tôi ước tính rằng quy trình mới này giúp tiết kiệm hàng trăm giờ làm việc của lập trình viên mỗi tháng, cho phép đội ngũ của chúng tôi tập trung vào các ưu tiên bảo mật khác.

Sửa lỗi lỗ hổng

Trên toàn bộ Google, các lập trình viên chia sẻ trách nhiệm ưu tiên sửa lỗi bảo mật với đội ngũ bảo mật, nhưng việc mở rộng quy mô phát hiện lỗi đòi hỏi một quy trình sửa lỗi có khả năng mở rộng tương đương.

Để đạt được điều này, chúng tôi dựa vào các quy trình làm việc đa tác nhân xuyên suốt:

Tại thời điểm này, chúng tôi đã có các LLM tạo ra các bản sửa lỗi tiềm năng cho hầu hết các lỗ hổng, làm tăng đáng kể tốc độ sửa lỗi bảo mật trong các bản phát hành Chrome gần đây:

Số lượng lỗi bảo mật đã được sửa trong các cột mốc phát hành Chrome Stable gần đây

Trong hai cột mốc gần nhất, Chrome 149 và 150, chúng tôi đã sửa 1072 lỗi bảo mật, vượt qua tổng số lỗi bảo mật đã sửa trong 23 cột mốc trước đó cộng lại.

Chúng tôi đã hợp tác chặt chẽ với Google DeepMind và Project Zero trong nhiều năm, bao gồm cả các dự án BigSleep và CodeMender. Các công cụ này được tích hợp nguyên bản vào hệ thống tích hợp liên tục (CI) của chúng tôi, chạy mỗi 24 giờ trên tất cả các CL để chủ động phát hiện lỗi bảo mật. Sự tích hợp này đã mang lại kết quả đáng kể: chỉ riêng trong tháng 5, chúng tôi đã ngăn chặn hơn 20 lỗ hổng tiếp cận môi trường sản xuất, bao gồm cả một vấn đề nghiêm trọng cấp độ S1+.

Phát hành bản sửa lỗi

Một khi bản sửa lỗi đã được áp dụng và hiển thị trên cơ sở mã nguồn mở công khai, kẻ tấn công có thể bắt đầu kỹ thuật đảo ngược và khai thác lỗi trước khi bản sửa lỗi đến được máy tính của người dùng — đây được gọi là các cuộc tấn công "N-day". Điều này thường được gọi là "khoảng cách vá lỗi" (patch gap). Vì các bản sửa lỗi được cam kết vào "cây" chính thường mất vài tuần để đến được kênh Chrome Stable (nơi đại đa số người dùng của chúng tôi sử dụng), việc giảm thiểu khoảng cách vá lỗi này là một phần quan trọng trong chiến lược của chúng tôi.

Dựa trên mức độ nghiêm trọng, các bản sửa lỗi bảo mật được hợp nhất trực tiếp từ "cây" chính vào nhánh phát hành Chrome ổn định đang hoạt động, vốn được giám sát liên tục để ngăn chặn các sự cố treo hoặc lỗi hồi quy mới. Chúng tôi đang trong quá trình chuyển đổi sang chu kỳ hai tuần cho các cột mốc lớn của Chrome, với các bản cập nhật bảo mật hàng tuần. Tuy nhiên, trước các cuộc tấn công nhanh chóng và được hỗ trợ bởi AI, tốc độ phân phối của chúng tôi phải tăng tốc hơn nữa. Để đáp ứng yêu cầu này, chúng tôi đang thí điểm chuyển sang hai bản phát hành bảo mật mỗi tuần.

Ngay cả với tốc độ này, việc công bố công khai phù hợp vẫn là tối quan trọng. Mọi lỗi bảo mật đến được Chrome Stable, bất kể là được phát hiện nội bộ hay được báo cáo từ bên ngoài, đều được ghi lại và công bố công khai như một phương pháp thực hành tốt nhất tiêu chuẩn. Chúng tôi đang nỗ lực tự động hóa việc tạo ghi chú phát hành và mô tả CVE từ các bản sửa lỗi bảo mật để loại bỏ các nút thắt thủ công và rút ngắn khoảng thời gian giữa việc phát hiện lỗ hổng và công bố công khai.

Áp dụng cập nhật

Năm 2008, Chrome đã tiên phong trong khái niệm cập nhật phần mềm thầm lặng, chạy ngầm: các tệp nhị phân mới được tự động tải xuống và lưu trữ trên đĩa với sự can thiệp tối thiểu của người dùng. Ở lần khởi động lại trình duyệt tiếp theo, bản cập nhật sẽ được áp dụng và người dùng sẽ được bảo vệ. Tuy nhiên, so với 1–2 ngày cần thiết để phân loại, sửa lỗi, kiểm thử và phát hành, thời gian chờ người dùng khởi động lại Chrome có thể là một yếu tố đóng góp đáng kể vào rủi ro khai thác N-day.

Mọi người có những lý do dễ hiểu để trì hoãn việc khởi động lại Chrome. Việc khởi động lại có thể gây gián đoạn, đòi hỏi phải sắp xếp giữa các công việc và hiếm khi là ưu tiên hàng đầu tại bất kỳ thời điểm nào. Để loại bỏ sự bất tiện này, chúng tôi đang tiên phong tìm cách chuyển gánh nặng khỏi người dùng bằng cách:

Tự động khởi động lại không cửa sổ (zero window) trên macOS