Home / Blog / Almost Every Real Penetration Test Starts by…
Application Security
Almost Every Real Penetration Test Starts by Hunting for Secrets
An API key left in git. A token embedded in an image or a PDF. A config.old.js somebody forgot to delete. Google open-sourced a secret scanner, and it is worth your attention.
This piece is my read on research published by Google (Veles). The findings are theirs; the argument about what they mean is mine. Their original write-up is worth reading in full.
Google have released a new secret scanner, open source.
I don't know how it is for other people, but for us - almost every penetration test of a real system starts by looking for secrets.
Sometimes it is an API key accidentally left in git. Sometimes it is a token embedded in an image or a PDF file. Sometimes it is simply a config.old.js somebody forgot to delete.
Which is exactly why I was interested in Veles, the new secret scanner Google open-sourced.
Not another generic plugin that shouts at password=123
Veles is a serious tool, developed out of Google's own needs. It already scans their internal code, runs across millions of open-source artifacts, and connects to cloud tooling like Artifact Registry and SCC.
It already identifies sensitive Google Cloud and RubyGems keys among others - but what matters most is that it is built to be extended. You can connect it to CI/CD, run it against code repositories, Docker, individual files, anything.
This is not a nice-to-have recommendation
It is simply necessary, because secrets leak. Not out of amateurism, but because of reality: a development team under pressure wires something up temporarily, never gets round to deleting it, and a private key has gone up to git.
It has happened to everybody. I have seen it at startups, at enterprises, and at security companies too. Nobody is immune.
Veles is an important step forward - not only because it identifies keys, but because it changes the approach: find the secret before it becomes a problem.
I first shared a version of this as a LinkedIn post on 2025-08-19. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula
Keep reading
More from the blog
Application Security
We checked 1,237 fixes. One in four was not fixed.
Between October 2021 and August 2026 our clients sent 1,237 fixes back to us and asked us to confirm they worked. 307…
Read itApplication Security
What 890 security engagements actually find
6,048 findings across 700 tests. The most common are configuration and hygiene. The most dangerous are authorization - 133 high and critical,…
Read itApplication Security
The Most Expensive Vulnerability Is a Token Nobody Rotated
No sophisticated SQL injection. No state actor with three APT teams. A developer pushed code with a secret in it, and a…
Read itTell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.