GitHub adds live validity checks and incident integrations to public secret monitoring

Enterprise security teams can triage attributed public leaks, follow their state history and connect alerts to response systems through APIs and webhooks.

GitHub has expanded public secret monitoring with alert management, recurring validity checks and integration points for enterprise response systems. The 23 October update gives security teams more ways to work through credentials attributed to their organisation when those credentials appear in public repositories.

The feature remains in public preview for GitHub Enterprise Cloud customers, including customers using data residency. GitHub says it is included with an Advanced Security or Secret Protection licence at no additional cost.

From a detected leak to a managed alert

The enterprise security dashboard now supports closing an alert as dismissed or fixed, adding an optional decision comment and reopening it later. An activity timeline records state changes and actions.

Teams can filter by repository, committer, secret type, attribution method and open or closed state. Attribution can be based on membership or a verified domain. These fields help an enterprise separate the work into queues—for example, newly found active credentials, a particular provider or repositories associated with a specific team.

That matters because a public exposure is often discovered outside the repository where the credential was originally intended to be used. The incident record has to connect the exposed location with the organisation that can act on the credential and the system that issued it.

Validity becomes an ongoing signal

For supported providers, public monitoring now checks validity continuously and displays active, inactive or unknown. An active credential can receive immediate attention, while an unknown result remains distinct from a confirmed inactive one.

GitHub explicitly separates alert state from credential state. Closing an alert does not revoke the exposed credential or remove it from the public repository. Those actions belong to the issuing provider and the repository's own content lifecycle.

A response workflow can therefore use several records together: the detection, the provider-side revocation or rotation, and the verification that dependent systems have moved to the replacement credential. The dashboard's timeline supplies a place to follow the alert decisions without turning a closed label into a claim about every external action.

Connecting enterprise response systems

The release adds a REST endpoint for enterprise administrators and enterprise security managers to query attributed public-monitoring findings. Returned material includes alert metadata, secret type, attribution and exposed locations.

An enterprise-level webhook can also notify response systems when a newly detected leak is attributed to the organisation. This allows a security team to connect detection with its existing incident queue rather than repeatedly poll a dashboard manually.

The useful integration is specific: a new finding can open or enrich an incident, route it to the relevant owner and retain the link back to the GitHub alert. Repeated notifications can update the same incident when the integration recognises the alert identity.

These additions make public monitoring more operational. Detection is followed by prioritisation, assignment, credential action and a recorded decision. For engineering organisations maintaining many repositories and external integrations, that progression is what turns a scanning feature into a workable response process.

GitHub's preview now provides more of the interface and transport needed for that process, while the actual credential lifecycle remains with the systems and owners responsible for the exposed access.

Sources

- [Public monitoring adds triage, validity, API, and webhooks](https://github.blog/changelog/2026-10-23-public-monitoring-adds-triage-validity-api-and-webhooks/) — GitHub