Inference - State of Security 2023

Your Inference wrapped

Another year has gone by, and we at Inference were drawn into the frenzy of drawing conclusions and analyzing our data from 2023.

What came out was our own, biased, portion of the state of security of the Web3 environment, almost exclusively from smart contract audits. We are now able to tell you how many findings we raise, on average, on each project we work on (spoiler, it’s more than 30), and what are the issues we identified the most (and the least) during this 2023. If you are interested, by all means, read ahead.

The approach

To run this statistical wonder, what we did was easy:

• We took a hot cup of a drinkable liquid
• We sat down and went through ALL OUR ASSESSMENTS completed this year
• For each observation, finding or issue we raised to our clients, we assigned them to a category
• We ran the numbers and made a beautiful pie chart, for all of you to enjoy

The categories

In order to make any sense out of it, we had to assign issues to categories. Every issue is special and unique, but it needed a label to belong to in order to run some statistical analysis at the end. These categories are, necessarily, broader than single issues, so here they are along with an explanation of what they represent, and what kind of vulnerabilities ended up in them:

• Precision: rounding up, rounding down, small portions of tokens remaining in the contract as a result of a poorly performed operation, forgetting that not all tokens are represented with 18 decimal places…
• Testing: poor tests, lack of tests for some endpoints/functionalities, complete absence of tests for the code base…
• Signature replay: this one is pretty much self-explanatory
• Low-level code optimization: all the optimizations suggested after the analysis of the low-level code, identifying cost expensive procedures and instructions that could be modified to save gas and performance
• Logic: probably the broadest category. All the issues in high-level code that meant that the contract was not behaving as expected. Poor coding, bad design, lack of security controls, this is what you would usually see ranked as Medium, High or Critical on bug bounty platforms like Immunefi, Code4rena, HackenProof…
• Documentation: all the issues raised relative to the lack of documentation regarding some feature or functionality, or potential improvements to help users better understand how the contract and the overall platform work
• Non-Compliance with standard specification: something has not been implemented according to the specification, meaning that all tools wishing to integrate with this product might run into trouble
• 0-token transfers: attempting to transfer a null quantity of tokens can lead to unexpected behavior
• Native token management: should you accept payments in the blockchain native token? Should you not? Which entrypoints need to accept them, and which definitely shouldn’t?
• Contract locked due to logic mistakes: the contract is broken and not recoverable with this kind of vulnerabilities. There is some key component of the smart contract that can be exploited and sets the contract in such a state that it is no longer usable
• Gas exhaustion: using inefficient data structures, or looping over undefined items, or performing actions whose cost can be unexpectedly high. All these can expose to the risk of exhausting gas for the transaction
• Unnecessary variables: it is better not to expand the attack surface of a contract. If something, be it a variable, an entrypoint, or anything at all, is not needed, remove if from the code
• Casting: the risk of casting a data type to a different one is a well-known one for all the IT community. Ariane 5, anyone?
• Optimization: every single suggestion to improve performance, trim unnecessary code, save gas or write better code ended up in here

Results and immediate conclusions

We totaled a sound 31.28 issues raised per project we worked on, this year. The peak was 76, while the dip was a still-very-much-respectable 12. Of course, all these numbers are affected by scope, dimension of the code base to be analyzed, complexity of the project, and many other factors. However, if we take a look at the distribution in the pie chart, there are some simple conclusions we can come to:

• Category “Logic” had to be the most relevant one, because of the kind of issues it represents. Most of our job is to find the relevant, dangerous bugs that make up this section, it could not be any other way
• Besides finding bugs, we also believe that developing sound, clear, performing code improves the overall security level of the project. Our dedication to this is clear: even though optimizing and improving the code base is not what we are hired for, we still report significantly about it: “Optimization” is the second broadest category in the pie chart, as a matter of fact
• It takes skill and dedication (and loads of patience) to look at low-level code, but almost 10% of our reports came from this. It shows, once again, the importance of deep diving into all the projects of our clients, and that no stone needs to be left unturned in the realm of security

Wrapping the wrapped

A successful year has come to an end, hopefully we can turn this into an even-more-successful one. If you would like to be one of the projects that will be a part of the next State of Security, hurry up. You have from right now until the end of 2024 to send an email to [email protected] and get your smart contract audited from us. Don’t miss out on this offer!