GitHub 安全公告機密評論：傳送前先確認讀者
Dev
瀏覽 2
內部調查筆記會不會被報告者看到？安全協作應先確認讀者。GitHub在10月2日宣布安全公告中的機密評論。
官方說明只有儲存庫write權限者可讀。沒有該權限的報告者與受邀協作者看不到，也不收到通知。圖示是建議流程，不是產品截圖。
機密跟隨目前權限
這不是僅作者可見的個人筆記。目前write權限者是讀者，失去權限便無法閱讀。機密標籤和目前權限名單要分別檢查。
適用範圍為啟用私密漏洞報告的公開儲存庫，涵蓋Free、Pro、Team、Enterprise Cloud。本文不建議擴大權限，而是按目的區分內部筆記與外部說明。
傳送後不能切換類型
普通和機密評論發布後不能相互切換。傳送前檢查讀者、內容、選擇狀態。草稿階段把調查假設和已確認事實分開。
例如先內部審閱負責人和未確認假設，再向報告者說明已驗證重現結果。這是團隊建議，不是GitHub強制表單。不要用真實秘密測試。
API不可見不代表紀錄不存在
機密評論可由GraphQL取得，REST不會回傳。僅有REST歸檔不能證明調查完整。記錄蒐集路徑與讀者權限。
查看紀錄進入稽核日誌，但不等於保存評論正文。匯出與搜尋工具應註明API、讀者及未驗證範圍，區分不可見與不存在。
用無害文字驗證流程
在團隊擁有的測試公告中設計非敏感文字檢查。負責人先審閱公告、帳號、權限，再對照可見類型與蒐集結果並記錄。
內部空間可能讓協作者缺少必要資訊，仍需向報告者解釋進展和結果。本文確認功能、權限與API邊界，不編造安全或回應速度改進數字。