Get ready for an audit

Get ready for an audit

TL;DR - Getting the correct audit is one if most important items for any team so please reach out if you have any questions during your process or for help finding the correct match!

Contact information:

X formerly twitter: 0xkato

Telegram: Oxkato

Email: tobias@espressosys.com

Pre-Audit

Before considering an audit, ask yourself a few questions!

Is your code well documented? (Good to have)

• Are your code comments up to date?
• Are there any third-party dependencies that the code relies on?
• Is there a system architecture overview?
• Have you mapped out the data flow and transaction lifecycle?
• Are off-chain and on-chain components clearly documented?
• Are access control mechanisms clearly outlined?
• Have you done a risk assessment and threat model?
  • Do you have a list of all known issues with explanations?

Have you done comprehensive testing?

• Do you have 90-100% line coverage?
• Is there sufficient unit and integration testing, including edge case testing?
• Are you conducting differential fuzz, stateless or stateful fuzz testing or mutation testing?
  • Even if you don’t, do you know what the core invariants are?
  • Note: Some teams offer to build fuzzing suites as part of an audit or as a separate service. You may consider this if you are building something that is heavily reliant on math or state transitions like ticks in uniswap v3.

What kind of Communication are you looking for?

• How involved in the process would you like to be?
  • Weekly calls?
  • Shared document of findings?
  • Receive the report at the end?
  • Do you want to dedicate a single point of contact to the auditing team, or involve the full team?
• What is your preferred communication method?
  • Do you prefer chat tools (e.g., Telegram, Discord) or project management platforms (e.g., Notion, Jira)?
  • What format should the shared document be in, e.g., Word or Notion?
  • How would you like auditors to reach you with questions?
  • Do you prefer a single point of contact or a group chat?

Clarify what Deliverables you want

• Standard audit deliverables
  • An audit report
    • Findings Summary
    • Risk Assessment
  • Proof of Concept for issues
    • Team dependent some only do for high and critical severity vulnerabilities
      • PoCs can greatly speed up the process of getting a solid understanding of the vulnerabilities and its root cause.
  • Security advisory during the review
  • Fix review (Important to know that some teams do not include it as part of the engagement)
• Optional deliverables at extra cost
  • Comprehensive Testing (Note that some firms do offer this as part of the engagement)
  • Scope extensions
  • Remediation Support
  • Architecture or Design Reviews
• Delivery Timeline and Milestones
  • Do you want to be involved during the process or just receive the report once it’s complete?
  • What is the final report deadline?
  • Do you want the remediation PRs reviewed? (Always recommended)
  • Private and public report?
• Are you looking for long-term support or just a single review?

Define the Audit

• Define Scope
  • List each file and dependency that should be considered in scope.
    • Recommendation: Everything involved in the system should be considered in scope. Even code written by others (e.g. libraries) that is not already audited or heavily battle-tested should also ideally be in scope.
  • Outline all critical functionalities.
  • Have you outlined excluded components to avoid ambiguity?
• Define Budget
  • What is the budget for the audit?
    • Based on what style of audit you are looking for there are pros and cons.
      • Talent factories lends out security researcher (e.g. Spearbit, OakSecurity)
        • Pro
          • You can create a team composition that has exactly what you are looking for in terms of skillsets.
          • The prices are usually negotiable.
        • Cons
          • Tend to match or surpass the traditional auditing firms which is the high end of prices. To give an idea here you can see the public Spearbit rate for researchers excluding the spearbit fee.
          • Some times researcher are not available year around to review updates to repos after the main audit concludes.
      • Traditional audit firms (e.g. Openzeppelin, Sigma prime)
        • Pro
          • These are some of the most well known auditing firms and have done tons of audits for many different types of systems, there is a good chance they have some experience with a similar system to the one you are building.
          • Usually these are able to set have people available year around to review updates to repos after the main audit concludes.
        • Cons
          • The firms being as large as they are means that their demand surpasses their capabilities meaning that it can be hard to ensure that you get quality auditors on your audit.
          • These are some of the most expensive audits that you can get.
      • Niche specific firms focus on specific area like ZK or even more specific like smart contracts in solidity (e.g. ZK security, Guardian audits offers a pay per vulnerability model)
        • Pro
          • If there is a firm working in your niche chance are that they have the most experience working with that type of system.
          • Usually these audit are on the more affordable side.
          • Usually these are able to set have people available year around to review updates to repos after the main audit concludes.
        • Cons
          • A lot of research is require to ensure that these niche first actually perform.
          • Usually these are smaller teams meaning less availability.
      • Individual security researchers

      How can you find individuals?

      It can be quite a time consuming task to find someone with relevant experience. A few places to look include Telegram groups (e.g., ETHSecurity Community), Crypto Twitter, and contest platforms like Code4rena, SherlockDeFi, Cantina, and Immunefi, where you can review leaderboards and past reports of similar systems.

      An important note when searching for individuals: you need to be very selective about who you choose. Avoid mediocre researchers reviewing your code, always aim for the best in the field. I strongly recommend getting a second opinion on the selected researchers, as well as on the platforms and sources you use to find them.

        - Pro
            - You can find exactly what you are looking for in terms of skillsets.
            - Usually these audit cheapest audits that you can get.
        - Cons
            - By nature of them being individuals there are less reputation behind them and is much harder to find good individuals.
            - Some times researcher are not available year around to review updates to repos after the main audit concludes.
      

  • Quotes can range from $5-25k USD per week for an individual to $35-70k per week for firms, depending on the scope and complexity of the engagement.
    • A useful question to ask here is: if the audit reveals numerous findings and requires a follow-up, are you okay with an additional budget?
    • Recommendation: If an audit report has 5 or more high/critical vulnerabilities you should consider getting another audit.
