Severity

Severity Classification

Purpose

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).

Severity Levels

Scoring weights reference the Audit Scoring System efficiency metric.

How to Use

1. Classifying a finding → Use the Severity Scoring Decision Tree to determine the correct level
2. Validating severity → Compare your finding against the top vulnerability types table in each file
3. Writing the report → Reference representative examples for formatting and depth expectations
4. Scoring the audit → Apply severity weights from AUDIT_SCORING.md to calculate composite scores

Quick Severity Decision Tree

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

Cross-Severity Vulnerability Migration

Some vulnerability types appear across multiple severity levels depending on conditions. Key crossovers:

Related Skills

• Audit Scoring System — Composite scoring using severity weights
• Severity Scoring Decision Tree — AI-optimized classification guide
• Audit Report Templates — How to write findings at each severity
• PoC Writing Guide — Proving exploitability strengthens severity claims
• Checklists — Protocol-specific vulnerability checklists

Prerequisites

Severity classification requires understanding of the Severity Scoring Decision Tree. The decision tree MUST be consulted before assigning final severity.

Validation

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

Behavior Guidelines

• Every finding MUST have a severity classification before submission
• The decision tree is required for borderline HIGH/MEDIUM cases
• Auditors may optionally include a severity justification paragraph for contested findings
• GAS findings ALWAYS have 0 scoring weight in composite metrics

References

• Severity References - Historical distribution data and calibration benchmarks