GitHub Secret Scanning Audit Logs Switch Enterprise Names to Slugs November 12, 2026

The item with a deadline: the audit log business field​

On November 12, 2026, the business field in secret_scanning_alert.* and secret_scanning_push_protection.bypass events switches from the enterprise display name to the enterprise slug. GitHub's changelog says the field is still a string, and that event names and numeric business_id values stay the same.

GitHub tells admins to update any integration that filters on the display name. The two options are to accept both formats or to filter on business_id.

Here is why that matters. Imagine a SIEM rule or a log-forwarding filter that matches business == "Contoso Global Holdings". After the change, the same events would carry something like contoso-global, and the rule would stop matching. This is my inference from the announced value change. GitHub does not say every integration will break.

GitHub's audit-log documentation lists both business and business_id as standard fields on enterprise audit events. So business_id is a documented field you can rely on.

What to do before November 12:

1. Search your SIEM rules, dashboards, alert queries and log-forwarding filters for any match on the enterprise display name. Look at the two affected event families first.
2. Either switch the filter to business_id, which is the sturdier choice, or temporarily match both the display name and the slug.
3. Check any compliance report that groups by business. After the cutover, a historical series could show two different values for the same enterprise.
4. After the date, confirm that events are still arriving in your pipeline with the expected value.

The other changes​

The changelog lists these as recent improvements and bug fixes. It gives no rollout timing and no version numbers for any of them.

• Custom pattern alerts: If a rescan finds that an open alert still matches an edited custom pattern, the alert now stays open. Before, it was closed and reopened. Workflows that react to close/reopen events may see fewer transitions in this case. That is an operational inference, not something GitHub states.
• Base64-encoded GitHub tokens: In private and internal repositories on github.com with secret scanning enabled, the revocation action now handles encoded tokens. GitHub labels that action public preview. The supported types are personal access tokens (classic), fine-grained personal access tokens, OAuth access tokens and GitHub App user access tokens. GitHub decodes the value automatically. The announcement is limited to github.com private and internal repositories, so don't assume it covers GitHub Enterprise Server or other token types.
• Dismissal-request webhooks: Payloads now include exemption_request.number. This is the repository-scoped request number that the REST API also exposes. Because the number is scoped to a repository, GitHub says to pair the repository with the number when correlating requests across integrations. The number alone isn't globally unique.
• Accessibility: The Request pending status on an alert can now take keyboard focus without triggering an action. The revocation flow announces progress to screen readers. It also moves focus to the completion panel when that panel appears.
• Bypass-request metadata: GitHub fixed empty secret-type and location details in bypass-request API responses and webhook payloads. The problem occurred for command-line pushes when another repository rule ran after secret scanning. This was a metadata problem. The changelog doesn't describe any change to detection or blocking.
• Delegated bypass: Two fixes. Pushes no longer fail because of existing organization-role entries in reviewer lists. Valid reviewer configurations for organization-owned repositories no longer return 500 errors when set through the REST API. The changelog doesn't say which role entries caused the failures, so there is no workaround to pass along.
• Custom pattern API: Requests that the scanning service rejects for invalid arguments now return 422 instead of 500. Client code can then tell bad input apart from a server fault. Teams that retry on 5xx responses should check that their retry logic doesn't keep resubmitting a request that will never be valid. They also shouldn't count these rejections as outages.

Who is affected​

GitHub's documentation says secret scanning runs automatically and for free on public repositories. For organization-owned private and internal repositories it requires GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud. The audit-log change therefore matters mainly to enterprise admins and security teams. The API and webhook fixes matter to anyone who has built automation around alerts, bypass requests or custom patterns.

This update isn't a new release of secret scanning and it doesn't report a security incident. It is housekeeping that can still cause trouble. The audit-log change in particular is easy to miss until a detection rule goes quiet.

Admins should make that one fix before November 12. The rest can wait for the next routine review of your secret scanning integrations.