Fix DependencyBundlingAnalyzer

[jeremylong]

The DependencyBundlingAnalyzer has grown over time from multiple PRs to do things it was not originally intended to do (at least not at the phase it is running in). Additionally, how the bundling analyzer works in conjunction with the suppression analyzer it is possible that vulnerabilities are being hidden (see issue #629). What needs to be done is the following:

1. Split the bundling based on package path into a separate analyzer that runs prior to CPE identification. This will allow us to better solve issues like Reduce multiplicities in .NET scans #453. When doing this consider renaming package path to something more along the lines of coordinates as that seems to be more what we can "bundle" on. Note, this is solely for multiple file type analyzers that may each generate a dependency (based on different artifacts) for the exact same dependency. An example would be a dependency from analyzing NuSpec and another from analyzing the actual DLL - the goal would be to report only a single dependency with multiple sources of evidence.

2. Solve for CVE suppressions with regards to the bundling related dependencies. The vulnerability analysis should run, then the suppression analysis, then finally the bundling and we should only bundle what appear to be related dependencies if the vulnerability count is the same (based off of identical CPE identifications, etc.).

[jeremylong]

This has been implemented in 1.4.5-SNAPSHOT and will be included in the next release. The new DependencyMergingAnalyzer will likely need additional re-work when we solve #453.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.