Google thực sự dừng phần nào của OSS VRP?
Từ ngày 1/10/2026, Google tạm ngừng tiếp nhận các báo cáo lỗ hổng sản phẩm mới thuộc Open Source Software Vulnerability Reward Program (OSS VRP). Điểm cần làm rõ là Google không đóng toàn bộ chương trình săn lỗi mã nguồn mở: các báo cáo đang được xử lý và báo cáo liên quan đến chuỗi cung ứng vẫn không bị ảnh hưởng.
Google cũng khuyến nghị giới nghiên cứu tìm kiếm tác động bảo mật phù hợp trong các chương trình VRP khác hoặc tham gia Patch Rewards Program. Với một số kho mã nguồn mở có ảnh hưởng trực tiếp đến sản phẩm Google Cloud, lỗ hổng phù hợp vẫn có thể thuộc phạm vi xem xét của Cloud VRP.
Như vậy, cách diễn đạt chính xác hơn không phải là OSS VRP bị khai tử, mà là Google đang tạm dừng một hạng mục tiếp nhận quan trọng để điều chỉnh mô hình vận hành.
Vì sao báo cáo do AI tạo ra trở thành vấn đề?
OSS VRP được Google triển khai từ năm 2022 nhằm khuyến khích cộng đồng phát hiện và báo cáo có trách nhiệm các vấn đề bảo mật trong hệ sinh thái phần mềm mã nguồn mở của hãng. Tuy nhiên, sự phổ biến của mô hình ngôn ngữ lớn và công cụ phân tích mã tự động đã làm chi phí tạo một báo cáo lỗ hổng giảm mạnh.
Vấn đề không nằm ở việc sử dụng AI. Chính Google thừa nhận AI có thể hỗ trợ nghiên cứu bảo mật và phát hiện nhiều vấn đề tiềm năng. Rủi ro xuất hiện khi kết quả do máy tạo ra được gửi đi mà không trải qua bước xác minh kỹ thuật, tái hiện lỗi và đánh giá tác động thực tế.
Trong lần cập nhật quy định OSS VRP hồi tháng 3/2026, Google cho biết đã ghi nhận sự gia tăng đáng kể của các báo cáo chất lượng thấp hoặc không hợp lệ. Một số báo cáo chứa thông tin sai hoặc “ảo giác” về cách kích hoạt lỗ hổng; số khác phát hiện lỗi trong mã nhưng không chứng minh được tác động bảo mật đáng kể hoặc thậm chí nằm ở đường dẫn mã không thể tiếp cận trong điều kiện thực tế.
Từ siết tiêu chuẩn đến tạm dừng tiếp nhận báo cáo
Google đã cảnh báo vấn đề từ đầu năm 2026
Việc tạm dừng không diễn ra đột ngột. Trước đó, Google đã điều chỉnh OSS VRP theo hướng ưu tiên bằng chứng có thể kiểm chứng. Với một số nhóm dự án quan trọng, báo cáo lỗi bộ nhớ phải có khả năng tái hiện chính xác thông qua OSS-Fuzz hoặc đi kèm bản vá đã được hợp nhất.
Đối với các dự án thuộc nhóm ưu tiên thấp hơn, Google cũng thu hẹp phạm vi được nhận thưởng cho một số loại lỗ hổng sản phẩm và vấn đề bảo mật khác. Mục tiêu là dành nguồn lực cho những phát hiện có tác động thực tế thay vì xử lý một lượng lớn cảnh báo chưa được xác minh.
Đến tháng 10, Google tạm dừng báo cáo lỗ hổng sản phẩm mới
Ngày 1/10/2026, Google thông báo tạm thời không tiếp nhận báo cáo lỗ hổng sản phẩm mới qua OSS VRP. Lý do được đưa ra là lượng báo cáo tự động tăng đáng kể và phần lớn trong số đó không hợp lệ.
Google cam kết cung cấp thông tin cập nhật trong quý I/2027 trong khi tiếp tục định hình lại phần này của chương trình. Đây là mốc cập nhật, không đồng nghĩa Google đã xác nhận OSS VRP sẽ mở lại vào một ngày cụ thể trong năm 2027.
Hệ lụy của làn sóng báo cáo bảo mật tự động
- Tăng chi phí phân loại: Mỗi báo cáo thiếu căn cứ vẫn cần thời gian đọc, kiểm tra mã nguồn, tái hiện và đánh giá trước khi có thể
kết luận không hợp lệ.
- Làm loãng tín hiệu quan trọng: Khi số lượng dương tính giả tăng mạnh, những lỗ hổng có khả năng khai thác thực sự có nguy cơ bị chìm trong hàng loạt cảnh báo chất lượng thấp.
- Gia tăng áp lực lên maintainer: Các dự án mã nguồn mở thường có nguồn lực bảo mật và nhân sự hạn chế, vì vậy lượng báo cáo tăng nhanh có thể tạo ra gánh nặng không tương xứng.
- Buộc chương trình bug bounty thay đổi: Proof-of-Concept, khả năng tái hiện, phân tích tác động và chất lượng bản vá ngày càng trở thành những tiêu chí quan trọng hơn số lượng phát hiện.
Google không phải trường hợp duy nhất chịu áp lực. Năm 2026, OpenJS Foundation cũng cho biết khối lượng tư vấn bảo mật và yêu cầu CVE tăng mạnh, trong đó một phần đáng kể đến từ các báo cáo được tạo hoặc hỗ trợ bởi mô hình ngôn ngữ lớn. Điều này cho thấy bài toán “AI slop” trong bảo mật đã vượt ra ngoài phạm vi một chương trình riêng lẻ.
Chuyên gia bảo mật và AI khác nhau ở đâu?
AI có ưu thế rõ rệt về tốc độ phân tích và khả năng rà soát khối lượng mã lớn, nhưng phát hiện một mẫu mã đáng ngờ chưa đồng nghĩa với chứng minh được một lỗ hổng có thể khai thác. Khác biệt quan trọng nằm ở bước xác minh và đánh giá tác động.
| Tiêu chí | Nghiên cứu có kiểm chứng | Quét AI thiếu kiểm chứng |
|---|---|---|
| Phát hiện vấn đề | Kết hợp công cụ và phân tích chuyên môn | Có thể rà soát mã với tốc độ rất cao |
| Xác minh | Tái hiện lỗi và kiểm tra điều kiện kích hoạt | Có nguy cơ suy luận sai hoặc tạo thông tin không tồn tại |
| Đánh giá tác động | Xem xét bối cảnh, mô hình đe dọa và khả năng khai thác | Có thể nhầm lỗi lập trình với lỗ hổng bảo mật thực tế |
| Proof-of-Concept | Ưu tiên bằng chứng có thể tái hiện | Kết quả tự động không mặc nhiên chứng minh khả năng khai thác |
| Giá trị với maintainer | Cung cấp dữ liệu hỗ trợ xác nhận và vá lỗi | Có thể làm tăng khối lượng phân loại nếu gửi hàng loạt |
AI vẫn có vai trò quan trọng trong săn lỗi bảo mật
Việc Google hạn chế một loại báo cáo không có nghĩa AI thất bại trong lĩnh vực an ninh mạng. Ngược lại, Google vẫn sử dụng AI trong hoạt động phát hiện lỗ hổng nội bộ và kết hợp công nghệ này với các phương pháp đã được kiểm chứng như fuzzing.
Điểm mấu chốt là AI nên đóng vai trò tăng năng suất cho nhà nghiên cứu thay vì trở thành công cụ sản xuất báo cáo hàng loạt. Một cảnh báo do mô hình phát hiện chỉ nên được xem là điểm khởi đầu cho quá trình điều tra. Trước khi gửi tới maintainer hoặc chương trình bug bounty, người nghiên cứu cần xác nhận lỗi tồn tại, xác định đường dẫn mã có thể tiếp cận, chứng minh tác động và cung cấp hướng tái hiện rõ ràng.
Nhà nghiên cứu bảo mật cần thay đổi cách làm thế nào?
- Xác minh trước khi gửi: Không sử dụng kết quả từ LLM hoặc công cụ quét tự động như bằng chứng cuối cùng về một lỗ hổng.
- Chứng minh tác động: Phân biệt rõ lỗi lập trình thông thường với vấn đề tạo ra rủi ro bảo mật trong mô hình đe dọa thực tế.
- Chuẩn bị bằng chứng tái hiện: Cung cấp điều kiện kích hoạt, bước tái hiện và Proof-of-Concept phù hợp với quy định của từng chương trình.
- Chọn đúng kênh báo cáo: Trong thời gian hạng mục OSS VRP bị tạm dừng, cần kiểm tra phạm vi của các VRP khác và Patch Rewards Program thay vì gửi một phát hiện đến kênh không còn tiếp nhận.
Điều gì có thể thay đổi sau đợt tạm dừng?
Google chưa công bố cấu trúc cuối cùng của hạng mục OSS VRP đang được điều chỉnh. Tuy nhiên, các thay đổi trong năm 2026 cho thấy xu hướng rõ ràng: chương trình thưởng lỗi sẽ ngày càng coi trọng khả năng tái hiện, bằng chứng kỹ thuật và tác động bảo mật thực tế.
Về dài hạn, các nền tảng tiếp nhận lỗ hổng cũng có thể phải tăng cường cơ chế sàng lọc tự động, chấm điểm chất lượng và phát hiện báo cáo trùng lặp trước khi chuyển hồ sơ cho kỹ sư. Đây là bài toán đặc biệt quan trọng khi AI khiến chi phí tạo nội dung kỹ thuật giảm nhanh hơn nhiều so với chi phí xác minh nội dung đó.
Thông điệp đáng chú ý từ vụ OSS VRP không phải “AI không thể săn lỗi”, mà là phát hiện tự động chỉ có giá trị khi đi kèm kiểm chứng. Trong an ninh mạng, tốc độ tạo báo cáo không thể thay thế bằng chứng về khả năng khai thác và tác động thực tế.
Kết luận
Việc Google dừng chương trình trao thưởng tìm lỗi mã nguồn mở 2026 ở hạng mục tiếp nhận lỗ hổng sản phẩm mới phản ánh một nghịch lý của kỷ nguyên AI: công nghệ giúp tìm kiếm dấu hiệu bất thường nhanh hơn, nhưng đồng thời có thể tạo ra lượng nhiễu khổng lồ nếu con người bỏ qua bước thẩm định. OSS VRP chưa bị đóng hoàn toàn và Google mới cam kết cập nhật tình hình trong quý I/2027. Với cộng đồng nghiên cứu bảo mật, thay đổi quan trọng nhất là chuyển trọng tâm từ số lượng báo cáo sang bằng chứng, khả năng tái hiện và giá trị bảo mật thực tế.