Reading Findings

Learn to interpret vulnerability findings effectively. Each finding has several components. Understanding each helps you triage effectively. --- A brief...

Last updated: January 14, 2026

Reading Findings

Learn to interpret vulnerability findings effectively.

Finding Anatomy

Each finding has several components. Understanding each helps you triage effectively.

Finding Header

Title

A brief description of the issue:

  • "Reentrancy vulnerability in withdraw()"
  • "Unchecked return value from transfer()"
  • "Missing access control on admin function"

Severity Badge

Color-coded severity indicator:

  • šŸ”“ Critical
  • šŸŸ  High
  • šŸŸ” Medium
  • šŸ”µ Low

Status

Current triage status:

  • Open, Acknowledged, Fixed, etc.

Location Information

File and Line

Where the issue exists:

šŸ“ contracts/Token.sol
šŸ“ Line 45

Function Context

Which function contains the issue:

Function: withdraw(uint256 amount)
Visibility: external

Click to Navigate

Click the location to jump directly to the code.

Description

What It Says

The description explains:

  1. What the vulnerability is
  2. Why it's a problem
  3. How it could be exploited

Example Description

This function makes an external call to transfer Ether before updating the contract's state. An attacker can recursively call back into the contract, draining funds before the balance is decremented.

Reading Tips

  • Look for the attack scenario
  • Understand the root cause
  • Note any conditions required

Code Snippet

Highlighted Code

The relevant source code with the vulnerable line highlighted:

42  function withdraw(uint amount) external {
43      require(balances[msg.sender] >= amount);
44 ā†’    (bool success, ) = msg.sender.call{value: amount}("");
45      require(success);
46      balances[msg.sender] -= amount;  // State updated after call
47  }

What to Look For

  • The highlighted line (ā†’)
  • Surrounding context
  • Flow of execution
  • State changes

Recommendation

Fix Guidance

How to resolve the issue:

Apply the checks-effects-interactions pattern: update state before making external calls. Consider using OpenZeppelin's ReentrancyGuard modifier.

Example Fix

Some recommendations include code examples:

// Fixed version
function withdraw(uint amount) external nonReentrant {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;  // State updated first
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

Scanner Information

Which Scanner Found It

Field Example
Scanner Slither
Detector reentrancy-eth
Version 0.10.0

Confidence Level

How certain the scanner is:

  • High - Very likely real issue
  • Medium - Probably an issue
  • Low - Might be false positive

Multiple Scanners

If multiple scanners found the same issue:

Found by: Slither, Aderyn, SolidityDefend

This increases confidence it's a real issue.

References

External Links

Links to learn more:

  • SWCR registry entries
  • OWASP documentation
  • Academic papers
  • Blog posts

Example References

Risk Score

ML-Powered Score

A 0-100 score indicating overall risk:

  • Based on exploitability
  • Considers impact
  • Accounts for context

Using the Score

Score Meaning
80+ Prioritize immediately
60-79 Address soon
40-59 Plan to fix
<40 Lower priority

Interpreting Findings

Is It Real?

Ask yourself:

  1. Does the code flow match the description?
  2. Is the attack scenario plausible?
  3. Are the required conditions realistic?

False Positive Indicators

Signs it might not be a real issue:

  • Context makes exploitation impossible
  • Additional protections exist
  • Code is unreachable
  • Assumptions don't hold

True Positive Indicators

Signs it's likely real:

  • Multiple scanners found it
  • Attack scenario is clear
  • High confidence score
  • No protective context

Taking Action

After Reading

Decide next steps:

Decision Action
Real issue Set status to Acknowledged, plan fix
Need investigation Research more, consult team
False positive Mark as False Positive, add note
Won't fix Document reasoning, mark Won't Fix

Adding Context

Use comments to:

  • Explain your analysis
  • Note why it's a false positive
  • Document mitigations
  • Track discussion

Tips for Effective Reading

1. Start with Severity

Focus on Critical and High first.

2. Read the Attack Scenario

Understand how exploitation would work.

3. Check the Code

Verify the finding matches the code.

4. Consider Context

What else is in the contract?

5. Verify Assumptions

Are the scanner's assumptions correct?

6. Document Decisions

Leave notes for future reference.

FAQ

Q: Should I fix everything?
A: Focus on Critical/High. Evaluate Medium/Low based on resources.

Q: What if I don't understand a finding?
A: Research the vulnerability type. Ask your team. Contact support.

Q: How do I know if it's a false positive?
A: See False Positives guide.

Next Steps