接入 GitHub 企业审计日志的团队，最近有一项需要提前处理的兼容性调整。GitHub 在 2026 年 10 月 20 日公告：11 月 12 日起，部分密钥扫描事件的 business 字段将由企业显示名称改为企业 slug。
受影响的是 secret_scanning_alert.* 和 secret_scanning_push_protection.bypass 中的相关事件。字段仍是字符串，事件名称和数值型 business_id 不变。官方给出的迁移办法是兼容新旧格式，或者改用 business_id。
先查筛选条件，不只是日志解析器
对维护日志平台的人来说，容易漏掉的不是字段类型，而是字段取值。比如一条告警规则把企业显示名称写死在筛选条件里，切换后日志仍可能正常入库，规则却不再命中。这是基于字段变化做出的集成风险分析，并不意味着 GitHub 已发生安全事件。
排查时可以从三个地方入手：日志采集配置、告警规则，以及报表和定时查询。搜索 business 和当前企业显示名称，确认有没有字符串精确匹配。也要检查依赖这些查询结果的自动分流、工单生成和通知脚本，避免只改了第一层筛选。
改完后，做一次新旧数据回放
建议用两份脱敏测试事件，分别填写企业显示名称和 slug，检查解析、归属判断和告警输出。不要仅以接口返回成功作为验收标准；还应确认目标事件真的进入了预期规则，并且没有把其他企业的事件错误归入。
如果准备改用 business_id，先核对各系统中企业与 ID 的对应关系。对于历史日志查询，新旧数据可能长期并存，应保留兼容查询或明确查询时间范围。具体改法取决于现有集成，这些检查步骤是本文的维护建议，不是 GitHub 宣布的额外产品要求。
这次公告包含其他密钥扫描改进，但对审计集成而言，最需要放进变更计划的是 11 月 12 日这个切换日期。提前完成规则检查和回放测试，比切换后排查“日志还在，告警没了”更省事。
原始来源：GitHub Changelog：Updates to GitHub secret scanning，发布于 2026 年 10 月 20 日。本文核验日期：2026 年 10 月 22 日。