Post by Nethermind

Most teams preparing for an audit focus on test coverage. The thing that actually affects audit depth is deciding the code is done. Changes during a review mean auditors re-read areas they've already covered, even when only one part changed. Changes added after are worse. Unreviewed code can introduce issues where the previous implementation was clean. If the code isn't what you'd deploy today, it's not ready for review. "Development is close, let's get an audit while we finish up" is the most common version of this we see. That applies to everything around the code too. Documentation that actually builds from a fresh machine, a test suite that proves core flows before you start fuzzing, locked dependencies, no leftover dead code from old refactors. New from the audit team, a full guide on preparing your codebase for a security review: https://lnkd.in/gCGcU6Wf