GitHub expanded public monitoring with alert management, recurring validity checks for supported tokens, REST APIs, and webhooks. The feature is described as a public preview for Enterprise Cloud customers. GitHub official announcement
GitHub explicitly states that closing an alert does not revoke the credential or remove it from a public repository. Alert state organizes investigation; it does not replace the credential’s actual lifecycle.
On this page
A public exposure and a currently usable credential are different facts
Secrets such as API keys and tokens can grant access to anyone holding the value. Once placed in a public repository, they can be copied independently of the repository owner’s original intentions. Public monitoring can help find exposures attributed to an organization, but response still requires identifying the credential owner and every service that depends on it.
An Active result is a useful prioritization signal. Inactive conveys the reported validity result, while Unknown can reflect insufficient information or unsupported validation. It should not be treated as a safe verdict. Understand the provider’s validation coverage and compare the result with the organization’s actual credential state instead of using a single dashboard status as the whole investigation.
Connect revocation, replacement, and service recovery
Removing the text from a document or repository is different from making the credential unusable, since someone may already have copied it. Prepare a sequence for revocation, deployment of the replacement, and confirmation that the old value is no longer used. Include infrequent scheduled jobs and deployment utilities in the consumer inventory rather than checking only continuously running services.
Coordinate replacement order with the service owner where downtime is possible, while avoiding unnecessary delay in addressing a usable exposed credential. Investigation records should not create another copy of the full secret. Track the alert identifier, exposed location, and redacted evidence so the response remains traceable without distributing the credential to additional systems.
Integrate webhooks with incident state
An incident system can use the alert identifier to update an existing case when new information arrives. Account for retries and duplicate webhook delivery so that receiving the same event twice does not unnecessarily repeat revocation tasks or page the owner again. Store notification receipt separately from actual remediation completion; successful delivery is not evidence that a secret has been replaced.
Closure criteria can include owner confirmation, the previous credential’s status, and successful operation of dependent services. Closing the GitHub alert then records that completed work. During the public-preview evaluation, inspect validity coverage and the actual API and webhook fields available to the account before connecting them to the existing response process.
Connect detection with response work
- Map alert identifiers to credential owners and service contacts.
- Track revocation, replacement, and service validation as separate tasks.
- Handle duplicate webhook delivery and retries without duplicating incidents.
Detection starts the response. Confirm that the exposed credential can no longer be used before considering the incident resolved.
Announcement reference date: 2026-10-23 · Checked: October 24, 2026
.jpg){kind=link}