Does a scanner resolve versions from a Maven BOM or parent POM?

It depends on the scanner. Maven can set a dependency version in a parent POM or an imported BOM, so the module's own pom.xml may show no version at all. A scanner that reads only that file misses the dependency or guesses. Scanners that resolve the effective POM report the real version.

How Maven hides the version

The Maven dependency mechanism guide describes dependency management as a place to control versions of artifacts, including those used in transitive dependencies. A module can then declare a dependency with no version, and the version comes from the managed section.

The same guide documents the import scope. It applies to a dependency of type pom in the dependencyManagement section and means the dependency is replaced by the effective list of dependencies from that POM's dependencyManagement section. That is how a BOM works: one file pins many versions.

So a module POM can look like this.

<dependency>
  <groupId>org.example</groupId>
  <artifactId>some-library</artifactId>
</dependency>

No version. The truth lives elsewhere.

Where scanners go wrong

• The scanner reads only the module file and records the dependency with no version, so nothing matches.
• It reads a property placeholder, not the resolved value.
• It resolves the parent but not an imported BOM.
• It ignores a managed override, so a pinned transitive version is reported as an older one.

How to test your scanner

1. Pick a module whose POM has a dependency with no version.
2. Run mvn dependency:tree and note the resolved version of that artifact.
3. Look at the scan output for the same artifact.
4. If the versions differ or the artifact is absent, the scanner is not resolving management.
5. Repeat once for a dependency pinned in an imported BOM.

You can also feed the scanner the resolved result. Generating an SBOM with a Maven plugin that works from the resolved graph gives exact versions. See CycloneDX SBOM for a multi module Maven aggregate.

What to do when it fails

1. Prefer scanning the resolved dependency tree over raw POM files.
2. Keep managed versions in one BOM so there is a single place to review.
3. Record the scanner limitation in your coverage notes so nobody assumes it is complete.

Try it yourself

Click through it at your own pace, or open it full screen. Look for the version on each component and ask where that number came from.

Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan. Use the dependency tree test above to judge any tool's Maven handling.

Quick check

Sources

• Maven: introduction to the dependency mechanism

Last reviewed: 19 October 2026.