Today, we’d like to continue a series of articles in which we’ll examine new promising tools and learn how to use them, as well as their advantages and disadvantages. We understand and respect your limited time, therefore we created a specific research article with nothing superfluous only for you!
Authors: Nikita Kirillov, officercia.eth
This series will only cover aspects of auditing, bug bounty & white-hacking that are not covered elsewhere. We will additionally look into Semgrep rules for smart contracts based on DeFi exploits and compare them to our own set of custom Slither detectors, Slitherin!
First and foremost, we want to express our heartfelt gratitude to the people who created the SemGrep tool, everyone who supports it, Decurity and the authors of all reference materials! And today it will be made available to you today, dear readers!
SemGrep is a lightweight static analysis tool for a variety of programming languages. It can detect bug variants using patterns that resemble source code. We’ll be talking about Decurity’s custom set of SemGrep rules for smart contracts based on DeFi exploits.
We finished our own research a few months ago; in many ways, this article will rely on information from our previous article, so read it if you haven’t already:
That said, we believe that no one doubts that the foundation of any secure implementation is a unique approach to writing code. As a result, this article will focus solely on those aspects that can be extremely useful in making your code safe and secure. You’ll also discover a bonus part at the conclusion of this article with a ton of great tips, and we highly suggest reading it independently for a clearer understanding!
Therefore, below you will see not a typical article but a systematization of knowledge (SoK), in which I will rely on authors that I myself trust in this matter and, of course, our pessimistic.io auditors. By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here!
The idea to compare the two tools did not come about by chance; in a chat devoted to the development of Slitherin, Sam Bacha from Manifold Finance asked us which tool is better. Following that, we felt compelled to bring it up!
So, in this post, we will only look at the most important aspects of using the following repository:
So, you will have to deal with 48 rules, which we have divided roughly into 3 types and 2 subtypes:
3 Types: Security, Gas Optimization, Best Practices;
2 Subtypes: There are general ones that fit any code base. There are also specific ones that are inspired by attacks on protocols;
Advantages: Being updated frequently;
Install semgrep;
Make a clone of the library repository;
Run:
semgrep path_to_contracts --config path_to_lib_rules;
Contracts must compile;
Files in .gitignore and .semgrepignore are not analyzed by default;
On Linux, run with sudo;
It performs a grep search (by writing custom patterns);
In essence, it is similar to the tool we discussed above — SolGrep. Roughly speaking, it’s the same as SolGrep, only with ready-made (built-in) rule-creation patterns.
For beginners, it is recommended to start with the Semgrep Cloud Platform because it provides a visual interface, a demo project, result triaging and exploration workflows, and makes setup in CI/CD fast. No code has been uploaded to the cloud; scans are still being done locally. You can also use the CLI without logging in and navigate the terminal output to run one-off searches.
Following our prior research, it appears that we can use it to the following:
For writing various detectors (detectors that cannot be implemented using a Slither tool);
To perform an in-depth search for syntactic constructions (You can use this when performing an initial project inspection. For instance, to quickly determine how many external functions, libraries, and so on are used in a given project).
Lastly, a few words about our old (deprecated) tool, SmartCheck — which can serve as a reinforcement of what we’ve just discussed. Even in its raw form, it shows good results, and second place in ToB’s article is not bad for a tool we stopped supporting three years ago… it should be noted that this is just one more tool in our toolbox of working methods.
However, let’s move on to our today’s topic and compare Semgrep rules by Decurity with our own toolset of custom detectors — Slitherin. We recently conducted some more research on this subject and came to some interesting conclusions. So, in the coming articles, we’ll look into this as well!
So, for the test, we took both tools and tested them on each of Slitherin’s 22 test contracts. On 22 Slitherin test contracts, the Semgrep toolset shown 16 hits out of 22. The entries were mostly optimization-related ones:
In the end we came to the conclusion that there are not so many overlapping rules with Slither and Slitherin and the search technology in Semgrep is completely different, so for better analysis you should use both tools, especially if you take into account that it is easy and fast — you can significantly raise your audit quality level!
It is important to note that 16 positive results in this case does not mean that 16 rules overlap — not at all, we found only two such similar rules. We will definitely compare 10 000 lines of Solidity code in our next article because it will take a lot of resources and space at the moment.
You may even want to write your own rule, in which case, here’s our advice on how you can do it quickly:
To add, however, we are pessimistic about the use of AI in development at all stages (such tools cannot be 100% trusted) particularly when working with RegEx, but early feedback indicates that it can significantly ease life. Use this tip for writing your own Semgrep rules & Slitherin detectors!
The most important message we want to send you today is as follows: Both tools work well and allow you to easily filter bugs and customize search, but they are fundamentally different in their nature and the way their code is written. In any case, we recommend using both solutions!
Anyway, first of all we advise you to check out our own solution as in recent months we have been actively developing our own Slither detectors to help with code review and audit process.
More recently, we have released our own detectors and we encourage you to use them for your initial internal audit, particularly the read-only Reentrancy detector:
If you have any further questions or suggestions, please join our Discord Server or Telegram chat. We hope to see you there, and we intend to support the community and its initiatives.
Please let us know if you have discovered an issue/bug/vulnerability via our custom Slither detectors. You may contact us via opening a PR/Issue or directly, whichever is more convenient for you!
The main point we want to make clear to you today is this: The nature and style of their code are fundamentally different, but both tools function well and let you quickly filter bugs and tailor search. In every instance, we advise employing both solutions:
We hope that this article was informative and useful for you! Thank you for reading! The bonus part for today will include an unexpected life-hack for auditors:
Did you know that you can utilize VSCode on your iPad (preferably with a Magic Keyboard) using the Blink App? If not, watch the following video! We hope you find this tip useful in your work!
What instruments should we review next? What would you be interested in reading about? Please leave your comments, we will be happy to answer them, and the best answers and questions may be included in the next article!
Make sure to read the rest of the series:
By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here. Let’s get in touch: gm@pessimistic.io!
Support is very important to me, with it I can do what I love — educating users!
If you want to support my work, please, consider donating me:
0xB25C5E8fA1E53eEb9bE3421C59F6A66B786ED77A or officercia.eth — ETH, BSC, Polygon, Optimism, Zk, Fantom, etc
4AhpUrDtfVSWZMJcRMJkZoPwDSdVG6puYBE3ajQABQo6T533cVvx5vJRc5fX7sktJe67mXu1CcDmr7orn1CrGrqsT3ptfds — Monero XMR