A shaded JAR, also called an uber JAR, packs your code and your dependencies into one file, and can rename the packages of some of them. Scanners that read the POM or lockfile may miss the copied libraries, because the published POM no longer lists them as dependencies.
Definition
The Maven Shade Plugin packages an artifact as an uber-jar containing its dependencies and can shade, meaning rename, the packages of some of them. Its single goal, shade:shade, runs at the package phase by default.
Two settings matter for security.
Dependency-reduced POM. The createDependencyReducedPom parameter defaults to true. Dependencies included in the uber JAR are removed from the dependencies section of the generated POM, and the result is written as dependency-reduced-pom.xml. Anyone who resolves your library from a repository and reads that POM sees fewer dependencies than the JAR contains.
Relocation. A relocation rewrites a package such as org.apache to hidden.org.apache. This avoids clashes on the classpath. It also changes class names, so tools that match by package or class name may no longer recognise the library.
Why this hides risk
A scanner that works from declared coordinates reads the POM. The copied classes are not declared there. A scanner that opens the JAR sees classes under renamed packages. Neither path hands it a tidy name and version.
The minimizeJar option goes further. It strips dependencies at class level so the JAR holds only the classes the artifact needs. That is good for size, and it means a vulnerable class may or may not remain, depending on what the analysis kept.
How to check a shaded JAR
- List the contents:
jar tf app.jar. Look for package trees that belong to well known libraries, including renamed ones. - Check for leftover metadata under META-INF. Some copied libraries leave descriptors behind, though shading configuration can remove them.
- Compare against your build. Which dependencies does the shade configuration include? Check the includes and filters.
- Record the bundled libraries in your own SBOM. Do not rely on the published POM.
- When a critical CVE lands, search both the dependency tree and the JAR contents. For why inventory has to come first, see Finding Log4j everywhere.
Shaded versus nested
Spring Boot avoids the shaded approach and nests the original jars inside the archive instead, which keeps the library names visible. See what is inside a Spring Boot executable JAR.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how an inventory is built from components. A shaded copy needs to be added to that list deliberately.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies, and its asset discovery helps you find which services and artifacts exist. Start with the free scan and compare the result with a JAR listing for any shaded build.
Quick check
Does relocation remove the vulnerability?
No. It renames packages to avoid clashes. The same code remains and has the same flaw.
Is a shaded JAR the same as a Spring Boot fat JAR?
No. Spring Boot nests the dependency jars unchanged under BOOT-INF/lib instead of merging their classes.
Sources
Last reviewed: 19 October 2026.
