GitHub public monitoring adds secret validity checks, API access and webhooks

GitHub has expanded Public Monitoring in GitHub Secret Protection with capabilities that help organisations move from merely detecting a leak to managing it as a controlled incident. Teams can now close and reopen alerts, check the state of supported tokens, retrieve data through the REST API and react to webhook events.

The change matters when an organisation’s secrets may appear outside its own repositories—in public code published by an employee, supplier, open-source contributor or someone testing an integration. GitHub says the public preview is available to GitHub Enterprise Cloud customers, including data-residency deployments, that use GitHub Advanced Security or GitHub Secret Protection. There is no additional charge beyond the applicable licence.

Breachroad’s conclusion: a better alert does not revoke a secret. The essential organisational change is to connect GitHub’s signal to the service owner, safe rotation, a review of credential use and a documented closure decision.

What GitHub introduced

The update covers four areas:

• alert management, including closing, reopening, filtering and a change timeline;
• continuous validity checks for supported secret types, showing Active, Inactive or Unknown;
• the GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts REST endpoint;
• the enterprise-level secret_scanning_public_monitoring_alert webhook event.

Public Monitoring watches for secrets belonging to the organisation that GitHub finds in public repositories. A security team no longer has to rely solely on the repository author noticing the problem or the service provider independently sending a notification.

GitHub’s most important caveat is explicit: closing an alert does not revoke the credential or remove it from the public repository. Alert state is part of the workflow, not the remediation itself.

What the validity states mean

An Active state is the strongest operational signal. It indicates that the exposed secret still works according to the validation mechanism supported by GitHub. The alert deserves urgent handling because a third party may still be able to use the credential.

Inactive means the secret no longer appears to be active. It does not prove that nobody used it before revocation. The team should still establish when the credential was created, when it became public, which resource it could reach and whether unusual operations occurred during the relevant period.

Unknown does not mean safe. Validation may be unsupported for the particular token type, or the provider may not have returned a decisive answer. In practice, the organisation should treat it as potentially active until the service owner confirms otherwise.

Who is affected

Organisations with many business units, technology partners and public repositories gain the most obvious value. In these environments, a secret can be copied into a demonstration, bug report, fork, configuration file or commit history outside the organisation’s controlled GitHub estate.

This is not exclusively a software-development concern. Exposed values may include cloud-service keys, marketing-platform tokens, messaging webhooks, and credentials for automation, support and analytics systems. Business impact depends on the secret’s permissions, not the department that created it.

The security team therefore cannot be the sole owner of the process. Security can receive and enrich the signal, but the application or service owner must be able to revoke access quickly, assess the impact and restore the integration without placing the replacement secret back in code.

A response procedure for public secret exposure

1. Identify the secret and its owner

Establish the credential type, service, account, project, environment and responsible team. Do not copy the full value into chat or the ticketing system. The alert identifier, a masked fragment and a secured link should be enough for coordination.

2. Revoke or rotate the credential

If the secret is active, or its state cannot be established confidently, the first objective is to remove its value to an attacker. Rotation must include creating a replacement and invalidating the old value. Merely generating another key leaves the original exposure open.

Plan the order of operations to limit disruption, but do not leave an active internet-exposed secret in place for hours simply for convenience.

3. Establish the exposure window and access scope

Determine the secret’s first public appearance, the permissions it had during that period and the logs available from the destination service. Look for new locations, unusual times, unfamiliar agents, bulk data access, configuration changes and privilege-escalation attempts.

If the credential provided access to personal data, financial systems or production, involve risk owners, legal counsel and incident response according to the organisation’s escalation thresholds.

4. Remove the cause, not only the visible string

Deleting a secret from the latest version of a file does not automatically remove it from Git history. Establish whether history and copies must be cleaned, but never delay rotation until that work is complete. After revocation, identify the source of the mistake: hard-coded configuration, a faulty script, CI/CD output or documentation example.

Move the replacement into a secret manager, reduce its privileges and lifetime, and add a control that lowers the chance of recurrence. A structured secrets management, Vault, KMS and rotation programme provides the foundation.

5. Close the alert with evidence

Close the alert only after the old secret is invalid, the owner has reviewed logs, the impact has been assessed and the root cause has a remediation task. Record the decision and its basis in the case history without storing the full credential value.

Using the API and webhooks safely

The webhook can forward an event quickly to a SOAR platform, SIEM, ticketing system or on-call service. Automation can enrich the alert with the resource owner, environment criticality and response target, while the API can report open cases and identify work that has stalled.

Not every credential should be automatically revoked without context. Instantly blocking a key used in production may cause an outage, while a poorly secured webhook receiver can itself become a route for workflow manipulation. Automated rules should account for the secret type, environment, criticality and an approved contingency path.

Monitor the integration itself: webhook delivery failures, expired API credentials, processing delays and alerts without an assigned owner. A process that worked at launch can silently stop routing events to the correct team months later.

Metrics that reflect actual security

The number of closed alerts can be misleading. Better measures include:

• time from detection to invalidation of an active secret;
• the share of alerts with a confirmed owner and permission scope;
• the share of cases with log review covering the full exposure window;
• recurring leaks from the same source or team;
• credentials without expiry or with excessive permissions;
• time from the incident to deployment of a preventive control.

These measures connect detection to risk reduction. A green status in a dashboard does not provide that assurance on its own.

Source facts and Breachroad’s analysis

GitHub confirms the new alert-management functions, continuous validity checks for supported tokens, REST API, enterprise webhook, public-preview scope and absence of an extra charge for appropriately licensed customers. The vendor also stresses that closing an alert neither revokes the secret nor removes it from the public repository.

The rotation procedure, exposure-window review, automation safeguards and metrics are Breachroad recommendations. Add them to the organisation’s incident response plan and rehearse the decisions with technical and business teams through cybersecurity training for organisations. An IT security audit can also assess the maturity of secrets management and its integrations.

Primary source: GitHub Changelog — Public monitoring adds triage, validity, API, and webhooks.