.
Problem
Sonatype Lifecycle is being used to scan my application distributable that was created as an "uber" or "fat" jar.
The resulting application report shows similar matches to OSS components that my project is not even using. My scan times are also slower than I expect.
When I view the Occurrences section of my report for the similar matched component, it tells me the match is on my uber/fat jar application file.
If I add a policy waiver on the similar matched component, when I rebuild and rescan my application, the similar component vulnerability for that policy and component re-appears.
Diagnosis
An uber jar is a single archive that consists of many individual files from one or more individual OSS components.
When a proprietary non-OSS cataloged uber jar is scanned, IQ scanning algorithms are going to choose 1 OSS component similar match out of potentially thousands in the OSS world that look structurally similar. Scanning uber jar applications is going to make your application scan times longer than typical, with no actionable benefits.
If you scan an uber jar, you will likely get similar matches to real OSS components and you will get noise that you will have to deal with in the reports, that you otherwise would not if only the dependencies which went into the application were scanned.
How to Avoid the Problem
Scanning uber jars directly is not a recommended way to use Sonatype Lifecycle tooling. Instead only the dependencies used by the final application should be scanned.
Adding policy waivers for vulnerabilities against the "similar matched" component is not effective because waivers are associated with the unique hash of the component to which it is applied. On re-build the hash changes and thus the old waiver is no longer applicable.
For an uber jar application you have the following options in order of preference:
- Use the clm-maven-plugin in the Maven project that builds the uber jar. The plugin goals precisely calculate the exact coordinates of open-source software (OSS) components used in the build, eliminating reliance on less accurate similar-match algorithms. If a continuous integration plugin is being used to do the scan, such as the Nexus Platform Plugin for Jenkins, be sure to configure it to exclude scanning the uber jar itself.
- Use the maven dependency plugin to unpack all dependencies into a directory, and then use a Sonatype Lifecycle scanner ( CLI or CI ) to target that directory of dependencies
- Assuming there are unique proprietary paths inside your uber jar, configure a proprietary matcher to tell IQ server to treat your uber jar as proprietary and this will avoid the incorrect similar matches.