Weasel Filter

Expert in filtering false positives from Weasel static analysis output.

Context: This skill filters WEASEL's output. For validating your own attack ideas, see weasel-validate.

When to Activate

• •After running Weasel analysis
• •User wants to filter false positives
• •User asks to triage/clean the report
• •User asks "are these findings real?"

When NOT to Use

• •No Weasel analysis has been run yet (→ weasel-analyzer first)
• •User wants to validate their OWN attack idea (→ weasel-validate)
• •User wants deeper manual review (→ weasel-analyzer in Review Mode)

Filtering Strategy

Priority Triage

┌─────────────────────────────────────────┐
│  HIGH SEVERITY (typically 0-5 issues)   │
│  → Verify ALL - these are critical      │
├─────────────────────────────────────────┤
│  MEDIUM SEVERITY (typically 2-10)       │
│  → Verify ALL - these matter            │
├─────────────────────────────────────────┤
│  LOW SEVERITY (can be many)             │
│  → Sample check if >10 issues           │
│  → Check all if ≤10 issues              │
├─────────────────────────────────────────┤
│  GAS / NC                               │
│  → Skip verification (not security)     │
└─────────────────────────────────────────┘

Two Workflows

Workflow A: Filter In-Memory (No Report File)

When user just ran weasel_analyze via MCP:

1. •Get findings from weasel_analyze output
2. •For each High/Medium:
   • •Read source code at location
   • •Verify: true positive or false positive?
3. •Report confirmed findings only

Workflow B: Clean Existing Report File (Context-Efficient)

When report file already exists (user ran weasel with output flag):

1. •Don't read the full report - it's too large
2. •Get summary via weasel_analyze MCP (small)
3. •For each High/Medium finding:
   • •Read SOURCE CODE (not the report)
   • •Determine: true or false positive?
4. •For false positives:
   • •Use Edit tool to DELETE that section from report.md
   • •Find section header (e.g., ## [H-01] Reentrancy...)
   • •Delete entire section until next ## [ or end

Why Workflow B is efficient:

• •Full report stays on disk (never in context)
• •Only load: summary (~2KB) + source code
• •Edit file directly instead of regenerating

Verification Process

For each finding to verify:

1. •Check known issues - Is this documented in README or known-issues.md?
2. •Read the code - Use Read tool at the reported location
3. •Understand context - Check surrounding functions, modifiers
4. •Check for guards - Look for existing protections
5. •Assess exploitability - Can this actually be exploited?
6. •Verdict - Confirmed, False Positive, or Known Issue

Verification Checklists

Reentrancy

• • Is there an external call?
• • Is state modified AFTER the call?
• • Is there a reentrancy guard?
• • Can the called contract be malicious?

Access Control

• • Is the function actually privileged?
• • Are there modifier checks?
• • Is the caller validated elsewhere?

Unchecked Returns

• • Is the return value actually important?
• • Is there error handling elsewhere?
• • Using SafeERC20 or similar?

Integer Issues

• • Is unchecked{} block used?
• • Is the value user-controlled?
• • Can overflow/underflow cause harm?

Common False Positive Patterns

Reentrancy

• •Read-only reentrancy (view functions)
• •Trusted contract calls (own contracts)
• •Already protected by mutex/nonReentrant

Unchecked Transfer

• •Intentional fire-and-forget
• •Using SafeERC20
• •Return value checked elsewhere

Access Control

• •Internal/private functions (not callable)
• •Checked in parent function
• •Initializer functions (one-time)

Output Format

Keep output minimal - one line per finding:

Filtered 5 findings → 2 confirmed, 3 false positives

✓ [H-01] Reentrancy in withdraw() - confirmed
✓ [M-03] Access control missing - confirmed
✗ [H-02] Reentrancy in deposit() - has nonReentrant
✗ [M-01] Unchecked return - uses SafeERC20
✗ [M-02] Integer overflow - in unchecked{} intentionally

Removed 3 sections from report.md

No verbose evidence blocks - user can ask for details on specific findings if needed.

After Filtering

Ask user:

• •"Found X confirmed issues. Want me to write reports for them?"
• •"Want me to add PoCs for High severity findings?"
• •"Should I explain any of these in more detail?"

Rationalizations to Reject