Understanding Severity, Exploitability, and Effort to Fix
Severity and exploitability are two different measures of the seriousness of a flaw. Severity is defined in terms of the potential impact to confidentiality, integrity, and availability of the application as defined in the CVSS. Exploitability is defined in terms of the likelihood or ease with which a flaw can be exploited. A high-severity flaw with a high likelihood of being exploited by an attacker is potentially more dangerous than a high severity flaw with a low likelihood of being exploited.
Veracode Flaw Severities
Veracode flaw severities are defined on a severity scale, which, for SCA and manual results, is based on the CVSS rating assigned to the CVE:
|Severity||CVSS Rating (SCA and MPT only)||Description|
|5 - Very High||
|These lines of code have a very serious weakness and are an easy target for an attacker. Fix this flaw immediately to avoid potential attacks.|
|4 - High||
|These lines of code have a serious weakness and are an easy target for an attacker. Fix this flaw immediately to avoid potential attacks.|
|3 - Medium||4.1-6||These lines of code have a moderate weakness and may be an easy target for an attacker. Fix this flaw after fixing all Very High and High flaws.|
|2 - Low||2.1-4||These lines of code have a low weakness. Consider fixing this flaw after fixing all Very High, High, and Medium flaws.|
|1 - Very Low||
|These lines of code have a very low weakness. The flaw may be indicative of other problems in the code, but you do not need to mitigate it.|
|0 - Informational||
|These lines of code have an issue with no impact on the security the application, but it may be indicative of other problems in the code. You can safely ignore this issue.|
Informational (Severity 0) findings are items observed in the application scan that have no impact on the security quality of the application but may be interesting to the reviewer for other reasons. These findings may 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 flaws for the application.
Each flaw instance in a static scan may receive an exploitability rating. The rating is an indication of the intrinsic likelihood that the flaw may be exploited by an attacker. Veracode recommends that you use the exploitability rating to prioritize flaw remediation within a particular group of flaws with the same severity and difficulty of fix classification.
The possible exploitability ratings include:
|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|
Exploitability for some flaws is set at the category level. Some flaws have additional contextual information that provides a more specific exploitability factor. You can access this information by clicking the help icon for the flaw, located in the exploitability column.
Veracode Dynamic Analysis assumes that all reported flaws are exploitable because the Dynamic Analysis scan executes the attack and verifies that it is valid.
Effort to Fix
Each flaw instance receives an effort-to-fix rating based on the classification of the flaw. The effort to fix rating is given on a scale of 1 to 5, as follows:
|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.|