Audit Cycle

The initial phase where the audit scope is defined. This includes:

• Codebase Review: Determining which contracts, libraries, and dependencies are in scope.
• Specification Analysis: Reviewing technical documentation, whitepapers, and intended functionality.
• Tool Selection: Choosing the appropriate mix of static analysis, dynamic analysis, and manual review tools.
• Timeline & Resource Allocation: Establishing the audit schedule and assigning specialized auditors.

The phase where automated tools perform initial, broad-spectrum vulnerability detection.

• Static Application Security Testing (SAST): Tools like Slither or Mythril analyze source code without executing it to find common bug patterns.
• Formal Verification: Tools attempt to mathematically prove the correctness of contract logic against a specification.
• Purpose: This phase efficiently catches low-hanging fruit and common vulnerabilities (e.g., reentrancy, integer overflows) to allow manual reviewers to focus on complex logic.

The core phase where experienced security engineers conduct a line-by-line, in-depth examination of the code.

• Business Logic Audit: Evaluating if the code correctly implements the intended protocol mechanics and economic incentives.
• Architectural Review: Assessing the security of the overall system design, contract interactions, and upgrade paths.
• Advanced Vulnerability Hunting: Finding complex, context-specific flaws that automated tools miss, such as intricate governance attacks, oracle manipulations, or economic exploits.

The phase where findings are documented, prioritized, and addressed.

• Findings Report: A detailed document categorizing issues by severity (Critical, High, Medium, Low, Informational), with clear explanations and code references.
• Remediation Guidance: Providing actionable recommendations and code patches for each finding.
• Client Fix Review: The audit team reviews the developer's fixes to ensure vulnerabilities are properly resolved before final sign-off.

The concluding phase where the remediated code is re-audited and the process is formally closed.

• Re-audit (Verification): A focused review of the patches applied to ensure they fix the issues without introducing new vulnerabilities.
• Final Report: Issuance of the definitive audit report, often including a summary of findings, test coverage metrics, and a risk assessment.
• Public Disclosure: Depending on the engagement, the final report may be published to provide transparency to the protocol's users and stakeholders.

Audit Cycle phases interact with these key security practices:

• Continuous Auditing: Integrating automated security checks into the CI/CD pipeline.
• Bug Bounty Programs: Crowdsourced security testing that complements formal audits.
• Monitoring & Incident Response: Post-deployment surveillance for anomalous activity.
• Time-Locked Upgrades: Using a timelock contract to enforce a delay between governance approval and execution, allowing time for community review.

The initial phase where the audit's scope, objectives, and rules of engagement are defined. Key activities include:

• Repository Access: Establishing secure access to the codebase and documentation.
• Scope Definition: Determining which contracts, libraries, and functions will be reviewed.
• Threat Modeling: Identifying key assets, trust boundaries, and potential attack vectors.
• Tool Selection: Choosing a mix of static analysis, dynamic analysis, and manual review tools.

The use of specialized software tools to scan code for known vulnerability patterns and deviations from best practices. This includes:

• Static Application Security Testing (SAST): Tools like Slither or Mythril analyze source code without executing it.
• Formal Verification: Tools like Certora Prover use mathematical proofs to verify that code satisfies specified properties.
• Fuzz Testing: Tools like Echidna or Foundry's fuzzer generate random inputs to test for unexpected reverts or state changes.

The core of a high-quality audit, where experienced security engineers manually inspect the code line-by-line. This uncovers complex logical flaws that automated tools miss. Reviewers focus on:

• Business Logic: Ensuring the protocol behaves as intended under all edge cases.
• Access Control: Verifying that only authorized actors can call privileged functions.
• Financial Math: Checking for precision errors in calculations (e.g., rounding, slippage).
• Integration Risks: Assessing interactions with external contracts (e.g., oracles, DEX routers).

The process of documenting, classifying, and prioritizing discovered vulnerabilities. Findings are typically categorized by severity:

• Critical: Direct loss of funds or permanent protocol failure (e.g., reentrancy, flawed logic).
• High: Conditions likely leading to significant loss (e.g., improper access control).
• Medium: Issues that could cause problems under specific conditions.
• Low / Informational: Deviations from best practices with minimal immediate risk. The report includes detailed descriptions, code snippets, and proof-of-concept exploits.

The final phase where the development team fixes the issues, and auditors verify the corrections. This cycle may repeat until all critical/high issues are resolved.

• Remediation Guidance: Auditors provide recommendations for fixes.
• Patch Review: The updated code is re-reviewed to ensure fixes are correct and don't introduce new vulnerabilities.
• Final Report: An updated report is issued, often with a summary of findings and their resolution status. Some firms provide a public attestation or verification seal.

An emerging practice where audit firms provide ongoing oversight post-deployment. This is not part of the traditional cycle but is increasingly offered as a service. It includes:

• Post-Launch Review: Auditing new features or upgrades.
• Bug Bounty Triage: Assisting with evaluating submissions from public bug bounty programs.
• Governance Oversight: Reviewing proposed governance changes for security implications. This helps maintain security as the protocol evolves.

An audit is most effective on mature, stable code. Submitting code that is still under active development or lacks comprehensive unit tests and documentation reduces auditor efficiency and increases the risk of missing critical issues. The Definition of Done for development should be met before the audit engagement begins.

Audits are sampling exercises, not proofs of correctness. They examine a specific code snapshot and cannot guarantee the absence of all bugs. Key limitations include:

• Out-of-scope components: Dependencies like oracles, external protocols, or front-ends may not be reviewed.
• Economic/modeling risks: Flaws in tokenomics or game theory may be considered "business logic" and not a security finding.
• Time-boxed review: The depth of analysis is constrained by the audit's duration and cost.

The cycle's security value is realized only after findings are properly addressed. A critical failure point is the remediation phase, where:

• Fix verification must be rigorous; a simple "acknowledged" status is insufficient.
• Re-audits or focused reviews are often required for high/critical severity fixes.
• Last-minute changes before deployment can introduce new, unaudited vulnerabilities.

An audit provides a point-in-time assessment. Runtime security requires ongoing measures the audit does not cover:

• Monitoring and alerting for suspicious on-chain activity.
• Bug bounty programs to crowdsource ongoing scrutiny.
• A prepared incident response plan to react if a vulnerability is exploited post-deployment. The audit report is an input to, not a replacement for, these operational security practices.

Not all audit firms provide equal rigor. Limitations arise from:

• Varying methodologies: Some may rely heavily on automated tools, while others emphasize manual review.
• Conflict of interest: Auditors paid directly by projects they review may face implicit pressure.
• Lack of skin-in-the-game: Unlike code forking or insurance protocols, traditional auditors do not share in the financial loss from a failure, potentially misaligning incentives.

An audit is a snapshot against known vulnerability classes (e.g., reentrancy, overflow). It cannot anticipate:

• Novel attack vectors and emerging exploit techniques.
• Integration risks with new, unaudited protocols or Layer 2 solutions.
• Upgrade risks introduced by proxy patterns or governance-controlled changes. This necessitates a cycle of periodic re-audits as the ecosystem and codebase evolve.