No, you do not need lockfiles to start, but they make results exact. Gradle dependency locking records the precise versions a project used, so a scanner can read facts instead of resolving ranges. For a legacy monorepo, generate lockfiles for the services you care about first, then expand.
What a Gradle lockfile does
The Gradle user guide describes a lockfile as a record of the exact versions of dependencies used in a project, allowing verification during builds for consistent results across environments and over time. It also says the file should be kept in source control so everyone uses the same versions.
For scanning, the effect is simple. With a lockfile the scanner reads a fixed list. Without one, it sees declarations such as dynamic versions, and the answer can change from one day to the next.
Where the files live
Lockfiles sit at the root of each project or subproject directory, with the build script itself getting its own separate lockfile. In a monorepo with sixty Gradle subprojects, that is up to sixty new files. Plan the review accordingly.
Should you generate them before scanning?
| Situation | Recommendation |
|---|---|
| Services built and shipped regularly | Generate lockfiles; they also make builds repeatable |
| Services frozen but running | Scan the manifest first; generate lockfiles only if you will rebuild |
| Dynamic versions widely used | Generate lockfiles soon; findings drift without them |
| Build too old to run | Skip; scan declarations and mark results approximate |
Steps for the first lockfile commit
- Pick one active subproject as a pilot.
- Enable locking in the build configuration for that subproject, following the Gradle guide.
- Generate the lockfile on a clean machine or in CI, not on a developer laptop with a warm cache.
- Review the diff: the versions in it should match what runs in production. If they do not, you have found a drift problem before the scanner did.
- Commit the lockfile with a short note in the pull request about what it is.
- Repeat for the next ten subprojects, then script the rest.
Mistakes to avoid
- Generating lockfiles with a different Java version than production uses. Some resolution can differ.
- Committing lockfiles and then never updating them. A stale lockfile pins a vulnerable version quietly. Schedule regular regeneration, and make dependency update pull requests include the lockfile change.
- Treating the lockfile as the fix. It records versions; it does not choose safe ones.
Explaining it to developers
Teams worry that locking will slow them down. The honest answer: it adds one file to review when dependencies change, and in return builds stop changing under them. Say that, and offer to do the first generation for them.
Where Safeguard fits
Safeguard's dependency scanning reads lockfiles and manifests, and autonomous remediation can open fix pull requests, which stays off by default with every category on Manual until your team turns it on. See https://gold.safeguard.sh/scan for a free scan.
Quick check
Do lockfiles help with transitive dependencies?
Yes. The lockfile records the resolved versions of the whole set, so transitive packages show up with exact versions.
Who should own lockfile updates?
The team that owns the subproject. A platform group can supply a script, but the owning team should review the change.
Sources
Last reviewed: 19 October 2026.
