Severity Levels

Understanding vulnerability severity classifications.

Overview

BlockSecOps uses four severity levels to classify vulnerabilities:

Level	Color	Priority
Critical	Red	Immediate
High	Orange	High
Medium	Yellow	Medium
Low	Blue	Low

Critical Severity

Definition

Issues that can be exploited immediately with significant impact. These vulnerabilities pose an immediate threat to funds or contract operation.

Characteristics

Direct loss of funds possible
No special conditions required
Any user can exploit
Contract can be permanently damaged

Examples

Vulnerability	Impact
Reentrancy in withdraw	Drain all funds
Unprotected selfdestruct	Destroy contract
Open mint function	Infinite token creation
Arbitrary delegatecall	Complete takeover
Access bypass on admin	Unauthorized control

Response

Action: Fix immediately before any deployment or continued use.

Timeline: Same day resolution.

High Severity

Definition

Serious security issues that need attention but may require specific conditions to exploit.

Characteristics

Potential for significant fund loss
May require specific conditions
Could lead to privilege escalation
Major functionality impact

Examples

Vulnerability	Impact
Unchecked transfer return	Silent transfer failures
Integer overflow in balance	Incorrect accounting
Flash loan vulnerability	Profitable attack possible
Missing access control	Unauthorized actions
Frontrunning opportunity	Value extraction

Response

Action: Fix before deployment. If already deployed, prioritize fixing.

Timeline: Within current development cycle.

Medium Severity

Definition

Issues that should be addressed but don't pose immediate critical risk.

Characteristics

Potential for denial of service
Centralization concerns
Missing best practices
Conditional exploitation

Examples

Vulnerability	Impact
Missing event emission	Reduced transparency
Centralized admin key	Single point of failure
DoS with block gas limit	Temporary lock
Floating pragma	Inconsistent behavior
Timestamp dependence	Minor manipulation

Response

Action: Plan to fix. Document if accepting risk.

Timeline: Addressed in regular development.

Low Severity

Definition

Minor issues, informational findings, or code quality suggestions.

Characteristics

No direct security impact
Code style issues
Gas optimization opportunities
Documentation improvements

Examples

Vulnerability	Impact
Unused variable	Wasted gas
Naming convention	Reduced readability
Missing NatSpec	Documentation gap
Suboptimal loop	Gas inefficiency
Redundant code	Maintenance burden

Response

Action: Consider addressing during code cleanup.

Timeline: When convenient.

Severity Decision Guide

How Severity Is Assigned

Scanners consider:

Exploitability - How easy to exploit?
Impact - What's the damage?
Confidence - How certain is the finding?
Context - What's the surrounding code?

Severity Matrix

Impact	Easy to Exploit	Hard to Exploit
High Impact	Critical	High
Medium Impact	High	Medium
Low Impact	Medium	Low

Adjusting Severity

When to Upgrade

Consider upgrading severity when:

Contract holds significant value
Finding affects core functionality
Multiple issues compound
Context makes exploitation easier

When to Downgrade

Consider downgrading when:

Additional protections exist
Context makes exploitation impractical
Finding is in unused code
Risk is accepted with mitigations

Documenting Adjustments

When you change severity:

Note the original severity
Explain your reasoning
Document any mitigations

Severity by Vulnerability Type

Always Critical

Reentrancy in fund transfers
Arbitrary delegatecall
Unprotected selfdestruct
Missing authentication on admin functions

Usually High

Integer overflow in balances
Unchecked external calls
Flash loan vulnerabilities
Access control weaknesses

Usually Medium

Centralization risks
Missing events
Timestamp dependencies
DoS vulnerabilities

Usually Low

Gas optimizations
Code quality
Documentation
Style issues

Prioritization Guidelines

Triage Order

Critical - Review and fix immediately
High - Fix before next deployment
Medium - Plan to address
Low - Fix when convenient

Resource Allocation

Severity	Time Allocation
Critical	Drop everything
High	Priority task
Medium	Scheduled work
Low	Backlog

FAQ

Q: Can severity change between scans?
A: Yes. Code changes may raise or lower severity.

Q: Should I fix all Low severity issues?
A: Not necessarily. Focus on higher severities first.

Q: Who decides final severity?
A: Scanners provide initial severity. You can adjust based on context.

Q: Do different scanners assign different severities?
A: Yes. BlockSecOps normalizes them to a consistent scale.

Next Steps

Reading Findings - Interpret finding details
Managing Findings - Triage workflow
False Positives - Identify false alerts