Closing a GitHub Public Monitoring Alert Does Not Revoke the Key
A company credential turns up in an issue comment outside its own repositories. After the finding is marked Fixed, what happens to applications that already have a copy of that key?
- GitHub’s October 23 update adds alert management, validity checks and integrations to Public monitoring.
- An alert’s workflow state is separate from whether its credential still works.
- Data-residency tenants can use the preview with attribution based on verified email domains.
Find exposure beyond repositories your enterprise owns
Public monitoring attributes credentials found in public GitHub repositories to an enterprise. It reaches beyond the enterprise’s own repositories and includes non-code surfaces such as issue and pull-request comments.
In the standard environment, attribution can come from enterprise membership or a user email matching a verified enterprise domain. This is coverage across public GitHub repositories, rather than a claim to monitor the entire internet.
The management view lives at enterprise level. Under Security and quality, Public monitoring shows findings and their attributed users and repositories. Opening a finding reveals its location and recommended remediation.
Closing the finding changes its record, not the credential
The October 23 release adds closure and reopening, plus ongoing validity checks for supported secret types. GitHub explicitly separates closing an alert from revoking the credential or removing its public copy.
| Signal or action | What it represents |
|---|---|
| Close or reopen | The enterprise’s handling of a finding |
| Active, Inactive or Unknown | A supported credential’s validity status |
| Revoke at the issuer | Invalidate the credential itself |
Unknown is not a clean bill of health. GitHub’s remediation guidance identifies the issuer as the best authority on whether a secret remains valid. It also calls for updating dependent services where replacement credentials are needed, verifying those services and checking for unauthorized access.
Feed new findings into incident response
Enterprise administrators and security managers can query attributed findings at GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts. Enterprise webhooks provide the secret_scanning_public_monitoring_alert event when a newly detected leak is attributed to the enterprise.
An incident system can use that event to begin handling a finding. Completion needs its own evidence. The management interface supports comments when dismissing or reopening alerts, so teams can preserve the reason for a decision without treating an empty open-alert queue as proof that every exposed credential has been invalidated.
Regional tenants use verified domains for attribution
GitHub’s October 22 announcement extends the public preview to Enterprise Cloud with data residency. Those tenants do not share enterprise membership rosters with github.com. Attribution instead relies exclusively on a commit author’s email matching a verified enterprise domain.
GitHub says the resulting alert is encrypted and delivered to the enterprise dashboard while data stays in the designated geography. Teams should therefore distinguish this domain-based coverage from the standard environment’s membership-based attribution.
An active GitHub Advanced Security or GitHub Secret Protection license is required. Public monitoring is included without an additional charge under those licenses; the feature remains a public preview.
Frequently asked questions
Does GitHub ever revoke leaked credentials automatically?
Yes. GitHub automatically revokes its personal access tokens exposed in public repositories. Other supported secrets may be reported to their providers, which may revoke them. That process is separate from closing a Public monitoring alert.
Is deleting the exposed line enough?
No. Removing code does not invalidate a value that has already leaked. Confirm revocation with the issuer and update services that need replacement credentials.
Use the integrations to connect discovery to response, and record completion only after confirming that the exposed credential has been revoked.