When a container scan flags a library inside a jar, the fix is a dependency change in your Java build followed by a rebuild, not a base image update. The base image holds the Java runtime, while your application jar carries its own libraries. Shaded jars can hide those versions, so check carefully.
Two places Java findings come from
A Java image has two sources of code. The runtime, a JRE or JDK, is installed by the base image or a package. The application and its libraries sit in your jar or in a directory of jars that your build produced.
| Path in the finding | Source | Fix |
|---|---|---|
| Under the Java home directory | Runtime from the base or an install step | Newer runtime tag, rebuild |
| An application jar in your app directory | Your build | Update the dependency, rebuild |
| A jar nested inside another jar | Fat or uber jar | Update the dependency in the build that produced it |
What shading does
The Apache Maven Shade plugin documentation says it packages the artifact into an uber jar, including its dependencies, and can shade, meaning rename, packages of some dependencies. Renaming helps avoid class conflicts but also means the library's original package names and sometimes its metadata change. A scanner that reads jar metadata may then miss a library or report a version you do not expect, depending on what remains inside.
So two things can go wrong. A vulnerable library may be present but not detected, and a detected library may be one you did not know was bundled. Neither is fixed at the image level.
Steps
- Identify which jar and which nested library the finding names.
- Trace it to a direct or transitive dependency in the build, using your build tool's dependency tree.
- Update the direct dependency, or override the transitive version, to a fixed release.
- Rebuild the jar, then rebuild the image from it.
- Rescan the new digest.
mvn dependency:tree -Dincludes=group:artifact
If the finding is in the runtime path, move to a patched runtime tag and rebuild. If you have just the built artifact and no source, see scanning a built jar without source.
Do you need a source scan as well?
Yes, it is a good cross check. A dependency scan of the source or an SBOM from the build lists libraries with their coordinates before shading, which is more reliable than reading a bundled jar. The image scan then confirms what shipped. Differences between the two are worth investigating. See reconciling a source SBOM and an image SBOM.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers dependencies from the build, and reachability analysis helps show whether a vulnerable library's code is called. Free scan: gold.safeguard.sh/scan.
A note on Spring style layered jars
Some build setups split a jar into layers for faster image builds, with dependencies in one layer and your classes in another. That does not change who fixes a finding. A library flagged in the dependencies layer is still a dependency of your build, and a rebuild with the updated version replaces that layer. The benefit is that the layer rebuilds without touching your application classes, and the image build can reuse cached layers for everything that did not change.
Evidence worth keeping
Keep the dependency tree output from the build next to the scan report. When a customer asks which version of a library you ship, the tree answers directly, and it shows whether the version came from your own declaration or arrived transitively.
Quick check
Will a newer base image remove a vulnerable library inside my jar?
No. The base image does not contain your jar's libraries. Update the dependency in your build.
Why does the scanner miss a library I know is bundled?
Shading and repackaging can remove or change the metadata scanners read. Use the build's SBOM as a cross check.
Sources
Last reviewed: 19 October 2026.
