vulnerability-scanning

Vulnerability Scanning

Overview

Find security vulnerabilities in an EVM contract and return a severity-rated finding set. A pattern match is a hypothesis, not a finding. Every candidate must be confirmed reachable and un-neutralized before it is reported.

The Iron Rule: never report an unconfirmed candidate as a confirmed vulnerability. A false positive that triggers a needless rewrite is its own kind of harm; an unconfirmed-but-flagged item must be labeled as such.

When to Use

• Security-auditing Solidity/Vyper/bytecode before deployment or review
• Symptoms: "is this safe?", "audit this", suspected reentrancy, access-control, tx.origin, delegatecall, selfdestruct, unchecked calls
• Producing a severity-rated report for a contract or PR

Do NOT use for: gas optimization (use gas-optimization) or arbitrage/economic analysis (use arbitrage-analysis).

Workflow

Four reasoning steps, in order. You perform them; they are not scripts.

1. Seek — Read the contract and match it against reference/patterns.md. List every candidate with file:line and its SWC id.
2. Innovate — Beyond the library, reason about contract-specific risks (storage-layout collisions in proxies, oracle manipulation, integer edges). Propose a remediation per candidate.
3. Execute — Confirm each candidate per reference/severity-model.md: check reachability and existing guards. Utilize Action-State Differential Verification (taking pre- and post-trigger state snapshots in a local fork like Foundry) to definitively prove exploitability. Corroborate with tools (Slither, Aderyn, Echidna) if available. Assign final severity; drop neutralized candidates.
4. Manage — Emit the report: each confirmed finding with severity, location, SWC id, impact, and remediation. List dropped candidates and why. State explicitly if Slither was unavailable.

Verification

• Use Bug-Context Extraction (BCE) to isolate focused function-level slices before executing complex tests.
• For static analysis, prefer the MCP tool evm_scan_vulnerabilities (schema-validated findings with code snippets; supports severityFilter and detectors for focused scans). Fall back to raw slither <path> or aderyn only when the MCP server is unavailable. Reconcile findings either way.
• To confirm reachability of a candidate on a local fork, prefer evm_trace_call — the structured call tree shows whether the vulnerable frame executes, what it calls, and where it reverts.
• For proxy storage-collision candidates, use evm_inspect_storage_layout on both implementations and diff the slot assignments.
• For dynamic verification, leverage Foundry/Echidna in a Generate-Repair-Execute (GRE) loop to compile and test Proofs of Concept — the MCP tools evm_compile_and_diagnose and evm_run_tests (structured failures with fuzz counterexamples) drive this loop; fall back to raw forge when the MCP server is unavailable.
• When tools/Foundry are absent, explicitly state so, fall back to manual review, and mark findings as manual review, not tool-confirmed. Never present manual review as tool-confirmed.