How to Define Audit Scope Early

Defining the audit scope early establishes the technical and functional boundaries of the security review. It explicitly answers what code is in-scope (e.g., specific Solidity contracts, libraries, interfaces) and what is out-of-scope (e.g., front-end code, oracle reliability, economic model risks). Without this clarity, auditors may waste time on irrelevant code, while critical vulnerabilities in the core protocol remain unchecked. A formal scope document prevents these misalignments, turning a vague request for a "security check" into a targeted, actionable engagement.

The scope directly dictates the audit's methodology, timeline, and cost. A review of a simple ERC-20 token contract requires less effort than auditing a complex DeFi protocol with multiple integrators and upgrade mechanisms. By detailing the components—such as the PoolManager.sol contract or the Vault upgrade logic—teams can accurately estimate the required man-hours and specialist expertise (e.g., needing a mathematician for a novel AMM curve). This transparency allows for realistic budgeting and scheduling before any code is examined.

From a risk management perspective, a precise scope creates a shared understanding of responsibility. It forms the basis of the engagement agreement between the project team and the auditing firm. If a vulnerability is later discovered in an out-of-scope component (like an unaudited admin script), the scope document provides clear reference points. This is crucial for post-audit processes, including the issuance of a final report and any potential remediation verification, ensuring all parties agree on what was reviewed and what assurances were provided.

Before drafting the scope document, auditors and clients must gather and agree on several key inputs. The primary prerequisite is the technical specification or whitepaper, which details the system's intended functionality, architecture, and economic model. A second critical input is the codebase itself, including its repository location, commit hash for the version to be audited, and a list of all smart contract files. Without these artifacts, defining what is in scope versus out of scope is impossible.

The audit team must also understand the project's stage and objectives. Is this a pre-launch review of a new protocol, a check on an upgrade to existing contracts, or a focused assessment of a specific vulnerability class? The answers determine the audit's depth and breadth. Furthermore, clarifying the timeline and budget is essential, as these constraints directly impact how many person-hours can be allocated to reviewing different components, influencing the scope's granularity.

A final, often overlooked prerequisite is identifying key stakeholders and decision-makers. This includes the core development team, project management, and any external security advisors. Establishing clear communication channels with these parties early ensures that questions about system behavior and design intent can be resolved quickly during the audit, preventing delays. This collaborative foundation turns scope definition from a bureaucratic task into a strategic alignment exercise.

The scope document is a formal agreement between your project and the audit firm, detailing exactly what will be reviewed. A well-defined scope prevents scope creep, ensures cost and timeline accuracy, and aligns both parties on the audit's objectives. It should explicitly list the smart contract files (e.g., src/core/Vault.sol, src/tokens/ERC20Staking.sol), their commit hashes or version tags, and the specific blockchain networks (Mainnet, testnets like Sepolia) they target. Ambiguity here is a primary source of delays and misunderstandings.

Beyond file listings, detail the functional scope. Specify which user flows and interactions are in-scope, such as deposit/withdraw functions, governance proposals, or specific upgrade paths. Equally important is defining what is out-of-scope: this often includes already-audited third-party libraries (like OpenZeppelin contracts), front-end code, or economic/game theory risks unless explicitly requested. Clearly stating the testing environment requirements, such as forking a specific mainnet block or using custom mocks, is also crucial for the auditor's setup.

Finally, include key project context and success criteria. Provide links to technical documentation, architecture diagrams, and the test suite. Define the severity classification you expect the auditor to use (e.g., following the Immunefi or Code4rena severity scales). Specify any compliance requirements, like adherence to specific standards (EIP-712, ERC-4626), and the desired final deliverables (a PDF report, a presentation to the team, remediation verification). A comprehensive scope document transforms the audit from a black-box review into a targeted, collaborative security exercise.

The most common mistake is failing to define the scope before the audit begins. This often happens when teams provide auditors with a sprawling, evolving codebase or a moving target of requirements. Without a clear, immutable scope document, auditors may waste time reviewing deprecated code, miss critical new functions, or deliver a report that doesn't match the client's expectations. The scope must be agreed upon and frozen at the start of the engagement.

A precise scope includes specific, version-controlled artifacts. This means providing the exact commit hash (e.g., git commit a1b2c3d) of the repository, the deployed contract addresses for on-chain components, and a list of all files and directories to be reviewed. Exclusions are equally important: explicitly state which files (like mocks, legacy code, or third-party libraries) are out of scope. Tools like slither-flat can help generate a flattened representation of the in-scope contracts for clarity.

The scope must also define the security properties to be verified. Beyond generic checks, specify if the audit should focus on centralization risks (admin key compromise), economic model attacks (flash loan manipulations, oracle manipulation), or compliance with specific standards (like ERC-20 or ERC-721). For a DeFi protocol, you might list: "Verify the integrity of the price oracle, ensure no single liquidity provider can drain the pool, and confirm fee calculations are correct under all edge cases."

Finally, establish clear rules for scope creep. Development rarely stops during an audit. Define a process for handling newly discovered, critical issues that require patching mid-audit. Will the fix be added to the scope? How will re-auditing be handled? Documenting this upfront prevents conflicts and ensures the final report accurately reflects the security of the code that will be deployed.

The first critical step is to establish a secure and isolated testing environment. This should be a fork of the mainnet or testnet state, not a local simulation. Use tools like Hardhat or Foundry to fork the target chain at a specific block. For example, anvil --fork-url $RPC_URL --fork-block-number 18900000. This provides a realistic context for testing interactions with live oracles, dependencies, and other protocols. Ensure all necessary private keys for privileged roles (admin, owner) are accessible in this environment to test access control functions.

Next, compile a comprehensive test suite that validates the intended functionality outlined in the scope. This isn't about finding bugs yet; it's about confirming the system works as the developers expect. Write integration tests for core workflows—like depositing, swapping, and withdrawing in a DeFi protocol—using the forked environment. This baseline suite serves a dual purpose: it helps auditors understand normal behavior and becomes a regression test to ensure fixes don't break core logic. Document any discrepancies between the tests and the provided specification immediately.

Concurrently, set up static analysis and automated scanning tools. Run Slither or Semgrep with custom rule sets tailored to the project's patterns (e.g., specific inheritance structures or state variable layouts). Automated tools excel at finding common issues like reentrancy patterns, unused state variables, or deviations from standards. Triage these initial findings: flag clear vulnerabilities for deep investigation and note stylistic warnings for later review. This automated pass creates a preliminary issue list, allowing manual review to focus on complex business logic.

Finally, initiate a preliminary manual code walkthrough. Before diving into exploit construction, read through the entire in-scope codebase linearly. Focus on understanding data flow, permission boundaries, and external calls. Map out how funds enter, move through, and exit the system. This high-level mental model is indispensable for the deep-dive analysis that follows. Use this phase to formulate initial hypotheses about potential risk areas, such as complex math in a lending protocol's interest rate model or cross-contract callback logic in an NFT marketplace.