Slither
is a simple automatic code check that detects simple vulnerabilities.
Article author:
HASHEX
HASHEX
A Developer’s Guide:
A Framework setup
A Framework setup
Published
Developers often ask how to correctly, efficiently, and securely set up a framework for developing smart contracts. This guide aims to help new developers do it quickly and conveniently.
Boilerplates speed up the process
Thanks to the use of boilerplate, you can quickly start developing a project, since the software is already ready.
List of handy pre-installed plugins:
Docgen
creation of contract documentation in automatic mode.
Coverage
is testing the coverage of smart contracts.
Prettier
code formatting to ensure proper styling.
Echidna
tests contracts based on properties.
Solhint
is a linter of Solidity code.
The Initial Repository using
Clone this repository and install the packages to start using the initial repository.
These commands can help you:
a. through yarn installing: yarn
b. through npm installing: npm install
These commands can help you:
a. through yarn installing: yarn
b. through npm installing: npm install
The next step is to create a config.js file and paste in the API keys as well as the private keys. An example is in the config.example.js file. And private keys are in .gitignore.
Try running the plugins to make sure they work. After that, you can start developing the project.
Slither
The plugin performs static analysis of the smart contract code to find potential vulnerabilities. Simple vulnerabilities like unwanted external calls or reentrancy can be easily found with this tool.
Docgen
This plugin simplifies writing documentation. Anyone can easily figure out how the contract works by using the documentation as it is converted to an .md file instead of (NatSpec) in the contract files.
Coverage
The plugin makes it easy to test contracts. It looks for lines of code that are not covered by tests, which may contain a vulnerability or some kind of error.
Prettier
We recommend running this plugin before deploying or committing. It helps maintain the quality of the code style and the appearance of the repository at the highest level.
Echidna
This plugin is needed to test contracts based on properties. For the plugin to work, it is necessary to write contracts that will be tested. You can find several examples in the /contracts/echidna-test folder.
The plugin tries to break the contract invariants during the test, which must be fulfilled all the time. This is the verification of the contract. The plugin calls contract functions by calling the functions in a different order. But it is worth remembering that this is not a panacea, but just a standard test that absolutely all combinations cannot check. Therefore, sometimes Echidna may not detect a vulnerability.
The plugin tries to break the contract invariants during the test, which must be fulfilled all the time. This is the verification of the contract. The plugin calls contract functions by calling the functions in a different order. But it is worth remembering that this is not a panacea, but just a standard test that absolutely all combinations cannot check. Therefore, sometimes Echidna may not detect a vulnerability.
Solhint
The plugin helps to check the security of the code in terms of basic recommendations and generally accepted rules for developing contracts.
0XGUARD
Top Solana Vulnerabilities
Solana is a widely popular blockchain and attractively low transaction fees are certainly among the reasons developers choose it. Among Solana-based dApps are some of the most popular and valued projects. This is why knowing Solana and its weaker points is now more necessary than ever.
DSA
5 Most Common Vulnerabilities You Need to Know in 2022
The blockchain industry is making big steps toward achieving security for all participants, however, it’s still not a done deal just yet. Hackers come up with new ways to exploit vulnerabilities and steal funds. Sadly, this lowers the trust in blockchain technology.
Comments
2Pinning the compiler and dependencies makes the setup easier to reproduce. The audit environment should use the same versions as the release build. I would keep the build command beside those versions. A fresh environment should be able to produce the same review target.
A small failing security test would be a useful companion to the setup steps. It would show that the harness can detect the behavior it is meant to check. Could the example first run against an intentionally broken fixture? Then the same test could run after the missing check is added. Keeping both results would explain what the security test actually establishes.
Leave a comment
Share a question or observation about this article.