A correct Maven SBOM lists the versions Maven resolves, not the ones you see in a single pom.xml. Dependency mediation picks the nearest definition, and dependencyManagement can override versions of transitive artifacts. A tool that only reads declared versions will report numbers your build never used.
What Maven does before it picks a version
The Maven documentation describes several mechanisms that decide what ends up on the classpath. Three matter for an SBOM.
- Dependency mediation. When more than one version of an artifact appears, Maven picks the nearest definition, meaning the one closest to your project in the dependency tree. If two versions sit at the same depth, the first declaration wins.
- Dependency management. An author can pin the version of an artifact in a dependencyManagement section, and that takes precedence over mediation for transitive dependencies.
- Scope, exclusions and optional dependencies. These control whether a dependency is included at all, and when.
Here is the example from the Maven guide. If your project A depends on B, which leads through C to version 2.0 of an artifact D, and A also depends on E, which needs D 1.0, then D 1.0 is used, because the path through E is shorter. A pom.xml for B alone would say 2.0. The SBOM for A must say 1.0.
Why this trips up SBOMs
Reading a pom.xml gives you declared intent for one module. It does not apply inheritance from a parent pom, imported bills of materials, property substitution such as a version held in a variable, or mediation across the whole tree. Each skipped step is a chance to list a version that is not the real one, which means a vulnerability match can be wrong in either direction.
| Approach | Resolves mediation? | Handles parent and imports? | Risk |
|---|---|---|---|
| Parse one pom.xml as text | No | No | Wrong versions, missing transitives |
| Ask the build tool for the resolved tree | Yes | Yes | Needs the build to run |
| Scan the built artifact | Reflects what was packaged | Not applicable | May miss scope detail |
A test that exposes the problem
- Pick a multi-module project that uses a parent pom and at least one imported bill of materials.
- Ask Maven for its dependency tree and save the resolved name and version pairs.
- Generate the SBOM with the tool you are evaluating.
- Compare the two. Any version in the SBOM that differs from the resolved tree is an accuracy bug.
- Check that test scope dependencies are labelled as test and not mixed in with runtime ones.
Maven's own documentation adds that the dependency plugin can analyse declared and used dependencies, which helps you spot artifacts that are declared but never used and used but never declared.
Multi-module projects
For aggregate builds, decide whether you want one SBOM per module, or one for the deliverable. A web service and a shared library have different audiences. Where your product is a single war or jar, the SBOM for that artifact is the one customers care about. Where several deliverables share modules, one SBOM each is clearer than a single combined file.
Where Safeguard fits
Safeguard's dependency scanning is built to work from resolved dependency information so vulnerability matches reflect what you ship, with reachability analysis to help sort which findings matter. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Why is the version in my SBOM different from my pom.xml?
Maven mediation or dependencyManagement probably selected a different version. The SBOM should show the resolved one.
Do test scope dependencies belong in the SBOM?
They can, if labelled with their scope. Runtime consumers usually want them filtered out.
Sources
Last reviewed: 19 October 2026.
