GitHub 秘密扫描更新

本次更新涵盖 GitHub 秘密扫描的改进和错误修复。

2026 年 11 月 12 日，受影响的 secret_scanning_alert.* 和 secret_scanning_push_protection.bypass 审计日志事件中的 business 字段将从企业显示名称更改为企业 slug。

为避免对任何自动化工作流造成中断，你应在推出前更新按显示名称过滤的集成，使其接受两种格式，或改用 business_id。

business 字段仍为字符串。事件名称和数值 business_id 值不变。

自定义模式警报：当重新扫描发现现有开放警报仍匹配编辑后的自定义模式时，这些警报保持开放，而不是被关闭并重新打开。

Base64 编码的 GitHub 令牌：在 github.com 上启用了秘密扫描的私有和内部仓库中，现有的吊销操作（公开预览）现在支持编码的个人访问令牌（经典）、细粒度个人访问令牌、OAuth 访问令牌和 GitHub App 用户访问令牌。GitHub 会自动解码该值。

解除请求 webhook：载荷现在包含 exemption_request.number，即可在 REST API 中获得的仓库范围请求编号。将仓库和请求编号一起使用，以跨集成关联请求。

可访问性：警报上的“请求待处理”状态现在无需激活操作即可通过键盘聚焦。吊销流程会向屏幕阅读器播报进度，并在完成面板出现时将焦点移到该完成面板。

绕过请求元数据：修复了命令行推送时绕过请求 API 响应和 webhook 载荷中秘密类型和位置详细信息为空的问题，该问题发生在秘密扫描之后运行了另一个仓库规则时。

委托绕过：修复了审核者列表中现有组织角色条目导致的推送失败，以及通过 REST API 为组织拥有的仓库设置有效审核者配置时的 500 错误。

自定义模式 API：因无效参数被扫描服务拒绝的请求现在返回 422 而不是 500，因此你的集成可以区分这些输入错误和服务器故障。

了解有关企业审计日志事件和秘密扫描 REST API 的更多信息。在 GitHub Community 中分享你的反馈。

GitHub 公布 secret scanning 多项改进与修复，核心包括审计日志 business 字段改为企业 slug、自定义模式警报保持开放、Base64 编码令牌吊销支持，以及 webhook、API 错误码和可访问性修复。

• GitHub 公布 secret scanning 多项改进与修复，核心包括审计日志 business 字段改为企业 slug、自定义模式警报保持开放、Base64 编码令牌吊销支持，以及 webhook、API 错误码和可访问性修复。
• 原贴提到：This update covers improvements and bug fixes for GitHub secret scanning
• 来源：github.blog

这不是一次单纯的功能上新公告，而是一次面向安全运营与集成开发者的兼容性更新。GitHub 在 secret scanning 上同时推进了几类改动：审计日志字段格式变化、自定义模式警报生命周期调整、Base64 编码令牌的吊销支持、webhook 载荷补充、可访问性修复，以及若干 API 错误码与绕过请求相关问题修复。信号很明确：秘密扫描正在从能发现泄露，走向能被自动化系统稳定消费和处理。

为什么重要

最需要留意的是 2026 年 11 月 12 日这个时间点。受影响的 secret_scanning_alert.* 与 secret_scanning_push_protection.bypass 审计日志事件中，business 字段会从企业显示名称改为企业 slug。字段仍是字符串，事件名和数值 business_id 不变。对按显示名称过滤的自动化工作流来说，这是一次静默的过滤条件失效风险；原文给出的规避方式是让集成同时接受两种格式，或改用 business_id。这说明安全事件数据的稳定标识更重要，展示名称不适合作为机器集成的长期依据。

自定义模式警报的变化也值得注意：重扫发现已有开放警报仍匹配编辑后的自定义模式时，警报保持开放，而不是关闭后重开。对安全团队而言，这减少了警报噪音和状态抖动，但也意味着不能再用关闭再重开来判断模式是否被编辑后重新命中。依赖警报生命周期的统计、SLA 和自动化处置流程需要重新校准。

对谁有价值

直接受益者包括：维护 secret scanning 告警看板的安全工程师；消费审计日志的 SIEM 与自动化团队；处理 dismissal-request 与 bypass-request webhook 的平台集成开发者；以及为 github.com 私有和内部仓库做令牌吊销流程的运维与安全响应人员。Base64 编码令牌的吊销支持把发现泄露到执行吊销的链路补得更完整，尤其是经典 PAT、细粒度 PAT、OAuth 访问令牌和 GitHub App 用户访问令牌被编码后仍可被自动解码处理。

可以怎么行动

行动上先做兼容性盘点：搜索所有按企业显示名称过滤 secret_scanning_alert.* 和 secret_scanning_push_protection.bypass 审计日志的集成，在 2026 年 11 月 12 日前改为接受显示名称与 slug 双格式，或直接使用 business_id。然后检查 webhook 消费端是否已读取 exemption_request.number，并用仓库与请求编号组合做跨集成关联。对 API 集成，补充 422 与 500 的分支处理，避免把输入错误当服务器故障重试。对可访问性有要求的团队，验证“请求待处理”状态的键盘聚焦，以及吊销流程的屏幕阅读器播报和焦点转移。对委托绕过场景，回归测试组织角色条目与 REST API 审核者配置，确认推送失败和 500 错误已被覆盖。

风险或限制

这次更新没有改变事件名称和数值 business_id，所以风险主要集中在过滤条件和状态语义上，而不是数据整体不可用。Base64 令牌吊销支持限定在 github.com 上启用 secret scanning 的私有和内部仓库，且吊销操作仍是公开预览能力，原文没有承诺所有仓库类型或所有令牌类型都覆盖。自定义模式警报保持开放也要求团队区分仍匹配和新命中，否则容易误读趋势。最后，422 替代 500 只针对扫描服务因无效参数拒绝的请求，不能据此推断所有服务端错误都已修复。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub 秘密扫描更新》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