The world of decentralized finance (DeFi) is an exciting space to be in. It can seem like every day there’s someone or some initiative introducing a new protocol, upgrade, or some other creative, new way of putting various DeFi building blocks together. Nevertheless, this also increases the need for prudent smart contract security, and smart contract audits.
Anyone familiar with the DeFi sector will have seen the massive influx of capital to DeFi projects in 2020. Unfortunately, along with all that excitement and the $13.5 billion flowing through the ecosystem (see DeFi Pulse), DeFi has also proven attractive for some opportunistic hackers. There have been several highly publicized hacks in DeFi in 2020. We’ve already covered some of these, such as the bZx hacks, the Harvest Finance hack, the Eminence hack, the Balancer hack, and others.
Suffice to say, DeFi can be an interesting and highly profitable space to be in, but it’s also a risky one. As such, making smart contracts secure is more important than ever. That’s because DeFi is built on the Ethereum blockchain and its protocols use smart contracts. Hence, any platform in DeFi that wants to mitigate risk will need to undergo a secure smart contract audit.
However, any discussion about smart contracts should be prefaced with learning more about the nature of smart contracts. Enroll in Ivan on Tech Academy, one of the largest online blockchain education platforms in the world and get access to dozens of in-depth blockchain courses, explaining all you need to know about blockchain technology, DeFi, smart contracts and much more!
What Is a Secure Smart Contract Audit?
Practically speaking, a secure smart contract audit is the process of investigating code. Auditors perform secure smart contract audits to find vulnerabilities in Solidity contracts before they go live.
Now, before we get ahead of ourselves, don’t be one of those people who think that just because a DeFi protocol has been audited means that their code is bulletproof. Perfection is never the case. A secure smart contract audit just means that an auditor has inspected the code and the development team has revised it.
What Does a Secure Smart Contract Auditor Do?
Essentially, smart contract auditors check code for any bugs, vulnerabilities, and risks.
With all the money at stake in DeFi, security is a key component to gaining trust. Smart contract auditors are therefore a crucial component to establishing trust amongst users, investors, the community, etc.
A secure smart contract audit for a DeFi protocol will be similar to a regular code audit. Auditors just need to vet the code before it goes public.
The DeFi Creator’s Responsibility
DeFi creators have a responsibility to their users to provide them with the most secure products available. We know that the Ethereum blockchain is secure and it’s immutable. That’s because an enormous amount of computing power goes into securing it. But, as smart contracts are self-executing, it is crucial to find their security risks before a hacker does.
So even though the Ethereum blockchain is secure, that doesn’t mean that all the decentralized applications (dApps) running on it are ipso facto secure. They need to be tested.
These dApps interact with the blockchain through smart contracts. And smart contracts with buggy code can lead to security risks. Furthermore, because dApps in DeFi control large amounts of funds, bugs can cost users millions of dollars.
With your standard type of software, bug-free code is nice to have. With DeFi it’s imperative, and security audits help make sure your code is secure.
A Standard Smart Contract Audit
If you work with a smart contract auditor, you will probably first notice their disclaimer. This is where they state that the audit is not legally binding nor does it provide any legal security guarantees. The purpose of the disclaimer is to set expectations that the audit is about fostering a discussion grounded in security best practices.
The auditor will then explain who they are in the space and why they can be trusted to conduct this security analysis. They will also provide an explanation and overview of their smart contract auditing process. This process can also include white-hat, penetration testing (pen testing) styles of attack to probe for soft spots in the code.
When auditors find vulnerabilities, they will list them based on their severity:
- Critical Vulnerabilities
These can do heavy damage. Even an innocent mistake like buggy code can be critical if it is flagrant enough to allow hackers to steal tokens.
- Major Vulnerabilities
These types can cause limited damage. For example, this type of issue could allow others to modify a variable in the code.
- Minor Vulnerabilities
These issues can cause minor problems, but don’t pose a threat to the smart contract’s stability.
The Steps of a Secure Smart Contract Audit
Writing secure smart contracts is not easy. That’s why undergoing an independent audit is a must for any serious DeFi project. The DeFi industry is becoming more sprawling by the day, and can seem hard to keep track of. Smart contracts underpin a massive percentage of the various DeFi solutions out there, and in order to understand the need for secure smart contract audits, it’s a good idea to familiarize yourself with smart contracts in general. Enroll in Ivan on Tech Academy to learn more about smart contracts, and get 20% off with the code BLOG20!
Some people think a smart contract security audit is a simple code review. However, it goes deeper than that. The goal of the audit is to correct design issues, find security vulnerabilities, bugs, misconfigurations, and/or just expose a poor security policy in general.
The top auditing firms follow a strict methodology, while others may play it looser. However, since the DeFi space is still so new, there is no strict rulebook for the sequence of events expected to take place. Nonetheless, a serious smart contract audit will likely take similar steps to the following:
1. Project Familiarization
Before auditors start digging into the code, they will want to explore the architecture and the purpose of the smart contract itself. Whitepapers can be helpful, but oftentimes the auditors will need more detailed reports. Or they may need the development team to sit down and explain their design and architecture. Without this, the auditors won’t know what is working as intended.
2. Code Freeze
When auditors ask when the “code freeze” will happen, it means they want to know when the code has been finalized. When the code is in its final draft stage, it means that the developers have already looked at everything and have made their best efforts to fix any undesirable code.
The first step will be to ensure the integrity of the audited code. An auditor will need a way to fingerprint and identify the exact source code version in their report. This can take the form of an SHA-265 hash, deployed smart contracts, and a mainnet contract address.
Version Control
This isn’t that different from traditional software development. The Release Candidate (RC) is a term for the final stage before launch. An RC does not change and it is managed by a version control system. In the case of DeFi, that version control system exists on the Ethereum blockchain.
This gets a bit technical, but there is a method to the madness. Auditors don’t want to start working only to find the developers making changes to the code halfway through the audit.
Also, users must be reassured that security has been verified and that the code behaves as documented in the audit. It’s the auditor’s responsibility to ensure that the audited version is what the community gets to use.
That’s why auditors like to have the mainnet addresses for the release. Otherwise, one never knows whether the audited code on Github that passed with flying colors will end up as the code that gets deployed. The goal is to prevent developers from changing audited code (whether accidentally or on purpose) before they deploy it.
3. Code Review
In the code review step, auditors look at the code to understand more aspects of how it works. This can be the design and which libraries the developers used. The developers can help auditors by giving them insight into how the project should function.
Checking the test coverage (how much of the code is covered by tests ) is another important step. Greater test coverage means that fewer bugs will make their way through the process.
High-quality assurance auditors may aspire for 100% coverage, but 85 to 90% is considered reasonable.
4. Automated Analysis
Automated tests are a quick and easy way to detect bugs in a secure smart contract audit. This is why auditors will often use automated bug detection software first to scan contracts for vulnerabilities.
Developers often use these same tools early in the process as well. However, auditors can still come up with some useful findings afterwards.
Of course, automated analysis tools are still in their early stages of development. That means they can report false positives. So, that’s why it’s always a good idea to manually review the code as well.
But as an initial step, a test suite is a quick way to start. If the contract passes an automated analysis, it’s unlikely there are major issues to follow. However, if a high number of tests fail, the auditors may need to pause to give the developers time to rework the codebase.
5. Manual Analysis / Functional Analysis
This analysis involves best practices regarding security. It also applies the usual software guidelines such as commenting code, code structure, naming variables, and the avoidance of replicated code.
Automated test suites are great for helping to pinpoint common vulnerabilities, but they’re not intuitive. They aren’t great at uncovering the developer’s intentions. So, while the code may be free from bugs, it can still lack the intended functionality.
Auditors need to make sure the code behaves the way it’s supposed to. At this stage, they will be verifying the math as well as access and permission management.
So, manual inspections are necessary for not only uncovering more vulnerabilities but to help determine intended functionality. It’s also nice to have multiple auditors look at the code and then compare their findings afterward. This minimizes the chance of one auditor overlooking an error.
6. Known Vulnerability Analysis
This phase is what most people consider a secure smart contract audit to be – a line by line audit against a list of vulnerabilities. Some of the better-known ones are:
- Denial of Service (DOS) Attacks
- Gas Limit Issues
- Insecure Random Number Generation
- Overflows and Underflows
- Reentrancy Attacks
- Timestamp Dependencies
- Variable Shadowing
If the auditors find issues they will list them under similar headings mentioned above: Critical, Major, or Minor, depending on their severity.
7. Live Test / Pen Testing
This can involve auditors deploying the code on a local testnet to run their tests or perform their white-hat attacks.
8. Gas Usage
After locking down the smart contract’s security and functionality issues, auditors will need to look at their gas efficiency. This test is conducted by an automated gas estimation and another round of line-by-line code analysis.
9. First Audit Report
After all the steps are complete, the auditors will write up a report for the client with their findings and recommendations.
10. Review of First Audit Fixes
Audits rarely turn up nothing, so the process usually goes at least two rounds. After the client has fixed the issues from the first round of testing, they can submit a new version of their code. Auditors review each fix to ensure they’ve resolved the issue without adding any new problems.
11. Final Audit Report
The auditing team will compile their report for the project team after the automated analysis and manual code review and testing is complete. After all the fixes are in, the auditors will update their report with their final version. This will include all the issues found, the fixes that were applied, and the eventual outcome.
By the end of the audit, the project team should fully understand all the issues detected, how to patch them, and how to integrate the recommendations into their final project. This is the best way to ensure that no more vulnerabilities exist.
Overview of the Secure Smart Contract Audit
Although auditing processes will vary depending on the team, reputable auditors will follow some sort of strict methodology. And in their haste to launch the latest and greatest DeFi protocol, the founders, the developers, and their communities need to realize that secure smart contract audits take time.
That’s why it’s best for teams to prepare in advance and not just try to slap on an audit at the last minute before launch.
More thorough developers will want to get auditors involved from the start. That way they can help steer the project through all the phases of smart contract development – from beginning to deployment. OpenZeppelin has a process for this.
However, there is no perfect, step-by-step guide to the auditing process. Especially with DeFi still in its infancy. Standards are under development and nothing is set in stone yet. So, different auditors will follow different processes than the sample above.
What’s more, it’s not unusual for development teams to disagree with the auditor’s findings especially if they appear too subjective. The main thing is that both sides get the issues out in the open for everyone to see and deal with.
This kind of collaboration, even though it can end up a bit combative or contentious, can reduce the likelihood of failure just by team members coming together.
Do you want to become a smart contract auditor? No matter what level you’re at, it’s never too late to start your blockchain education. Visit Ivan on Tech Academy today to begin!
Author: MindFrac
