GitHub public monitoring: triage leaked secrets with API and webhooks

GitHub public monitoring watches public GitHub repositories for secrets attributed to your enterprise. On 23 October 2026 it gained alert triage, continuous validity checks, a REST API and a webhook. It remains in public preview for GitHub Enterprise Cloud customers.

It is included with GitHub Advanced Security or GitHub Secret Protection at no extra cost. Enterprise admins and enterprise security managers turn it on from the enterprise security dashboard.

Sources checked on 26 October 2026. Features, prices and availability can change; confirm the linked primary sources before acting.

What changed in GitHub public monitoring

Alerts can now be triaged, filtered and automated. Validity checks tell you which leaked credentials still work.

Validity checks run continuously for supported providers and show Active, Inactive or Unknown. The REST API returns alert metadata, secret type, attribution and exposed locations. The webhook fires when a new leak is attributed to your organisation.

Dismissing an alert does not revoke the secret

Closing an alert changes its state for your enterprise only. It does not revoke the credential or remove it from the public repository.

Anyone who copied the secret can still use it until you revoke it at the provider. Treat every alert as a live incident until rotation is confirmed.

Build a response workflow from webhook to rotation

Automate intake and triage, then keep a person on revocation. This order limits exposure time.

1. Receive. Point the secret_scanning_public_monitoring_alert webhook at an internal endpoint. Verify the signature and store the event.
2. Enrich. Fetch the alert from the REST API for its secret type, attribution and locations.
3. Prioritise. Active credentials first, Unknown next. Confirm Inactive ones at the provider rather than trusting the label.
4. Revoke and rotate. Revoke at the provider, issue a new credential and deploy it through your secret manager.
5. Request removal. Ask the repository owner to remove the file. Rotation comes first, because history and forks may keep copies.
6. Close with evidence. Mark the alert Fixed with a comment linking the rotation ticket.

Audit evidence and post-incident rotation

The alert timeline becomes part of your audit trail. Add what GitHub cannot see.

• Check provider logs for use of the credential during the exposure window.
• Record who rotated what and when, and which systems received the new secret.
• Enable push protection and pre-commit scanning to stop the next leak.
• Prefer short-lived credentials so a future leak expires on its own.

Our verdict: wire the webhook into your incident process now, even in preview, but never let closing an alert stand in for revocation. Our Docker Compose production checklist covers secret handling in deployments. For a secret-scanning and response setup, see our application maintenance and support service.

Sources and further reading

• Public monitoring adds triage, validity, API and webhooks — GitHub

Image credits

Explanatory diagrams: Cloudsoft Zone, CC BY-SA 4.0. Featured photograph: ImagePerson, CC BY-SA 4.0, via Wikimedia Commons. API Portal - API key management: APaskulin (WMF), CC BY-SA 4.0, via Wikimedia Commons.