"Zero findings" is the worst thing a pentest report can say

Last week I delivered a production scan to a customer. Authed scan against their live SaaS, full sweep across what the agents can do today.

The result: zero high findings, zero medium findings, one low (a JavaScript library with no current CVEs against its version).

That's the headline a traditional pentest report can't really write. "We couldn't find anything wrong" reads as either a hedge or an inadequate test. The customer pays $15,000 for a deliverable, and the deliverable says nothing. Their enterprise auditor asks "but what did you check?" and the answer is buried in the appendix or absent entirely.

I had to build the deliverable differently, because zero findings was always going to be the goal.

The deliverable, restated

The strongest possible result for a pentest customer is a report that says "we checked these specific things, and here's the evidence each one was actually exercised, and here's what held." Not "no findings." Not "looks secure." A structured statement of what the agents tested, attached to the actual probes that ran.

Last week's scan produced 25 of these. Each row names a control, an OWASP category, and the number of endpoints the agents tested it against. The customer can hand that document to their enterprise auditor and answer the real question, which is "what did you test?" rather than the wrong question, which is "what did you find?"

Some of what was on it, paraphrased:

• Object-level access control on resource endpoints, tested across 25 endpoints under two different identities
• Cross-identity authorization on session-management endpoints, tested across 15 endpoints
• Mass assignment across the write surface, with both echo-detection and persistence-detection variants
• Server-side request forgery against URL-shaped fields in authed write bodies
• XML external entity attacks against file-upload surfaces, including the OOXML format spreadsheet uploads use
• Property-level data exposure on every authed JSON endpoint the agents reached
• Standard hygiene checks across headers, cookies, TLS, and exposed source maps

Each row is generated from what the agents actually probed, not from a checklist the product claims to support. If no agent fired against any candidate for a given control, the row doesn't appear. The report can't lie about what was tested.

What this changes for the buyer

A small dev team being pressed on security by an enterprise customer needs an artifact that proves due diligence. They've usually only had two options. The expensive option is a $15,000 manual pentest that arrives months later. The cheap option is an automated scanner report that lists no findings without explaining what was checked, which is rarely accepted as evidence.

The third option is a report that names what the agents tested, shows it against real endpoint counts, and lists what held alongside what didn't. Zero high findings becomes a strong result instead of an empty one. The customer can attach it to their security questionnaire and answer the actual question their enterprise customer was asking.

Zero findings isn't proof of secure. Some negatives are confirmed-secure (tested and enforced) and some are inconclusive (the agent couldn't complete the probe for benign reasons). Distinguishing those is the next piece of work.

But even today, a structured record of what the agents tested and what held is meaningfully different from a one-liner that says nothing was found. It's the deliverable a small dev team can actually use.

Week 8 next Tuesday.