Slither Integration with DefectDojo

Slither Integration with DefectDojo

Slither is an open source static analysis framework for Solidity smart contracts, developed by Trail of Bits under its Crytic project. It compiles contracts and runs a large set of detectors for issues such as reentrancy, unprotected self-destruct, missing zero-address checks, risky low-level calls, and outdated compiler versions. Each result carries two ratings: an impact (High, Medium, Low, Informational, or Optimization) and a confidence level. Slither can write its results as JSON, which DefectDojo imports.

Slither Integration with DefectDojo

We run Slither on every contract change because a deployed contract is hard or impossible to patch, and the cost of a missed bug is measured in funds rather than downtime. Slither output in a terminal is easy to skim past, especially once a codebase has a dozen accepted informational results. Importing Slither reports into DefectDojo turns each detector hit into a Finding on the Asset for that protocol, with the file, line, and detector named, an owner, and a status that persists between runs. Accepted results stay accepted, and a new High shows up as new.

Why Slither Matters

Smart contracts combine public code, irreversible deployment, and direct control of value. Static analysis before deployment is one of the few controls that runs on every change.

• Slither's detectors target issues specific to Solidity and the EVM, such as reentrancy and dangerous use of delegatecall, that general-purpose SAST tools do not model.
• It is fast enough to run in pull request checks rather than only in pre-audit reviews.
• Separating impact from confidence lets reviewers decide whether a result is serious and how likely it is to be real as two different questions.
• Results name the contract, function, and source lines involved, which gives a developer a precise starting point.
• Every detector links to documentation explaining the issue and the recommended fix.
• External audits are periodic. Slither results need tracking between audits so known issues do not get lost or reintroduced.

Advantages of This Integration

What we gained by sending Slither results through DefectDojo:

• Impact-based severity. Slither's impact maps directly to DefectDojo severity, so High results fall under the High SLA. Confidence is kept in the description instead of being blended into severity.
• Detector-level identity. The detector name (for example reentrancy-eth) is stored as the tool ID and is part of deduplication, along with file path and line.
• Documentation one click away. References link to the detector's entry in Slither's documentation.
• History across commits. Reimporting each run into the same Test mitigates results that were fixed and reactivates any that return.
• Documented exceptions. Informational and Optimization results that the team has reviewed can be risk-accepted or marked false positive once, instead of being read again on every run.
• Audit preparation. Before an external audit, the team can export the open Findings and their history, so auditors see what was already found and how it was handled.

How This Integration Works

DefectDojo imports Slither output with the Slither Scan scan type.

1. Produce a JSON report. From the project root, with a matching solc available (solc-select can manage compiler versions):

slither . --json slither.json

Slither also works with common development frameworks, so pointing it at the project directory is usually enough.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Slither Scan, and upload the file. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Slither Scan" 
  -F "file=@slither.json" 
  -F "product_name=lending-protocol" 
  -F "engagement_name=CI" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Slither Scan" 
  --report-path "./slither.json" 
  --product-name "lending-protocol" 
  --engagement-name "CI" 
  --auto-create-context

3. Reimport on every change. Send later reports to /api/v2/reimport-scan/ against the same Test so the history for each contract stays in one place.

Data Granularity: What Gets Imported

One Finding is created for each detector result in results.detectors.

Use Cases

In pull request checks: A CI job runs Slither on each pull request and reimports into a Test per repository. Reviewers see only new results in DefectDojo, and a release gate can query for open High Findings before a deployment.

Between external audits: A protocol team tracks Slither Findings continuously and records triage decisions in DefectDojo. When the next audit begins, auditors receive a list of known issues with their status, which saves time on both sides.

Across several protocols: An organization with multiple contract repositories imports each into its own Asset. Security leads can compare open High and Medium Findings by protocol and see which teams are keeping up.

After a compiler upgrade: When a project moves to a new Solidity version, a fresh Slither run and reimport confirm that compiler-version results closed and show whether the change introduced new detector hits.

Operational Tips

• Line numbers are part of the deduplication hash. A refactor that moves a function can mitigate the old Finding and open a new one for the same issue, so review mitigated and new Findings together after large changes.
• Slither Findings also store Slither's own result ID as the unique ID, but the shipped deduplication algorithm is hashcode, not unique ID.
• Confidence is only in the description. Low-confidence High results deserve a quick check before they trigger escalations.
• Informational and Optimization results both import as Info. Use minimum_severity=Low on import if your team does not want to track them, or tag and filter them instead.
• Titles include line ranges from Slither's description, so search by detector name (the tool ID) rather than by title when looking for every instance of an issue.
• Tag imports with the commit or release (for example tags=v2.1.0) so Findings can be tied to the contract version that was actually deployed.
• Pin the solc version in CI to match your contracts, so a compiler mismatch does not produce a failed or partial run that looks like a clean report.