Yes. A golden path template should commit a lockfile and make CI install strictly from it, so every build resolves the same dependency versions that were reviewed. Without one, a new release can change what you ship between two builds of the same commit.
What a lockfile gives a platform team
A lockfile records the exact resolved versions, including indirect dependencies. For a platform team, that turns "what is in this service?" from a guess into a file you can read, diff and scan. It also makes a pull request that changes dependencies visible, because the lockfile diff shows every version that moved.
The template matters because new services copy it. If the first commit has no lockfile, most teams never add one.
How each ecosystem enforces it
| Ecosystem | Commit this | CI command or setting | What happens on drift |
|---|---|---|---|
| npm | package-lock.json | npm ci | Exits with an error if the lock and package.json disagree |
| Gradle | lock files from dependency locking | Dependency locking on, STRICT mode in CI | Build fails on mismatched resolution; STRICT also fails if lock state is missing |
| pip | requirements.txt with hashes | --require-hashes | Install fails if a hash does not match |
The npm documentation says npm ci requires an existing package-lock.json or npm-shrinkwrap.json, and that if dependencies in the lock do not match package.json, it exits with an error instead of updating the lock. That is the behavior you want in CI.
Gradle's documentation warns that dynamic versions such as 1.+ can cause builds to change unexpectedly, and describes dependency locking, with a STRICT mode that also fails when a locked configuration has no lock state. You can update specific entries with the --update-locks flag.
pip's hash-checking mode, added in pip 8.0, uses hashes embedded in a requirements file to protect against remote tampering and network issues. It is all or nothing: once on, every requirement needs a hash.
Put it in the template, then test it
- Generate the lockfile in the template's own CI and commit the result.
- Set the CI install step to the strict command from the table.
- Add a check that fails when the lockfile is missing or changed by the build.
- Document the one command developers run to update the lock on purpose.
Keep the update path easy. If updating the lock is painful, people will bypass the strict install, and the control erodes.
Common objections
Teams sometimes say lockfiles freeze them on vulnerable versions. They do, until you update them, which is why you pair the lock with automated update pull requests. A lockfile makes updates deliberate and reviewable, not absent.
Another worry is merge conflicts in large lockfiles. Regenerating the file after a rebase usually resolves them. A short note in the template README saves many support questions.
Where Safeguard fits
A lockfile gives a scanner a precise inventory to work from. Safeguard reads dependency manifests and lockfiles to build SBOMs and scan for known vulnerabilities, then uses reachability analysis to help you sort what matters. A free scan is at gold.safeguard.sh/scan. For the wider pipeline picture, see what belongs in a golden pipeline.
Try it yourself
Open the inventory and look at how much of the list is indirect dependencies, which is exactly what a lockfile pins.
Click through it at your own pace, or open it full screen.
Quick check
Is npm install fine in CI if we have a lockfile?
Prefer npm ci. Per the npm docs it fails when the lock and package.json disagree, while npm install can update the lock.
Do libraries need lockfiles too?
Applications should always commit one. For libraries the practice varies, so decide per ecosystem, but commit one for the library's own CI so builds are repeatable.
Sources
Last reviewed: 19 October 2026.
