Yes, if your builds install from a lockfile and fail when it does not match the manifest. Say that, and be clear about what it does not do: pinning makes builds repeatable, but it does not make the pinned version safe.
What pinning means
A manifest such as package.json states acceptable version ranges. A lockfile records the exact versions that were resolved, including transitive dependencies. Installing from the lockfile reproduces the same set every time.
npm's documentation for npm ci explains the behavior customers care about: it requires an existing package lock or shrinkwrap file, and if the dependencies in the lock do not match the manifest it exits with an error instead of updating the lock. It is described as meant for automated environments such as test platforms, continuous integration and deployment.
What a good answer includes
- Lockfiles are committed for every deployable project.
- CI and release builds install from the lock, not from ranges.
- Lock changes appear in pull requests and are reviewed.
- Updates are deliberate, through a routine process.
Other ecosystems have equivalents, so name the ones you actually use.
What pinning does not do
| Misconception | Reality |
|---|---|
| Pinned means secure | A pinned version can contain a known flaw |
| Pinned means never updated | You still need a path to upgrade |
| Lockfile covers the image | OS packages and base layers sit outside it |
| Lockfile proves origin | It records versions and integrity data, not trust |
Pinning without a refresh process creates stale software. Pair it with automated advisory matching and a regular update cadence.
Reply template
Our builds install from committed lockfiles, and the build fails if the lock and manifest disagree. Lockfile changes go through code review. Dependency updates are applied on a regular schedule and promptly for significant advisories.
When pinning gets awkward
Libraries you publish for others should declare sensible ranges, while applications you deploy should lock. If you ship both, describe each separately. If some services still install from ranges, say which ones and when that changes.
For the update side, see automated dependency updates and patch management.
How to prove it in a questionnaire
Customers sometimes ask for evidence of pinning. Three small artifacts usually suffice. First, a screenshot or export showing that lockfiles are committed in the repositories that matter. Second, a CI configuration excerpt showing the install step uses the lock. Third, a pull request that changed the lock and shows a reviewer comment.
Check before you answer that every deployable repository follows the rule. One service that installs from ranges can make a blanket statement false, and the customer's follow up will find it. Listing the exceptions and the date they will be fixed is the safer route.
Quick check
Is a lockfile an SBOM?
No. It is useful input for one, but an SBOM is a standard format meant to be shared and includes more metadata.
Should we pin to exact versions in the manifest too?
It is a choice. The lockfile already fixes exact versions for installs, so the key rule is installing from it.
Sources
Last reviewed: 19 October 2026.
