A secret was committed: why deleting the file is not enough and what the response order is

Goal

Contain a credential that was committed to a repository, in the order that limits damage, including when an agent made the commit.

Prerequisites

Rights to revoke the credential at its issuer; write access to the repository; access to the issuer's usage logs.

Steps

1. Revoke or rotate first. GitHub's guidance on removing sensitive data advises treating the secret as compromised and rotating it; history rewriting comes after. Assume automated scanners watch public pushes.
2. Deploy the replacement credential to every legitimate consumer. Consumers that break reveal where the old one was used.
3. Check the issuer's logs for use of the old credential since the commit time, from unexpected addresses or with unusual actions. Record what you find.
4. Remove the file from the current tree and add it to .gitignore if it should never be tracked.
5. If the repository requires it, rewrite history with a tool built for it; GitHub documents git-filter-repo for this. Coordinate with collaborators: every clone must be re-cloned or rebased, and old branches pushed again will reintroduce the secret.
6. Ask the hosting provider to purge cached views and pull-request references if their process supports it; forks and existing clones stay outside your control.
7. Search CI logs, build artefacts, container images and chat messages that may have captured the value.
8. Add a pre-commit or push-time secret scanner to prevent recurrence, and write down the incident with times.

Expected result

The exposed value is useless before cleanup starts; history is cleaned where it matters; you know whether the credential was used.

Limits and test basis

History rewriting cannot recall copies already made; revocation is the only step that neutralises them. Some secrets (signing keys, long-lived certificates) need reissuing and redistribution of trust, which takes longer than rotating an API key.