Responding to a compromised secret: revoke, rotate, analyse

As soon as a secret is exposed, password, API key or access token, consider it already used by an attacker. The right reaction is not to investigate first, but to cut off access: you revoke, you create a new secret, and only then do you analyse what may have happened. This lesson describes this procedure in five steps, so that you know what to do, in the right order, on the day a key leaks.

Three facts make it concrete. gitleaks 8.30.1 finds a GitHub token in the history even though the file has been deleted. GitHub provides a public revocation API, usable by anyone who finds a token. And at AWS, deactivating an access key does not cut off the temporary sessions already obtained with it: they stay valid until they expire.

What you will learn

A secret is confidential information that proves an identity or unlocks access. When one of them escapes your control, it is called a compromised secret or a secret leak. In concrete terms, you will be able to:

• Recognise that an exposed secret is compromised, even without proof of use
• Run the five-step procedure: detect, revoke, rotate, analyse, prevent
• Tell apart revoking (cutting off access) and rotating (replacing the secret)
• Also cut off what the secret has already opened: sessions, leases, derived tokens
• Avoid the classic pitfalls, such as rotating a secret without revoking the old one
• Meet requirement SOCLE-SEC-GEN-6 (in French): leak detection and response procedure

What to do when a secret leaks

The founding principle fits in one sentence: an exposed secret is a compromised secret. As soon as a key appears in a public repository, a chat message, a log or a screenshot, assume an attacker has copied it. Waiting for proof of abuse means leaving the door open during the investigation.

This logic comes from the fact that bots constantly crawl public repositories looking for keys. You cannot know whether the attacker was faster than you, so you act as if they were. This is the reflex that separates a controlled incident from a disaster.

The five-step procedure

The response is organised in five steps, in the order of the diagram. Revocation, in red, comes second, before any analysis; the dotted loop is a reminder that prevention's first effect is to shorten the next detection.

Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

1. Detect: spot the leak, where, and which secret it is.
2. Revoke: immediately invalidate the exposed secret.
3. Rotate: generate a new secret and distribute it to the legitimate systems.
4. Analyse: measure the scope, what may have been read or modified.
5. Prevent: fix the cause so that the leak does not happen again.

OWASP describes the same sequence in its Secrets Management Cheat Sheet: revoke immediately, rotate, delete the copies all the way into Git history and logs, then log the accesses for the investigation.

Revoking and rotating: two different moves

Two words deserve a precise definition, because they are often confused. Revoking a secret means declaring it invalid with the service that recognises it: the service now refuses any request that presents it, like a bank blocking a stolen card. Rotating (performing a rotation) means replacing it with a new one, put in place in the legitimate systems.

Revoking looks to the past, you close the old access; rotating looks to the present, you restore sound access. Some services do both at once, creating a new key invalidating the old one; many do not, and that is what you must check with each provider.

Detecting: the leak outlives the file

Detection relies on tools that look for known secret formats and high-entropy strings. The trap is to scan only the files present: a secret deleted in the next commit stays in the history, and therefore in every clone of the repository.

Measured with gitleaks 8.30.1 on a repository where a ghp_ token was committed in deploy.env and then deleted: dir mode finds nothing, git mode finds the token in the first commit and exits with code 1, which is enough to fail a CI job.

$ gitleaks dir . --no-banner
INF no leaks found

$ gitleaks git . --no-banner --redact -v
RuleID:      github-pat
File:        deploy.env
Commit:      d400395794befbc7039f5fdad842ea1aa9f0f197
...
WRN leaks found: 1
$ echo $?
1

The commit and the file reported by gitleaks are the starting point of the investigation: they date the exposure. The lesson on Gitleaks shows how to plug this scan into pre-commit and CI to shorten the window.

Revoke before investigating: why the order matters

The most costly mistake is wanting to understand before acting. Faced with a leak, the temptation is strong to open the logs, look for who pushed the key, then decide. Meanwhile, the exposed secret remains valid, and the attacker does not wait: the investigation takes hours, copying a key takes a second.

That is why revocation comes first. Even if an attacker has a copy, it is useless to them: the service rejects it. The analysis then proceeds without urgency, the immediate danger having been removed. The price is a possible outage of the legitimate service, while the new secret is deployed: an acceptable price compared with access left open.

What revocation must also cut off

Revoking the key is not always enough: you must cut off what it has already opened. The trickiest case is AWS: the IAM documentation states that temporary credentials remain valid until they expire, up to 36 hours, even after the key that obtained them is deactivated. You then have to remove the permissions of the user or the role.

Service	Revoke the secret	Also cut off
GitHub (ghp_, github_pat_ token)	Delete the token, or the public POST /credentials/revoke API	What the token may have created during the exposure: deploy keys, webhooks, other tokens
AWS (AKIA... key)	aws iam update-access-key --status Inactive, then delete-access-key	Temporary sessions already issued: deny policy, or revocation of the role's sessions
Vault / OpenBao	vault token revoke or vault lease revoke	All the leases of a path: vault lease revoke -prefix

