GitHub nâng cấp chương trình Bug Bounty: Tập trung vào chất lượng và mô hình trách nhiệm chia sẻ

Cộng đồng nghiên cứu bảo mật là một trong những tài sản quý giá nhất của GitHub. Mỗi năm, các nhà nghiên cứu trên toàn thế giới giúp chúng tôi tìm và khắc phục các lỗ hổng, giúp nền tảng này an toàn hơn cho hơn 180 triệu nhà phát triển. Chương trình tiền thưởng tìm lỗi (Bug Bounty) của chúng tôi tồn tại vì chúng tôi tin rằng sự hợp tác với các nhà nghiên cứu bên ngoài là một trong những cách hiệu quả nhất để cải thiện bảo mật, và chúng tôi vẫn cam kết sâu sắc với điều đó.

Tuy nhiên, giống như mọi chương trình bug bounty khác, chúng tôi đang thích nghi với một bối cảnh đang thay đổi. Chúng tôi muốn chia sẻ những gì chúng tôi đang thấy, những gì chúng tôi đang làm về nó, và cách chúng tôi nghĩ về ranh giới bảo mật của một nền tảng như GitHub.

Bảo mật và Bug Bounty tại GitHub

Vấn đề về số lượng báo cáo

Trong năm qua, khối lượng báo cáo gửi trên toàn ngành đã tăng đáng kể. Các công cụ mới, bao gồm cả AI, đã hạ thấp rào cản tham gia vào nghiên cứu bảo mật, điều này theo nhiều cách là một sự phát triển tích cực. Nhiều người khám phá các bề mặt tấn công hơn có nghĩa là nhiều cơ hội hơn để tìm ra các vấn đề thực sự.

Tuy nhiên, cùng với sự gia tăng trong các báo cáo hợp lệ, chúng tôi đã thấy sự gia tăng mạnh các bài nộp không chứng minh được tác động bảo mật thực sự. Những báo cáo này bao gồm các báo cáo không có bằng chứng khái niệm (PoC), các kịch bản tấn công lý thuyết không chịu được sự kiểm chứng kỹ lưỡng, và các phát hiện đã nằm trong danh sách không đủ điều kiện đã được công bố của chúng tôi. Điều này không phải là duy nhất đối với GitHub. Các chương trình trên toàn ngành đang vật lộn với cùng một thách thức này, và một số đã phải đóng cửa hoàn toàn.

Chúng tôi không muốn đi theo hướng đó. Thay vào đó, chúng tôi muốn đầu tư vào việc làm cho chương trình của mình tốt hơn.

Thế nào là một bài nộp chất lượng?

Chúng tôi đang nâng cao tiêu chuẩn về những gì chúng tôi coi là một bài nộp hoàn chỉnh. Từ nay về sau, các báo cáo sẽ được đánh giá nghiêm ngặt hơn dựa trên các tiêu chí sau:

• Một PoC hoạt động với tác động bảo mật được chứng minh: Hãy cho chúng tôi thấy tác động, đừng chỉ mô tả nó. Kẻ tấn công thực sự có thể đạt được gì? Chúng tôi cần một PoC hoạt động chứng minh việc khai thác thực sự và tác động bảo mật cụ thể. Hãy cho chúng tôi thấy ranh giới có thể bị vượt qua, không chỉ là nó tồn tại về mặt lý thuyết. Nếu báo cáo của bạn nói "điều này có thể dẫn đến..." nhưng không cho thấy nó thực sự dẫn đến điều đó, thì nó chưa hoàn chỉnh.
• Nhận thức về phạm vi và các phát hiện không đủ điều kiện: Trước khi gửi, hãy xem xét phạm vi và danh sách các phát hiện không đủ điều kiện của chúng tôi. Các báo cáo bao gồm các danh mục không đủ điều kiện đã biết (cấu hình DMARC/SPF/DKIM, liệt kê người dùng, thiếu tiêu đề bảo mật mà không có đường dẫn tấn công được chứng minh, v.v.) sẽ bị đóng là Không áp dụng, điều này có thể ảnh hưởng đến điểm HackerOne Signal và uy tín của bạn.
• Xác thực trước khi gửi: Bất kể bạn sử dụng công cụ nào (trình quét, phân tích tĩnh, trợ lý AI), bạn cần xác thực đầu ra trước khi gửi. Một dương tính giả đã được xem xét thủ công sẽ bị bắt trước khi lãng phí thời gian của bất kỳ ai. Một báo cáo chưa được xác thực chỉ là tiếng ồn.

Chúng tôi chào đón AI trong nghiên cứu bảo mật

