What happened
GitHub published an improvement update for Secret Scanning on October 20, 2026. Its most operationally consequential item is a change to enterprise audit-log data. Beginning November 12, 2026, the business field in affected secret_scanning_alert.* and secret_scanning_push_protection.bypass audit-log events will change from an enterprise display name to an enterprise slug. The field will remain a string; event names and numeric business_id values will not change. GitHub advises teams whose integrations filter on the display name to accept both forms before rollout, or to use business_id instead.
The update also expands an existing revocation action that remains in public preview. In private and internal repositories on github.com where Secret Scanning is enabled, the action now supports base64-encoded GitHub credentials: classic personal access tokens, fine-grained personal access tokens, OAuth access tokens, and GitHub App user access tokens. GitHub says it automatically decodes the detected value. The announcement does not describe a new detection engine or a new repository tier; it extends the remediation path for already supported encoded credentials in the stated repository and hosting scope.
Several changes concern the reliability of integrations around alert review and push protection. When a rescan finds that an open custom-pattern alert still matches an edited custom pattern, GitHub will keep that alert open instead of closing and reopening it. Dismissal-request webhook payloads now include exemption_request.number, a repository-scoped request number that is also available through the REST API. GitHub recommends using the repository together with that number to correlate a request across integrations.
GitHub also fixed empty secret-type and location details in certain bypass-request API and webhook payloads. The affected condition was command-line pushes where another repository rule ran after Secret Scanning. It says delegated bypass fixes address push failures caused by existing organization-role entries in reviewer lists, plus 500 errors when valid reviewer configurations were set through the REST API for organization-owned repositories. Finally, invalid arguments rejected by the scanning service in the Custom Pattern API now return HTTP 422 rather than HTTP 500, allowing clients to distinguish invalid input from a server-side failure. The update includes accessibility improvements to pending-request focus behavior and status announcements in the revocation flow.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
No supplied New Runtime pattern is genuinely established by this maintenance and compatibility update.
Why now
The source provides a specific reason to act before the broader set of improvements fades from view: the audit-log field migration is scheduled for November 12, 2026. A parser that assumes a human-readable enterprise display name can silently stop matching after that date even though the event type remains unchanged. The coexistence guidance is practical: accept both string formats during transition, or key the workflow to the unchanged numeric business_id.
Why it matters
Security automation is only as dependable as the identifiers, error semantics, and correlation fields that cross its boundaries. For a team using Secret Scanning to create tickets, enrich incident records, measure bypasses, or trigger remediation, the audit-log change is not cosmetic: a display-name filter can be part of a production control. Moving logic to business_id, where appropriate, reduces dependence on a mutable presentation field.
The other changes improve the completeness and diagnosability of an automated remediation pipeline. Encoded credentials can appear in source, generated files, or copied configuration values; support for decoding them before the revocation action runs narrows a gap between detection and response. A 422 response for invalid custom-pattern arguments also lets an integration classify a configuration error without treating it as a platform outage. None of this removes the need to validate alerts and access policies, but it makes the surrounding workflow less ambiguous.
What happens next
- More teams will update Secret Scanning log parsers to rely on
business_idor accept both name formats. (3 months, 80%). Watch for: November migration notices or integration fixes. - Remediation workflows will test encoded-token cases alongside plain-text secret fixtures. (6 months, 60%). Watch for: runbooks and automated test coverage that include base64 values.
Limits and uncertainty
This changelog does not quantify how often encoded tokens are found, how successful the public-preview revocation action is, or whether every supported credential can be revoked in every circumstance. It does not state when the revocation capability will become generally available, nor does it provide a migration grace period beyond its recommendation to accept both audit-log formats before the stated rollout. The announcement also does not establish that existing customer integrations currently depend on display names. Teams should inspect their own queries, webhook consumers, and downstream schemas rather than infer impact from the presence of the change alone.
Skill to build now
Create a small compatibility test for the Secret Scanning event consumer this week. Feed it representative affected event records whose business values are both an enterprise display name and an enterprise slug, and verify that routing, enrichment, and alert correlation still work. Where the integration has access to it, make business_id the durable key and retain the string only for display. Add API fixtures for a 422 Custom Pattern response and for a dismissal request identified by the combination of repository and exemption_request.number.
Reader takeaway
The important change is not a new dashboard feature: it is a dated contract change in security-event data, plus more robust remediation for encoded GitHub credentials. Before November 12, make Secret Scanning automations tolerant of the slug format or anchor them on business_id; then test the newly distinguishable API error and correlation paths.
Open question
How long will the two audit-log representations coexist in real customer pipelines, and will GitHub publish migration telemetry or additional compatibility guidance before the change takes effect?