Read a security audit for scope, version and exclusions

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

An audit is bounded work

The useful unit is not 'audited project'. It is a named team reviewing named code at a named revision, during a named period, under stated assumptions. Download the actual report rather than relying on a logo. Record the auditor, dates, repository, commit hash or release tag, files and contracts in scope, excluded components, effort, methods, severity scheme and final resolution status. If any of those are missing, write 'not stated'. Do not fill gaps from marketing copy.

Match the report to what runs

1. Resolve the live contract, including any proxy implementation, using the implementation-and-admin workflow.
2. Find the source repository and deployment record for that implementation. Compare its bytecode, commit or release tag with the audit target.
3. List changes after the audited revision. Pay particular attention to access control, pricing, upgrade logic, external calls and dependencies.
4. Check whether a remediation review examined fixes. 'Fixed' in a project table may mean a patch was proposed, not independently re-reviewed or deployed.
5. Read every unresolved high or medium finding and every assumption that can invalidate the analysis.

Trail of Bits' public index demonstrates why dates and effort matter: one protocol can have several reviews covering different versions and work measured in different engineer-weeks. Ajna's audit repository goes further by naming scope and listing findings whose dispositions include fixed, improved testing and no fix. A zero-count headline would erase those distinctions.

Hypothetical example

Hypothetical: a lending app displays an audit dated March. The report covers commit abc123, core lending contracts and four engineer-weeks; it excludes the oracle adapter and frontend. The live proxy now points to code built from def456, added in July, and the oracle adapter determines collateral prices. Supported conclusion: the March report is evidence about the earlier core-contract scope. It is not evidence that the July implementation, oracle integration or transaction-signing interface was reviewed.

Grade relevance, not prestige

Use a simple decision: matched when the deployed version and material dependencies fall inside the reviewed scope; partial when some components or later changes sit outside it; stale when the running implementation cannot be tied to the audited revision; and unverifiable when the report is unavailable. Auditor reputation cannot repair a version mismatch. Multiple audits may broaden coverage, but they may also repeat the same exclusions.

Limits

An audit samples a system under time and scope constraints. It cannot prove absence of bugs, economic attacks, compromised signers or later configuration errors. A report may also contain sensitive details removed from the public version. This workflow evaluates how much a published report supports, not the competence of an auditor. It complements the guide to assurance terminology: in both cases, the engagement label matters less than its stated subject, criteria and boundary.