Bạn duy trì một thư viện công cộng và nhận được một báo cáo bảo mật. Tin nhắn cho biết một người dùng có thể truy cập vào một tài nguyên không thuộc về họ, nhưng không nêu rõ phiên bản hoặc điều kiện tái tạo. Bạn cần phản hồi, hiểu phạm vi và tổ chức một cuộc thảo luận giữa các nhà duy trì, mà không tiết lộ chi tiết của báo cáo.
Kịch bản giả tưởng này phục vụ như một sợi chỉ xuyên suốt. Những diễn biến GitHub từ ngày 1 và 2 tháng 10 năm 2026 mang đến các công cụ tiếp nhận và điều phối. Chúng không loại trừ việc phải xác định thực tế của vấn đề. Giao thức được trình bày ở đây là một đề xuất Partitech, không có lỗ hổng thực sự cũng như không có thử nghiệm khai thác.
Ba công cụ cho cùng một mạch tiếp nhận
GitHub thông báo vào ngày 1 tháng 10 các biểu mẫu có cấu trúc cho các báo cáo riêng tư. Các người duy trì có thể tùy chỉnh thông tin được yêu cầu bằng một tệp .github/VULNERABILITY_REPORT.yml. Mẫu mặc định đặc biệt yêu cầu tóm tắt, chi tiết, minh chứng và ảnh hưởng. Một mẫu được điền đầy đủ cải thiện việc tổ chức thông tin; nó không xác nhận tuyên bố của người báo cáo viên.
Cùng ngày đó, các giới hạn về việc gửi báo cáo được thông báo. Chúng liên quan đến các báo cáo mới. Các quản trị viên có thể đặt giới hạn hàng ngày chung cho việc gửi báo cáo và chỉ định những người báo cáo đáng tin cậy. Các nhận xét về các thông báo hiện có không bị ảnh hưởng.
Ngày 2 tháng 10, các bình luận bí mật trở nên có sẵn. Quyền truy cập của họ tuân theo quyền ghi hiện tại của kho. Người báo cáo và các cộng tác viên được mời không có những quyền này sẽ không nhìn thấy chúng. Phạm vi đã thông báo liên quan đến các kho công khai đã kích hoạt việc báo cáo riêng tư các lỗ hổng.
Ba đòn bẩy này đáp ứng các khó khăn khác nhau: thu thập thông tin chính xác, kiểm soát việc xuất hiện của các hồ sơ mới và lựa chọn người nhận của một cuộc thảo luận. Không có đòn bẩy nào tự động đánh giá mức độ nghiêm trọng của một lỗi. Một hồ sơ ngắn có thể quan trọng; một hồ sơ rất dài có thể vẫn không thể tái tạo.
Yêu cầu cách tái hiện có thể sử dụng được
Trong ví dụ của chúng tôi, câu trả lời đầu tiên phải cho phép hiểu tình huống mà không yêu cầu dữ liệu của khách hàng. Phiên bản nào bị liên quan? Hành vi nào được mong đợi? Hành vi nào đã được quan sát? Tài khoản được sử dụng có những quyền nào? Những câu hỏi này giới hạn việc tái hiện cục bộ.
Biểu mẫu được đề xuất dưới đây là một mẫu biên tập, không phải tệp YAML sẵn sàng triển khai. Nó dùng để chọn thông tin trước khi xác nhận cú pháp so với tài liệu GitHub.
| Thông tin được yêu cầu | Lợi ích cho người bảo trì |
|---|---|
| Phiên bản và môi trường | Tìm lại hành vi liên quan |
| Điều kiện tiên quyết | Xác định các quyền và cấu hình cần thiết |
| Các bước cục bộ không gây hại | Hiểu hành trình mà không chạm vào người thứ ba |
| Được mong đợi và quan sát | Phân biệt sự khác biệt với hành vi bình thường |
| Phạm vi được giả định | Xem xét những gì thực sự có thể tiếp cận |
| Giới hạn của thử nghiệm | Tránh tổng quát hóa một kết quả duy nhất |
Khuyến khích sử dụng tài khoản và dữ liệu tổng hợp. Không yêu cầu mã truy cập, bản sao cơ sở dữ liệu sản xuất, hay thông tin cá nhân. Nếu một bằng chứng bao gồm dữ liệu nhạy cảm, hãy yêu cầu làm rõ sự tồn tại và vai trò của nó mà không sao chép nó vào biểu mẫu.
Cuộc trình bày, thường được gọi là bằng chứng khái niệm, nhằm làm cho một hành vi có thể quan sát được. Độ dài của nó không quyết định tính hợp lệ của nó. Trong một báo cáo được hỗ trợ bởi AI, hãy kiểm tra các liên kết, các phiên bản và các bước chính xác như trong bất kỳ báo cáo nào khác. Nguồn gốc của văn bản không đủ để kết luận thiện chí hay ác ý.
GitHub chỉ ra một sự khác biệt quan trọng đối với các tích hợp : một biểu mẫu tùy chỉnh được yêu cầu đối với các gửi REST, trong khi biểu mẫu mặc định thì không. REST ở đây chỉ một giao diện cho phép chương trình gửi báo cáo. Nếu bạn tùy chỉnh biểu mẫu, hãy kiểm tra hoạt động của các tích hợp của bạn; kết quả trên trình duyệt không bao quát con đường thứ hai này.
Giới hạn luồng mà không làm mất các báo cáo hữu ích
Giới hạn nộp đơn ảnh hưởng đến số lượng hồ sơ mới, không phải giá trị của chúng. Trước khi thay đổi cài đặt, hãy xem xét điều gì đang làm chậm nhóm của bạn: thiếu phiên bản, trùng lặp, không có người chịu trách nhiệm hoặc khối lượng thực tế. Một biện pháp về tốc độ xử lý không sửa được một quy trình phân loại không có người phụ trách.
Phân loại là bước đánh giá đầu tiên của hồ sơ. Nó bao gồm việc hiểu những gì được mô tả, kiểm tra các điều kiện và hướng dẫn các bước tiếp theo. Nó không nhất thiết có nghĩa là ngay lập tức khai báo một lỗi đã được xác nhận hoặc phân loại báo cáo mà không trả lời.
Dự kiến một lộ trình thay thế trong chính sách bảo mật của bạn cho một người hợp pháp bị chặn bởi một giới hạn. Lộ trình này phải cho phép liên lạc bí mật được những người duy trì biết đến. Nó không được dẫn đến việc gửi chi tiết nhạy cảm lên một vấn đề công khai. Kiểm tra ai nhận các tin nhắn và ai thay thế người này trong trường hợp vắng mặt.
Danh sách các người báo cáo đáng tin cậy cũng cần được theo dõi. Xác định ai có thể thêm một người vào danh sách này, cách đánh giá lại sự tin cậy này và khi nào nên xóa một mục. Trạng thái này nên tạo điều kiện liên lạc với những đối tác đã biết, mà không trở thành một ngoại lệ bị lãng quên.
Đối với một bản trùng lặp, liên kết hồ sơ mới với việc theo dõi hiện có mà không tiết lộ các yếu tố bí mật của một báo cáo khác. Giải thích cho người báo cáo những gì bạn có thể chia sẻ và bước tiếp theo. Một phản hồi dễ hiểu sẽ tránh việc họ hiểu nhầm việc phân loại hành chính như là từ bỏ báo cáo của họ.
Chọn mức độ hiển thị trước khi đăng bình luận
Trong kịch bản của chúng tôi, nhóm muốn thảo luận về một giả thuyết tái tạo và một biện pháp sửa chữa có thể. Một phần của cuộc thảo luận này có thể hữu ích cho báo cáo viên; phần khác thuộc về sự phối hợp nội bộ. Hãy chọn mức độ hiển thị dựa trên nội dung và những người nhận thực sự.
| Nội dung để chia sẻ | Câu hỏi đánh giá |
|---|---|
| Yêu cầu làm rõ với báo cáo viên | Người báo cáo có đọc được nội dung trong kênh họ theo dõi không? |
| Giả thuyết đánh giá nội bộ | Các chủ sở hữu hiện tại của quyền viết có phải đều liên quan không? |
| Tổ chức bản vá | Người phụ trách nào phải nhận thông tin? |
| Thông tin nhạy cảm không cần thiết | Liệu có thể loại bỏ nó trước bất kỳ lần xuất bản nào không? |
GitHub chỉ ra rằng mức hiển thị riêng tư không thể được chuyển đổi sau khi công bố, rằng các lượt đọc được ghi lại trong nhật ký kiểm toán và rằng việc hỗ trợ khác nhau giữa GraphQL và REST: những bình luận này có sẵn trong GraphQL, nhưng không được trả về bởi REST khi khởi chạy. Nếu công cụ theo dõi của bạn chỉ sử dụng REST, việc không có bình luận do đó không chứng minh sự thiếu thảo luận.
Mức độ bảo mật phụ thuộc vào các quyền hiện hành, không phải vào một danh sách cố định vào thời điểm soạn thảo. Việc một người quản trị rời đi phải được xử lý trong quản lý quyền truy cập. Ngược lại, một người mới được cấp quyền ghi có thể được đưa vào phạm vi đọc. Hãy kiểm tra quyền trước khi chọn kênh cho nội dung đặc biệt nhạy cảm.
Xây dựng một mạch dẫn đến một quyết định
Đối với mỗi hồ sơ, hãy lưu một tờ ghi chú đơn giản: ngày nhận, thành phần bị nghi ngờ, phiên bản, trạng thái tái tạo, người sở hữu và hành động tiếp theo. Trạng thái "thông tin thiếu" phải chỉ rõ những gì còn thiếu. Trạng thái "xác nhận" phải đề cập đến những gì đã quan sát. Một giả thuyết vẫn là giả thuyết cho đến bước này.
Trong lỗi giả định của chúng tôi, bạn có thể trước hết yêu cầu phiên bản và điều kiện truy cập, sau đó chỉ tái tạo với hai tài khoản tổng hợp trong môi trường cục bộ. Nếu hành vi là bình thường và đã được ghi chép, hãy giải thích lý do. Nếu xuất hiện lỗi, hãy áp dụng bản sửa và tổ chức kiểm tra trước khi thông báo công khai. Không có hoạt động nào trong số này được thực hiện trong bài viết này.
Đo lường thời gian cho đến phản hồi hữu ích đầu tiên và số lượng hồ sơ vẫn chưa có người phụ trách. Những chỉ số này mô tả cách thức hoạt động của bạn; chúng không chứng minh rằng mọi lỗi quan trọng đã được nhận. Tránh công bố các chi tiết có thể xác định người báo cáo hoặc một lỗ hổng chưa được tiết lộ.
Trước khi mở rộng quy trình, hãy để một người khác trong nhóm đọc lại một bản nộp giả định. Họ có thể xác định môi trường, giải thích quyền xem nội dung và xác định quyết định tiếp theo không? Nếu có, việc tiếp nhận của bạn tạo ra một hồ sơ có thể sử dụng được. Nếu không, hãy sửa các câu hỏi và trách nhiệm trước khi thêm các hạn chế mới cho người báo cáo.
Nguồn và ngày kiểm tra
Nguồn GitHub tái mở cửa vào ngày 6 tháng 10 năm 2026: mẫu có cấu trúc, giới hạn của việc gửi báo cáo và bình luận bí mật. Phiếu, các bảng và kịch bản là những khuyến nghị nguyên bản Partitech. Không có advisory, cấu hình GitHub hay báo cáo thực tế nào được tạo.