You've invested the time, familiarized yourself with common attack vectors, and participated in CodeHawks First Flights. Now, you are ready for your first real audit.
You sit down and clone the contest repo. Next thing you know, you're staring at 10,000 lines of overbearing confusion, and the job application in your trash is looking appealing again.
It's vital to approach large or intimidating tasks systematically. Breaking the process into compartmentalized chunks will make it far more approachable, allowing you to recognize progress as you go.
Here, we will outline 10 steps a security researcher can take to mitigate the question, 'Where do I start?'
Your first step should almost always be to examine the documentation. Understand the audit's scope and grasp the business logic that underpins the protocol.
This foundational step is crucial. Skipping it is like navigating a labyrinth without a map. The documentation is your map, offering insights into the protocol's intended functionality and objectives.
If you can, ask the development team questions and speak with them about their architectural decision-making. The more insight you gain into what a protocol is supposed to do, the easier it will be to spot when it is doing something else.
Armed with this understanding, it’s time to…
Your next action should be to test drive the protocol and clone the audit repo locally. Most protocols being audited will provide the steps required to build in a local testing environment.
Try out the primary functions of the protocol and familiarize yourself with its flow when working under ideal conditions. Next, compile the contracts and play with the commands shared in the README.
The more familiar you are with how things should work properly, the more easily you can find bugs.
With this familiarity, turn your focus to the protocol's test suite.
Tests are the protocol's heartbeat, revealing what the developers value and consider critical.
Examining test coverage can identify the protocol's more vulnerable segments. This step highlights the areas well-trodden by developers and illuminates the darker, perhaps neglected, corners of the codebase by identifying omitted tests.
Look closely at the existing tests and be prepared to write more to cover any overlooked blindspots.
Note: Each framework is different, but the Foundry command forge coverage will give you an at-a-glance view of areas where tests have been written. Use this as a guide to determine how much time and effort a protocol has spent testing its codebase!
Next, gain a visual perspective of how the protocol's components interact.
A visual representation of how the “seemingly disparate” parts of a protocol interact can often be helpful.
Creating (or leveraging tools to create) protocol diagrams is a great way to understand how one part of a protocol may affect another. Excalidraw is an amazing (and free) online tool for creating your own simple diagrams.
Tools like Solidity Metrics provide valuable insights by generating diagrams that highlight which areas of a protocol are external or involve state changes. As a security researcher, this can help you concentrate on the most vulnerable sections.
With a clear understanding of the structure, it’s time for…
Assess the stability of the protocol — literally.
Check which version of Solidity is in use, as each version carries its own set of known bugs and idiosyncrasies. Determine if the protocol is using up-to-date versions of Solidity, and if not, delve into understanding why.
Older versions may be suitable depending on the protocol's scope. Still, understanding their use and the potential impact of version choices on the code is essential for identifying possible vulnerabilities.
So, it’s best to stay up-to-date with Solidity’s version changes.
Then, it’s time to leverage industry insights to deepen your analysis.
Solodit is a comprehensive database of past bugs and vulnerabilities discovered in smart contracts. So, it’s wise to navigate to Solodit and familiarize yourself with vulnerabilities found in similar protocols.
Solodit consolidates 15,500+ verified security review findings across the industry into one convenient location. It provides unparalleled knowledge into the weaknesses in code across web3 and is an invaluable tool for any auditor serious about their craft.
Additionally, leverage Solodit’s audit checklist, which provides a comprehensive list of common attacks to look for, questions to ask, and examples to study.
Next, zoom in on the protocol’s key components to uncover its weakest points.
Great places to start assessing a codebase are its more vulnerable points - the weakest links.
These include:
All of these are potential vectors for malicious attacks. Understanding these elements is crucial for identifying security risks.
By leveraging tools like Solidity Metrics (mentioned in #4), you can visualize where these areas of interest reside in a protocol.
However, remember to use automated tools to complement your manual review.
While using auditing tools such as Aderyn or Slither might not uncover unique or critical findings, they are invaluable in pinpointing weaker areas of the codebase. Static analysis tools offer a preliminary sense of where vulnerabilities might lie, guiding further manual inspection.
As these tools improve their ability to detect vulnerabilities, security researchers can spend more time narrowing their focus on more severe findings.
Implementing static analysis into a security workflow is something protocols should do by default before inviting private or public auditing!
With this groundwork, it’s time to dive deep into the code for a line-by-line review.
This is the “getting your hands dirty” part! Apply what you've learned about the protocol and assess each function's contribution to that goal.
Compare the intended versus actual functionality of code segments. Often, vulnerabilities aren't hidden in complex code but in mismatches between the expected business logic and the code's execution. This analysis can reveal subtle bugs that could have profound implications.
Leverage auditing methods like "The Tincho" or an auditing checklist (courtesy of Tincho Abbate and Hans Freise respectively) to ensure a thorough, systematic codebase assessment.
Finally, present your findings with clarity and precision.
Your audit report is your magnum opus. Identifying bugs is not enough. You must convincingly demonstrate their existence and potential impact.
Employ proofs of code (PoC), articulate titles, and thorough documentation to make your findings impossible to ignore.
Use report formats, such as this basic template for competitive scenarios or this more in-depth version for private audits.
These ten steps provide a clear starting point for tackling any new audit. Large codebases can feel overwhelming, but using a systematic and structured approach allows security researchers to work efficiently and focus on the details without losing sight of the bigger picture.
Remember:
Q. How do you eat an elephant?
A. One bite at a time.
If you want to dive deeper into smart contract security and auditing, check out Cyfrin Updraft - the ultimate learning platform for smart contract development and auditing.
