Close the exposure before closing the secret alert

GitHub's 23 October update adds triage, validity checks, API and webhooks. Public monitoring remains an Enterprise Cloud preview, included with Advanced Security or Secret Protection. Closing an alert does not revoke a credential. Validity can be Active, Inactive or Unknown. (GitHub)

For a team with several account owners, a notification needs a named responder and a containment decision. Treat its reported status as one piece of evidence, then establish who can verify and revoke the credential.

Three labels, three different questions

Unknown is not an instruction to paste a token into a third-party checker. Nor does Inactive prove that nothing happened before it stopped working. Avoid recording the full secret in tickets, chat notifications or a CRM; use a restricted incident reference that leads authorised responders to the source system.

Make the response record survive a handover

• Assign an incident owner and identify the credential issuer, scope and affected deployments.
• Contain or revoke through the issuer's process, coordinating dependent services to avoid a silent outage.
• Replace the credential in the approved secret store and redeploy the consumers that need it.
• Verify that the replacement works and the old credential is no longer accepted where you can safely establish that.
• Review relevant logs, document the time boundary and close the alert with links to the containment evidence.

Removing a token from the current version of a file does not make previous public exposure disappear. Treat repository cleanup and issuer-side containment as separate tasks. The response may also need customer or internal incident handling according to the circumstances; a feature announcement cannot decide those obligations for a Swiss organisation.

Integrate alerts without spreading the secret

A useful integration sends minimal metadata to a private incident queue: an alert identifier, affected repository reference, reported type, validity observation and owner. Authenticate the incoming notification through the documented enterprise integration mechanism. Make delivery retries safe so one alert does not create several independent incident records.

Illustrative incident record, not a webhook payload schema:
alert_reference -> restricted incident ID
reported_validity -> Active | Inactive | Unknown
owner -> accountable responder
containment_evidence -> issuer-side reference
replacement_check -> pending | verified
closure_reason -> linked evidence

The queue is for coordination, not for deciding that a leak is harmless. Keep permissions narrow and ensure that responders can find the issuer without distributing the credential itself. If a webhook or API is unavailable for your account, use the supported dashboard workflow rather than assuming access from the announcement.

Measure response quality, not closed-alert volume

Useful internal measures include unassigned exposure time, time to verified containment and incomplete replacement checks. Their starting values must come from your own records. Counting closed alerts alone rewards administrative activity while hiding unresolved credentials. This proposed workflow has not been tested against a live customer incident.

For agency work, agree who owns the client's credentials before an incident occurs. That responsibility can be defined alongside technical delivery for agencies and the handover process.