No matter your involvement with the blockchain space, you may have heard the term “audit” thrown around quite a bit, usually as a stamp of officially for the general security posture of a smart contract. While numerous methodologies, technologies, and phrases exist for this process — the idea remains generally the same, verifying at some level the known security posture of a smart contract. The phrase known here we use for good reason — finding unknown (or “zero day”) vulnerabilities is a bit separate from what we’re discussing here, so we’ll discuss those later.
When performing an audit looking for known vulnerabilities, various patterns are considered. Most of the technologies used in this space involve toolsets which carry out static analysis based upon formal methods. That is to say, a static analyzer will generate control flow of a piece of code — upon which formal methods can then be applied to verify conformance to the system’s expected design. As it pertains to a specific language (for smart contracts, often Solidity), static analysis presents a fantastic venue for verifying that specifications made remain valid. For example, if it is a design goal to prevent the stack memory from exceeding a particular limit, then one could apply a limit on the depth of recursion (or forbid recursive functions calls altogether). By having these indicators, a developer would have the ability of preventing (or at least detecting) potential vulnerabilities, a practice which would have proved beneficial useful in the early days of ethereum.
This process has existed outside of blockchain for several years, with many firms and solutions existing to focus upon unearthing software vulnerabilities through these approaches. While these tools are often released through various means (open source, vendor solution, SaaS), many firms focus on openly visible audits performed by engineers at the company, a practice which many in smart contract auditing companies follow regularly.
In short, these audits discuss the security posture of the smart contract — detailing elements of potential concern and where one may wish to place more countermeasures and focus. While the results of an audit do not always mean there is explicitly a security issue, findings generated through an audit should always go through further review.
Why manual audits?
Manual audits continue to prosper for the reasons detailed above — there are simply too many abstract concepts which tools cannot fully encompass. While certain logical constructs are incredibly simple to explain to a human, attempting to convert these constructs into a byte-code representation may prove difficult.
Manual audits present the peculiar intersection of knowing the right tool for the job and knowing the right way to use it — much like a baker or chef. Even with all the right ingredients, if they’re not used correctly, the dish is ruined. By knowing the right way to use the ingredients (or outside of our metaphor, how to securely code Solidity), a fantastic dish is created for all to enjoy.
Manual audits also present the added value of finding the unknown. Many of the analysis tools above succeed through verifying conditions, and finding values for which those conditions are not met. But what about when the condition being tested for is not known? How can we audit the security of something we’re not entirely sure how to structure as a formally expected design? In this space, manual audits reign key. By having people educated with the idiosyncrasies of a language, aware of the particular nuances of performing certain actions, flaws are unearthed that an automated software audit simply would not be able to uncover.
For contracts dealing with any moderate level of severity, these circumstance are why manual audits are heavily recommended — and in many cases required for listing on public exchanges.
Any time one opts to discuss security, it’s important to remember a key aspect: security is not a boolean. Security measures change over time, and gradually new vulnerabilities are discovered. Acting more as a sliding scale, audits and further security measures not only bolster the general security posture of a smart contract, having inherent familiarity with a smart contract can allow a team (and their respective auditing firm) to quickly and appropriately respond to newfound security flaws. By engaging early and rapidly with an auditing team, projects put their best foot forward, assuring their communities of a commitment to security and to the general health of the community.