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.

Extension: secrets in browser bundles

A secret can be exposed even when it never appears in the visible page.

1. In the same disposable repository, create config.js containing a deliberately fake value such as DEMO_AWS_KEY=FAKE-ONLY-DO-NOT-USE.
2. Copy or bundle that file into a dist/ directory, simulating a production build.
3. Search the build output with rg -n "DEMO_AWS_KEY|FAKE-ONLY" dist or your editor’s search.
4. Open the generated JavaScript in a browser and confirm that anyone who can download the asset can read the value.
5. Remove the fake value from the source, rebuild, and scan both the output directory and Git history again.

Deliverable: A two-column note identifying where the fake value existed before and after rebuilding. Explain why environment-variable syntax does not make a value secret once a build tool inserts it into client-side JavaScript.

Discussion: Which values belong in browser code, and which operations must move behind a server-side API? Why must a genuinely exposed cloud credential be revoked or rotated even after the public asset is replaced?

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

August 18, 2026 extension source

The browser-bundle extension was added after the August 18 PTIR reviewed the Beacon CRM incident and the broader credential-hygiene failure mode. UK Charity Commission guidance confirmed the incident’s potential impact on charities, while OWASP’s CI/CD guidance explains why credentials in code, build artifacts, and pipeline contexts require strict secret management. The classroom activity uses only a fake value and does not reproduce access to any real system.

UK Charity Commission guidance · OWASP: Insufficient Credential Hygiene