Google tạm dừng chương trình Bug Bounty cho mã nguồn mở do làn sóng báo cáo rác

• Thay đổi chính sách: Google tạm dừng tiếp nhận báo cáo lỗ hổng sản phẩm (product vulnerability) trong chương trình Open Source Software Vulnerability Reward Program (OSS VRP) kể từ ngày 01/10/2026.
• Nguyên nhân gốc rễ: Sự bùng nổ của các báo cáo lỗ hổng được tạo tự động (automated submissions) với tỷ lệ sai lệch cao, gây quá tải cho đội ngũ đánh giá.
• Phạm vi ảnh hưởng: Các dự án flagship như Go, Angular, Flutter, Bazel và Protocol Buffers không còn được nhận thưởng cho các báo cáo lỗ hổng sản phẩm thông thường.
• Lộ trình tương lai: Google dự kiến cập nhật lại cấu trúc chương trình trong quý 1 năm 2027 để tối ưu hóa quy trình sàng lọc và xử lý.

1. Bối cảnh & Tổng quan về sự thay đổi chính sách

Kể từ ngày 01/10/2026, Google đã đưa ra quyết định chiến lược trong việc tạm dừng tiếp nhận các báo cáo lỗ hổng sản phẩm thông qua chương trình Open Source Software Vulnerability Reward Program (OSS VRP). Đây là một động thái quan trọng nhằm bảo vệ tính toàn vẹn của hệ sinh thái nghiên cứu bảo mật, sau khi ghi nhận sự gia tăng đột biến của các báo cáo tự động không hợp lệ.

Chương trình OSS VRP, được ra mắt từ tháng 08/2022, vốn là cầu nối quan trọng giữa các nhà nghiên cứu bảo mật độc lập và đội ngũ kỹ sư của Google. Tuy nhiên, sự phát triển của các công cụ tạo báo cáo tự động, bao gồm cả việc lạm dụng các mô hình ngôn ngữ lớn (LLM), đã tạo ra một khối lượng công việc khổng lồ nhưng thiếu giá trị thực tiễn, buộc Google phải tái cấu trúc lại quy trình vận hành.

2. Phân tích nguyên nhân: Sự bùng nổ của báo cáo kém chất lượng

Theo thông báo từ Google, phần lớn các báo cáo nhận được trong thời gian gần đây không đáp ứng được các tiêu chuẩn kỹ thuật tối thiểu. Các báo cáo này thường chứa các chi tiết giả mạo về cách thức khai thác lỗ hổng (vulnerability trigger), gây lãng phí tài nguyên của đội ngũ phân tích (triage team).

Các loại lỗ hổng thường bị báo cáo sai lệch bao gồm:

• Memory Corruption: Các lỗi tràn bộ nhớ (Heap/Stack Overflow) được báo cáo mà không có bằng chứng PoC (Proof-of-Concept) xác thực.
• Path Traversal: Các báo cáo về lỗi duyệt thư mục không tồn tại hoặc không thể khai thác trong môi trường thực tế.
• Logic Flaws: Các lỗi logic xác thực được suy diễn từ các công cụ quét tự động mà không qua kiểm chứng thủ công.

Việc lạm dụng LLM để tạo ra các báo cáo giả mạo đã trở thành một thách thức lớn đối với các chương trình Bug Bounty toàn cầu. Các nhà nghiên cứu được khuyến cáo không nên gửi các báo cáo chưa qua kiểm duyệt kỹ lưỡng, vì điều này không chỉ làm giảm uy tín cá nhân mà còn ảnh hưởng đến hiệu quả của toàn bộ cộng đồng bảo mật.

3. Bảng phân loại dự án và thay đổi mức thưởng

Google duy trì hệ thống phân loại dự án dựa trên mức độ nhạy cảm và tầm quan trọng của mã nguồn. Dưới đây là bảng tóm tắt các thay đổi về mức thưởng sau khi cập nhật chính sách:

⚠️ Cảnh báo quan trọng: Mặc dù các báo cáo lỗ hổng sản phẩm bị tạm dừng, Google vẫn tiếp tục tiếp nhận các báo cáo liên quan đến Supply chain compromises (tấn công chuỗi cung ứng) và các vấn đề bảo mật nghiêm trọng khác như rò rỉ thông tin xác thực (leaked credentials).

4. Hướng dẫn quy trình báo cáo thay thế

Đối với các nhà nghiên cứu bảo mật, Google đã cung cấp các kênh thay thế để đảm bảo các phát hiện quan trọng vẫn được xử lý kịp thời:

• Cloud VRP: Các lỗ hổng ảnh hưởng đến các dự án mã nguồn mở được duy trì bởi Google Cloud vẫn có thể được gửi qua chương trình Cloud VRP.
• Patch Rewards Program: Chương trình này tập trung vào việc thưởng cho các bản vá (patches) đã được chấp nhận và triển khai, thay vì chỉ báo cáo lỗ hổng.
• Kênh báo cáo trực tiếp: Đối với một số dự án cụ thể như Go, nhà nghiên cứu có thể gửi báo cáo trực tiếp đến đội ngũ bảo mật của dự án thông qua email hoặc các kênh được chỉ định trong file SECURITY.md trên GitHub.

Để đảm bảo báo cáo được chấp nhận, nhà nghiên cứu cần tuân thủ các quy tắc sau:

# Kiểm tra chính sách bảo mật của dự án trước khi gửi báo cáo: 1. Truy cập vào kho lưu trữ GitHub của dự án. 2. Tìm kiếm file SECURITY.md hoặc SECURITY.txt. 3. Tuân thủ đúng kênh liên lạc được chỉ định (email hoặc nền tảng Bug Hunters). 4. Cung cấp PoC chi tiết và các bước tái hiện (reproduction steps) rõ ràng.

5. Khuyến nghị cho cộng đồng nghiên cứu

Để duy trì tính chuyên nghiệp và đóng góp giá trị thực cho an ninh mạng, các nhà nghiên cứu cần tập trung vào chất lượng hơn là số lượng. Việc sử dụng các công cụ tự động là cần thiết, nhưng việc kiểm chứng thủ công (manual verification) là bắt buộc trước khi gửi bất kỳ báo cáo nào. Tham khảo thêm các tiêu chuẩn tại MITRE CWE để hiểu rõ hơn về các loại lỗ hổng phổ biến và cách mô tả chúng một cách chính xác nhất.