skills/severity/SKILL.md
Data-driven severity classification for smart contract audit findings with statistical breakdowns and 30 representative examples per level from top audit firms. Use when assigning severity to findings, justifying classifications with historical data, or calibrating severity judgment against Code4rena, Sherlock, and Cyfrin benchmarks.
npx skillsauth add 0x-shashi/web3-audit-skills skills/severityInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
4 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This directory provides data-driven severity classification for smart contract audit findings. Each file contains statistical breakdowns of real vulnerability types at that severity level, plus 30 representative examples from top audit firms (Code4rena, Cyfrin, Spearbit, Pashov, MixBytes, Shieldify, OtterSec, Quantstamp).
| Level | File | Finding Count | % of All | Scoring Weight | |-------|------|---------------|----------|----------------| | HIGH | high-severity.md | 8,022 | 15.88% | 5 points | | MEDIUM | medium-severity.md | 13,814 | 27.34% | 2 points | | LOW | low-severity.md | 25,272 | 50.01% | 1 point | | GAS | gas-optimizations.md | 3,422 | 6.77% | 0 points |
Scoring weights reference the Audit Scoring System efficiency metric.
Is there direct fund loss possible?
├── YES → Is it unconditional (anyone can exploit)?
│ ├── YES → CRITICAL (not in this dataset — escalate)
│ └── NO (needs conditions) → HIGH
└── NO → Is there indirect fund loss or protocol damage?
├── YES → Is the attack practical?
│ ├── YES → HIGH
│ └── NO (theoretical) → MEDIUM
└── NO → Is there any functional impact?
├── YES → LOW
└── NO → GAS / INFORMATIONAL
Full decision tree with scoring matrix: patterns/severity-scoring.md
Some vulnerability types appear across multiple severity levels depending on conditions. Key crossovers:
| Vulnerability Type | HIGH Count | MEDIUM Count | LOW Count | Notes | |---|---|---|---|---| | Business Logic | 100 | 127 | 7 | Most common at every level | | Validation | 52 | 75 | — | Severity depends on what's unvalidated | | Reentrancy | 39 | 20 | — | HIGH when funds at risk, MEDIUM when state-only | | Oracle | 24 | 34 | — | HIGH for price manipulation, MEDIUM for staleness | | Access Control | 27 | 19 | 2 | HIGH for privilege escalation, LOW for missing events | | Front-Running | 39 | 67 | — | MEDIUM unless sandwich causes fund loss | | DOS | 23 | 43 | — | HIGH for permanent, MEDIUM for temporary | | Overflow/Underflow | 21 | 22 | — | Severity = magnitude of miscalculation |
Severity classification requires understanding of the Severity Scoring Decision Tree. The decision tree MUST be consulted before assigning final severity.
To verify severity classification consistency, compare against historical benchmarks:
# Validate severity distribution against expected ranges
def test_severity_distribution(findings):
high_pct = len([f for f in findings if f.severity == 'HIGH']) / len(findings)
assert 0.10 <= high_pct <= 0.25, f"HIGH findings at {high_pct:.0%} (expected 10-25%)"
print(f"Severity distribution validated: {high_pct:.0%} HIGH")
# Expected severity distribution benchmarks
benchmarks:
high: 15.88% # 8,022 of 50,530 findings
medium: 27.34% # 13,814 findings
low: 50.01% # 25,272 findings
gas: 6.77% # 3,422 findings
# Verify severity files are complete
for f in high-severity.md medium-severity.md low-severity.md gas-optimizations.md; do
echo "Checking $f: $(wc -l < $f) lines"
done
development
Systematically hunt for every variant of a discovered vulnerability across the entire codebase. Use when a bug is found and all instances of the same root cause pattern must be identified, or when performing variant analysis during competitive audits on Code4rena or Sherlock.
testing
Use when the user wants to audit TON smart contracts for security vulnerabilities, scan FunC or Tact contracts for message chain replay, bounce handling, or gas issues, review TON DeFi protocols for actor-model concurrency flaws, or analyze asynchronous message passing security.
tools
Analyze ERC20/ERC721/ERC1155 token implementations for non-standard behavior, fee-on-transfer mechanics, rebasing logic, blacklists, pausability, and integration risks. Use when reviewing protocols that interact with external tokens or implementing token-related features.
testing
Use when the user wants to audit Sui Move smart contracts, scan Sui-specific patterns including object ownership, shared objects, or dynamic fields, review Sui DeFi protocols for object model security issues, or analyze Sui-specific transaction and consensus patterns.