Secret Scanning and Git History Lab

This lab demonstrates why secret removal and secret remediation are different tasks.

Safety rule

Use a fake token only. Never put a real password, API key, student credential, or production secret into the repository.

Activity

1. Create a disposable Git repository.
2. Add a text file containing an obvious fake value such as DEMO_API_KEY=not-a-real-secret-12345.
3. Commit the file.
4. Scan the repository with a secret-scanning tool such as TruffleHog, or inspect the history manually if the scanner does not flag the intentionally simple value.
5. Remove the fake token from the current file and commit again.
6. Use git log, git show, or the scanner’s history mode to locate the earlier committed value.

Deliverable

Explain why deleting a secret from the latest version of a file is not enough after a genuine credential has been exposed.

Key conclusion

For a real secret, the response includes revocation or rotation. History cleanup may also be appropriate, but rewriting history does not make an already exposed credential safe again.

Source material

First spotted in PTIR: August 3, 2026, Evening Briefing.

Truffle Security reported finding more than 221,000 live credentials while scanning public Hugging Face datasets, illustrating how secrets can persist in repositories and data even after the current copy appears clean. The PTIR turned that into a safer classroom demonstration using a deliberately fake token so students can see the difference between deleting a line, preserving Git history, and actually remediating a compromised credential.

Consult the original Truffle Security study · TruffleHog repository