Skip to content

Scan rule · RSC-SEC-081

Secret key in the Git history

SecuritySeverity: HighCWE-540OWASP A07-2021

Checks the added lines of recent commits against the same pattern list as the current tree — a deleted key stays readable.

Why this matters

Git is an archive, not a folder. Every state you ever committed stays retrievable — including the one that still contained the key. Anyone who can clone the repository reads it with a single command. That holds even when the file has long been deleted from the current tree and added to `.gitignore`.

In generated projects the sequence is almost always the same: the first commit is "everything in", `.gitignore` comes later, and at some point the `.env` is noticed and removed. That takes the problem out of the working copy and leaves it in the history.

The only effective response is rotation. Removing the key from history is possible (`git filter-repo`) but laborious, breaks every clone — and is worthless as long as the old value is still valid. Rotate first, clean up afterwards, if at all.

Scan tier

Repo access (deep scan)

How to fix it

Rotate the affected keys; deleting the file is not enough.

Scan your own app for free