Methodology and scoring
We use a unique methodology for Static Analysis and Dynamic Analysis scans to inspect executables and identify security findings (flaws or vulnerabilities) in applications. Performing both Static Analysis and Dynamic Analysis scans helps reduce false negatives and detect a broader range of findings.
The Static Analysis Engine models the uploaded binary executable of your application into an intermediate representation, which is then verified for security flaws using a set of automated security scans. Dynamic Analysis uses an automated penetration testing technique to detect security flaws at runtime. After the automated process is complete, a security technician verifies the output to ensure the lowest false positive rates in the industry. The end result is an accurate list of security flaws for the classes of automated scans applied to the application.
Rating system using multiple analysis techniques
Higher business criticality applications require more comprehensive analysis to accurately score their security quality. Analysis techniques include automated static, automated dynamic, manual penetration testing, and manual review. Because each analysis technique has differing false negative (FN) rates for different types of security flaws, any single analysis technique or even a combination of techniques is more likely to produce a certain level of false negatives. Some false negatives are acceptable for lower business critical applications, therefore, a less expensive analysis using only one or two analysis techniques is acceptable. At higher business criticality the FN rate should be close to zero. Therefore, Veracode recommends multiple analysis techniques.
Flaw methodology
We use the following methodology to identify and determine the risk level of detected flaws, and to compute the Security Quality Score.
Flaw types by severity level
We use the flaw types, such as API abuse, code injection, or encapsulation, and their severity levels to compute the Security Quality Score for the application.
You can view this information in the Flaw Types by Severity and Category table in the Detailed Veracode Report. This table provides a summary of flaws found in the application by Severity and Category. The table puts the Security Quality Score into context by showing the specific breakout of flaws by severity. If multiple analysis techniques are used, the table includes a breakout of all flaws by category and severity for each analysis type performed.
Flaws by severity
The distribution of flaws by severity. An application can receive a mediocre security rating by having a few high-risk flaws or many medium-risk flaws. You can view this information in the Security Flaws by Severity chart in the Summary Veracode Report.
Flaws in common modules
A shared dependency is a dependency that is used by more than one analyzed module. The score impact represents the amount that the application score would increase if all the flaws in the shared dependency module were fixed. This information can be used to focus remediation efforts on common modules with a higher impact on the application security score.
You can view a summary of flaws in shared dependency modules for a scanned application in the Common Modules Listing section of the Summary Veracode Report. Each module is listed with the number of executables that consume it as a dependency and a summary of the impact on the application's security score of the flaws found in the dependency. Only common modules uploaded with debug information are included in the Flaws in Common Modules listing.
Common Weakness Enumeration (CWE)
The Common Weakness Enumeration (CWE) is an industry standard classification of types of software weaknesses, or flaws, that can lead to security problems. CWE is widely used to provide a standard taxonomy of software errors. Every flaw in a Veracode report is classified according to a standard CWE identifier. For more information, see Common Weakness Enumeration.
About business criticality
The foundation of the Veracode rating system is the concept that more critical applications require higher security quality scores to be acceptable risks. Less business critical applications can tolerate lower security quality. The business criticality is dictated by the typical deployed environment and the value of data used by the application. Factors that determine business criticality are: reputation damage, financial loss, operational risk, sensitive information disclosure, personal safety, and legal violations.
When you create an application profile, by default, we automatically assign a security policy based on the selected business criticality.
| Business criticality | Description |
|---|---|
| Very High | Mission critical for business or safety of life and limb on the line. This is typically an application where the safety of life or limb is dependent on the system; it is mission critical that the application maintain 100% availability for the long-term viability of the project or business. Examples are control software for industrial, transportation or medical equipment, or critical business systems such as financial trading systems. |
| High | Exploitation causes serious brand damage and financial loss with long-term business impact. This is typically an important multi-user business application reachable from the internet and is critical that the application maintain high availability to accomplish its mission. Exploitation of high-criticality applications cause serious brand damage and business/financial loss and could lead to long term business impact. |
| Medium | Applications connected to the internet that process financial or other private information. This is typically a multi-user application connected to the internet or any system that processes financial or other private information. Exploitation of medium-criticality applications typically results in material business impact resulting in some financial loss, brand damage or business liability. An example is a financial services company's internal 401K management system. |
| Low | Typically internal applications with non-critical business impact. This is typically an internal only application that requires low levels of application security such as authentication to protect access to non-critical business information and prevent IT disruptions. Exploitation of low-criticality applications may lead to minor levels of inconvenience, distress, or IT disruption. An example internal system is a conference room reservation or business card order system. |
| Very Low | Applications with no material business impact. Applications that have no material business impact should its confidentiality, data integrity, and availability be affected. Code security analysis is not required for this business criticality level, and you can direct security spending to other higher-criticality applications. |
US. Govt. OMB Memorandum M-04-04; NIST FIPS Pub. 199
Scoring methodology
The Veracode Security Quality Score is built on the foundation of two industry standards, the Common Weakness Enumeration (CWE) and the Common Vulnerability Scoring System (CVSS). CWE provides the dictionary of security flaws, and CVSS provides the method for computing severity based on the potential impact to Confidentiality, Integrity, and Availability if a flaw is exploited.
Only flaws found by Static and Dynamic scans affect the Veracode Security Quality Score. Vulnerabilities found by SCA scans do not affect the score.
The Security Quality Score is a single score from 0 to 100, where 0 is the most insecure application and 100 is an application with no detectable security flaws. The score calculation includes non-linear factors so that, for instance, a single Severity 5 flaw is weighted more heavily than five Severity 1 flaws, and so that each additional flaw at a given severity contributes progressively less to the score.
Veracode assigns a severity level to each flaw type based on three foundational application security requirements: Confidentiality, Integrity, and Availability. Each of the severity levels reflects the potential business impact if a security breach occurs across one or more of these security dimensions.
Confidentiality impact
According to CVSS, this metric measures the impact on confidentiality if an exploit should occur using the vulnerability on the target system. At the weakness level, the scope of the Confidentiality in this model is within an application and is measured at three levels of impact: None, Partial, and Complete.
Integrity impact
This metric measures the potential impact on integrity of the application being analyzed. Integrity refers to the trustworthiness and guaranteed veracity of information within the application. Integrity measures are meant to protect data from unauthorized modification. When the integrity of a system is sound, it is protected from unauthorized modification of its contents.
Availability impact
This metric measures the potential impact on availability if a successful exploit of the vulnerability is performed on a target application. Availability refers to the accessibility of information resources. Almost exclusive to this domain are denial-of-service vulnerabilities. Attacks that compromise authentication and authorization for application access, application memory, and administrative privileges are examples of impact on the availability of an application.
Security Quality Score calculation
The overall Security Quality Score is computed by aggregating impact levels of all weaknesses within an application and representing the score on a 100 point scale. This score does not predict vulnerability potential as much as it enumerates the security weaknesses and their impact levels within the application code.
The Raw Score formula puts weights on each flaw based on its impact level. These weights are exponential and determined by empirical analysis by Veracode's application security experts with validation from industry experts. The score is normalized to a scale of 0 to 100, where a score of 100 is an application with 0 detected flaws using the analysis technique for the application's business criticality.
Veracode Level calculation
The Veracode Level is calculated based on the scan types performed, the score attained in each scan, and the severity of flaws found.
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.
Finding severity scale
Veracode defines flaw severities, for SAST and DAST, on a severity scale. For SCA and MPT findings, the severity 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. |
1 Veracode uses a proprietary method to convert CVSS scores to severities for Manual Penetration Testing (MPT) results in the Veracode Platform.
2 Veracode converts CVSS scores to severities in the same manner as the National Vulnerability Database (NVD). SCA Upload and Scan use the CVSS v3 range by default. For SCA Agent-based Scan, 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
Veracode applies an exploitability rating to each finding (flaw) from a Static Analysis scan. This rating indicates how likely it is that an attacker might find and exploit the flaw to harm the application or compromise its data.
When prioritizing which findings to address, group them by severity and estimated effort to remediate. Then, use the exploitability rating to determine which findings in each group to fix first.
The following table describes the exploitability ratings. The Code mapping column lists the corresponding numeric values displayed by the Veracode APIs and products that run Static Analysis using Pipeline Scan, such as the Veracode CLI.
| Exploitability | Description | Code mapping |
|---|---|---|
| V. Unlikely | Very unlikely to be exploited | -2 |
| Unlikely | Unlikely to be exploited | -1 |
| Neutral | Neither likely nor unlikely to be exploited | 0 |
| Likely | Likely to be exploited | 1 |
| V. Likely | Very likely to be exploited | 2 |
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. |