Scan the artifact itself: unpack the JAR or WAR and list the libraries inside, or scan the container image layers. This works when you have no source, such as vendor software or old builds. Expect gaps with shaded libraries, so treat the result as a floor, not a full list.
When you need this
- A vendor hands you a JAR or WAR.
- A legacy service has no repository anyone can find.
- A build produced an image and the pipeline logs are gone.
- A critical CVE lands and you must check what is deployed, not what is in Git.
What the three common layouts look like
| Artifact | Where libraries are | Visibility to a scanner |
|---|---|---|
| Spring Boot executable JAR | Nested jars in BOOT-INF/lib | Good, names stay visible |
| WAR | WEB-INF/lib, and WEB-INF/lib-provided for embedded-only | Good |
| Shaded or uber JAR | Classes merged, packages possibly renamed | Weak, see shaded JARs |
The Spring Boot documentation describes the first two layouts. The Shade plugin documentation describes why the third is harder: bundled dependencies are removed from the generated POM, and packages may be relocated.
Steps
- Identify the packaging. Look at META-INF/MANIFEST.MF and the folders.
- List nested jars with unzip -l and note names and versions.
- Check for duplicates. Two versions of one library suggest a conflict or a hidden bundle.
- For images, scan each layer, since a Boot image can separate a dependencies layer from application code. The layer index file layers.idx records that grouping.
- Record the runtime too. The JDK and the container base image have their own findings.
- Save the output as an inventory and rescan on new advisories.
Limits you should state to your team
- A nested jar name can be changed. Do not treat file names as proof.
- Shaded copies can hide libraries.
- Native libraries and code loaded at runtime from elsewhere are outside a static listing.
- A listing says what is present, not what the application calls. Use reachability to prioritise, see Is a vulnerable Java dependency actually reachable?.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how an image is broken into packages and how findings are attached to each one.
Where Safeguard fits
Safeguard scans container images and dependencies and produces SBOMs for what it finds. You can try a free scan to see what it reports.
Quick check
Can I trust file names inside a jar?
Treat them as strong hints, not proof. Names can be changed, and shaded libraries may not appear as jars at all.
Does a clean artifact scan mean the software is safe?
No. It means the scanner found no known issue in what it could see.
Sources
Last reviewed: 19 October 2026.
