Scan from the root aggregator POM so Maven's reactor sees every module and resolves versions the way your build does. Scanning one module folder alone can miss versions pinned in the parent. Then check that the report lists each module, not just the top level.
What the reactor is
The Maven guide for multiple modules says the reactor collects all the modules to build, sorts them into the correct build order, and builds them in that order. The modules element in the parent POM lists what the reactor collects. Order comes from real relationships first, such as one module depending on another, and falls back to the declared order.
The guide adds a detail that matters for security: only instantiated references affect sorting. Entries in dependencyManagement and pluginManagement do not change the order.
Why the parent matters
In many Maven projects the parent POM holds a dependencyManagement section or imports a bill of materials. Child modules then declare a dependency with no version. The version comes from the parent.
If you scan a child folder with a tool that reads only that one POM, it sees a dependency with no version. It either skips it or guesses. Resolving from the root avoids that.
| Scan start | What it sees | Risk |
|---|---|---|
| Root aggregator | Parent, managed versions, all modules | Complete, but slower |
| Single child folder | That module, and maybe not the parent | Missing or guessed versions |
| Each child, with parent resolved | Per module results, correct versions | Needs the parent reachable |
Steps
- Identify the aggregator. It is the POM with pom packaging that lists modules.
- Build the dependency tree from the root so managed versions resolve.
- Confirm the module count in your report matches the modules element, including nested aggregators.
- Check for modules that are in the folder tree but not in the modules list. They are not built, so decide whether they belong in scope.
A common command for the tree is the dependency plugin run from the root:
mvn dependency:tree
The reactor runs it for each module in order. The Maven guide also lists switches for the reactor, including one that builds a selected project together with the modules it depends on. Use that when you want results for one deliverable and its internal dependencies without the rest of the build.
Internal modules are not third party
One module depending on another is an internal edge. Your scan should treat sibling modules as your own code. If your report shows an internal module as an unknown package, the tool did not read the reactor, and you should resolve from the root.
Profiles can hide dependencies
A dependency declared inside a profile only appears when that profile is active. If production builds use a profile your scan does not activate, the scan is missing part of what you ship. Run the scan with the same profiles as the release build.
Safeguard scans Maven projects and builds SBOMs per project. See the troubleshooting guidance in the related post on scanning a large monorepo with the CLI if the root scan runs long, and try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Open the demo and trace one component back to the file that declares it. In a multi-module build that file may be a parent POM.
Click through it at your own pace, or open it full screen.
Quick check
Does dependencyManagement change module build order?
No. The Maven guide says only instantiated references, such as real dependencies, affect the reactor sort order.
Why does a child module scan show dependencies with no version?
The version is probably managed in the parent POM. Resolve from the root so the managed version is applied.
Sources
Last reviewed: 19 October 2026.
