Matching flaws between scans

You can match flaws between Veracode Upload and Scan, Veracode Dynamic Analysis, or Veracode Manual Penetration Testing (MPT) 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 might 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 might 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 might 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.

MPT flaw matching

The MPT Flaw Matching feature evaluates findings from successive MPT tests of the same application. It identifies recurring findings across multiple tests and links the matched instances together. This link ensures that all instances of the same finding across successive tests trace back to the original test in which it was first identified.

MPT Flaw Matching adds the following information to findings:

• A status, such as New or Fixed.
• Consistent flaw IDs for each finding across test results. When we identify the same MPT finding in multiple tests of the same application, all instances inherit the flaw ID from the first time we found it.
• First found dates that display the publication date of the test in which we first identified the finding.

First found date

The first found date indicates when a finding was first identified during a test. The value is the publication date of the test results from the test in which we found the finding. For example, if we run tests in January, February, and March, and the January test found two findings that remain open, those findings appear in the March test results with a first found date of January.

Any findings identified before the release of MPT Flaw Matching might have inaccurate first found dates.

Because MPT findings retain their first found dates, you can include them in the remediation grace periods of any security policies applied to your applications. Grace periods provide teams flexibility in meeting security compliance goals before certain findings impact the application’s policy score.

MPT finding statuses

In the results, each MPT finding shows one of the following status values.

• New: findings identified for the first time in the latest test. All findings from the initial test show a New status.
• Open: unresolved findings that were identified in a previous test and again in the latest test. Open findings retain their original flaw IDs (assigned the first time they were identified) and their first found dates. Any New findings identified during an initial or subsequent test that we also identify in the latest test change to Open status.
• Fixed: resolved findings identified in a previous test but not in the latest test. Fixed findings retain their original flaw IDs (assigned the first time they were identified) and their first found dates.
• Closed: findings that we did not identify during two successive tests. When a finding is Closed, we remove it from the results in the Veracode Platform Analytics and reports.

About historical MPT findings

MPT Flaw Matching does not support any findings identified in a given application before the release of the flaw matching feature. These findings continue to show an Open status, and results from the latest test replace the results from the previous test.

To start using the benefits of MPT Flaw Matching on an application that you tested previously, you must run a new test on the given application. When we publish the results of the first new test, all findings will have a New status.