GitHub Public Monitoring: Triage, Validity, API and Webhooks

GitHub expanded its public-monitoring preview on October 23, 2026 with tools for managing credentials detected in public commits and attributed to an enterprise. Administrators and enterprise security managers can now dismiss, mark fixed, reopen and filter findings, with an activity timeline recording state changes. Supported secret types also receive ongoing validity checks labelled Active, Inactive or Unknown. This is a separate operational update from GitHub’s October 22 extension of public monitoring to Enterprise Cloud tenants with data residency.

Alert state and credential state are different

GitHub explicitly warns that closing an alert changes only the enterprise’s record. It does not revoke the exposed credential or remove it from the public repository. An Active result can help prioritize a live key, while Inactive or Unknown should not be treated as proof that the key was harmless or never copied.

Respond at the issuing provider: revoke or rotate the credential, identify legitimate dependants, inspect relevant audit logs and then remove the exposed value from current code and history as policy requires. Keep comments free of the secret itself. The alert timeline is evidence of triage, not a substitute for provider-side remediation.

The API and webhook can connect enterprise response systems

A new enterprise REST endpoint returns attributed public-monitoring alerts with metadata, secret type, attribution and exposed locations. An enterprise webhook can notify a response pipeline when GitHub attributes a newly detected leak. Filters include repository, committer, secret type, attribution method and alert state.

Automation should preserve least privilege and idempotency. Validate webhook signatures, avoid echoing secret material into tickets, and make retries safe. A webhook delivery failure must not become the only place a critical alert exists; retain dashboard review and ownership checks.

Public preview and licence boundaries still apply

GitHub says public monitoring remains a public preview for Enterprise Cloud, including data-residency deployments, and is included with GitHub Advanced Security or GitHub Secret Protection licences. The announcement does not establish that a particular enterprise has enabled the feature or that every credential provider supports validity checks.

Canadian organizations should verify corporate domains, attribution assumptions, notification destinations and employee-response procedures before enabling automated routing. Test with synthetic credentials only under an approved plan, and cross-link findings to the earlier data-residency configuration review rather than assuming residency resolves identity or response gaps.

Sources and editorial method

We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.

GitHub: public monitoring adds triage, validity, API and webhooks ↗ — October 23 preview update; alert management, validity status, endpoint, webhook and eligibility.
GitHub Docs: public monitoring for secret scanning ↗ — Official scope, attribution, management and remediation guidance.