About severity, exploitability, and effort to fix

Severity and exploitability are two different measurements of the seriousness of a finding. Effort to Fix measures the complexity of the work required to fix the finding.

Severity is the potential impact on confidentiality, integrity, and availability of the application as defined in the CVSS (Common Vulnerability Scoring System). Exploitability is the likelihood or ease with which an attacker could exploit a finding. A high-severity finding with a high likelihood of being exploited by an attacker is potentially more dangerous than a high-severity finding with a low likelihood of being exploited.

Effort to Fix, also called Complexity of Fix, is a measure of the expected effort required to fix a finding. In addition to severity, Veracode uses Effort to Fix to provide Fix First guidance.

Veracode finding severities

Veracode defines finding severities on a severity scale, which, for SCA and manual results, is based on the CVSS rating assigned to the CVE:

Severity	Veracode range1	CVSS v3 range2	Description
5 - Very High	8.1-10.0	9.0-10.0	These lines of code have a critical weakness and are an easy target for an attacker. Fix this finding immediately to avoid potential attacks.
4 - High	6.1-8.0	7.0-8.9	These lines of code have a serious weakness and are an easy target for an attacker. Fix this finding immediately to avoid potential attacks.
3 - Medium	4.1-6.0	4.0-6.9	These lines of code have a moderate weakness and might be an easy target for an attacker. Fix this finding after fixing all Very High and High findings.
2 - Low	2.1-4.0	0.1-3.9	These lines of code have a low weakness. Consider fixing this finding after fixing all Very High, High, and Medium findings.
1 - Very Low	0.1-2.0	n/a	These lines of code have a very low weakness. The finding might indicate other problems in the code, but you do not need to mitigate it.
0 - Informational	0 .0	0.0	These lines of code have an issue with no impact on the security of the application, but the finding might indicate other problems in the code. You can safely ignore this issue.

¹ Veracode uses a proprietary method to convert CVSS scores to severities for Manual Penetration Testing (MPT) results in the Veracode Platform.

² Veracode converts CVSS scores to severities in the same manner as the National Vulnerability Database (NVD). SCA upload scans use the CVSS v3 range by default. For agent-based scanning, you can configure agent rules to use either CVSS v2 or CVSS v3.

Informational findings

Informational (Severity 0) findings are items Veracode observes in the application scan that have no impact on the security quality of the application but might be interesting to the reviewer for other reasons. These findings might include code quality issues, API usage, and other factors.

Informational findings have no impact on the security quality score of the application and are not included in the summary tables of findings for the application.

Exploitability

Each finding instance in a static scan may receive an exploitability rating. The rating is the likelihood that a finding can be found and used by an attacker to cause damage to the application or the data it protects. Veracode recommends that you use the exploitability rating to prioritize finding remediation within a specific group of findings with the same severity and difficulty of fix classification.

The possible exploitability ratings include:

Exploitability	Description
V. Unlikely	Very unlikely to be exploited
Unlikely	Unlikely to be exploited
Neutral	Neither likely nor unlikely to be exploited
Likely	Likely to be exploited
V. Likely	Very likely to be exploited

Two different methods determine exploitability:

• Categorical exploitability: describes the likelihood of exploit, from Very Unlikely to Very Likely, based on proprietary formula and input from the Veracode security research team. All Veracode static flaw categories have categorical exploitability.
• Contextual exploitability: increases or decreases the categorical exploitability assigned to an individual flaw using this data:
  • Information about the data flow path, specifically, the source of the tainted data
  • Heuristics

If the tainted data comes from an HTTP request, the contextual exploitability calculations might increase the exploitability of a cross-site scripting flaw. If the tainted data comes from a file on the application local file system, the contextual exploitability calculations might decrease the exploitability of a SQL injection flaw.

Open source code exploitability

See Understanding SCA exploitability information for details.

Effort to fix

Each finding instance receives an effort-to-fix rating based on the classification of the finding. The effort-to-fix rating is a scale from 1 to 5, as explained in this table.

Effort to fix	Description
5	Complex design error. Requires significant redesign.
4	Simple design error. Requires redesign and up to 5 days to fix.
3	Complex implementation error. Fix is approx. 51-500 lines of code. Up to 5 days to fix.
2	Implementation error. Fix is approx. 6-50 lines of code. 1 day to fix.
1	Trivial implementation error. Fix is up to 5 lines of code. One hour or less to fix.