3.9 Audits for Developers

By the time a contract is ready for an external audit, the developer has done most of the security work that matters. The audit is the final verification step, not the security plan. A contract that arrives at audit with no internal review, no test coverage, no threat model, and no documented invariants will get a report full of findings — but the report is the symptom, not the cause. The cause is that security was treated as something the auditor would handle.

This section covers the audit process from the developer's perspective. It is deliberately distinct from two other audit-related areas of the book:

• Section 2.3 (Audits and Code Review) covers audits at the SDLC level — why they matter, where they fit in the development lifecycle, the role of routine and iterative auditing. It is the strategic framing.
• Book 4 (Smart Contract Auditing) is the security researcher's manual — how to perform an audit, the techniques and tools auditors use, the deliverables they produce. It is the practitioner's framing for the person doing the audit.

This section sits between them. It assumes you are a developer whose contract will be audited, and it answers the practical questions that come up at each phase: what should I do before the audit starts, who should I hire, how do I work with auditors during the engagement, what do I do with the findings, and what comes after.

The audit industry has matured substantially over the past several years. A decade ago, audits were performed primarily by a small number of firms operating like traditional security consultancies. Today the landscape includes traditional firms, independent solo auditors, contest platforms (Code4rena, Sherlock, Cantina, Codehawks), bug bounty programs (Immunefi), and formal verification engagements (Certora). Each format serves different needs at different stages of a protocol's life. Choosing the right format is one of the central decisions covered here.

How to Read This Section

The seven subsections progress through the audit lifecycle:

3.9.1 Internal Audit Process covers what the development team should do before engaging external auditors — peer review, automated tooling, internal threat modeling, test coverage. This is the work that turns "we wrote the code" into "the code is ready to be reviewed."

3.9.2 Preparing for an External Audit covers the deliverables the development team owes the auditor before the engagement begins: the codebase freeze, NatSpec documentation, the threat model, invariant documentation, deployment scripts, known-issue lists, and the scope document. Skipping these makes the audit less effective and more expensive.

3.9.3 Selecting an Audit Path covers the choice between firms, independent auditors, contest platforms, and bug bounties — when each is appropriate, what each costs, and what each is good and bad at finding.

3.9.4 During the Audit covers the operational dynamics of an active engagement: communication channels, response time expectations, mid-audit code changes, finding triage as it arrives, and the relationship dynamics between developer and auditor.

3.9.5 Post-Audit Remediation covers what to do with the report: triaging findings by severity, implementing fixes, requesting re-audits, and the public disclosure timing question.

3.9.6 Developer's Pre-Audit Checklist is a scannable reference — the items to verify before sending the code to auditors. The mechanical complement to the prose in 3.9.2.

The Core Tension

Audits exist because no internal review process is perfect, but external auditors don't have unlimited time either. A typical external audit for a moderately-complex protocol runs 2-4 weeks with 2-3 reviewers. That is a finite budget of senior security expert hours applied to your codebase. The work the development team does to maximize the return on those hours — clean code, clear documentation, focused scope, well-tested invariants — is the highest-leverage security work the team can do before the audit even starts.

The opposite is also true. Auditors looking at code that is undocumented, untested, sprawling, and changing during the engagement spend most of their time on context-building rather than finding bugs. The same auditors looking at well-prepared code spend their time looking for the actual subtle issues that automated tools and developer review missed. The quality of the audit you get is directly proportional to the quality of the preparation you do.

Conventions

The conventions established for the rest of Book 3 apply here:

• Solidity ^0.8.20 is the default version for code examples
• OpenZeppelin contracts are the default library references
• Foundry is the primary test framework, with forge coverage, forge inspect, and forge snapshot referenced as standard tooling

Specific auditor- and contest-platform references throughout (Code4rena, Sherlock, Trail of Bits, OpenZeppelin Security, Spearbit, Cantina, etc.) reflect the state of the industry at time of writing. The specific firms and platforms will evolve; the principles of working with them will not.

Sections 3.9.1 through 3.9.6 follow.