Matching Flaws

Results and Reports

Carrying mitigations and comments forward from one scan to the next requires that the flaws match from one scan to the next of the same application.

Flaw matching is a process that occurs when you perform two scans of the same application. Veracode compares the results of the second scan to the first scan to identify any flaws that may be identical between the two scans. If a match is found for any given flaw, any comments or mitigation information you may have supplied for the original flaw are brought forward to the new flaw, and the flaws are matched in the database.

Static Flaw Matching

For a flaw to match across scans, it must meet the following criteria:
  • The source file name has not changed.

  • The name of the module in which the flaw is located cannot change between scans. However, Veracode can match flaws if the module name contains a varying numeric sequence at the end. For example, "foo-123.jar" matches with "foo-125.jar".

The following table lists some of the things that often go wrong with static flaw matching. If a flaw is marked as mitigated in a given scan, but the same flaw shows up in a later scan with a different ID and not mitigated, it most likely failed one or more of the following reasons.
Cause of Problem Explanation
Different module names If module names differ between scans of an app, Veracode sometimes fails to match issues pertaining to those module names. However, Veracode can match flaws if the module name contains a varying numeric sequence at the end.
High flaw density If, for example, one scan of an application has five flaws of a particular type in a function, and the next scan has four flaws of that same type in that same function, Veracode is sometimes unable to determine which flaws in the new scan map to which flaws in the old scan.
Moved source files Veracode tries to detect source files that have moved within the source tree (for example, "com/veracode/Foo.java" to "com/veracode/bar/Foo.java"), but this is not always possible. We explicitly do not detect source filename changes.

Web Application Scan Flaw Matching

For DynamicDS scans, DynamicDS Vulnerability Rescans rely on flaw matching to identify the status of previously found vulnerabilities to retest them and determine the appropriate status. Veracode matches flaws in an application between DynamicDS scans that have the same:
  • CWE
  • Full URL
  • Form parameters, if used
Flaws in these applications do not match when:
  • The URL has changed (for example, from between a stage URL and a production URL)
  • Form parameters, if used, have changed.

After the DynamicDS scan has completed, flaws are returned with one of the remediation statuses listed in the DynamicDS remediation status table.

For DynamicMP scans, flaw matching requires the scan results to be linked to an application profile. Veracode does not perform rescans to test vulnerabilities previously found in DynamicMP scans. Instead, each scan identifies flaws in the latest version of the application and Veracode determines their statuses based on whether or not they were found in the previous scan.

After the DynamicMP scan has completed, flaws are returned with one of the remediation statuses listed in the DynamicMP remediation status table.