Overview
The Slither integration in packages/core/src/ast/slither.ts currently maps Slither findings to ChainProof findings with a basic severity translation. Several problems exist with the current implementation: incomplete detector coverage, imprecise severity mapping, poor deduplication against built-in rules, and no mechanism to configure which Slither detectors to enable or disable.
Current Problems
1. Incomplete Detector Mapping
Slither has 90+ built-in detectors. The current mapping covers only a subset. Unmapped detectors fall through with a generic title and no SWC cross-reference, losing valuable context.
2. Severity Mapping Imprecision
Slither uses a two-axis severity model: impact (High/Medium/Low/Info) × confidence (High/Medium/Low). ChainProof currently maps only on impact, ignoring confidence. A High impact / Low confidence finding should surface differently than High impact / High confidence.
3. Deduplication Gaps
Current deduplication uses line + title string match. This misses cases where:
- ChainProof's CP-107 and Slither's reentrancy-eth fire on the same line with different titles
- Slither reports the same issue across multiple contract inheritance levels
4. No Detector Allowlist/Denylist
Teams cannot exclude noisy Slither detectors (e.g. assembly usage in known-safe inline assembly) without disabling Slither entirely.
Proposed Changes
Comprehensive Detector Registry
// packages/core/src/ast/slither-detectors.ts
const DETECTOR_MAP: Record<string, {
chainproofId: string;
swcId?: string;
severityOverride?: Severity;
title: string;
}> = {
'reentrancy-eth': { chainproofId: 'CP-107', swcId: 'SWC-107', title: 'Reentrancy (ETH)' },
'arbitrary-send-eth': { chainproofId: 'CP-116', title: 'Arbitrary ETH send' },
// ... 90+ entries
};
Confidence-Weighted Severity
Map Slither impact × confidence to ChainProof severity:
| Impact |
Confidence |
ChainProof Severity |
| High |
High |
critical |
| High |
Medium |
high |
| High |
Low |
medium |
| Medium |
High |
high |
| Medium |
Medium |
medium |
Improved Deduplication
Match on (normalized_file + line_range_overlap + rule_category) rather than exact title match to deduplicate across ChainProof and Slither findings for the same vulnerability class.
Detector Configuration
{
"slither": {
"detectors": {
"exclude": ["assembly", "low-level-calls"],
"include": ["reentrancy-eth", "arbitrary-send-eth"]
}
}
}
Acceptance Criteria
Overview
The Slither integration in packages/core/src/ast/slither.ts currently maps Slither findings to ChainProof findings with a basic severity translation. Several problems exist with the current implementation: incomplete detector coverage, imprecise severity mapping, poor deduplication against built-in rules, and no mechanism to configure which Slither detectors to enable or disable.
Current Problems
1. Incomplete Detector Mapping
Slither has 90+ built-in detectors. The current mapping covers only a subset. Unmapped detectors fall through with a generic title and no SWC cross-reference, losing valuable context.
2. Severity Mapping Imprecision
Slither uses a two-axis severity model: impact (High/Medium/Low/Info) × confidence (High/Medium/Low). ChainProof currently maps only on impact, ignoring confidence. A High impact / Low confidence finding should surface differently than High impact / High confidence.
3. Deduplication Gaps
Current deduplication uses line + title string match. This misses cases where:
4. No Detector Allowlist/Denylist
Teams cannot exclude noisy Slither detectors (e.g. assembly usage in known-safe inline assembly) without disabling Slither entirely.
Proposed Changes
Comprehensive Detector Registry
Confidence-Weighted Severity
Map Slither impact × confidence to ChainProof severity:
Improved Deduplication
Match on (normalized_file + line_range_overlap + rule_category) rather than exact title match to deduplicate across ChainProof and Slither findings for the same vulnerability class.
Detector Configuration
{ "slither": { "detectors": { "exclude": ["assembly", "low-level-calls"], "include": ["reentrancy-eth", "arbitrary-send-eth"] } } }Acceptance Criteria