Chúng tôi muốn nói rõ điều này: chúng tôi không có vấn đề gì với các nhà nghiên cứu sử dụng công cụ AI. AI là một lực lượng nhân lên, và chúng tôi mong đợi nó sẽ đóng vai trò ngày càng tăng trong nghiên cứu bảo mật. Chúng tôi sử dụng AI trên các chương trình bảo mật nội bộ của chính mình, và chúng tôi thấy rằng những nhà nghiên cứu bên ngoài tốt nhất cũng đang làm như vậy. Chúng tôi chào đón nó.

Điều chúng tôi cần là cùng một tiêu chuẩn mà chúng tôi luôn mong đợi: xác thực. Một phát hiện được hỗ trợ bởi AI đã được xác minh, tái tạo và gửi kèm với một PoC hoạt động là một bài nộp tuyệt vời. Một đầu ra chưa được xác thực được gửi nguyên trạng mà không có sự tái tạo hoặc tác động được chứng minh thì không phải vậy. Đây không phải là một tiêu chuẩn mới. Đó là cùng một tiêu chuẩn mà chúng tôi áp dụng cho đầu ra của trình quét, phân tích tĩnh hoặc bất kỳ công cụ nào khác. Nhà nghiên cứu con người phải chịu trách nhiệm về độ chính xác của bài nộp.

Chúng tôi cũng muốn các nhà nghiên cứu giữ cho báo cáo ngắn gọn và có cấu trúc. Một báo cáo mạnh có ba thứ: một tóm tắt ngắn về vấn đề, các bước rõ ràng để tái tạo với bằng chứng hỗ trợ (ảnh chụp màn hình, yêu cầu HTTP, đầu ra thiết bị đầu cuối), và một tuyên bố về tác động giải thích những gì kẻ tấn công thực sự có thể đạt được. Đó là tất cả. Các báo cáo dài dòng như những câu chuyện lý thuyết nhiều trang, bối cảnh nền lặp lại, hoặc nội dung lấp đầy do AI tạo ra sẽ làm chậm quá trình phân loại vì phát hiện thực sự bị chôn vùi. Báo cáo của bạn càng rõ ràng và trực tiếp, chúng tôi càng có thể hành động nhanh chóng.

Công cụ không quan trọng. Chất lượng công việc mới là quan trọng.

Hiểu về mô hình bảo mật của GitHub: Trách nhiệm chia sẻ

Một mô hình chúng tôi thường thấy xứng đáng được thảo luận riêng. Nhiều báo cáo mô tả các kịch bản trong đó người dùng tương tác với nội dung do kẻ tấn công kiểm soát (kho lưu trữ độc hại, vấn đề được tạo ra kỹ lưỡng, mã không đáng tin cậy) và gặp phải kết quả không mong muốn. Các báo cáo này thường được viết tốt và chính xác về mặt kỹ thuật trong các quan sát của họ, nhưng chúng hiểu sai nơi ranh giới bảo mật nằm ở đâu.

Chúng tôi đầu tư mạnh vào các hệ thống và đội ngũ chuyên phát hiện và xử lý nội dung độc hại trên nền tảng, từ quét tự động đến xem xét thủ công. Tuy nhiên, GitHub hoạt động dựa trên mô hình trách nhiệm chia sẻ. Người dùng chịu trách nhiệm cho:

• Lựa chọn những kho lưu trữ, vấn đề và mã mà họ tin tưởng. GitHub lưu trữ hơn 600 triệu kho lưu trữ. Không phải tất cả đều lành tính. Người dùng được kỳ vọng sẽ sử dụng phán đoán về những gì họ tương tác.
• Xem xét nội dung trước khi thực thi hoặc tương tác với nó. Điều này áp dụng cho mã, tập lệnh, quy trình làm việc và bất kỳ nội dung thực thi nào khác.
• Hiểu rằng sao chép một kho lưu trữ có nghĩa là lựa chọn tin tưởng mã đó. Git hooks, tập lệnh xây dựng và các quy trình tự động khác ở cấp độ kho lưu trữ thực thi vì người dùng đã chọn lấy (checkout) kho lưu trữ đó.
• Cấu hình môi trường của riêng họ một cách an toàn. Quản lý mã thông báo, lưu trữ thông tin đăng nhập và cài đặt bảo mật cục bộ là trách nhiệm của người dùng.

Khi một cuộc "tấn công" yêu cầu nạn nhân chủ động tìm kiếm và tương tác với nội dung do kẻ tấn công kiểm soát (sao chép một kho độc hại, yêu cầu công cụ AI phân tích mã không đáng tin cậy, mở một tệp được tạo ra kỹ lưỡng), ranh giới bảo mật là quyết định của người dùng để tin tưởng nội dung đó. Các kịch bản này thường không đại diện cho việc vượt qua các kiểm soát bảo mật của GitHub.

