Reading an audit report as a buyer: severity, remediation, and what's not on the page
This one's for the other side of the table — acquirers and serious users evaluating an app whose maker hands over a security report — though makers should read it to understand exactly what that artifact does and doesn't say for them. An audit report is evidence, not absolution, and reading one well takes about twenty minutes if you know where the information hides.
Read the scope statement first, always
The findings mean nothing until you know what was examined. Check: source-assisted or black-box? Which components — and is the thing you care about (the billing integration, the agent's tool access) inside or outside the boundary? What dates, against which version? A clean report scoped to half the system is a clean half-report. The scope statement is also where quality shows: precise boundaries signal a real practice; vague scope ("reviewed the application") signals a deliverable built to be waved, not read.
Read findings for pattern, not count
Six findings is not worse than two — sophisticated buyers read the shape: (1) severity distribution and whether ratings are justified with impact reasoning or just labeled; (2) reproduction quality — findings you could hand to a developer versus vibes; (3) the pattern class — five instances of missing route authorization tells you about the codebase's development process, not just five bugs; (4) what's marked informational — good auditors park judgment calls there, and it's often the most honest section on the page.
The remediation trail is the actual signal
A report alone says "examined once." A report plus fixes plus a re-test attachment says "found, fixed, verified" — the full loop that the cost thread calls the conversion of a problem list into a diligence asset. No re-test? Ask what happened to each critical and high. The maker's answer quality here tells you more about how the app is operated than the original findings do.
What's structurally not on the page
Age (a report is a snapshot — ask what's shipped since, and see the audit-scope thread's dating logic); everything outside scope (data-flow reality, key history, zombie infrastructure — the outside-the-repo class from the AI-testing thread); auditor independence (was the auditor also the remediation contractor? Disclosed conflict isn't disqualifying, but you should know); and the counterfactual (absence of findings in an unexamined area is absence of examination, not of flaws).
The three questions that finish the job
Ask the maker: "What did you not fix, and why?" (honest triage is a green flag — everything-fixed-immediately sometimes means severities were soft); "What would the auditor say has changed since?"; and "Can I talk to the auditor?" — makers with nothing to hide usually say yes, and the auditor's off-report color is routinely the most informative ten minutes in technical diligence.
Buyers: what do you look for in these reports that this misses? Auditors: what do you wish buyers understood about reading your work? Both answers improve the next maker's engagement.
Replies (4)
Follow-up from an acquirer, via intake: "What are the report red flags that should make me discount the artifact entirely?"
The ones practitioners name: (1) no scope statement, or scope discovered to exclude the app's core surface; (2) findings without reproduction steps — unfalsifiable findings suggest scanner output with prose on top; (3) uniform severity inflation (everything high/critical — sells remediation) or deflation (everything informational — sold a clean letter); (4) no named practitioner willing to take a call; (5) a report that reads identically to public template reports — search a distinctive sentence and see; (6) makers who present the report but refuse the three finishing questions. Any one of these doesn't zero the artifact, but two or more means you're holding marketing, and your technical diligence should proceed as if no audit exists.
Follow-up from maker intake (the other direction): "Reading this as a maker — should I fix everything before showing a buyer, or is visible triage genuinely better?"
Visible, reasoned triage genuinely reads better to sophisticated buyers than a suspiciously perfect record. What that means concretely: criticals and highs fixed and re-tested, no exceptions — those you never argue past a buyer. Mediums and lows: fix what's cheap, and for the rest write one honest line each — 'accepted: requires the legacy export path we're sunsetting in Q1; mitigations X in place.' That sentence demonstrates the security judgment the whole diligence exercise is trying to measure. The failure mode isn't open findings — it's open findings with no evidence anyone decided anything about them.
Why this thread exists on a marketplace: as audit reports become standard artifacts in listings and bidder rooms here — and they are trending that way — the ecosystem needs buyers who can read them, or the artifact decays into a checkbox and then into theater, and we've all watched that lifecycle elsewhere. Skilled reading keeps the artifact honest: makers commission real engagements because buyers ask real questions about them. That's the same trust-compounding loop as verified metrics, applied to security. If you're a buyer and this reading discipline feels like work — it's about twenty minutes, and it's the highest-information twenty minutes in most small-app diligence.
Follow-up from an acquirer, via intake: "The maker's report is eight months old with meaningful shipping since. Do I demand a fresh audit, and who pays?"
Market practice is converging rather than settled, but the reasonable pattern: an aged report plus a written delta from the maker ('what changed since: features, dependencies, infra — and what re-review happened') covers small drift; meaningful architectural change since the report — new agent capabilities, new data flows, a platform migration — justifies asking for a targeted re-review of the changed surface, not a full re-audit. Who pays tracks deal posture: sellers who want top-of-range pricing refresh their own artifacts (it's their asset — see the exit-readiness logic); buyers who want extra assurance beyond that buy it themselves. What you shouldn't accept is the eight-month-old report presented as current — the dating discipline this platform applies to metrics applies identically here.
Threads are permanent — locked, not deleted, once resolved. New posts go through a submission form and are published by moderators, usually within 1 business day.