依赖锁定实战：lockfile 能防住什么，防不住什么
一个被过度信任的机制
“我们用了 lockfile，依赖是锁定的。”这句话在安全评审里出现的频率很高，而它通常被当作一个终止讨论的答案。
lockfile 确实重要。但它解决的是构建一致性问题：让今天的构建和三个月后的构建装到完全相同的依赖树。这和“依赖是安全的”之间，隔着好几个问题。
lockfile 挡得住什么
版本漂移。 没有 lockfile 时，^1.2.0 这样的语义化版本范围会在每次安装时解析到最新的兼容版本。这意味着两个开发者、或者开发环境与 CI，可能装到不同的代码。lockfile 消除了这种不确定性。
间接依赖的意外变化。 你的直接依赖没变，但它的某个传递依赖发了新版本——没有 lockfile 时这会静默进入你的构建。这类变化正是很多“昨天还好好的”故障的来源。
部分投毒场景。 如果攻击者是通过发布一个新的恶意版本来投毒（这是最常见的手法之一），那么锁定在旧版本的项目不会自动受影响。这是 lockfile 提供的真实安全价值——但它是被动的、有条件的。
lockfile 挡不住什么
已经锁在里面的漏洞。 这是最直接的一点：如果你锁定的那个版本本身有漏洞，lockfile 会忠实地、可复现地、每次都把这个漏洞装进来。锁定不等于安全，它只等于“一致”。而且 lockfile 会让你更不容易注意到——因为不再有版本变化触发你去看一眼。
首次引入时就是恶意的包。 lockfile 锁的是你已经决定要用的东西。如果引入决策本身就错了（装了一个 typosquatting 包、装了一个 AI 幻觉出来的包名），lockfile 只会把这个错误固化下来。
同版本号内容被替换。 多数生态的 lockfile 会记录完整性校验值（如 npm 的 integrity 字段），这能防止内容被篡改。但如果你的 lockfile 是从一个已被污染的环境生成的，或者校验值本身就是基于恶意内容计算的，锁定就失去了意义——信任链的起点必须是干净的。
构建环境与依赖之外的攻击面。 构建脚本、CI 配置、镜像源、编译器本身——lockfile 对这些一概不管。SolarWinds 式的构建环节攻击，完全不需要碰依赖树。
过期本身的风险。 讽刺的是，lockfile 用得太好会带来新问题：依赖长期不更新，安全补丁进不来。锁定和更新之间需要平衡，而不是选一个极端。
配套实践
一、锁定 + 持续扫描，不可分开。
lockfile 提供了一份精确的依赖清单，这恰恰是持续漏洞比对的理想输入。把 lockfile 作为 SCA 的扫描对象，新漏洞情报到达时就能立即回答“我们受不受影响”。锁定的价值只有配合监控才能完全兑现——否则它只是把风险固定住了。
二、lockfile 变更进代码评审。
每一次 lockfile 变动都意味着依赖树发生了变化。这应当是一个显式的、被人看到的决策，而不是构建时的副产品。评审时要问：谁引入的、为什么、传递依赖带进来了什么。
三、分级的更新策略。
补丁版本可自动更新（安全修复通常在这一级）、次版本需测试通过、大版本必须人工评估。配合 Dependabot 或 Renovate 这类工具，让更新成为日常小步走，而不是一年一次的大扫除。
四、内部镜像 + 完整性校验。
所有依赖经由内部制品仓库获取，配合 lockfile 的完整性校验，构成“内容确定 + 来源可控”的双重保障。这也顺带解决了依赖混淆攻击。
五、区分开发依赖与运行时依赖。
lockfile 通常两者都包含，但风险性质不同：运行时依赖直接进入生产攻击面，开发依赖影响的是构建环境。分别设定更新节奏和审查强度，能把有限的注意力放在更要紧的地方。
正确的期待
lockfile 是可复现构建的基础设施，是依赖管理的必要条件——但不是充分条件。把它理解为“确定性工具”而非“安全工具”，你就会自然地去补上真正缺的那部分：持续的漏洞监控、显式的引入决策、以及对构建环境本身的保护。
一句话概括：lockfile 保证你每次装到同样的东西，SCA 才告诉你那个东西有没有问题。
---
