Cybersecurity
What a Penetration Test Actually Finds
Not zero-days. After years of assessments, the findings that matter are almost always mundane, and almost always fixable in an afternoon.
Clients often brace for a penetration test as though we are going to demonstrate some exotic exploit. That is almost never what happens. The findings that put a system at genuine risk are, with dull consistency, configuration and access problems.
The findings that recur
The recurring list: an admin interface reachable from the public internet, credentials committed to a repository years ago and never rotated, an object storage bucket readable by anyone who guesses the name, a forgotten staging environment running last year's code against a copy of production data, and permissions granted for a one-off task that were never revoked.
Why simple beats sophisticated
None of that requires sophistication to exploit, which is exactly why it matters. An attacker is not looking for the most interesting way in — they are looking for the cheapest one. The staging server nobody remembers is cheaper than any zero-day.
Decisions, not just findings
The useful output of an assessment is therefore not a list of vulnerabilities but a list of decisions: what should be internet-facing, who should hold which credential, what happens to an environment when the project that needed it ends. Those decisions outlive the specific findings.
Attackers are not looking for the most interesting way in. They are looking for the cheapest one.
Treat the report as a starting inventory rather than a scorecard. The point is not to reach zero findings once; it is to make the class of finding stop recurring.
