Audit scope drift: the badge can outlive the reviewed code

An audit report concerns a defined target and scope. This review method asks whether that target still corresponds to the deployed system. A report's existence is useful evidence, but it cannot establish the security of changes that were not examined.

Pin the reviewed version Record the repository, commit, compiler settings and deployed addresses where available. Check exclusions and assumptions. Distinguish source verification from an audit: showing a relationship between source and deployed bytecode does not establish that the source is free of vulnerabilities.

Follow subsequent changes Look for upgrades, new modules, changed dependencies and configuration changes that affect the report's assumptions. A small diff can alter an important trust boundary. Conversely, a change in website copy does not necessarily mean the audited contract changed.

Explain the remaining coverage State which part of the current system is covered and which part needs further review. Do not describe an old report as fake merely because the software evolved. The concrete issue is whether the current marketing accurately communicates the scope and age of the assessment. Readers need the correspondence, not just the auditor's logo.