如果密钥扫描审计日志按企业显示名称分流，11月12日之前应检查过滤规则。GitHub公告说，部分事件里的business字符串将改为企业slug；只验证字段仍是字符串，会漏掉一次语义迁移。优先使用已核实的business_id，旧格式兼容应作为受控过渡。

这不是检测准确率的新评测，而是安全日志消费端的接口变化。下面用九条虚构事件说明“同名、改名、缺失ID”怎样影响路由，再给出不接触真实凭据的回放验收方法。Read in English。

10月公告，11月才切换的字段

Google News收录的10月20日原始公告给出计划：2026年11月12日，受影响的secret_scanning_alert.*及secret_scanning_push_protection.bypass审计事件中，business由企业显示名称改为slug。事件名称和数值business_id不变，business仍是字符串。

因此不能把公告日写成已经完成切换，也不应把这项变化扩展成所有GitHub日志字段都改了。本文只分析公告明确列出的范围，读取原始事件时仍应核对自己实际接入的产品、事件族和版本。

变更容易藏在类型检查之后：旧值“Example Engineering”和新值“example-eng”都能通过string断言。但若规则只写business等于旧显示名称，新事件会掉入默认分支。JSON没有解析失败，下游统计却可能漏计；这比显式报错更难发现。

名称用于展示，身份用于关联

给虚构目标企业指定数值ID101，另一个企业ID202。若事件明确携带202，却同时带着目标的旧名称，不能因为名称匹配就把它认成101。名称兼容逻辑应服从已经核实的身份字段，而不是用“任意一个字段匹配就通过”的宽松表达式。

实际消费端先按受影响事件族筛选，再应用身份规则；下面的字典示例假定这一前置范围已经确定，不是所有审计事件的统一路由器。一个可解释的迁移模型把事件分成四类：目标ID匹配、其他ID、没有ID但名称符合过渡映射的候选、结构或身份不清楚需要复核。候选不是身份已确认；可以进入隔离统计或回查路径，不能自动当成可信目标事件。

不要把字符串“101”、布尔值true与整数101混为一谈。示例有意把错误类型送入复核，而不是静默强制转换。真实集成也可能有明确的解析规范；若要做转换，应把规范、拒绝条件和原始值保存方式写清楚，不能用一次隐式转换掩盖上游格式变化。

先回放，再切换生产路由

先准备经授权、脱敏的旧格式和新格式样本，保留原始字段，再并行运行旧规则与候选新规则。对每个样本比较旧规则是否命中、新规则落在哪一类，而不是只比较最终目标计数。两个方向的错分可能恰好抵消总数，让看板看起来正常。

例如旧规则把ID202但名称相同的事件误收进来，同时漏掉ID101的新slug事件。如果样本各有一条，目标总数可能没变，归属却已经错了。验收应保留逐事件关联依据、错误类别和对照结果；没有稳定事件标识的样本要明确标记，不能靠显示文本去重。

回放不等于向生产安全系统注入测试告警。优先把输入当成离线数据，验证解析、路由与统计，不触发关闭告警、批准绕过或撤销凭据。这篇代码只操作内存中的虚构字典，没有读取真实日志，也没有调用GitHub接口改变任何状态。

十项检查，覆盖看板总数可能漏掉的错误

下面模型把ID101作为人工设定的目标。输入既有旧名、新slug，也有其他ID同名、缺失字段和错误类型。最后检查四类计数，确保没有把候选和已确认目标合并。代码中的名字与ID不对应真实企业。

# Synthetic migration fixtures only. No account or audit-log access.
TARGET=101
NAMES={'Example Engineering','example-eng'}
def route(event):
    ident=event.get('business_id')
    if type(ident) is int:
        return 'target' if ident==TARGET else 'other'
    if ident is not None:
        return 'review'
    return 'legacy-candidate' if event.get('business') in NAMES else 'review'
fixtures=[
 ({'business_id':101,'business':'Example Engineering'},'target'),
 ({'business_id':101,'business':'example-eng'},'target'),
 ({'business_id':202,'business':'Example Engineering'},'other'),
 ({'business':'Example Engineering'},'legacy-candidate'),
 ({'business':'example-eng'},'legacy-candidate'),
 ({'business_id':'101','business':'example-eng'},'review'),
 ({'business_id':True,'business':'example-eng'},'review'),
 ({},'review'),
 ({'business_id':101,'business':'a renamed label'},'target')]
for event,expected in fixtures:
    assert route(event)==expected
counts={k:sum(route(e)==k for e,_ in fixtures)
        for k in ['target','other','legacy-candidate','review']}
assert counts=={'target':3,'other':1,'legacy-candidate':2,'review':3}
print('10 migration-contract checks passed',counts)

九条事件分别通过检查，分类汇总再通过一项断言。它验证的是本地迁移契约，不是GitHub提供的通用解析器。尤其legacy-candidate只是本文命名的过渡状态，不是官方字段或正式审计事件类型。

迁移期间，应该观察什么

记录各事件族的输入总数、解析失败数、未知ID或名称数、候选数，以及新旧规则不一致数。应按同一采集窗口和同一输入集合比较；不同窗口的自然流量变化，不能直接归因于规则迁移。

已进入存储不等于已成功路由，路由成功也不等于安全处置完成。给日志管线分开设置验收：入口是否保留事件，身份是否明确，下游是否正确接收，后续动作是否需要人工或额外授权。不要因为字段迁移就顺手扩大自动处置范围。

如果旧名与slug兼容映射仍需保留，记录来源、适用企业、允许的时间范围和退出条件。迁移完成后是否移除旧名路径，应根据真实输入证据决定。不能在未知事件仍增长时仅因过了日期就删掉观察路径，也不能无限保留未经核实的名称白名单。

这次公告没有证明哪些事

如果已有事件被旧规则错分，修改未来路由还不能修复历史统计。应在有授权、保留原始输入的前提下另行设计回放窗口与去重规则；这里没有回写任何真实历史数据。

身份字段正确，不表示事件一定完整、实时或未重复。采集延迟、重试和丢失是另一组问题，需用现有、有授权的管线证据验证。这里不声称测量了任何企业覆盖率、漏洞修复率或泄漏减少比例。

显示名称变化也不意味着告警风险发生变化。不要把字段不同当成新告警、不同企业或已经解决的问题。此前的GitHub凭据检测解读关注检测证据；本篇关注同一类事件进入集成后的身份与路由，两层问题应分别验证。

对AI代理消费的安全上下文，这个边界同样重要：代理读到的是已归属的事件，还是仅凭名称猜测的候选，应明确标注。这里的建议是提高输入契约可解释性，不是授权代理自动批准、关闭或撤销任何对象。

如果这组回放样例帮你提前发现了一条容易静默漏计的过滤规则，欢迎通过文末自愿支持。可直接带走的是逐事件比对和身份优先的验收方法。

来源与文章日期

October20 announcement · Enterprise audit events

通过Google News条目发现并打开原始公告；来源时间早于原计划时段。示例与图形为原创教学内容，不是产品测评或真实账户操作。计划文章日期为2026年10月21日16:00北京时间；实际排期或公开状态另行核验，补发不表示此前已经公开。