Reading a VPN Audit Report: Scope Beats the Badge

Badges are cheap to display and expensive to interpret. A published audit report is a bounded piece of engineering work: a named assessor examined named components, at a named version, with a stated method and a time budget. Those four facts determine what the conclusion can support, and they are usually in the first few pages rather than in the marketing summary. Reading them takes ten minutes and prevents the common error of extending a client-app finding to an entire service.

What the Scope Section Actually Bounds

A scope statement is a fence, and everything outside it is unanswered rather than passed. Reports list the components examined, the commit range or build identifier, the environment used and the interaction model allowed. A desktop client, a mobile app, the server code, the account backend and the production infrastructure are five different subjects, and an engagement can cover any subset of them.

Exclusions matter as much as inclusions, because they are stated deliberately and read carelessly. An account system described as out of scope is not implied to be secure, and a mobile app left out of an engagement is simply unexamined. Mark every untested component in your own notes as unknown, and resist the pull to fill the gap with reputation.

Two Kinds of Test Answer Different Questions

Source review and runtime testing look for different failures. A reviewer reading code can follow a key derivation, spot a missing length check and reason about an entire parser without executing it. A tester against a running service discovers what the deployed build actually does: a certificate the app refuses, a fallback protocol still enabled, an endpoint that leaks a version banner through configuration nobody reviewed.

Neither substitutes for the other, and a report usually names which was performed. When a summary says "audited" without that distinction, the ambiguity is in the summary, not in the report.

Access limits do the same work. A black-box engagement cannot see the server configuration, and an architecture review that never touches a deployed endpoint cannot notice that production differs from the diagram. Both are legitimate; conflating their results is not.

How a Finding Becomes a Fixed Version

The valuable half of a report is the remediation table: each finding, its severity under the assessor's method, the operator's response and the retest result. Severity numbers come from a chosen methodology rather than from nature, so compare severities within one report instead of across two with different scales.

Then connect the fix to released software. A corrected finding matters to a user only once the version carrying the correction is the one installed, which is why a report's build identifier and a release changelog have to be read together. A retest that covered the fix closes the loop; an untested fix is a claim. So is a fix shipped only in a branch that no stable release ever merged.

What the Badge Cannot Tell You

Absence of findings is not proof of absence of defects. A short engagement with a fixed budget will miss things, and the honest reading of a clean report is that the assessor did not find the classes of problem they looked for in the time available.

The badge also cannot speak for properties outside its scope. Claims about logging practice, jurisdiction or retention live in a policy document, not in an audit of a client application, and no reputation of the assessor transfers across that boundary.

Recording Evidence You Can Defend

Write the citation as three parts: the component, the version and the verified correction. A published engagement such as the Mozilla-commissioned VPN audit supports exactly the statements its scope describes and nothing wider, which is still worth rather a lot when the citation is precise. The same report cited for something it never examined is worth less than no citation, because it invites a confidence nobody earned.

Where a claimed property falls outside every available report, leave it unresolved in the document. An unresolved line invites a follow-up question; a badge does not. The one exception is a property that a different, equally specific document settles, and then the citation changes rather than the claim.

Two more habits make the reading durable: note the report date against the release you actually run, and keep the diff between what was tested and what you deployed. Both turn a trust decision into something a colleague can check.