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 更新，实际上是把「检测、分类、通知、轮换」之间的自动化接口做得更清楚。
