Having a smart contract audit is a lot like washing your hands– do it only once, and be prepared for the consequences.
As the conversation around crypto security gets heated in response to a devastating year of losses to cybercrime –
All too often, new blockchain projects treat their security checks as something to get out of the way before their launch, never to be thought of again. This haphazard attitude is seen clearest in projects that have only had a single smart contract audit. Projects that do this seem to think that audits are more for marketing purposes than actual security. While it is true that investors and users alike should steer clear of projects that haven’t had any kind of smart contract audit, they should also make sure that the projects they invest in are taking an active, end-to-end approach to their security.
You may be wondering ‘why should a project need regular audits at all? Shouldn’t one cover the project in its entirety?’. This is a common (and expensive) misconception. While any good smart contract audit should provide a comprehensive evaluation of a project’s underlying code, it cannot evaluate any changes or updates that occur after the audit has occurred, especially any time that a change is made to the underlying code.
Of course, any tech project that never updates will soon become redundant, and this is especially true in the fast-moving world of web3. Any good tech investor or user knows to avoid a project that refuses to update and develop, yet they regularly put their money in projects that never (or rarely) update their security. To return to the cleanliness metaphor, this is like shaking hands with someone after they say they haven’t washed their hands in a year.
Take the
Now, any smart contract worth its coin would warn you of the dangers of using an oracle that determines a price by using a trading pair as these can be easily manipulated. However, since the vulnerable smart contract was outside the scope of the initial audit, auditors were not given a chance to highlight the problem.
Deus should serve as a clear warning to projects that they must treat smart contract audits as an ongoing feature in their security framework and have them audited every time a significant change is made to the project. Yet, not all audits are equal. Time and again we see well-planned projects suffer from the flaws of bad auditing.
Take the recent
In each attack, the hacker (or hackers) targeted the same vulnerability in FEG’s smart contract. CertiK’s analysis of the exploit discovered that this was due to a flaw in the token’s
Perhaps most frustratingly for FEG, is the fact that this flaw should have been detected by a smart contract audit. Even though FEG did have their smart contracts audited, the auditors should have noticed that FEG’s untrusted “path” parameter passed to the protocol and approved for spending assets of the contract. Any good audit would then flag this as a major severity and advise the project to act and edit accordingly.
There is a lesson to be learned here for the crypto-security industry– that, as hackers continue to find new and ingenious ways to exploit projects, it is no longer enough for auditors to just update their checks in response to new attacks. Instead, they must constantly be updating their technology so that when a new attack happens they are prepared for it.
Both of these exploits highlight not only the need for rigorous and regular smart contract audits but also the need for a proactive, consistent, end-to-end approach to web3 security. This amounts to a shift towards viewing security as something to be built and maintained rather than just a label to be bought and sold. This applies to the teams who need to be updating their project’s security in tandem with their technology, and also to auditing companies who need to be anticipating attacks, rather than just responding to them.