Usually the SBOM lists the dependencies Maven resolved for the project, not what ended up inside the jar after shading. The shade plugin packages dependencies into one jar and can rename their packages. So check the SBOM against the jar contents, and note any shaded libraries explicitly.
What shading does
The Maven Shade Plugin describes itself as providing the capability to package the artifact in an uber jar, including its dependencies, and to shade, meaning rename, the packages of some of the dependencies. It runs in the package phase.
That is great for deployment and awkward for inventory. A library can be inside your jar under a different package name, with no metadata file next to it that a scanner would recognize.
What the SBOM plugin documents
The CycloneDX Maven plugin creates a BOM per module with makeBom, one aggregate BOM across a multi module build with makeAggregateBom, and package level BOMs for war and ear modules. Its documentation does not mention shaded or uber jars. By default it includes runtime, compile, provided and system scopes, and leaves out test scope.
So treat the result as a statement about resolved dependencies. Whether it matches the shaded artifact is something you verify.
Steps to check
- Generate the SBOM from the build as normal.
- List the contents of the shaded jar and note the top level package names.
- Match package names to SBOM components. Names that match no component are either your own code, or shaded or renamed libraries.
- For relocated libraries, identify the source from the shade configuration, which lists what was relocated and from where.
- Record the findings in the SBOM, as components you add by hand, or in a note that travels with it.
- Scan the final jar with a tool that reads artifacts, then compare with the build based SBOM.
Why it matters for security
If a vulnerable library is shaded into your jar, a scan of the declared dependencies may flag it, but a scan of the jar alone may not recognize it after renaming. Neither gives the full picture. Combining the two views does.
| View | Sees renamed classes | Sees declared version |
|---|---|---|
| Build based SBOM | Not directly | Yes |
| Jar content scan | Only if recognizable | Sometimes |
| Both together | Mostly | Yes |
Practical advice
- Prefer not to shade where you can, so the dependency tree stays visible.
- When you must, pin the shaded library versions and list them in your docs.
- Keep the shade configuration in the repository, so a reviewer can see what is relocated.
Quick check
Does the CycloneDX Maven plugin handle shaded jars?
Its documentation does not mention them, so verify the result against your jar.
Will test dependencies be in the SBOM?
Not by default. Test scope is off unless you enable it.
Safeguard's SBOM and dependency scanning covers Maven projects, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
