Security audits: compare the report with deployed code
A security-audit report is evidence about a defined review, not a permanent safety certificate for every deployment using the project’s name. Compare the report’s code scope, version, findings, and assumptions with the contracts currently relevant to your spot research. The useful output is a scope-gap table.
Ethereum’s smart-contract security guidance discusses security practices and the role of review. It does not certify any particular protocol. A project’s audit claim must be traced to the actual report and the code relationship it describes.
Establish the report identity
Record the reviewing organization, report date, engagement subject, repository, commit or release identifier, included files, and excluded components. Use the original report when available rather than only a badge on a project homepage. A list of auditor logos cannot establish what each organization examined.
Read the assumptions. A review may assume a trusted administrator, a particular oracle, a specific dependency version, or an intended deployment configuration. If those assumptions differ from the current system, the report may still be relevant but cannot be applied without explaining the gap.
| Scope dimension | Report evidence | Deployment evidence |
|---|---|---|
| Code version | Reviewed commit or release | Deployed implementation identity |
| Components | Included and excluded files | Contracts actually in the user path |
| Configuration | Assumed roles and parameters | Observed deployed settings |
| Findings | Severity, status, and limitations | Fix relationship and remaining issues |
| Dependencies | External systems assumed | Current sources and control paths |
Do not reduce this table to a count of findings. A high count can reflect review depth and scope; a low count can reflect a narrow engagement. Counts are not directly comparable without context.
Hypothetical version gap
Assume a fictional project publishes an audit for commit A. The report covers a vault and explicitly excludes a bridge integration. The deployed vault now corresponds to commit B, which changes an accounting function, and the user-facing product relies on the bridge.
The correct conclusion is not that the report is worthless. It supports a review of the defined version and scope. The research gap is the changed accounting function and the excluded integration. Request a version comparison, follow-up report, or other relevant evidence rather than asserting the new deployment was covered.
Suppose a finding is marked resolved in the report. Verify whether the fix belongs to the deployed version. A report status refers to the review process; it is not automatically proof of the configuration currently running. All details in this example are hypothetical.
Follow remediation without overclaiming
For material findings, retain the issue description, affected component, proposed mitigation, and reviewer response. Separate acknowledged risk from a verified code change. A team accepting a risk does not eliminate that risk; it records a decision within the engagement.
Check whether a later upgrade changes previously reviewed behavior. Preserve the original report as historical evidence and add the new change as a review trigger. A current badge can obscure a long sequence of modifications if the researcher does not track versions.
Also identify controls outside the audited code: privileged keys, deployment scripts, frontend routing, custody arrangements, and external dependencies where relevant. A contract review cannot be assumed to cover those areas unless the report explicitly includes them. The research note should state its own limits rather than pretending to perform a fresh audit.
Limits and common mistakes
Public reports can omit confidential details or provide insufficient version mapping. If the deployed bytecode cannot be tied to the reviewed source, mark the relationship unresolved. Absence of a public finding does not establish absence of vulnerabilities, and a completed review does not guarantee future behavior.
Common mistakes include relying on logos, applying an old report to a new implementation, counting all resolved labels as deployed fixes, and interpreting a narrow contract review as a full operational security assessment. The final note should say what was reviewed, what matches the deployment, and which material gaps remain. It should not assign a guaranteed safety grade or infer a spot investment outcome.
FAQ
Does an audit mean a protocol cannot lose assets?
No. It is a scoped review with assumptions and limitations. Deployment changes and risks outside that scope still require examination.
Should a report be ignored if the deployed version changed?
No. Preserve its relevant historical findings, then identify the exact changes and request evidence addressing the scope gap.