If secret-scanning audit events are routed by an enterprise display name, inspect the filter before November 12. GitHub says the business string in certain events will change to the enterprise slug. Checking only that it remains a string misses a semantic migration. Prefer a verified business_id, with name compatibility treated as a controlled transition.

This is an interface change for security-log consumers, not a new detection-accuracy benchmark. Nine fictional events show how matching names, renamed labels and missing IDs affect routing. The replay method avoids real credentials and keeps classification tests separate from consequential security actions. 中文版.

An October announcement for a November transition

The original October 20 announcement, discovered through Google News, schedules a change for November 12, 2026. In affected secret_scanning_alert.* and secret_scanning_push_protection.bypass audit events, business changes from an enterprise display name to its slug. Event names and numeric business_id values remain unchanged; business remains a string.

The announcement date therefore must not be presented as a completed rollout date. Nor should this scope be generalized to every GitHub log field. This investigation concerns the event families explicitly identified in the announcement. An integration still needs to establish which product, event family and version it actually consumes.

The failure can hide behind a passing type check. Both Example Engineering and example-eng satisfy a string assertion. A filter requiring the old display name can silently send the new value to its default branch. JSON parsing succeeds while downstream counts lose events. Such a failure can be harder to spot than a clear parser exception.

Use labels for display and identity for correlation

Assign fictional numeric ID 101 to the target enterprise and ID 202 to another one. If an event explicitly carries 202 while displaying the target’s old name, a name match must not turn it into an event from 101. Compatibility logic should respect a verified identity field rather than accept a loose expression where any matching field is sufficient.

A real consumer first selects the affected event families, then applies identity routing. The dictionary example assumes that scope has already been established; it is not a universal router for every audit event. A transparent migration model separates four outcomes: a matching target ID, another ID, a missing-ID event whose label matches the transition map, and an unresolved structure or identity requiring review. A label candidate is not a confirmed identity. It can feed isolated diagnostics or a lookup path without being silently counted as a trusted target event.

Likewise, the string 101, boolean true and integer 101 should not be treated as interchangeable without an explicit parsing contract. The example sends invalid types to review instead of coercing them. A production integration may have a documented conversion rule; if so, record that rule, its rejection conditions and how the original value is retained. Implicit conversion is a poor way to hide upstream schema drift.

Replay the candidate rule before switching routing

Prepare authorized, sanitized old-format and new-format fixtures. Preserve their input fields and run the old and proposed rules side by side. Compare the outcome for each event, including the new classification, rather than checking only the final count of target events. Errors in opposite directions can cancel numerically and leave a healthy-looking dashboard.

For example, an old rule can wrongly include an ID 202 event with the same label while excluding an ID 101 event carrying the new slug. With one of each, the total can stay unchanged even though both classifications are wrong. Retain per-event correlation evidence, error categories and comparison results. If a fixture lacks a stable event identifier, label that limitation instead of deduplicating by display text.

Replay does not require injecting test alerts into a production security system. Prefer offline data for validating parsing, routing and counting, with no alert closure, bypass approval or credential revocation. This program only operates on fictional in-memory dictionaries. It reads no private log and makes no state-changing GitHub API request.

Ten checks cover errors an aggregate can conceal

The model below chooses ID 101 as its artificial target. Inputs include the old label, the new slug, another ID using the same label, missing fields and invalid types. The final assertion checks all four class counts, preventing candidates from being merged with confirmed targets. None of the names or IDs represents a real enterprise.

# 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)

Nine event checks and one aggregate assertion execute locally. They validate this migration contract, not a general-purpose GitHub parser. In particular, legacy-candidate is a teaching label introduced here; it is neither an official payload field nor an audit-event type. A production implementation must connect its classifications to its own authorized handling process.

What to observe during migration

Track input count per event family, parse failures, unknown identities or labels, candidate count and disagreements between the two rules. Compare the same collection window and the same input set. A traffic difference across unrelated windows cannot be attributed directly to a routing change.

Successful storage does not establish successful routing, and successful routing does not establish completed security response. Give each stage its own acceptance condition: was the input retained, was identity established, did the intended consumer receive it, and does any subsequent action need human review or additional authorization? A field migration is not a reason to expand automated response privileges.

If a display-name/slug transition map remains necessary, record its source, enterprise scope, allowed period and retirement criteria. Decide when to remove its old-name branch using real input evidence. A calendar date alone does not justify removing observation while unresolved events keep growing. Equally, an unverified name allowlist should not become a permanent substitute for identity.

What this change does not establish

Changing future routing does not repair historical statistics already misclassified by the old rule. If authorized source records exist, design the replay window and deduplication rules separately. This example performs no historical writeback.

A correct identity field does not prove that events are complete, timely or unique. Delivery delay, retry and loss need separate evidence from an authorized pipeline. No enterprise coverage, remediation rate or reduction in credential exposure was measured here. The program tests classification rather than claiming operational outcomes.

A changed label also does not mean an alert’s risk changed. Do not interpret a different field value as a new alert, a different enterprise or a resolved issue. The earlier GitHub secret-detection analysis addresses detection evidence. This article addresses identity and routing after an event enters an integration; each layer needs its own validation.

The distinction also applies when an AI agent consumes security context. Mark whether it receives a confirmed event identity or a candidate inferred only from a label. Making input contracts explainable does not authorize an agent to approve bypasses, close alerts or revoke credentials. Those actions have different evidence and authorization requirements.

If these replay fixtures help find a filter that could silently undercount events, voluntary support through the section below is welcome. The reusable result is a per-event comparison method that gives verified identity priority over a display label.

Sources and article date

October20 announcement · Enterprise audit events

Discovered through Google News and checked against the original announcement, published before the planned slot. Examples and diagrams are original teaching material, not a product benchmark or real account operation. The planned article date is 2026-10-21 at 16:00 Beijing time. Scheduling or actual public release is verified separately; a backfilled date does not imply earlier publication.