Các ví dụ phổ biến

Để giúp các nhà nghiên cứu điều chỉnh, dưới đây là các mô hình chúng tôi thường thấy thuộc về trách nhiệm chia sẻ:

Kịch bản	Tại sao là trách nhiệm chia sẻ
Chèn lệnh (prompt injection) qua nội dung người dùng chọn đưa vào công cụ AI	Người dùng đã quyết định tin tưởng nội dung đó
Git hooks hoặc bộ lọc thực thi mã trong một kho người dùng đã checkout	Đây là cách Git hoạt động theo thiết kế
Nội dung độc hại trong một kho người dùng đã sao chép	Sao chép là một hành động tin tưởng
LLM tạo ra đầu ra bất ngờ khi xử lý đầu vào không đáng tin cậy	Người dùng đã chọn cung cấp đầu vào đó

Nghiên cứu trong các lĩnh vực này vẫn cực kỳ có giá trị. Nếu bạn nghĩ mình đã tìm ra một điểm mù trong hệ thống phòng thủ của chúng tôi (một cách để vượt qua một kiểm soát bảo mật thực sự ảnh hưởng đến người dùng mà không yêu cầu họ chủ động tin tưởng nội dung độc hại), đó chính xác là điều chúng tôi muốn nghe. Những phát hiện đó là một trong những bài nộp có tác động lớn nhất mà chúng tôi nhận được. Và nếu bạn gặp nội dung vi phạm Điều khoản Dịch vụ của chúng tôi, vui lòng báo cáo nó.

Điều này có nghĩa là gì cho các nhà nghiên cứu

Nếu bạn đã gửi các nghiên cứu chất lượng, xin cảm ơn. Không có gì thay đổi đối với bạn ngoại trừ thời gian phản hồi nhanh hơn khi chúng tôi giảm tiếng ồn trong hàng đợi.

Nếu bạn mới tham gia bug bounty, chào mừng! Hãy dành vài phút để đọc phạm vi của chúng tôi, xem xét danh sách không đủ điều kiện và đầu tư vào một PoC hoạt động trước khi gửi. Các bài nộp chất lượng từ các nhà nghiên cứu mới luôn được đánh giá cao và trân trọng.

Nếu bạn đã ưu tiên số lượng, chúng tôi khuyến khích sự chuyển dịch sang chiều sâu. Một phát hiện được nghiên cứu kỹ lưỡng, đã xác thực có giá trị hơn nhiều so với 10 phát hiện mang tính suy đoán, cả về tiền thưởng và uy tín. Những nhà nghiên cứu kiếm được nhiều nhất từ chương trình của chúng tôi là những người đi sâu vào vấn đề.

Thay đổi cách chúng tôi thưởng cho các phát hiện rủi ro thấp

Không phải mọi bài nộp hợp lệ đều đại diện cho một rủi ro bảo mật ý nghĩa. Một số báo cáo xác định các cơ hội củng cố hoặc khoảng trống tài liệu mà, mặc dù không thể khai thác, vẫn dẫn đến những cải tiến mà chúng tôi chọn thực hiện. Chúng tôi trân trọng công việc đó.

Từ nay về sau, chúng tôi đang cập nhật cách chúng tôi xử lý các trường hợp này. Các bài nộp không chứng minh tác động bảo mật đáng kể nhưng dẫn đến sửa đổi mã hoặc tài liệu sẽ được công nhận bằng quà lưu niệm của GitHub thay vì tiền thưởng. Điều này cho phép chúng tôi ghi nhận đóng góp trong khi tập trung nguồn lực bug bounty vào các phát hiện có tác động lớn nhất đối với bảo mật nền tảng.

Chúng tôi thà thấy các nhà nghiên cứu đầu tư thời gian vào các nghiên cứu sâu, có tác động cao và được bồi thường xứng đáng hơn là tối ưu hóa cho số lượng trên các phát hiện rủi ro thấp.

Nhìn về phía trước

Chúng tôi cam kết làm cho chương trình bug bounty của GitHub trở thành một trong những chương trình tốt nhất trong ngành, cho các nhà nghiên cứu và cho sự an toàn của nền tảng. Điều đó có nghĩa là phân loại nhanh hơn, giao tiếp rõ ràng hơn và đảm bảo rằng các phát hiện hợp lệ nhận được sự chú ý và bồi thường xứng đáng. Việc nâng cao tiêu chuẩn chất lượng là một phần của khoản đầu tư đó.

Các nhà nghiên cứu bảo mật làm cho GitHub an toàn hơn cho mọi nhà phát triển phụ thuộc vào nó. Công việc đó quan trọng, và chúng tôi không coi đó là điều hiển nhiên.

Chúc các bạn khai thác vui vẻ! 🚀