GitHub self-service credential revocation changes leaked-secret response. This guide maps revocation, ownership, evidence, and recovery.
Revoke first, then investigate
When a GitHub credential leaks—a personal access token, OAuth token, deploy key, SSH key, or GitHub App installation token—the first engineering action is revocation, not root-cause analysis. Self-service credential revocation shortens the window between discovery and containment: the person who finds the secret can kill it without waiting for a ticket queue or an admin who is offline. Treat revocation as a hard stop on further abuse. Everything after that (forensics, ownership mapping, recovery) happens against a credential that can no longer mint new access.
Build a short, practiced playbook: identify the credential type, revoke it in the GitHub UI or API, confirm the secret no longer authenticates, and record who revoked it and when. Parallel work is fine—triage can start while revocation is in flight—but do not delay kill until “we know more.” A leaked token that still works is an open door.
Ownership and blast radius
Revocation without ownership is incomplete. Every GitHub secret should map to a person, team, or system identity and to the repositories, organizations, and scopes it could reach. That map is what turns “we revoked a token” into “we know which CI jobs, bots, and human accounts need a replacement, and which repos may have been touched.” If you cannot name an owner within minutes, the incident expands from a single credential into an identity-governance gap.
- Inventory: personal tokens, fine-grained tokens, OAuth apps, GitHub Apps, deploy keys, and machine accounts used by pipelines.
- Scope: org vs. repo access, read vs. write vs. admin, and whether the secret could modify Actions secrets, packages, or environment protection rules.
- Dependents: which workflows, scripts, and third-party integrations break when this credential dies—and who must rotate them in order.
Evidence you should capture
Revocation ends the credential’s future; evidence explains its past. Before or immediately after kill, preserve enough signal to decide whether the leak was used: audit and security logs for the account and org, recent API and git activity, Actions runs that used the secret, and any outbound alerts that named the token prefix or hash. Capture timestamps, actor identities, IP or client metadata if available, and the path by which the secret was exposed (gist, log, chat paste, image, CI artifact).
Store that package with the incident ticket so recovery and postmortems are not guesswork. You do not need a courtroom-grade forensics lab; you need a repeatable checklist that always runs when a secret is revoked, even on “benign” false alarms. Patterns across incidents—same bot account, same repo, same paste channel—are how you fix systemic causes instead of only rotating one key at a time.
Recovery without reopening the door
Recovery is deliberate re-issuance, not a copy of the old secret. Issue a new credential with the least scope required, attach it to the correct owner, store it only in approved secret stores, and remove the old value from every place it may have been cached (local env files, runner caches, config repos, password managers, chat history). Verify dependent systems with a controlled test, not a silent wait for the next deploy to fail.
Close the loop with ownership and process: update the inventory, confirm monitoring would catch a similar leak, and write down what slowed revocation or made blast radius unclear. Self-service revocation only improves response if teams practice the full path—revoke, map ownership, preserve evidence, recover cleanly—so the next leak is measured in minutes of exposure, not hours of coordination.