Smart Contract Security: Practical Automated Security Audit for Developers with Slither

Smart Contract Security: Practical Automated Security Audit for Developers with Slither
In the Web3 and decentralized applications ecosystem, a single error in smart contract code can cost millions of dollars. According to Chainalysis, more than $3.8 billion was stolen in 2022 alone through attacks on DeFi protocols. In most cases, the root cause was bugs or vulnerabilities in smart contracts that could have been detected in advance.
This is where static analysis becomes an essential tool for every developer and auditor. One of the most powerful and popular tools in this category is Slither, developed by Trail of Bits. It allows developers to detect critical vulnerabilities before they reach production, significantly reducing the risk of financial loss and reputational damage.
In this article, we'll explore how Slither works, how to run it on your project, and how to interpret the analysis results. But first, let's understand why this matters.
Context: Why Is This Important?
Smart Contract Vulnerabilities Are Real
Ethereum's history is full of cases where a single bug in a smart contract led to catastrophic outcomes:
- The DAO Hack (2016) — $60 million stolen due to a reentrancy error.
- Parity Wallet Bug (2017) — a library bug froze over $300 million.
- Nomad Bridge Hack (2022) — $190 million lost due to a lack of incoming transaction verification.
The simple conclusion: contracts (Web3) don't forgive mistakes.
Audits Are Not a Luxury, But a Necessity
If you're developing a dApp or planning a token launch, smart contract auditing is an essential part of the process, along with testing and deployment. Audits help:
- Find logical and technical errors.
- Check for vulnerabilities and vulnerable patterns.
- Ensure business logic correctness.
- Build community and investor trust.
It's important to understand: manual auditing takes time and is expensive. This is where automated analysis tools come in handy.
Personal Experience
I started using Slither while working on the Lime Pad project, a platform with extensive Solidity logic. Despite confidence in test coverage, running Slither revealed how easy it is to miss important details, especially in complex business logic.