• Define Expertise Needed
  • Domain-Specific Expertise
    • Zero-knowledge proofs, cross-chain bridges, DeFi protocols, etc.
      • If its a AMM or math heavy protocol it would be good to look for an audit that has fuzzing or formal verification.
  • Language and Chain Expertise
    • Solidity and Ethereum, Move and Aptos, Rust and Solana, etc.
  • Finding the right fit among the many firms and individual security researchers is critical for a getting a good audit. Navigating this process can require a significant time commitment for research and discussions with teams, I recommend reaching out to me for assistance in connecting with the right team. I can also help guide you through the quoting process to minimize overcharging.

• Define Success Criteria

  Success criteria could include resolving a specific number of critical findings, achieving certain code coverage thresholds, or meeting defined security compliance standards.

Pick Your Audit Model

There are pros and cons to every single one, reach out to me and we can discus what might be best for your needs!

• Point-in-Time Audit

  A traditional audit with a fixed time frame, starting and ending at specific dates.

• Continuous Audit

  Ongoing audit support, where the security team continuously reviews updates and changes.

• Hybrid Model

  An initial audit is followed by ongoing checks as updates are made.

• Module-Focused Audit

  A model where code modules are reviewed separately.

• Retainer Audits

  You pay for a certain number of hours per month to utilise auditors as needed.

• OpSec Audit

  An audit focused on operational security practices to identify and mitigate risks of sensitive information leaks.

Outreach

• Reach Out to Auditors

  If possible, establish direct contact with the auditor to expedite the process.

  Unless a perfect match is found, it’s generally recommended to get 2-3 quotes from teams you’re interested in working with.

  A few things to confirm or ask:

  • Remediation Process
    • How much time is allocated, and is there a set deadline?
    • Prepare a summary document including your timeline, scope, and objectives before contacting auditors
    • How soon can they start the audit?
    • Are they willing to sign an NDA (if needed)?
    • Can they meet the deliverables you want?
    • Pricing structure and payment terms
    • Are the auditors dedicated members of the team, or are they contracted? If contracted, have they worked with the team before?
    • How adaptable is the auditing team to last-minute changes?

• Once You Have All the Quotes

  Make a decision based on timeline, price, and expertise.

  I recommend being available to answer any questions for the auditors. Depending on your communication approach, there may not be much to do until the report is ready, but ask the auditors to use a shared document for findings so you can start addressing issues during the audit itself.

  Build a timeline for remediation work and share it with the auditors.

During the Audit

After the audit has started you should be focus on a few things

• Be available for the auditors
  • The faster the auditors can get familiar with the code base the better review they can do.
    • You can do that by being ready answer any questions that the auditing team might have.
  • Instead of invalidating reported issue be creative in the path to find another way to use a attack vector.
• Be transparent about your code, if you know if some invariants don’t hold and there will be a problem, say it.

Post-Audit

After the audit, don’t just fix the issues and move on, spend some time reflecting on the engagement, and consider how to prevent similar issues from arising in the future.

• If there were a lot of bugs found, was it enough to warrant another review?
• Are you using all PoCs as test cases?
• What areas can you improve on?
• Were you satisfied with the auditing team’s performance and communication?

Next Steps: Building Long-Term Security

Security is an ongoing process. Consider:

• Creating a security roadmap.
• Building an incident response plan.
• Tracking security metrics.
• Exploring monitoring tools.
• Preparing for a bug bounty program.