Swipe to see more

GitHub's revocation API has a particularity: it is called without authentication, and an authenticated request even gets a 403 refusal. It accepts up to 1000 tokens per call (classic, fine-grained, OAuth, GitHub App tokens), and the token owner is notified. Anyone who finds a leaked token can therefore neutralise it without being its owner.

For a dynamic secret, revocation is the cleanest. Measured on Vault 2.1.1 with PostgreSQL 17: vault lease revoke -prefix database/creds/app removes all the users created by the role, and the database no longer counts any. The lesson on the lifecycle details this measurement.

Rotating is not revoking

Creating a new secret restores your service, but does not necessarily close the old access. Always check that the compromised secret is invalidated, by trying to use it and observing the failure. Two valid keys at the same time means two open doors.

Analysing the scope

Once access is cut off and the service restored, comes the scope analysis: measuring what the attacker may have done while the secret was valid. It is an investigation step, not an emergency, and that is why it comes after revocation. It answers three questions: what did the secret give access to, was it used by someone else, and if so, to do what.

The raw material is made of access logs (each connection and each action, with time and origin) and audit logs, more detailed, which trace sensitive operations. You look for abnormal uses in them: unknown address, unusual time, an action nobody recognises. At AWS, CloudTrail and aws iam get-access-key-last-used tell whether and when the key was used.

The goal is twofold. First, assess the damage: if the attacker read a customer database, you may have to notify these people or an authority, depending on the regulations. Then, determine the exposure window, from the faulty commit identified by gitleaks to the revocation: a secret leaked an hour ago and a secret exposed for six months do not call for the same investigation.

Preventing the next one

Putting out the incident is not enough: without fixing the cause, the same leak will come back. Prevention relies on four measures that reduce both the probability of a leak and its impact when it happens anyway.

The first is detection: tools that continuously scan code, repositories and logs, to warn within minutes rather than weeks. The second is automatic rotation: a stolen secret stops being valid on its own after a while. The third is a short lifetime, the TTL (Time To Live): a token valid for fifteen minutes is worth almost nothing an hour after the theft.

The fourth is least privilege: a key that can only read one resource does far less damage than a key that can do everything. These four measures turn a potential disaster into a simple incident: you will never prevent every leak, but you can make it cheap.

Putting it into practice

This lesson describes the procedure and its reasoning; others show the tools. To spot leaking secrets, secret detection (in French) compares gitleaks, TruffleHog and Trivy, and explains how to plug the scan into your development processes.

For revocation and rotation, the lesson on the lifecycle shows how to automate these steps. And a procedure that has never been played does not exist: requirement SOCLE-SEC-ROT-3 asks for the report of an emergency rotation and revocation test, to be run in cold conditions, before the incident.

Common pitfalls

The procedure is simple to state, but four mistakes keep coming back and cancel part of the effort. Knowing them prevents you from believing the incident is resolved when it is only half done, which is the worst state: nobody watches any more, and the attacker keeps their access.

The most frequent pitfall is rotating without revoking. You create a new secret, deploy it, and forget to invalidate the old one. As long as it remains valid, the attacker keeps their access: the rotation was falsely reassuring, the original door is still open.

The second is forgetting the copies. The key pushed in the code ends up in Git history, logs, container images and sometimes backups. Deleting the visible line removes it from nowhere, as gitleaks shows. The only reliable protection remains revocation: an invalidated key is useless, wherever it lingers.

The third is forgetting what the key opened. A deactivated AWS key leaves the temporary sessions already issued alive, and a token may have authorised a third-party application. Revoking the secret without cutting off its descendants leaves a door ajar for hours.

The last is delaying revocation for fear of breaking production. It is a bad calculation: a service interrupted for a few minutes is less serious than access left to an intruder. The right approach is to prepare the rotation to restore quickly, not to postpone the cut-off.

Key points

• An exposed secret is a compromised secret: act as if it were already being used.
• Revoke first, investigate later: the attacker does not wait for the end of the analysis.
• Rotating does not replace revoking: check that the old secret fails.
• Cut off the descendants: at AWS, temporary sessions outlive the key's deactivation; GitHub offers POST /credentials/revoke without authentication.
• The leak outlives the file: gitleaks 8.30.1 finds it in git mode, not in dir mode, and the commit dates the exposure.
• Analyse afterwards: access and audit logs, exposure window from the commit to the revocation.
• Prevent by reducing the impact: fast detection, automatic rotation, short TTL, least privilege.
• The evidence expected by SOCLE-SEC-GEN-6 is a secret leak detection system and its response procedure; the secrets threat model (in French) details the attacks covered.

Knowledge check

Check that you have the essentials of this lesson. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →