A Spring Boot executable JAR keeps your classes under BOOT-INF/classes and every dependency as an intact nested jar under BOOT-INF/lib. Because the libraries stay whole, you can list them from the archive and match each one to an advisory, unlike a shaded JAR.
Definition and layout
Java has no standard way to load jars nested inside another jar. The Spring Boot documentation says Boot avoids the shaded approach and nests dependency jars directly. The layout is:
| Path | Holds |
|---|---|
| META-INF/MANIFEST.MF | Manifest |
| org/springframework/boot/loader | Spring Boot Loader classes |
| BOOT-INF/classes | Your application classes |
| BOOT-INF/lib | Dependency jars, nested |
For war files, dependencies go in WEB-INF/lib, and those needed only for embedded running go in WEB-INF/lib-provided.
The index files
Two optional files sit under BOOT-INF.
classpath.idx lists jars in the order they are added to the classpath. Build plugins usually generate it, and it is used only with java -jar.
layers.idx splits the archive into layers for container image builds, for example a dependencies layer and an application layer.
For an inventory, classpath.idx and the BOOT-INF/lib listing are the two quickest sources of truth.
How to inventory one
- List the nested jars:
unzip -l app.jar | grep BOOT-INF/lib. - Read the file names. They normally carry artifact and version, such as a name followed by a version number.
- Turn each into a package URL so it can be matched to advisories, see how to write a purl for Maven.
- Compare against your build tool's tree. Anything in the JAR that is not in the tree deserves an explanation.
- Store the list with the build, and rescan when new advisories appear.
What to look for
- Old versions held back by a managed BOM, see overriding a managed version.
- Duplicate libraries at different versions.
- Libraries you thought you had excluded.
- Nested jars that are themselves shaded, which hide further copies.
Why layers are useful for inventory
The layer index groups dependency jars apart from your application classes. When you scan an image built from the archive, findings in the dependencies layer point at libraries, and findings elsewhere point at your own code or base image.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings are tied to packages inside an image. The same idea applies to the layers of a Boot image.
Where Safeguard fits
Safeguard scans container images and dependencies, and produces SBOMs you can store with each build. Try the free scan on a repository that builds a Boot application.
Quick check
Where do the libraries live in a Boot JAR?
As nested jars in BOOT-INF/lib. Your own classes are in BOOT-INF/classes.
Does classpath.idx apply in my IDE?
No. The documentation says it is used only with java -jar, not in IDEs or with spring-boot:run or bootRun.
Sources
Last reviewed: 19 October 2026.
