dependencyManagement is a section of a Maven POM that fixes the versions of artifacts used across a project, including those pulled in transitively. A bill of materials, or BOM, is a POM that does this for a whole library family, and you pull it in with the import scope.
What dependencyManagement does
The Maven documentation describes it as a mechanism for centralising dependency information. Project authors can specify versions to use when an artifact appears in transitive dependencies, or when a dependency has no version declared.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>d</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</dependencyManagement>
A key point from the docs: dependency management takes precedence over dependency mediation for transitive dependencies. So a managed version beats the nearest wins rule, which is why it is the right tool for forcing a fix. It affects project dependencies, not the dependencies of plugins.
Inheritance has a limit
A parent POM can hold the managed list, and children inherit it. But a project can only inherit from a single parent. In larger organisations that is often not enough.
Importing a BOM
The import scope solves that. Declare a POM artifact with type pom and scope import inside dependencyManagement.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>maven</groupId>
<artifactId>A</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
The docs say import is only supported on a dependency of type pom in the dependencyManagement section. The import dependency is replaced by the effective list from the named POM's dependencyManagement.
The documentation describes the BOM pattern directly: the root of the project is the BOM POM, defining versions of all artifacts the library creates, and other projects import it.
Conflicts between imports
If you import two BOMs that both manage the same artifact, the first declared wins, as long as your own dependencyManagement does not declare it. Your own entry always takes priority. So order your imports on purpose.
Using this for security hygiene
- Put every shared version in one place, so a fix is a one line change.
- Import a BOM from the library family you use rather than pinning each artifact separately, so the members stay compatible with one another.
- Override a single managed version in your own dependencyManagement when an advisory demands it, and leave a note about when to remove it.
- Keep the managed list in a shared parent or BOM that many services use, and release changes to it like any other code.
Cautions
A managed version applies everywhere, so a bad choice spreads quickly. Test against the services that consume the BOM. Also remember that an unused entry does no harm but also no good, so prune entries for artifacts you no longer use.
Safeguard's dependency scanning highlights vulnerable packages in the resolved tree so you know which managed entry to change first. A free scan is available at gold.safeguard.sh/scan. For the conflict rule that managed versions override, see Maven dependency mediation.
Quick check
Does dependencyManagement add a dependency to my project?
No. It only fixes the version to use if the artifact appears. You still declare the dependency to use it.
What happens when two imported BOMs disagree?
The first declared wins, unless your own dependencyManagement specifies the artifact.
Sources
Last reviewed: 19 October 2026.
