Key takeaway: A version range in a manifest is a statement of trust in every future release of that package. A lockfile converts that open-ended trust into a specific, auditable decision.
What a Range Actually Authorises
"library": "^2.3.0" permits any 2.x release. That includes versions published after your last review, by maintainers who may have changed, from accounts that may have been compromised.
Without a lockfile, two builds of identical source code minutes apart can install different dependency trees. The build that succeeded in CI is not necessarily the build that shipped, and reproducing a reported bug becomes guesswork.
Several widely reported incidents followed the same shape: a maintainer account was compromised, a malicious patch release was published, and every project resolving fresh pulled it within hours. Projects with committed lockfiles were unaffected until they deliberately updated.
Direct Dependencies Are the Small Part
A typical application declares perhaps forty dependencies and installs eight hundred. The transitive set is where the exposure concentrates, because nobody reviewed it and most developers cannot name a tenth of it.
A lockfile records the entire resolved graph with integrity hashes. That gives three properties that matter:
- Reproducibility — the same input produces the same tree on every machine
- Reviewability — a dependency change appears in a diff instead of happening silently
- Integrity — hashes detect a package whose contents changed after publication
The second property is the one teams undervalue. When a lockfile is committed, updating a transitive dependency requires a commit that a human approves. That is the difference between a supply chain change being a decision and being an accident.
Practical Discipline
| Practice | Why it matters |
|---|---|
| Commit the lockfile | Makes the dependency graph an artefact under review |
Use npm ci / pip install --require-hashes in CI |
Fails on mismatch instead of silently resolving |
| Pin build-tool versions too | Compilers and bundlers execute code as well |
| Review lockfile diffs for unexpected additions | A new transitive package deserves a glance |
| Automate updates on a schedule | Stale dependencies are their own risk |
The tension worth naming is that pinning creates staleness, and staleness means unpatched vulnerabilities. The resolution is not to stop pinning — it is to update deliberately and frequently through automated pull requests that a human merges.
Install scripts deserve separate attention. A package that runs code at install time executes on developer machines and CI runners with whatever privileges those have. Disabling install scripts by default and allowlisting the few genuinely needed removes a large attack surface cheaply.
The Bottom Line
Commit the lockfile, use the CI flag that refuses to resolve outside it, and treat lockfile diffs as reviewable changes rather than noise. Then schedule regular deliberate updates so that pinning does not become neglect.
