Securing Solidity Smart Contracts
Setting up some free security tools, to prepare a security Audit
Since we want to build a sustainable, and long term ecosystem at Frak, securing the Smart Contract is a big concern for us.
From the init of the repository, to the development, and the first run on a testnet, we needed to keep security in mind.
I will review some base security tools we have set up, to help us testing our contracts when we were developing them, and to prevent some bad surprise during the security audit.
Tools we will use
Slither : Static code analysis, erc20 compliance check, and many more useful features
Mythril : EVM Bytecode analysis
Manticore : Symbolic execution tools
Echidna : Contract fuzzing
Of course, this is just a small portion of all the security tools existing, but I will focus on this one first, because they are free, relatively easy to set up, and can prevent a lot of security issues if rightly configured.
Each one of this tools come with its own docker images. We are going with docker to prevent us from installing all the python dependencies of this tools on our machine, but also to ease the set up for new developers, and ease the automation of test in a CI pipeline.
Including the tools inside the project structure
We decided to go on a tools folder, at the root of our hardhat project, that will contain all the scripts necessary to run each tool individually, loosing a bit on performance, but gaining a lot on versatility, upgradeability, and readability.
Like that, we can add as many tools as we want, disable or remove some older ones etc. Let see the organisation inside our tools folder:
With that structure, we can have some shared element for each one of our tools. Especially useful for echidna, that require a Solidity test file for each contract we want to test, with some basic configuration.
Sample tools configuration
Let’s jump into the script for Mythril to start with a small example:
We first check that the scripts is executed from the root folder of the project, like that we are sure that we are in the right folder and we can access the contracts with no problem.
Now let’s take a look at our docker command:
- We are using mythril/myth docker image directly (instead of trailofbits/eth-security-toolbox that embed a lot of security tools), to get the latest version of mythril, and to have a lighter and faster docker image for this run.
- We want it to remove the file at the end of the build ( — rm) to prevent conflict between contract analysis.
- Then, we bind the current path to the docker container ‘/src’ folder (-v `pwd`:/src)
- And then, go directly into the src folder ( — workdir=/src mythril/myth).
After, it’s just a question of configuration for mythril:
- Increase verbosity level to get more details (-v 4)
- Increase the depth of the analysis, it will take a bit longer to run, but you will potentially cover more branch of you’re contract code ( — max-depth 50)
- And give some info for the soc compiler ( — solc-json tools/mythril/remapping.json). In our case this json contain the remapping for the OpenZeppelin dependencies, and enable the optimizer.
So now, from the project root, you can start mythril with a simple : ./tools/mythril/mythril.sh
For the others tools, the docker configuration is similar, and then the tools configuration depend on the tools themselfs. If you want the configuration for the other tools, don’t hesitate to ask! Our repository is still private but will go public soon.
Launch all the scripts, and preparation for CI
To launch all the scripts at once, just create a new bash script that will run all the tools you want, and write the output of each script into a separate folder (for clarity after the run).
In our case, we run Slither, Mythril, Manticore and Echidna, our script look like that :
Since Mythril, Manticore and Echidna can take a very long time to run (especially in our case with more than 10 contracts), and we don’t want our developers to wait more than a day or two just waiting for the run to complete, before they can ensure the security checks are successful.
To be able to run this script on another machine (in our case it’s an ec2 instance), we created a new script to run this script with nohup:
And now, with all of that, you can run your security analysis scripts and let them explore all of the contracts you want!
Security advice
These tools are great to prepare yourself before a security audit, but the best way to have secured smart contracts is to learn about all the security guidelines and common failures in the first place.
A good entry point for best practices around contract: https://consensys.github.io/smart-contract-best-practices/
And secondly, all these tools are great, but they aren’t as powerful as a qualified security audit firm. So it’s a good premise in term of security, but you should always consult a security audit firm before going live.
Other tools
We only cover some base security tools, not really intuitive but really efficient.
If you are searching for something more graphical, you can take a look at MythX (it will handle basic security runs and a few fuzzing tests), and Diligence Fuzzing (a lot more easier to understand and to set up than echidna).
If you are searching for really advanced security tools, you can check Karl and Theo from cleanunicorn.
If you want to continue the conversation, you can connect with us @frak_defi on Twitter or on Telegram.
Be informed when a new article is published by following us on Medium. If you liked this article, please clap for it (up to 50x) to let us know you enjoyed it. It’ll mean a lot to us.
