The Pen Test That Found Nothing (Because It Wasn't Looking)
A fintech's board asks for assurance before a funding round. The security team commissions an external penetration test of the customer web app. The tester is given production-like credentials and a scope limited to the app's URL. The report returns 'no critical findings' in 3 days for $20k. Simultaneously, a bug-bounty researcher privately reports an SSRF in the same app that reaches an internal metadata endpoint and exposes cloud credentials. The board is about to cite the clean pen-test report in its risk disclosures. The CISO has 5 days before the disclosure is filed.
1. Why did the pen test miss the SSRF, and what does that say about the assurance it provides?
Read the worked answer
It missed it because the test wasn't scoped or resourced to find it.
- Scope: URL-only, authenticated, 3 days. SSRF-to-metadata requires testing server-side request behavior and the app's outbound reach - often outside a URL-scoped, black-box-ish engagement.
- Time: 3 days for a fintech web app is thin; deep business-logic and server-side flaws need more.
- No infrastructure/cloud scope: the metadata endpoint and cloud credentials are outside the app URL, so even a diligent tester scoped to the URL wouldn't chase them.
- Incentive/quality: a fast 'no critical findings' report can reflect a shallow test, not a secure app.
What it says about assurance: a clean pen test proves what was tested came back clean under those conditions - it does not prove the app is secure. 'No findings' from a narrow test is weak evidence, and citing it as assurance is misleading.
2. The board wants to cite the clean report in its disclosure. What should the CISO advise in 5 days?
Read the worked answer
Do not cite the clean report as assurance - it would be misleading, and the SSRF is a known, material finding.
Advice:
- Validate the SSRF now (5 days is enough to reproduce and confirm impact: does it reach metadata, are credentials live, is there evidence of exploitation?).
- Treat the clean report as scoped evidence, not a clean bill of health. Disclose the actual control state: a vulnerability was identified and is being remediated, with the pen test's limitations noted.
- Don't bury it: citing a narrow test as proof of security while knowing of an SSRF is the kind of statement that becomes a liability if it surfaces later.
Judgement: the disclosure must reflect what you know, not what a limited test happened to miss. The CISO's duty is to prevent the board from overstating assurance; the clean report is not a defense once you have contrary knowledge.
3. How should the assurance program change so future tests actually inform risk decisions?
Read the worked answer
Fix the program, not just this report:
- Scope to the threat model: include server-side/outbound behavior, cloud metadata reach, and infrastructure where the app's trust extends. SSRF lives at the app/cloud boundary.
- Right-size effort: 3 days for a customer-facing fintech app is a red flag; budget time proportional to risk.
- Define objectives up front: 'can an authenticated user reach internal services?' - testable questions, not 'test the URL.'
- Use multiple assurance sources: pen test + bug bounty + code review + cloud config review. The bounty found what the test didn't - that's a signal about coverage, not a coincidence.
- Report limitations explicitly: every report should state what was not tested, so the board can't mistake scope for assurance.
- Feed findings into risk register and disclosure process so assurance and reporting are connected.
Principle: assurance is only as good as its scope and independence; a report's silence on out-of-scope risk is not evidence of safety.