Vulnerability Triage

Efficiently categorize and prioritize security findings. --- Triage is the process of: 1. Reviewing each finding 2. Validating true/false positive 3....

Last updated: January 14, 2026

Vulnerability Triage

Efficiently categorize and prioritize security findings.

Triage Overview

Triage is the process of:

  1. Reviewing each finding
  2. Validating true/false positive
  3. Categorizing by type/severity
  4. Prioritizing for investigation
  5. Assigning to team members

Triage Workflow

Step 1: Filter View

Start with highest severity:

  1. Go to scan results
  2. Filter by Critical first
  3. Then High, Medium, Low

Step 2: Quick Assessment

For each finding, quickly assess:

  • Is it a true positive?
  • Is severity accurate?
  • Does it need investigation?

Step 3: Update Status

Set appropriate status:

Status When to Use
Open Default, needs review
Investigating Currently analyzing
Confirmed Valid finding
False Positive Not an issue
Duplicate Same as another finding
Won't Fix Accepted risk

Step 4: Add Context

Add notes for:

  • Why marked as FP
  • Initial assessment
  • Areas to investigate

False Positive Identification

Common False Positive Patterns

1. Intentional Design

// Marked as "centralization risk" but intentional admin control
function pause() external onlyOwner {
    _pause();
}

→ Mark FP with note: "Intentional admin capability per spec"

2. External Context

// Marked as "unchecked call" but using SafeERC20
token.safeTransfer(to, amount);

→ Mark FP with note: "Using OpenZeppelin SafeERC20"

3. Guarded Code Path

// Marked as "reentrancy" but protected
function withdraw() nonReentrant external {
    // ...
}

→ Mark FP with note: "Protected by ReentrancyGuard"

4. Test/Mock Code

// In MockToken.sol - marked as vulnerability
function mint(address to, uint256 amount) external {
    _mint(to, amount);
}

→ Mark FP with note: "Test mock, not production code"

Documenting False Positives

Always include:

  • Reason: Why it's not an issue
  • Evidence: Where protection exists
  • Reviewer: Who made the decision

Severity Adjustment

When to Adjust

Adjust severity when:

  • Scanner misassessed impact
  • Context changes severity
  • Exploitability differs

Adjustment Guidelines

Original Adjust To Reason
Critical High Requires unlikely conditions
High Medium Limited impact
Medium Low Unlikely to be exploited
Low Informational Code quality only

Document Adjustments

Original Severity: High
Adjusted To: Medium

Reason: The vulnerability requires admin key compromise.
Since admin keys are in hardware wallets with multisig,
exploitation is unlikely.

Prioritization

Priority Matrix

High Impact Low Impact
Easy Exploit P0: Immediate P1: Soon
Hard Exploit P1: Soon P2: Later

Triage SLAs

Priority Triage Investigation
P0 4 hours 24 hours
P1 24 hours 3 days
P2 3 days 1 week

Assignment Strategies

By Component

Assign team members to specific contracts:

  • Alice → Token.sol
  • Bob → Vault.sol
  • Carol → Oracle.sol

By Severity

Assign seniors to critical findings:

  • Senior Auditor → Critical, High
  • Auditor → Medium, Low

By Expertise

Match skills to vulnerability types:

  • DeFi specialist → Economic issues
  • EVM expert → Low-level issues
  • General → Access control, common patterns

Bulk Triage

Similar Findings

When multiple similar findings:

  1. Investigate one thoroughly
  2. Apply to all similar
  3. Use bulk update feature

Category-Based

Triage by vulnerability type:

  • All reentrancy findings together
  • All access control findings together
  • Consistent assessment

Triage Notes Template

## Quick Assessment

**True Positive**: Yes/No
**Severity Correct**: Yes/Adjust to [X]
**Priority**: P0/P1/P2

## Context

[Brief context about the finding]

## Decision

[Status and reasoning]

## Next Steps

- [ ] Deep investigation required
- [ ] Need second opinion
- [ ] Ready for report

Efficiency Tips

1. Use Filters

  • Filter by severity
  • Filter by scanner
  • Filter by file

2. Keyboard Shortcuts

  • j/k - Navigate findings
  • c - Add comment
  • f - Mark false positive
  • a - Assign

3. Batch Operations

  • Select multiple findings
  • Apply same status
  • Assign to same person

4. Templates

Create note templates:

  • False positive template
  • Investigation template
  • Handoff template

Common Triage Mistakes

1. Auto-Confirming Scanner Results

Always verify:

  • Scanner can be wrong
  • Context matters
  • Check actual code

2. Dismissing Without Investigation

Don't mark FP too quickly:

  • Understand the issue
  • Check related code
  • Document reasoning

3. Inconsistent Severity

Maintain consistency:

  • Same issue = same severity
  • Document reasoning
  • Review with team

4. Missing Context

Add notes:

  • Future you will forget
  • Team needs context
  • Client needs explanation

Next Steps