GitHub secret scanning audit log format shift and API refinements: impact on automation and security tooling

GitHub secret scanning is receiving a set of concrete updates that touch audit‑log formatting, webhook payloads, and several REST‑API behaviours. The most visible change is the switch of the business attribute from an enterprise display name to the enterprise slug, and a handful of functional tweaks that directly affect CI/CD pipelines, security dashboards, and automated remediation scripts.

Audit log field format change

Effective 12 Nov 2026, events named secret_scanning_alert.* and secret_scanning_push_protection.bypass will emit the business field as the enterprise slug rather than the human‑readable display name. The field remains a string, and the numeric business_id stays unchanged. Integrations that filter logs by display name must be broadened to accept both formats or, preferably, switch to the stable business_id identifier to avoid breakage during the rollout.

API and webhook behavior updates

• Custom pattern alerts: Open alerts now remain open after a rescan confirms they still match an edited custom pattern, eliminating unnecessary close‑reopen cycles.
• Token revocation support: The public‑preview revocation action now automatically decodes Base64‑encoded values and can revoke classic PATs, fine‑grained PATs, OAuth tokens, and GitHub App user tokens in private and internal repositories.
• Dismissal‑request webhook payloads: New field exemption_request.number provides the repository‑scoped request number, matching the REST API and enabling reliable correlation across systems.
• Bypass‑request metadata: Empty secret-type and location details have been fixed for command‑line push bypass responses when another repository rule follows secret scanning.
• Delegated bypass fixes: Push failures caused by lingering organization‑role entries in reviewer lists are resolved, and 500 errors when configuring valid reviewers for organization‑owned repos via the REST API are eliminated.
• Custom pattern API error codes: Invalid argument rejections now return HTTP 422 instead of 500, allowing callers to distinguish client‑side input errors from server failures.

Operational and security considerations

These adjustments have several practical implications. Parsing pipelines must be updated to recognize the slug format and optionally prefer business_id. Automation that reacts to dismissal‑request webhooks should now capture exemption_request.number to uniquely identify requests. The expanded revocation capability means that token‑cleanup scripts can rely on a single endpoint for multiple token types, but they must also verify that the automatic Base64 decoding behaves as expected in their environment.

Accessibility improvements—keyboard‑focusable pending status and screen‑reader announcements—do not affect backend integrations but indicate a broader push for usable security UI, which may influence internal tooling design.

Related CloudNinjas coverage: security.

What This Means For Practitioners

• Audit existing log‑parsing rules; add support for both display name and slug, or migrate to business_id.
• Update webhook consumers to read exemption_request.number and adjust correlation logic.
• Validate that revocation workflows correctly handle Base64‑encoded tokens across all supported token types.
• Adjust error‑handling paths to treat HTTP 422 as a client‑error condition rather than a generic failure.
• Run integration tests for delegated bypass configurations on organization‑owned repositories to confirm the 500‑error fix.