- Chrome tự động hóa từ phát hiện lỗ hổng đến phân loại, sửa, phát hành và áp dụng bản cập nhật bằng tác nhân dựa trên Gemini; trong Chrome 149 và 150, họ đã sửa 1.072 lỗi bảo mật, nhiều hơn tổng số của 23 milestone trước đó
- Hệ thống phát hiện lỗ hổng kết hợp nhiều mô hình, cơ sở tri thức dựa trên CVE và lịch sử Git của Chrome, SECURITY.md, cùng một tác nhân phản biện riêng, vận hành trong môi trường hạn chế nghiêm ngặt quyền truy cập Internet và hệ thống cục bộ
- Phân loại tự động thực hiện loại bỏ spam/trùng lặp, tái hiện lỗi và thu thập stack trace, bổ sung metadata như mức độ nghiêm trọng, phân công người phụ trách, ước tính giúp giảm hàng trăm giờ làm việc của nhà phát triển mỗi tháng
- Để thu hẹp khoảng cách vá lỗi từ khi công bố bản sửa đến khi bị khai thác, Chrome đang thử nghiệm phát hành bảo mật hai lần mỗi tuần, đồng thời phát triển vá động thay thế tiến trình con mà không cần khởi động lại và tự động khởi động lại trên macOS
- Không chỉ sửa từng lỗi riêng lẻ, Chrome còn tăng cường an toàn bộ nhớ bằng MiraclePtr,
std::spanvà Rust; ngăn lỗ hổng lọt vào bằng kiểm tra AI tại thời điểm gửi mã và tự động cập nhật hơn 2.300 phụ thuộc bên ngoài
Vòng đời lỗi bảo mật được AI thay đổi
- LLM đã mở rộng phát hiện lỗ hổng tự động vượt quá quy mô mà chỉ chuyên môn bảo mật của con người có thể xử lý, và Chrome dùng AI để tìm và sửa hàng trăm lỗi bảo mật nhanh hơn
- Trong khi lỗi tính năng thông thường có thể gây ra các vấn đề như giao diện bị treo, lỗi bảo mật có thể bị dùng trong exploit để kẻ tấn công đọc dữ liệu cá nhân hoặc bí mật điều khiển máy tính của người dùng
- Lỗi bảo mật được xử lý theo trình tự: phát hiện, phân loại, sửa, phát hành Chrome có chứa bản sửa, rồi người dùng khởi động lại trình duyệt và áp dụng; mục tiêu là rút ngắn tối đa mọi bước
Mở rộng phát hiện lỗ hổng
- Nhóm bảo mật Chrome đã phát triển công nghệ phát hiện dựa trên LLM qua nhiều năm
- Năm 2023, họ phát triển cách tăng phạm vi và hiệu năng của fuzzing bảo mật
- Năm 2024, họ cùng Project Zero phát triển Naptime, cung cấp cho LLM các công cụ chuyên dụng để nghiên cứu lỗ hổng
- Năm 2025, họ cùng DeepMind và Project Zero phát triển Big Sleep; tác nhân này đã phát hiện lỗi trong engine JavaScript V8 và stack đồ họa
- Harness tác nhân Gemini được xây dựng đầu năm 2026 nâng cao hiệu quả phát hiện và giảm báo cáo sai trên phạm vi codebase Chrome rộng hơn
- Lỗi thoát sandbox được phát hiện có thể cho phép một renderer bị xâm phạm đánh lừa trình duyệt đọc tệp cục bộ, và đã tồn tại trong mã hơn 13 năm
- Harness phát hiện được bổ sung các chức năng sau
- Khả năng tương tác giữa các mô hình, tận dụng điểm mạnh của cả mô hình open-weight và mô hình độc quyền
- Cơ sở tri thức gồm toàn bộ CVE hiện có và toàn bộ lịch sử Git của Chrome
- Hướng dẫn viết SECURITY.md để truyền đạt rõ ràng ranh giới tin cậy và mô hình đe dọa
- Tác nhân phản biện đọc SECURITY.md trong ngữ cảnh riêng
- Quét lặp lại codebase để phản ánh tính phi tất định của mô hình và sự cải thiện theo thời gian
- AI chỉ phân tích mã nguồn đã lưu trữ trên thiết bị khóa, không thể truy cập Internet công cộng
- Mọi yêu cầu mạng đều bị chặn để áp dụng danh sách cho phép dựa trên ứng dụng và đích đến
- Không chạy mô hình ở chế độ không giới hạn; hạn chế thay đổi hệ thống của tác nhân con và quyền truy cập tệp ngoài thư mục nguồn được chỉ định
- Phát hiện bằng AI không thay thế các kiểm thử bảo mật hiện có
- Fuzzing đặc biệt hiệu quả với lỗi phát sinh từ tương tác tầm xa giữa các vùng mã cách xa nhau hoặc từ tổ hợp nhiều thao tác tưởng như không liên quan
- Nhà nghiên cứu bên ngoài tiếp tục được thưởng khi tìm các lỗ hổng khó và có tác động lớn thông qua Chrome Vulnerability Reward Program
- Đầu năm 2026, số báo cáo thuộc mọi loại đều tăng; riêng tháng 3 nhận được nhiều báo cáo lỗi hơn cả năm 2025
- Vì vậy, Chrome đã thay đổi VRP để tập trung vào các báo cáo tạo thêm giá trị so với kết quả phát hiện nội bộ và dễ được pipeline xử lý tự động tiếp nhận
Phân loại tự động và sửa lỗi bằng đa tác nhân
- Trước đây, phân loại một báo cáo bảo mật mất từ 5 phút đến hơn 30 phút và chủ yếu dựa vào chuyên môn con người; hiện nay Chrome kết hợp hệ thống dựa trên quy tắc với AI để tăng thông lượng và độ chính xác
- Phân loại tự động diễn ra qua bốn bước
- Loại bỏ spam và trùng lặp, kiểm tra xem báo cáo có đáp ứng tiêu chí tiếp nhận và có mô tả rõ ràng về lỗ hổng bảo mật Chrome hay không
- Xác nhận proof-of-concept và khả năng tái hiện, thử nghiệm trên hệ điều hành và phiên bản trình duyệt tương ứng, rồi đính kèm thông tin như stack trace
- Bổ sung thời điểm lỗi lần đầu được đưa vào và mức độ nghiêm trọng
- Tinh chỉnh rõ ràng hướng dẫn mức độ nghiêm trọng để dễ áp dụng tự động
- Nhà phát triển có thể thay đổi mức độ nghiêm trọng không chính xác và bổ sung thông tin ranh giới bảo mật bằng SECURITY.md
- Tự động gán vấn đề cho đúng thành phần và người phụ trách
- Tuy khó đo lường chính xác, Chrome ước tính phân loại tự động giúp giảm hàng trăm giờ làm việc của nhà phát triển mỗi tháng
- Quy trình sửa lỗ hổng áp dụng luồng làm việc đa tác nhân
- Tác nhân sửa lỗi nhận ngữ cảnh theo từng vấn đề và tạo nhiều bản vá ứng viên
- Tác nhân phản biện đánh giá ứng viên phù hợp nhất và tạo đầu ra cần thiết cho nhà phát triển xem xét
- Hai tác nhân thực hiện các vòng lặp tương tự code review để kiểm tra hành vi chức năng, phong cách Chromium/Google và việc tuân thủ quy ước mã cục bộ
- Tác nhân viết kiểm thử xác minh kiểm thử trên toàn bộ nền tảng và cấu hình Chrome hỗ trợ trước khi nhà phát triển review, tiết kiệm tối đa nhiều tuần
- Hiện phần lớn lỗ hổng đều có bản sửa ứng viên do LLM tạo ra
- Trong Chrome 149 và 150, Chrome đã sửa 1.072 lỗi bảo mật, vượt tổng số của 23 milestone trước đó
- Big Sleep và CodeMender, phối hợp với DeepMind và Project Zero, đã được tích hợp vào CI để kiểm tra mọi CL mỗi 24 giờ
- Chỉ trong tháng 5, hơn 20 lỗ hổng, gồm cả vấn đề nghiêm trọng S1+, đã bị chặn trước khi tới production
Rút ngắn khoảng cách vá lỗi và áp dụng cập nhật
- Khoảng thời gian sau khi mã sửa được đưa vào kho mã nguồn mở công khai nhưng trước khi được phân phối tới người dùng, trong đó kẻ tấn công có thể reverse-engineer và khai thác, được gọi là khoảng cách vá lỗi cho tấn công N-day
- Các bản sửa được đưa vào main tree thường mất vài tuần để tới kênh Stable mà phần lớn người dùng sử dụng
- Tùy mức độ nghiêm trọng, bản sửa được merge trực tiếp vào nhánh phát hành Stable hiện tại và Chrome tiếp tục theo dõi xung đột hoặc regression mới
- Khi chuyển các milestone Chrome chính sang chu kỳ 2 tuần, Chrome đang cung cấp cập nhật bảo mật hằng tuần
- Để ứng phó tốc độ tấn công dựa trên AI, Chrome cũng đang thử nghiệm phát hành bảo mật hai lần mỗi tuần
- Mọi lỗi bảo mật tới Stable đều được ghi nhận công khai, bất kể do nội bộ hay bên ngoài phát hiện
- Chrome đang phát triển việc tự động tạo release note và mô tả CVE từ bản vá để loại bỏ nút thắt thủ công và giảm thời gian từ phát hiện đến công bố
- Từ năm 2008, Chrome đã dùng cập nhật tự động: tải binary mới trong nền, chuẩn bị sẵn và áp dụng ở lần khởi động lại tiếp theo
- Phân loại, sửa, kiểm thử và phát hành mất 1–2 ngày, nhưng thời gian chờ người dùng khởi động lại cũng có thể góp phần lớn vào rủi ro khai thác N-day
- Khởi động lại làm gián đoạn công việc và phải được sắp lịch riêng, nên người dùng dễ trì hoãn
- Chrome đang phát triển các tính năng để không chuyển gánh nặng khởi động lại sang người dùng
- Vá động tận dụng kiến trúc đa tiến trình của Chrome để lần lượt thay thế các tiến trình con chạy nền như Renderer và GPU bằng binary mới, với mục tiêu loại bỏ việc khởi động lại toàn bộ trình duyệt trong hầu hết trường hợp
- Chrome đang xem xét lưu thêm trạng thái cục bộ để có thể khôi phục phiên ngay cả trong các tình huống phức tạp
- Tự động khởi động lại tại thời điểm bảo đảm có thể khôi phục phiên hoàn chỉnh
- Chrome 150 phát hiện trên macOS khi tất cả cửa sổ đã đóng nhưng ứng dụng vẫn còn ở nền, và tự động khởi động lại nếu có bản cập nhật đang chờ
- Về dài hạn, mục tiêu là trình duyệt luôn ở trạng thái mới nhất, kết hợp vá động liên tục với tự động khởi động lại vào thời điểm ít gây gián đoạn
- Khuyến nghị cho quản trị viên IT doanh nghiệp như sau
- Dùng chính sách RelaunchNotification để áp dụng theo từng bước từ thông báo đến bắt buộc khởi động lại sau một khoảng thời gian định sẵn
- Trong môi trường nhạy cảm cần xác minh thay đổi, dùng Chrome Extended Stable Channel
- Theo dõi phiên bản trình duyệt toàn diện và quản lý cập nhật chi tiết bằng dashboard độc lập hệ điều hành của Chrome Enterprise Core hoặc Premium
Phòng thủ C++ và chuyển sang Rust
- Chrome dùng chiến lược kép: vô hiệu hóa lỗ hổng C++ hiện có ở runtime, đồng thời về dài hạn chuyển sang ngôn ngữ an toàn bộ nhớ
- Vì phần lớn mã Chromium là C++, toolchain và biện pháp giảm thiểu runtime là tuyến phòng thủ đầu tiên tức thời
- Chrome đã giảm lỗ hổng Use-After-Free (UAF) bằng thư viện mẫu chuẩn được gia cố và các công nghệ thuộc họ MiraclePtr
- Lộ trình phòng thủ C++ gồm ba trục
- Mở rộng MiraclePtr và MiracleObject
- Mở rộng MiraclePtr sang Skia, ANGLE, Dawn, iterator C++ và container
std:: - MiracleObject đặt mục tiêu đánh đổi hiệu năng runtime cục bộ lấy an toàn theo thời gian, vô hiệu hóa tới 90% lỗ hổng UAF trên luồng chính GPU
- Mở rộng MiraclePtr sang Skia, ANGLE, Dawn, iterator C++ và container
- Chuyển sang
std::span- Thay cấu trúc cũ dùng kèm pointer và kích thước bằng
std::spando compiler kiểm tra, để loại bỏ truy cập ngoài biên (OOB) - 97% mã riêng của Chrome biên dịch không vấn đề với cảnh báo unsafe-buffer nghiêm ngặt, và yêu cầu này đang được mở rộng sang Skia, ANGLE và Dawn
- Thay cấu trúc cũ dùng kèm pointer và kích thước bằng
- Gia cố cấu trúc và cấp phát
- Áp dụng checked math cho tính toán cấp phát bộ nhớ để chặn đường dẫn tràn số nguyên
- Tăng cường heap partitioning để tách nghiêm ngặt kiểu chứa pointer và kiểu không chứa pointer, khiến việc khai thác UAF khó hơn
- Mở rộng MiraclePtr và MiracleObject
- Chrome cho rằng hiệu quả biên của các biện pháp giảm thiểu runtime cho C++ sẽ giảm trong vài năm tới
- Kiểm tra runtime tốn kém hơn bảo đảm tại thời điểm biên dịch, và ngay cả binary C++ được gia cố mạnh vẫn cần sandbox nghiêm ngặt làm hạn chế hiệu năng để tuân thủ Rule of Two
- Về dài hạn, Chrome thúc đẩy chuyển sang Rust
- Rust flywheel: xây dựng SDK trung tâm cung cấp trực tiếp API và công cụ dựa trên Chromium cho Rust, để Rust có thể trở thành lựa chọn hằng ngày cho thành phần mới
- Loại bỏ vùng tập trung lỗi: thay thế có chiến lược các đoạn mã từng có mật độ lỗi cao như parser dữ liệu phức tạp, codec hình ảnh, stack font
- Mô-đun hóa đặc quyền cao: viết module mới bằng Rust để chạy chức năng phức tạp trong vùng đặc quyền cao như tiến trình trình duyệt mà không chịu chi phí hiệu năng của sandbox
- Chrome cũng đang xem xét triển khai UI cấp cao nhất của trình duyệt bằng HTML, CSS và TypeScript để giảm thêm phụ thuộc vào framework C++ hiện có
Chặn lỗ hổng trước khi gửi mã
- Chỉ quét định kỳ toàn bộ codebase khó theo kịp tốc độ phát triển nhanh của Chrome, nên Chrome đặt kiểm tra AI gần thời điểm gửi mã
- Mô hình phòng thủ của CI và commit queue (CQ) tự động kiểm tra phần thay đổi
- Đề xuất bản sửa chuyển sang
std::span - Đánh dấu dangling pointer
- Bắt buộc an toàn trong phép toán số
- Đề xuất bản sửa chuyển sang
- Ngay cả mã độc lập có vẻ an toàn cũng có thể trở thành vấn đề bảo mật tiềm ẩn nghiêm trọng khi kết hợp với thay đổi logic nhỏ ở vị trí khác
- Phân tích ngữ nghĩa LLM liên tục trong CQ tìm các tương tác tinh vi hoặc phức tạp mà phân tích tĩnh truyền thống bỏ sót, và chặn chúng trước khi mã được đưa vào tree
Hệ sinh thái mã nguồn mở và phụ thuộc bên ngoài
- Bảo mật web phụ thuộc không chỉ vào riêng Chrome mà còn vào năng lực phản ứng của các dự án mã nguồn mở và maintainer
- Google cùng các bên tham gia khác đã đóng góp 12,5 triệu USD cho dự án Alpha-Omega để maintainer có công cụ và hỗ trợ phản hồi nhanh trước báo cáo lỗ hổng
- Google tham gia với tư cách thành viên sáng lập của dự án Akrites, nhằm cung cấp đầu mối báo cáo lỗ hổng tập trung và đội ứng phó sự cố bảo mật để giảm gánh nặng cho maintainer upstream
- Chromium và các dự án liên quan như V8, BoringSSL, Skia, ANGLE, Dawn có hơn 2.300 phụ thuộc bên ngoài
- Khoảng 1.700 trong số này được phân phối tới người dùng qua nhiều sản phẩm như thiết bị Android, nền tảng edge computing và stack của các công ty cloud quy mô lớn
- Pipeline kiểm tra lỗ hổng tự động thu thập dữ liệu từ feed nội bộ Google, NVD của chính phủ Mỹ và OSV tập trung vào mã nguồn mở
- Vì chỉ giám sát sau sự cố vẫn có thể để lại khoảng trống rủi ro, Chrome bắt đầu chuyển mọi phụ thuộc bên ngoài sang pipeline cập nhật tự động chủ động nâng lên phiên bản upstream mới nhất
- Trong quá trình tự động hóa, Chrome dùng tín hiệu an toàn từ các dự án như GOSSIP để phản ánh cả những rủi ro khác trong hệ sinh thái mã nguồn mở bên ngoài
Trình duyệt được bảo vệ liên tục
- Số lượng lỗi được LLM phát hiện và sửa ngày càng tăng không phải là thất bại; mỗi lỗi được sửa là bớt một điểm tựa để kẻ tấn công lợi dụng
- Chỉ phát hiện và sửa là chưa đủ; bản sửa phải được phát hành và áp dụng vào môi trường người dùng trước khi kẻ tấn công khai thác
- Chrome hướng tới Chrome được bảo vệ liên tục mà không làm phiền người dùng, bằng cách kết hợp phát hành nhanh hơn, vá động, tự động khởi động lại vào thời điểm ít gây gián đoạn và các biện pháp phòng thủ cấu trúc
1 bình luận
Ý kiến trên Hacker News
Gần đây khi công việc bận rộn, tôi đã dùng AI khá nhiều cho tối ưu hiệu năng, nhưng nó hầu như vô dụng trong việc định ra định hướng ở tầm cao. Dù chỉ ra những chỗ đáng ngờ trong truy vấn SQL, chênh lệch hiệu năng trước sau gần như không có, lại còn làm mất thời gian vì các đề xuất vô ích, và còn phải chịu cảnh người khác ném ra đầu ra AI chưa qua xử lý như thể đó là đóng góp có ý nghĩa
Tuy vậy, việc triển khai các thay đổi do tôi tự tìm ra hoặc chuyển các phép join sang CTE đã trở nên dễ hơn nhiều
Dù có liên tục nhắc công cụ AI rằng “hãy ngắn gọn”, “chỉ trả lời câu hỏi”, “đừng đưa thông tin không được yêu cầu”, nó vẫn xuất nhiều hơn mức cần thiết, trông như một nỗ lực tinh vi nhằm tiêu tốn thêm token
Chỉ từ văn bản code thì không thể biết kích thước cache, dung lượng cơ sở dữ liệu hay độ trễ mạng, nên phải cho nó bối cảnh như vậy mới có thể có kết quả tốt hơn
Tư liệu then chốt là việc Firefox đã không phải trả bất kỳ khoản thưởng nào tại Pwn2Own ở Berlin hồi tháng 5 vừa qua. Từ năm 2007 đến nay, mọi sự kiện đều có trả thưởng, nên việc không có lấy một lỗ hổng nào được xác nhận cho thấy các lỗ hổng dễ khai thác giờ gần như đã cạn, và đây có vẻ là tín hiệu rằng mô hình kiểu này có ích ở một mức độ nào đó
Tôi tin là có thể sửa được nhiều lỗi, nhưng vẫn tò mò về quy trình thực tế. Cũng có khả năng Google đăng blog rồi khuyến khích sửa lỗi trong vài sprint để các quản lý có thể cho cấp trên thấy thành quả áp dụng AI, khiến các nhóm làm việc nhiều hơn hẳn bình thường
Hiệu quả của LLM phụ thuộc vào cấu trúc lặp mà nó chạy trong, còn cấu trúc đó lại phụ thuộc vào chất lượng của bộ xác minh, nên ngay cả khi không có màn phô diễn thành tích của quản lý thì điều này vẫn hoàn toàn có thể được giải thích
Thay vì để AI tự lao vào làm vô tội vạ, nên dùng nó như công cụ tăng tốc, nhưng có vẻ những người chỉ trích đang nhầm lẫn điều đó. Nó giống như kiểu ngụy biện rơm rạ khi tức giận với Excel vì lợi nhuận đầu tư kém, nên hơn là tranh cãi tiếp, tôi muốn lặng lẽ chia sẻ cách dùng hiệu quả với những người thực sự muốn sử dụng đúng cách
Nếu mặc kệ nó, chỉ sau vài vòng lặp là kết quả đi xuống; còn nếu hướng dẫn kỹ thì nó có giá trị, nhưng công sức bỏ ra lại gần ngang với tự viết code, nhất là khi có công việc lặp lại
Không rõ có bao nhiêu bản sửa tự động đã bị hoàn tác, đã tạo ra bao nhiêu lỗi mới, và tỷ lệ dương tính giả của tác nhân phát hiện là bao nhiêu. Bài viết chỉ có các con số thành công và hoàn toàn không nói đến những gì có thể sai
Ngay cả khi sửa 10 lỗi mà tạo mới 2 lỗi, miễn không phải là các lỗi nghiêm trọng có thể bị khai thác độc lập thì vẫn là lãi ròng lớn. Các cuộc tấn công trình duyệt ngày càng đòi hỏi chuỗi lỗ hổng dài hơn, nên khó có thể bỏ qua lợi ích của việc dùng AI để tìm lỗi tiềm ẩn
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....
Lo ngại rằng sắp tới Google có thể kết luận Chromium không còn cần săn lỗi tập thể công khai nữa và ngừng phát triển công khai. Khi đó, các nhánh Chromium hiện tại trên thực tế sẽ trở thành các fork từ phiên bản công khai cuối cùng, và vì không có nguồn lực bảo trì như Chrome được Gemini hỗ trợ, độ khó quản lý của từng fork có thể khác nhau
Chỉ trích AI thường tập trung vào phạm vi hẹp là việc tạo mã một cách mù quáng là xấu, và điều đó có thể dễ dàng thừa nhận. Nhưng ở phía đối diện là kiểm thử đối kháng, xác minh giả định của lập trình viên, đề xuất refactor, các công cụ phát triển nhỏ, lập trình có hướng dẫn, và lần theo phụ thuộc cùng hành vi trong các codebase lớn, những việc mà AI có thể giúp rất nhiều
Người ta đang quá dễ dàng trộn lẫn các chỉ trích nhắm vào việc sinh mã mù quáng với toàn bộ các cách sử dụng này
Ngay từ đầu, điều cốt lõi là có bao nhiêu lỗi trong số này xuất phát từ mã do LLM viết. Tạo ra nhiều lỗi hơn 100 lần rồi sửa nhiều hơn 100 lần không phải điều đáng tự hào
Đây là dự án mã nguồn mở nên cũng có thể tự kiểm tra xem đó thực sự có phải lỗi do LLM tạo ra hay không
Cũng tự hỏi liệu họ có sửa cả các lỗi theo dõi hành vi nhằm bám theo người dùng bất kể Chrome làm gì ở đâu hay không