Free readiness test
Home / Tool labs / Gitleaks

Gitleaks hands-on lab Did someone commit cloud keys?

Find passwords, keys and tokens committed to Git, then stop it happening again.

DevSecOpsBeginnerFree live lab5 objectives
sec@laptop:~/payments-service$
$ git show 4f2a9c1 --stat
commit 4f2a9c1e8b7d3a10c55e2f9b8a1d7e6c4b3a2910
Author: ravi.k <ravi.k@acme.example>
Date:   Tue Oct 28 16:04:11 2026 +0530

    quick fix: hardcode creds for staging deploy

 config/settings.py | 3 +++
 1 file changed, 3 insertions(+)

What is Gitleaks?

Gitleaks scans Git repositories, including every past commit, for secrets like API keys, tokens and private keys. Used as a pre-commit hook and in CI, it stops leaks before they reach a remote.

1 History matters

Deleting a secret in a new commit doesn't remove it. It stays in Git history forever.

2 Detection rules

Regexes plus entropy checks recognise AWS keys, GitHub tokens, Slack webhooks and more.

3 Prevent, then rotate

Block new leaks with pre-commit; any leaked secret must be revoked and rotated.

The scenario: Did someone commit cloud keys?

A developer says they 'removed the AWS key from config last week'. Scan the payments-service repo, find any secrets in history, see who and when, export a report, and set up protection. All keys here are AWS documentation examples.

Live lab: try it now

Type the commands in the terminal below. Everything is simulated, so it's safe and legal and nothing is installed.

Step-by-step: Gitleaks commands used in this lab

1Scan the repository including history

gitleaks detect with verbose output.

gitleaks detect --source . -v
Show sample output
○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

2Inspect the commit that introduced the key

git show the commit id from the finding.

git show 4f2a9c1 --stat
Show sample output
commit 4f2a9c1e8b7d3a10c55e2f9b8a1d7e6c4b3a2910
Author: ravi.k <ravi.k@acme.example>
Date:   Tue Oct 28 16:04:11 2026 +0530

    quick fix: hardcode creds for staging deploy

3Prove the key is still in history after 'removal'

git log -p filtered to the config file.

git log -p -- config/settings.py
Show sample output
commit 9d1e2b7 (HEAD -> main)  "remove keys from config"
-AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
-AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
+AWS_ACCESS_KEY_ID = os.environ["AWS_ACCESS_KEY_ID"]

commit 4f2a9c1  "quick fix: hardcode creds for staging deploy"

4Export a JSON report for the ticket

--report-format json --report-path

gitleaks detect --source . --report-format json --report-path leaks.json
Show sample output
○
    │╲
    │ ○
    ○ ░
    ░    gitleaks
11:42AM WRN leaks found: 2

5Scan staged changes like a pre-commit hook

gitleaks protect --staged

gitleaks protect --staged -v
Show sample output
○
    │╲
    │ ○
    ○ ░
    ░    gitleaks
11:45AM INF no leaks found in staged changes

Key takeaways

Install Gitleaks and practise for real

brew install gitleaks   # or download a release from GitHub

Run gitleaks detect on your own repos. Many people find old tokens they forgot about. Only scan or test systems you own or are explicitly authorised to assess. Official site: gitleaks.io · Licence: MIT.

Scenario questions

The key was removed in a later commit. Is the risk gone?

Answer: No: it's still in Git history and may already be cloned, so it must be revoked and rotated. Treat any committed secret as compromised: revoke, rotate, check usage logs.

Where should gitleaks run to prevent leaks?

Answer: As a pre-commit hook and in CI on every push. Shift left: catch it before it ever leaves the developer's machine, with CI as a backstop.

Where should the application get credentials instead?

Answer: Environment variables or a secrets manager / workload identity (e.g. OIDC). Use a vault or federated identity so long-lived keys aren't needed at all.

More open-source tool labs