Here are a few examples where Slither helped identify critical or potentially dangerous areas:
- Unused return — I wasn't using all the returned data from an external call. This is a potential source of errors, especially if the returned values carry important information.
- Divide before multiply — Slither highlighted a non-obvious error: division occurred before multiplication, which could lead to precision loss when working with fixed-point arithmetic. This allowed optimization of the math and avoidance of subtle bugs in calculations.
- Reentrancy vulnerability — One of the most dangerous cases—the possibility of calling the contract again during execution. Even with
nonReentrantmodifiers in place, Slither helped track the path where a reentry could occur. This is critical for any contract working with balances. - Missing zero address validation — The absence of checks for
address(0)can lead to logical errors or loss of funds. Slither identified such places, and I added input validations that strengthened the contract's resilience.
Of course, not all warnings from Slither are actual errors. Some are false positives or situations where you, as a developer, consciously deviate from a common pattern. In such cases, you can:
- Locally disable specific checks
- Explicitly indicate this in the code using annotations (
// slither-disable-next-line)
This not only helps structure the code but also makes it clearer for other developers and auditors, especially in a team environment.
Today, Slither has become a mandatory part of CI/CD in all my smart contract projects. It runs with each commit and prevents accidentally introducing unsafe code into the main branch. Minimal effort—with maximum return.
Creating a Hardhat Project for Smart Contract Development
For demonstration, we'll create a simple project using Hardhat, a popular development environment for Solidity.
npm init -y
npm install --save-dev hardhat
npx hardhat
✔ What do you want to do? · Create a JavaScript project
✔ Hardhat project root: · /Users/vorobevsa/Documents/Work/lime/slither-example
✔ Do you want to add a .gitignore? (Y/n) · y
✔ Do you want to install this sample project's dependencies with npm (@nomicfoundation/hardhat-toolbox)? (Y/n) · y
After initializing the project, compile the contracts and ensure the tests pass:
npx hardhat compile
npx hardhat test
Installing Slither
Ubuntu
sudo apt update
sudo apt install python3-pip git -y
python3 -m pip install slither-analyzer
macOS
brew install python git
brew install slither-analyzer
First Slither Run
Let's analyze the smart contracts:
slither .
Example output on the basic Hardhat example:
INFO:Detectors:
Lock.constructor(uint256) (contracts/Lock.sol#13-21) uses timestamp for comparisons
Dangerous comparisons:
- require(bool,string)(block.timestamp < _unlockTime,Unlock time should be in the future) (contracts/Lock.sol#14-17)
Lock.withdraw() (contracts/Lock.sol#23-33) uses timestamp for comparisons
Dangerous comparisons:
- require(bool,string)(block.timestamp >= unlockTime,You can't withdraw yet) (contracts/Lock.sol#27)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#block-timestamp
INFO:Detectors:
Lock.owner (contracts/Lock.sol#9) should be immutable
Lock.unlockTime (contracts/Lock.sol#8) should be immutable
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#state-variables-that-could-be-declared-immutable
INFO:Slither:. analyzed (1 contracts with 100 detectors), 4 result(s) found
Even in the basic example from Hardhat, Slither finds issues. Imagine how much it can identify in your production project. This isn't cause for panic, but rather an excellent opportunity to improve your code.
Understanding Slither's Output
When you run slither ., Slither automatically:
- Compiles the contracts.
- Runs more than 100 built-in detectors on your code.
- Outputs a list of warnings, categorized by functions and lines where they were found.
How to Interpret Threat Levels
Slither classifies each issue type by importance level:
- High — Potentially critical vulnerability
- Medium — May lead to unexpected behavior
- Low — Affects readability, maintenance, or gas
- Informational — Just useful information, not an error
Filtering Results
If you want to show only errors with a specific threat level (e.g., medium and above):
slither . --filter-level medium
To exclude warnings below medium, use:
slither . --fail-on medium
This is especially useful for CI—it will fail if it finds serious vulnerabilities.
Viewing Available Detectors
Want to understand what exactly Slither checks?
slither --list-detectors

The output will show all available detectors. This will help you understand which checks are available and configure settings based on your project's specifics.
Disabling Individual Checks
If you are confident in a specific construction and want to disable a check on a particular line, use:
// slither-disable-next-line <detector-name>
For example:
// slither-disable-next-line timestamp
require(block.timestamp < _unlockTime, "Unlock time should be in the future");
Always add a comment explaining why you're disabling the check. This is useful for auditors and future developers.
Integrating Slither into GitHub Actions
To perform automatic security checks with each commit or Pull Request, add a GitHub Actions configuration:
name: Slither Analysis
on:
push:
paths:
- '**//*.sol'
pull_request:
paths:
- '**//*.sol'
workflow_dispatch:
permissions:
contents: read
statuses: write
security-events: write
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Run Slither
uses: crytic/slither-action@v0.4.1
id: slither
with:
sarif: results.sarif
fail-on: medium
- name: Upload SARIF file
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: ${{ steps.slither.outputs.sarif }}
If the repository is private, uploading reports to Code Scanning may not work. In this case, you can comment out the upload-sarif step or make the repository public.
Addressing the Issues
Let's examine how to deal with identified problems. For example:
Warning: Lock.owner should be immutable since it doesn't change after the constructor.
Fix:
address payable public immutable owner;
The same logic applies to the unlockTime variable:
uint256 public immutable unlockTime;
Some warnings don't require fixes but deserve attention. For example, using block.timestamp:
// slither-disable-next-line timestamp
require(block.timestamp < _unlockTime, "Unlock time should be in the future");
We are using block.timestamp to ensure the unlock time is set in the future. In Proof-of-Stake Ethereum, validators can slightly influence the timestamp, but only within a bounded range. This check is generally safe for enforcing simple time-based restrictions.
So, we have:
- Fixed 2 actual issues (
immutablevariables). - Accepted 2 other remarks, explaining them with comments in the code.
Slither helps not only find errors but also document technical decisions, making the code safer and more understandable.
Useful Resources
- Slither on GitHub — The main repository with documentation, installation, FAQ, and examples.
- Slither Detector Documentation — Complete list of all available checks with examples and severity levels.
- Echidna — Fuzz testing framework by Trail of Bits.
- MythX — Cloud-based smart contract analyzer.
Conclusion
Slither is not just a linter, but a full-fledged code analyzer that finds problems that are difficult to notice during manual review. It's a must-have tool for all Solidity developers. It helps avoid critical errors and speeds up auditing.
Use it:
- On your local machine — during development.
- In CI — for automatic checks.
- In production — as part of the audit process.
Smart contract verification is not a luxury, but a necessity. Slither helps make this task simple, fast, and reproducible. Add it to your project — and let it become another layer of protection for your users, reputation, and funds.