GitHub 於 2026 年 7 月 15 日公布一批 Secret Scanning 和 public monitoring 更新。今次更新一方面增加新的 provider detector，另一方面把 secret 類別寫入 webhook，讓安全團隊更容易把不同來源的 alert 路由到合適的處理流程。
GitHub 宣布與 Resend 加入 secret scanning partnership program，並新增 APIclub 和 Resend 的 API key 偵測。當 partnership secret 在公開 repository 被發現時，GitHub 會按合作安排通知 secret issuer，由對方採取撤銷或通知管理員等措施。
Push Protection 的預設覆蓋範圍亦擴大。VolcEngine 的 `volcengine_ark_api_key` 現在會被納入預設保護，啟用 Secret Scanning 的 repository，包括免費公開 repository，會在 commit 推送前自動阻止這類 secret。
對做整合和自動化的人來說，最值得留意的是 `secret_scanning_alert` webhook 新增 `secret_category` 欄位。它會把 finding 分為 `default` 和 `generic`：前者包括 provider pattern 和自訂 pattern，後者包括 generic pattern 及 AI-detected secrets。這讓團隊不必自行維持一份 secret type 對照表，就可以按類別篩選、路由和報告。
GitHub 也改善 public monitoring alert list，在頁面頂部加入 insight cards，顯示按 attribution 分組的 associated leaks、enterprise member 數量和 verified domains。這些摘要可以先讓安全團隊了解暴露範圍，再深入檢查個別 alert。
這些更新的價值不只在於多了幾個 detector。對使用 AI coding agent、CI/CD 和 webhook 自動化的團隊，安全流程可以先按 `secret_category` 分流，再要求確認 repository、commit、責任人和 token scope，最後由 secret issuer 或管理員旋轉憑證。AI-detected finding 仍然需要 triage 和驗證，不能因為有分類就當成確定洩漏。
Secret Scanning 也不是完整的憑證治理系統。團隊仍要使用最小權限、短效 token、環境變數管理、歷史 commit 清理和事故回應流程；公開 repository 的 alert 更應視為需要即時處理的事件。今次 GitHub 更新，實際上是把「偵測、分類、通知、旋轉」之間的自動化接口做得更清楚。
