What They Actually Prove.
Organisations treat the pentest report as a verdict on their security posture. It is not. It is a record of what a specific person found, in a specific scope, within a specific number of days, using a specific set of credentials. Everything outside those four constraints is untested — and the report almost never says so loudly enough.
Security Researcher • Penetration Tester
Tarun Jaswani is an independent security researcher and penetration tester with over five years in offensive security, 100+ accepted vulnerability reports, and Hall of Fame recognition from Google, Zoho, TripAdvisor and Adafruit. He writes about security for the people who have to build and defend real systems.
The report lands, the findings are low severity, and somebody forwards it to the board with the word clean in the subject line. I have written that report. What it means is that within the agreed scope, during the agreed window, with the access I was given, I did not find anything more serious. That is a genuinely useful statement. It is not the statement most people read it as, which is that the system is secure — and the distance between those two readings is where a lot of false confidence lives.
https://about.me/tarun_jaswani
This is not an argument against penetration testing. Testing is one of the most valuable assurance activities available and I would not do this work if I thought otherwise. It is an argument for reading the report as the bounded, time-limited, human artefact it actually is.
https://dev.to/tarun_jaswani_e9a4c1020df/lessons-every-cybersecurity-engineer-learns-from-real-world-web-applications-4pn1
The Four Constraints Every Report Carries.
SCOPE
A test covers what the contract said it covers. If the scope named three applications, the fourth is untested — not secure, untested. The same applies to the staging environment nobody mentioned, the legacy admin panel on a subdomain, the mobile API that was assumed to be out of scope, and the third-party integration that sits between two in-scope systems. Attackers do not read the scope document. It is the single largest gap between what was tested and what exists.
TIME
A test is bounded by days. An attacker is not. Given ten working days I will prioritise the highest-probability paths and I will find what those paths reveal. Given six weeks I would go further, and a motivated adversary has as long as they want. A clean report on a short engagement is weaker evidence than a clean report on a long one, and the report rarely frames it that way.
ACCESS
What I was given determines what I can see. A black-box test with no credentials finds what an anonymous outsider finds. A test with one standard user account finds far more, because most serious findings live behind authentication in the authorisation layer. A grey-box test with source access finds more again. These produce very different reports on identical systems, and comparing them as though they mean the same thing is a category error.
https://dev.to/tarun_jaswani_e9a4c1020df/why-identity-is-the-new-security-perimeter-29c6
THE PERSON
This is the one nobody likes to state plainly. Two competent testers will not produce identical reports on the same target. We have different backgrounds, different instincts about where to dig, different depth in different vulnerability classes. Someone who has spent years on authorisation logic will find access control gaps that a network specialist walks past, and the reverse is equally true. The report reflects a methodology and a person, not an objective measurement.
What a clean report actually says
Within this scope, in this timeframe, with this access, this tester did not find anything more serious. Every word of that sentence is load-bearing, and removing any of them turns a useful finding into a false assurance.
What the Report Genuinely Is Good For.
• Finding real, exploitable issues before someone else does. This is the core value and it is substantial — a single access control flaw found in testing is worth the engagement several times over.
• Validating that controls work in practice rather than on a diagram. Plenty of well-designed protections fail in implementation, and testing is where that surfaces.
• Producing evidence a non-technical audience can act on. A working proof of concept moves budget in a way a risk register never has.
• Teaching your engineers something durable. The best outcome of any engagement is that the same class of bug stops appearing, which requires the team to understand the root cause rather than just apply the patch.
https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-is-more-than-fixing-vulnerabilities-32jl
What It Is Not Good For, and Gets Used For Anyway.
- Proving security to a customer or a board. It proves a bounded absence of findings. Presenting it as proof of security is overclaiming on the tester's behalf, and most testers would not make that claim themselves.
- Replacing a secure development process. Testing at the end finds what was built wrong. It does not stop things being built wrong, and an organisation whose entire security programme is an annual pentest is paying to be told the same things repeatedly.
- Measuring improvement year on year. Different scope, different tester, different duration, different codebase. Comparing this year's finding count to last year's is comparing two different experiments and calling the difference progress.
- Covering the parts of the estate nobody remembered to mention. The forgotten subdomain is the most common serious finding in scoping conversations, and it is only found when someone asks what else exists. https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-starts-before-the-first-line-of-code-4gbl How to Get More Out of the Same Engagement.
- Scope by asset inventory, not by memory. Ask what is exposed to the internet and reconcile that against what you think is exposed. The gap between those two lists is frequently the most valuable output of the whole exercise.
- Provide credentials, and provide several roles. Most serious findings are authorisation failures that are invisible without a logged-in session. A black-box test on an authenticated application is spending most of the budget on the least interesting part.
- Ask for the methodology and the coverage notes, not just the findings. What was tested and found clean is as informative as what was found broken, and it tells you where the gaps in the engagement itself are.
- Insist on root cause, not just remediation. Fixing the reported instance leaves the pattern. Ask the tester whether the same flaw class is likely elsewhere in the codebase — usually the answer is yes.
- Rotate testers periodically. Different people find different things, and the second tester on a system frequently finds what the first walked past.
- Retest after remediation, and treat the retest as part of the engagement rather than an optional extra. A fix that was never verified is a hope.
https://github.com/tarunjaswani/Vulnerabilities-notes
https://github.com/tarunjaswani/CORS-Misconfiguration
The Findings That Recur, Regardless of Industry.
After enough engagements the pattern becomes monotonous, and the monotony is itself useful information. The same handful of issues appear across organisations of every size and sector, which suggests the cause is structural rather than incidental.
• Authorisation enforced in the interface but not at the endpoint. The button is hidden; the API call still works. This is the single most common serious finding in modern applications.
• Object references that trust the identifier supplied by the client, allowing one user to read another's records simply by changing a number.
• Cross-origin policies loosened during development and never tightened, quietly exposing authenticated responses to any site.
• Export and reporting functions that trust stored input, treating data that arrived from a user as safe because it has been in the database for a while.
• Forgotten infrastructure — a staging environment with production data, an old admin panel, a subdomain pointing at a decommissioned service.
• Secrets in places they should not be: repository history, client-side bundles, configuration files committed years ago and never rotated.
https://dev.to/tarun_jaswani_e9a4c1020df/your-corsconfiguration-isprobably-brokenheres-whatattackers-seewhen-it-is-1944
https://dev.to/tarun_jaswani_e9a4c1020df/your-export-to-csv-button-is-a-security-hole-csv-injection-explained-for-developers-who-didnt-45p
https://github.com/tarunjaswani/XSS
https://github.com/tarunjaswani/CSP-Bypass
What Actually Reduces Risk Between Tests.
The organisations with the least alarming reports are not the ones testing most frequently. They are the ones where security has moved earlier — threat modelling before the design is fixed, authorisation checks written as a shared function rather than reimplemented per endpoint, dependency scanning in the pipeline, secrets managed rather than committed, and an asset inventory somebody actually maintains.
Testing then does what it is genuinely good at: finding the things that slipped through a process that was already working, rather than serving as the process itself.
https://github.com/tarunjaswani/awesome-cybersec
https://github.com/tarunjaswani/bounty-targets-data
https://github.com/tarunjaswani/Hackthebox-cheatsheet
A penetration test report is a bounded observation, not a verdict. It says that within an agreed scope, during an agreed window, with the access provided, one tester did not find anything worse. That is genuinely valuable and it is not the same as being secure. Scope it against what actually exists rather than what you remember, give the tester credentials, ask what was covered as well as what was found — and stop reading a clean report as a conclusion when it is a snapshot.
— Tarun Jaswani
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
https://x.com/TJaswani7857
RELATED WRITING
Developer-facing security writing is published on dev.to, with vulnerability class research, testing methodology and reference material on GitHub.
https://dev.to/tarun_jaswani_e9a4c1020df
https://github.com/tarunjaswani
TAGS
Top comments (0)