GitHub secret scanning 更新：审计日志字段变更与多项修复
2026-10-21
本次更新涵盖 GitHub secret scanning 的改进与缺陷修复。
2026 年 11 月 12 日，受影响的 secret_scanning_alert.* 和 secret_scanning_push_protection.bypass 审计日志事件中的 business 字段，将从企业显示名称变更为企业 slug。为避免对任何自动化工作流造成中断，你应在推出生效前更新按显示名称过滤的集成，使其同时接受两种格式，或改用 business_id。business 字段仍为字符串。事件名称和数值型 business_id 值不变。
自定义模式告警：当重新扫描发现现有未关闭告警仍匹配编辑后的自定义模式时，这些告警保持开启，而不是被关闭后再重新打开。
Base64 编码的 GitHub 令牌：在 github.com 上已启用 secret scanning 的私有和内部仓库中，现有的吊销操作（公开预览）现在支持编码后的 personal access token（classic）、细粒度 personal access token、OAuth 访问令牌和 GitHub App 用户访问令牌。GitHub 会自动解码该值。
解除请求 Webhook：载荷现在包含 exemption_request.number，即同样可在 REST API 中获取的、仓库范围的请求编号。将仓库与请求编号一起使用，以便在多个集成之间关联请求。
无障碍：告警上的 Request pending 状态现在可键盘聚焦，而不会触发操作。吊销流程会向屏幕阅读器播报进度，并在完成面板出现时将焦点移至该面板。
绕过请求元数据：修复了当另一条仓库规则在 secret scanning 之后运行时，命令行推送的绕过请求 API 响应和 webhook 载荷中密钥类型和位置详情为空的问题。
委托绕过：修复了因审查者列表中存在既有组织角色条目而导致的推送失败，以及通过 REST API 为组织拥有的仓库设置有效审查者配置时出现的 500 错误。
自定义模式 API：因参数无效而被扫描服务拒绝的请求，现在返回 422 而不是 500，以便你的集成能够将这些输入错误与服务器故障区分开。
了解更多关于企业审计日志事件和 secret scanning REST API 的信息。在 GitHub Community 中分享你的反馈。
GitHub 发布 secret scanning 批次更新：2026 年 11 月 12 日起，受影响审计日志事件中的 business 字段由企业显示名称改为企业 slug，需提前改造自动化集成；同时修复自定义模式告警重扫语义、支持 base64 编码令牌吊销、补充 webhook 请求编号、改善无障碍，并将参数错误从 500 改为 422。
- GitHub 发布 secret scanning 批次更新：2026 年 11 月 12 日起，受影响审计日志事件中的 business 字段由企业显示名称改为企业 slug，需提前改造自动化集成；同时修复自定义模式告警重扫语义、支持 base64 编码令牌吊销、补充 webhook 请求编号、改善无障碍，并将参数错误从 500 改为 422。
- 原贴提到：This update covers improvements and bug fixes for GitHub secret scanning
- 来源：github.blog
这是什么信号
这是一次典型的“平台安全能力迭代”信号，而非单个新功能发布。GitHub 把 secret scanning 的审计日志字段变更、告警生命周期语义、令牌吊销范围、webhook 载荷结构、无障碍与错误码修复打包在同一条 changelog 里，说明它正在把 secret scanning 从“检测泄漏”推进到“可运营的泄漏处置流程”。
最关键的一条是审计日志字段的破坏性变更：2026 年 11 月 12 日起，受影响的 secret_scanning_alert.* 和 secret_scanning_push_protection.bypass 事件里，business 字段会从企业显示名称换成企业 slug。字段类型仍是字符串，事件名和数值型 business_id 不变，所以它不会报错，只会“静默过滤不到数据”——这是最难排查的一类故障。
为什么重要
安全告警的下游几乎全是自动化：SIEM 规则、工单路由、企业微信群机器人、指标看板。它们通常按字符串匹配企业名做分租户归属。字段一改，看板不会崩，只会变成空图；工单不会报错，只会堆在默认队列。这类问题往往在真实安全事件复盘时才被发现。
其余几项改动指向同一方向——减少误报与提升可操作性：自定义模式重扫后保持告警开启，避免“关闭再重开”打断处置上下文；webhook 增加 exemption_request.number，让跨集成关联同一请求成为可能；422 与 500 的区分，让集成能把“我传错了参数”与“服务端挂了”分开处理，前者不该重试，后者才该退避重试。
对谁有价值
- 安全工程师与 SOC 团队：告警生命周期与请求编号直接影响处置效率。
- 平台/DevOps 团队：审计日志字段是对接企业侧日志管道的接口契约。
- 安全工具集成方：错误码语义和 webhook 载荷结构决定集成健壮性。
- 使用私有/内部仓库并启用 secret scanning 的组织：base64 编码令牌现在也能走自动吊销。
可以怎么行动
- 盘点所有按 business 字段字符串匹配的解析逻辑，在生效日期前改为同时接受 slug 与显示名称，或直接改用 business_id（数值型，本次未变，最稳）。
- 把 422 纳入集成错误处理：作为输入错误记录并告警，不要进入无限重试循环。
- 检查告警看板或工单系统是否依赖“关闭再重开”来判断新事件；若是，改为依赖事件 ID 与告警状态。
- 若已有令牌吊销 runbook，补充 base64 编码令牌（含 classic PAT、细粒度 PAT、OAuth 令牌、GitHub App 用户令牌）的处置条目。
- 在 webhook 消费侧用“仓库 + exemption_request.number”作为幂等键，减少重复工单。
风险与限制
第一，原文只说明了变更日期与新行为，未说明旧格式是否会有并行兼容期，也未见迁移工具，因此兼容逻辑需要自己兜底并长期保留。第二，令牌吊销仍标注为公开预览，行为可能继续调整，不宜作为唯一处置手段。第三，自定义模式告警保持开启会减少状态抖动，但也可能让长期未修复的告警在列表里持续堆积，需要配套的过期与分级策略。第四，字段由显示名称改为 slug 后，任何面向人的报表会从“公司名”变成“标识串”，展示层需要额外映射。
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《GitHub secret scanning 更新：审计日志字段变更与多项修复》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。