Matching flaws between scans of the same application

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.

The flaw-matching process occurs when you perform two scans of the same application. To identify flaws that might be identical between the two scans, Veracode compares the results of the second scan to the first scan. If Veracode finds a match for any given flaw, it forwards any comments or mitigation information you supplied for the original flaw.

Static Analysis flaw matching

When publishing new static analysis scan results, Veracode searches these locations within the application to determine if a potentially matching flaw exists:

• All Static Analysis policy scans
• All Static Analysis sandbox scans

Veracode uses a complete model of the application program logic and data flow to identify the location of a flaw. Small changes in code location, including changes in line numbers, do not affect how Veracode identifies flaws. You can still change the code containing a flaw so that it no longer matches to a flaw that Veracode found previously.

For a flaw to match across scans, it must meet these 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 end of the module name contains a varying numeric sequence. For example, foo-123.jar matches with foo-125.jar.

Veracode Static Analysis requires debug information to find flaw locations for some languages, including .NET and Java. If an application is compiled without debug information, flaw matching may be impaired. For the list of languages that require compilation with debug information, see the Veracode packaging requirements.

This table lists some known scenarios in which flaw matching does not occur. If a flaw is tagged as mitigated in a given scan, but the same flaw appears in a later scan with a different ID and not mitigated, it is likely because of one of these scenarios:

Cause of problem	Explanation
Different module names	When identifying if a flaw is the same as a previously mitigated flaw, Veracode uses the module name to ensure that the analysis matches flaws that are in the same context. Veracode matches modules with different version numbers, as described above, but there are styles of versioning that can cause this matching to fail.
High flaw density	Veracode sometimes cannot determine which flaws in the new scan map to flaws in the old scan. For example, one scan of an application has five flaws of a specific type in a function, and the next scan has four flaws of that same type in that same function.
Moved source files	Veracode tries to detect source files that have moved within the source tree. For example, com/veracode/Foo.java moved to com/veracode/bar/Foo.java. Veracode does not explicitly detect source filename changes.
Multiple flaws on the same line	Flaw matching has improved to be able to correctly distinguish between flaws in applications that have multiple flaws on the same line. However, some past scans may have occurred when Veracode was not able to tell the difference between these flaws, causing flaws to close and reopen incorrectly. Future scans of these applications may cause some new flaws to appear because Veracode can now distinguish between multiple flaws on the same line.

Known limitations

When the code provided to Veracode from the previous scanned code undergoes changes, flaw matching becomes more challenging, and it introduces the following limitations, which Veracode is actively addressing.

Duplications

If there are identical copies of a flaw within different source files, you expect to see separate flaws reported. However, Veracode does not recognize this duplication and only reports a single flaw.

Third-party fingerprinting

In some cases, when there is a build upon the work of a third party, there might not be any changes to a module. As a result, Veracode copies the results from the original module without recognizing that the module actually contains different information. This issue, known as third-party fingerprinting, occurs because Veracode does not utilize shared dependencies effectively. Therefore, it sometimes reports two separate flaws instead of matching them with existing flaws, even though the underlying vulnerabilities are the same.

Dynamic Analysis flaw matching

Dynamic Analysis flaw matching requires you to link the scan results to an application profile. Each scan identifies flaws in the latest version of the application and Veracode determines their statuses based on whether they were found in the previous scan.