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||
|The offending line or lines of code is a very serious weakness and is an easy target for an attacker. The code should be modified immediately to avoid potential attacks.|
|4 - High||
|The offending line or lines of code have significant weakness, and the code should be modified immediately to avoid potential attacks.|
|3 - Medium||4.1-6||A weakness of average severity. These flaws should be fixed in high assurance software. You should consider fixing this weakness after you fix the very high and high flaws for medium assurance software.|
|2 - Low||2.1-4||This is a low priority weakness that will have a small impact on the security of the software. You should consider fixing these flaws for high assurance software. Medium- and low-assurance software can ignore these flaws.|
|1 - Very Low||
|Minor problems that some high assurance software may want to be aware of. These flaws can be safely ignored in medium- and low-assurance software.|
|0 - Informational||
|Issues that have no impact on the security quality of the application but which may be of interest to the reviewer.|
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.
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.|