Smart Contract Audits: Pentests of Web3?

Even in the midst of a bear market, the number of developers and security researchers joining Web3 still grew in 2022. This article is targeted at these newcomers, or anyone else who may be interested in how software testing processes differ between Web2 and Web3.

For many of you, pentests are a familiar part of the software development life cycle. Web2 Developer teams build an application, perform internal security checks and then, before they release to production, they get an external pentest. In Web3, the process is similar but it often leads to a smart contract audit instead of a pentest.

So, what are smart contract audits and how do they differ from pentests?

A smart contract audit is a comprehensive review of an application (smart contract) that will run on top of a decentralized network. Similar to application pentests, smart contract audits are seeking to uncover vulnerabilities in an application before they can be exploited.

Unlike pentests, smart contract audits differ in a few meaningful ways: smart contract audits are performed on open-source applications that are small enough to be manually reviewed in their entirety. They culminate in a report intended to be for both the development team and the community at large.

Whitebox vs Blackbox Testing

For anyone who has worked as an external pentester in the Web2 security space, you know that blackbox testing is the norm for application reviews. Pentesters are given access to the application in roughly the same manner as an intended user would be. From there, they try to find ways to exploit the application without direct knowledge of the underlying technology. Since pentesters are “flying blind” in this type of test, a lot of time can be spent on reconnaissance gathering and brute-force guessing and fuzzing of application inputs. There are a few reasons blackbox pentests are more popular in Web2, one being that protecting proprietary information is a common concern in traditional software development.

Contrast this with Web3 applications which are far more likely to be open-source projects. With the source code being available, there is an expectation that the code itself is reviewed during a smart contract audit. On-top of a manual review of the entire codebase, a good quality smart contract audit should also include an automated component using techniques such as static analysis, dynamic analysis, and fuzzing. This makes the typical smart contract audit much closer to a whitebox pentest.

Application Size

Another significant difference between smart contract audits and pentests is that, at the time of writing, applications built on top of blockchains are often much smaller than traditional software applications. While decentralization is one of the primary benefits of building on top of a blockchain, the built-in consensus mechanisms and resource constraints used to help achieve this property also limit the amount of compute and storage available. As a result, on-chain components of applications often number in the thousands to tens of thousands of lines of code. This makes full manual reviews of smart contracts feasible.

In comparison, it is not uncommon for Web2 pentesters to be given a few weeks to test an application that has hundreds of thousands of lines of code. In this case, it is simply infeasible to perform a thorough code-review of the entire project in the allotted time. As a result, much of the codebase has to be tested through automated or semi-automated means.

Audience of Deliverables

The last difference we will be discussing is how the deliverables differ between pentests and smart contract audits. For both tests, a report that details all findings and their suggested remediations is the typical client deliverable.

For a pentest, this deliverable is usually for internal stakeholder eyes only. This means that the target audience for a report may be limited to the organization’s executives, compliance/audit teams, and the engineering/technology teams responsible for implementing fixes. Tailored for these audiences, pentest reports often contain segments for each stakeholder with the expectation that it only needs to be understood by that stakeholder.

Web3 projects quite often post their source code for all to see. Combine this with the fact that Web3 users have an increased expectation of transparency, and it becomes unsurprising to hear that projects often wish to make their audit reports public for all to see. The audience of a smart contract audit can therefore include the entire world. This drastically changes the nature of report writing. For reports that will be made publicly available, they should be written so that they can be easily understood even by individuals lacking domain expertise.

Takeaway

If we were to try to describe smart contract auditing using traditional security terminology, it fits closest to a whitebox pentest that includes a full code-review. Just like in the traditional software development life cycle, teams should have their code tested before a release. Every Web3 development team should get at least one smart contract audit and the accompanying report should be written with the audience in mind.

If you’re interested in a smart contract audit or security advisory services, get the process started by visiting afterdarklabs.xyz or reaching out to info@afterdarklabs.xyz directly.