Why a Site Scan Can't See the Secret Still Sitting in Your Git History

Quick answer: a scan of your live site can only see what a visitor's browser can see, headers, TLS, DNS records, exposed client-side files, public pages. It has no way to open your source code, which means a credential committed once and deleted later, a vulnerable dependency still sitting in your lockfile, or a SQL query built from string concatenation are all invisible to it, no matter how good the scan is. Those need a different check entirely: one that reads the repository itself.

This isn't a gap in any particular scanner. It's a boundary built into what "public site scan" means as a category. A repo never gets exposed to a browser, so nothing that only checks what a browser sees will ever find what's inside one.

The specific thing a site scan cannot do

Picture a .env file with a real API key, committed to a repo by accident during a rushed demo, then "fixed" the next day by deleting the file and committing again. The live site never served that file. No browser ever saw it. A public scan checking headers, TLS, and reachable URLs has nothing to flag, because from the outside, nothing changed.

But the key is still there. Run this against the repo:

git log --all -p -- .env

That command walks every commit in the repo's history, including ones no longer reflected in the current files, and shows the full diff for anything touching .env. The deleted commit is still in there. Anyone who clones the repo, or anyone who already has a copy from before the "fix," can pull that exact credential out of history whether or not it's in the working tree today. Deleting a file removes it from what you see when you open the folder. It does not remove it from the repository's history, and a site scan was never going to see either version, because it never had access to the repository at all.

What actually needs to happen: a scan of the repo, not the site

A repository scan works on fundamentally different material, the source code and its full history, not the deployed result. That opens up checks a live site can never do:

Static analysis (SAST). This reads the code itself for dangerous patterns, not just whether the app happens to work. A query built like "SELECT * FROM users WHERE id = " + userInput is a classic SQL injection shape, and it looks identical to a working, correctly-behaving endpoint from the outside. A site scan sees a page that loads fine. Static analysis sees the actual line of code building an unsafe query, and flags it regardless of whether anyone has exploited it yet.

Dependency scanning (SCA). Every project pulls in packages, and packages get vulnerabilities disclosed against specific versions, sometimes long after the package was first added. A site doesn't announce which version of which library is quietly powering it under the hood. A dependency scan reads the actual lockfile and compares each version against known, disclosed vulnerabilities, catching a problem that has nothing to do with anything your own team wrote.

Secrets detection. The .env example above is the general case: any credential that ever touched a commit, an API key, a database password, a signing secret, stays discoverable through the repo's history even after it's removed from the current files. This needs to search commit history specifically, not just the current state of the code, which is exactly what a live-site check structurally cannot do.

Code quality. Complexity, duplication, dead code, and lint violations don't create a security hole by themselves, but they're exactly the conditions that make the other three categories harder to catch by hand later. A 400-line function with six responsibilities is where a subtle authorization bug hides in review. This is maintainability risk becoming security risk on a longer timeline.

Why "it works" doesn't rule any of this out

None of these four categories change what a visitor experiences. The vulnerable dependency still renders the page correctly. The string-concatenated query still returns the right result for every normal input. The deleted .env file is, as far as the running application is concerned, gone. This is the same pattern that shows up everywhere in AI-generated and fast-shipped code: a check built around "does it look right" has no way to catch something that only reveals itself when someone looks at the code, or the history, on purpose.

That's also exactly why these two categories of scanning aren't competing with each other, a public site scan and a repository scan. They're looking at different material entirely. One tells you what's true about the deployed result anyone on the internet can reach. The other tells you what's true about the code and its history, which nobody outside your team can normally see at all, until a repository gets cloned somewhere it shouldn't have been.

What this actually looks like in practice

A repo scan runs against a connected git repository directly, across the categories above, SAST, SCA, secrets, and code quality, and returns findings the same way a site scan does: ranked by severity, tied to a specific file and line, with a plain-language description of what's wrong. The output format is familiar even though the input is completely different.

The practical takeaway isn't "run more scans for the sake of it." It's that a clean public scan result and a clean repo scan result are answering two different questions, and a team that's only ever run one of them has only checked half of what's actually checkable.

Final Thoughts

A live site scan is genuinely good at what it does: telling you the truth about what's publicly reachable, right now, without anyone needing source-code access. It was never going to catch a secret sitting in a deleted commit, because that secret was never part of what a browser sees in the first place.

That's not a limitation to work around. It's a reason to run both kinds of checks, one for what's deployed, one for what's committed, since a team that only checks one has a blind spot shaped exactly like the other.