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 very serious 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. |
1 The default range for SCA upload scans and Veracode Manual Penetration Testing (MPT). Veracode uses a proprietary method to convert CVSS scores to severities.
2 For the CVSS v3 range, Veracode converts CVSS scores to severities for SCA upload scans in the same manner as the National Vulnerability Database (NVD). If your organization uses CVSS v3, you can contact Veracode Technical Support to enable this feature for your account.
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. |