Use a version source (a BOM, dependencyManagement or a catalog) to choose versions, a lock or Enforcer rules to keep them from drifting, and verification to prove the files are what you expect. No single control does all three jobs, and none replaces vulnerability scanning.
Definitions
Pinning means making the version that resolves a deliberate choice rather than an accident. There are three separate questions:
- Which version do we want? A decision about versions.
- Does the build resolve exactly that? A repeatability check.
- Is the downloaded file genuine? An integrity check.
Decision table
| Control | Build tool | Answers | Does not answer |
|---|---|---|---|
| dependencyManagement and BOM imports | Maven | Which version, for direct and transitive artifacts | Whether it drifts, or whether the file is genuine |
| Enforcer rules | Maven | Whether versions converge, stay at upper bounds, avoid banned artifacts | Which version is safe |
| Exact versions, no ranges | Maven | Repeatability for that artifact | Transitive drift |
| Dependency constraints | Gradle | Which version, including transitive | Whether the file is genuine |
| Version catalogs | Gradle | One place to declare versions | They are requests, not guarantees |
| Dependency locking | Gradle | Whether resolution matches a committed lock | Which version is safe |
| Dependency verification | Gradle | Whether files match recorded checksums | Which version is safe |
| Wrapper checksum | Gradle | Whether the Gradle distribution is genuine | Anything about your libraries |
Read the details here: Maven BOMs, Maven mediation, Maven Enforcer, Gradle catalogs, Gradle locking, Gradle verification, wrapper checks.
A sensible baseline for each tool
Maven
- Manage versions in a parent POM or imported BOM.
- Replace version ranges with exact versions.
- Add dependencyConvergence and requireUpperBoundDeps to Enforcer.
- Set checksumPolicy to fail on repositories you declare, see Maven ranges and checksum policy.
Gradle
- Declare versions in a catalog.
- Add constraints for transitive fixes.
- Turn on locking and commit the lockfile.
- Add dependency verification and wrapper checksum.
Which to do first
If you can do only one thing this week, make the version choice explicit and reviewed. Everything else builds on that. The second step is repeatability, then integrity.
Where scanning fits
None of these controls tells you whether a version has a known vulnerability. Scanning runs against the result. The pinning controls make scan results stable, and the scan decides which pins to change.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a pull request can be held until a policy passes. That is the review point for any version change.
Where Safeguard fits
Safeguard offers dependency scanning and SBOMs, and policies and gates that can block changes carrying known vulnerable versions. Try the free scan.
Quick check
Does a lockfile make my dependencies safe?
No. It makes them repeatable. A locked version can still be vulnerable.
Do I need both a BOM and Enforcer in Maven?
They do different jobs. The BOM chooses versions, and Enforcer fails the build when the tree breaks your rules.
Last reviewed: 19 October 2026.
