Why do reports have similar matches to seemingly unrelated components when I scan my Spring Boot, maven assembly, uber, shaded jar file?



Nexus 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 tab of 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.


An uber jar is a single archive that consists of many individual files from potentially many individual OSS components.

Depending on the technology used to create the uber-jar, the internal executable portions of the uber-jars will be identical to all other OSS component uber jars Sonatype has cataloged made with the same technology.

Technology used to create uber jars includes:

If an uber jar is scanned, IQ scanning algorithms are going to choose 1 OSS component similar match out of potentially thousands that look structurally similar to your custom uber jar. Scanning uber jar applications is going to make your scan times much longer as well, 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 is not a recommended way to use IQ scanner tooling. Instead the goal should be to only scan the dependencies used by the final application.

Adding policy waivers for vulnerabilities against the "similar matched" component is not an effective measure 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:

  1. Use the clm-maven-plugin in the Maven project that builds the uber jar to track the actual dependencies that make up the uber-jar, so that only the dependencies are scanned. 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.
  2. Use the maven dependency plugin to unpack all dependencies into a directory, and then use the CLI scanner or CI scanner on that directory of dependencies
  3. 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.
Have more questions? Submit a request


Article is closed for comments.