Imagine you close a deal for a security assessment of a codebase. You've got the commit hash, and the scope is crystal clear. Should you jump straight into the code?

No! Not until you first do a kickoff talk with the development team. Why?

Because they can be an invaluable source of information. Developers have context about the system, you don't. They know about its history, design decisions, weird edge cases, sensitive components, and much more. How could you miss learning about these? And that's not all.

You must settle on details about the auditing process, so as to adapt your workflow to their needs. Not doing this early can cost you badly later. Thus, talk to them first.

The client won't have much time. To be efficient, it's OK to prepare questions in advance. After a few times and years of experience, you'll grow an intuition of what works best for each project.

So here's a list of questions that worked for us in the past. Use them to survey precious information prior to getting your hands dirty. There's only one warning.

Don't use these as a checklist. Skip the ones you don't like, and add your own. Use them as a starting point, and adapt as necessary to fit each project.

We're grouping them in these categories:

  • Communications
  • Documentation
  • Prior security work
  • Project
  • Roles
  • Report

💬 Communications

  • Who's going to be the main point of contact during the audit?
  • What should be the main comms channel with the development team?
  • Should we share drafts of potentially severe issues in advance? Where? With whom?
  • Would you rather have sync meetings during the course of the audit to share progress?

📄 Documentation

  • What's the available documentation? Where can we find it?
  • Is the documentation up-to-date?
  • Does the documentation match the version of the system about to be audited?
🗒️
By documentation we mean any form of technical docs, whitepapers, design documents, diagrams, presentations, etc. Whatever can give you insights into the inner-workings of the system.
It can be either public, or non-public but shareable with you. If the latter, remember to quickly ask for access.

🔒 Prior security work

  • Is this the first audit you're getting? If not, can you share who else audited it? Can we read previous audit reports?
  • Are you planning to formally verify parts of the system?
  • Does your team run security-oriented tooling? Which? How (manually, CI, etc)?

💻 Project

  • Is it possible to schedule a walkthrough of the code base with a developer? 45 min should do.
  • Is the code forked from a well-known project? Or at least heavily inspired? Not necessarily as a whole – perhaps some parts. If so, what features did you add / remove? Why?
  • Is the code already in production? If so, how should we proceed if we find a critical vulnerability?
  • If the code isn't deployed, is it about to be deployed? When?
  • To which chains are you deploying it?
  • Is the code frozen? Or do you expect changes during the audit? Where? When? Should we periodically incorporate those changes?
  • What are the most sensitive parts of the codebase? What are you most fearful of?
  • What parts of the project would you consider the least tested?
  • What parts of the code where the most difficult to tackle?
  • Where did you make the most changes throughout the development process?
  • Are there any attack vectors you've already thought of? Are they documented? How's the code preventing them?
  • What are the most relevant integrations to consider? (oracles, DEXs, tokens, bridges, etc). Can we assume these external elements to work as documented?
  • Are you implementing and/or following any known ERC?
  • Are you using well-known libraries as dependencies? Which ones? Any specific reason why you decided to use X instead of Y?
  • Are there upgradeable contracts? Which ones? What does the upgrade process look like?

🤼 Roles

  • What are the main roles of the system? Any permissioned role worth highlighting?
  • Can we assume whoever holds these roles is benevolent and always act in the well-being of the protocol and its users?
  • Who holds the permissioned roles in reality? EOAs, multisig wallets, governance, etc.
  • If there are centralized roles, are there any plans for progressive decentralization of the system? How would that look like?

📜 Report

  • What's your preferred format to have the report? Could be a single PDF, plain-text files, GitHub issues, etc.
  • Is it necessary to deliver status reports as the audit progresses? How often?
  • Are you planning to make the report public?
🚀
Enjoyed the article? Say thanks by supporting The Red Guild in the latest clr.fund round!

What do you think about these questions? Do you use some of them already? Can you improve these, or suggest new ones ? Let us know!