Audit scope specifies exactly what code an auditor will review and what falls outside the engagement.
Before any audit begins, auditors and clients agree on scope. This prevents misunderstandings, ensures auditors focus on the code that matters, and allows for accurate time estimates. Changing scope mid-audit typically requires additional time and may necessitate a re-audit.
A typical scope definition includes:
- Commit hash: the exact version of the code being reviewed, so both parties reference the same codebase
- Files and folders: which smart contracts, Solana programs, or specific directories are included
- Exclusions: third-party dependencies, forked code, or out-of-scope integrations that auditors will treat as black boxes
- Focus areas: specific concerns like reentrancy, access control, or protocol integrations the client wants prioritized
Codebases should be near-production ready before scoping. Incomplete code leads to scope creep, wasted audit time on code that will change, and delays.
Ackee Blockchain audit reports include a scope section documenting the commit hash, reviewed files, and any subsequent fix reviews on later commits. This clearly defines what was covered. See the section in the summary of Ackee’s audit of Aave.
