代码仓库有依赖锁文件，供应商风险团队究竟能确认什么？
package-lock.json 是带日期的依赖解析快照，不是交付制品的证据。本文用五层复核把仓库观察与供应商责任决定分开。
package-lock.json 能支撑一条带日期的观察：npm 在某个时间点为该仓库解析出了怎样的依赖树。它不能证明交付制品里装了什么、谁在负责更新频率、以及买方是否在明确策略下接受了这套依赖。把锁文件当成产品依赖的证明，等于跳过了将仓库快照与供应商责任决定分开的五层证据。
先理清核心概念。锁文件（lockfile）——npm 项目中的 package-lock.json——是 npm 修改 node_modules 树或 package.json 时自动生成的 JSON 文件。它记录了已解析依赖树（resolved dependency tree）：满足项目语义化版本约束的全部直接和传递依赖，包含每个包的精确版本、registry 地址和完整性哈希。**制品（artifact）**是实际交付给客户的构建产出——容器镜像、二进制文件、压缩包或部署包。**开源安全基金会（OpenSSF）**是跨行业组织，维护着 Scorecard 这套通过自动化检查评估开源项目安全实践的工具。对供应商风险情报负责人而言，锁文件与交付制品之间的差距，正是供应商声明与证据交汇的位置。
锁文件能确认什么
已提交到仓库的锁文件能确认：在文件或其提交记录的日期，npm 为该仓库解析出了一个特定依赖树。它提供直接和传递依赖的精确包名与版本、可独立验证的 registry 地址和完整性哈希，以及一个可重现的起点——另一台机器用同一份锁文件运行 npm ci 应产出完全相同的 node_modules 树。
这些都是真实的观察，也确有价值。它们让风险团队自信地回答一个很窄的问题：“npm 在该日期为这个仓库解析出了什么？“它们不能回答”供应商构建、交付、部署、维护了什么？“——而那才是供应商风险评估存在的目的。
来自 npm 的关键事实
npm CLI v11 文档（2026 年 8 月 3 日访问）指出，package-lock.json “描述了所生成的精确依赖树”，同时声明该文件“不会被发布”且“在顶层包之外的任何位置被发现时会被忽略”。风险团队在读的是一份本地开发产物——连生态系统自身都视其为上下文相关的文件。
OpenSSF Scorecard 检查文档（2026 年 8 月 3 日获取）给出了平行警示。其 Maintained 检查在项目过去 90 天每周至少一次提交时给出最高分，但“明确告知外部用户应考虑通常需要较少活动的软件”。多项检测类检查——CI-Tests、Dependency-Update-Tool、Fuzzing、Packaging、SAST——均附有警告：低分“并非项目存在风险的明确标志，因为自动化检测可能遗漏有效实践”。一个本可标记维护风险的工具，告诉读者别把自己的输出当定论。
两处来源共同描绘了一扇窄窗口：锁文件是带日期的依赖树观察，自动化维护信号需要人工解读。没有哪处把仓库快照变成了交付产品声明。
五层证据复核
严格的供应商风险评估，将锁文件提供的信息与采购或安全决策所需的信息分开。五层证据跨越这个距离：
| 证据层 | 能回答什么 | 不能回答什么 |
|---|---|---|
| 1. 锁文件身份与日期 | 哪份锁文件、来自哪个仓库、何时提交 | 该提交是否代表交付产品 |
| 2. 已解析依赖树 | npm 解析出的精确包名、版本和完整性哈希 | 构建是否使用了这些精确解析结果 |
| 3. 构建与制品匹配 | 能否从锁文件和构建指令重现制品 | 交付制品是否来自该锁文件在该提交的构建 |
| 4. 更新与漏洞负责人 | 谁在做依赖更新分类、按什么频率、依据什么策略 | 依赖更新是否到达买方收到的制品 |
| 5. 负责的供应商决定 | 供应商是否向买方陈述了依赖集，买方是否在明确策略下接受了它 | 供应商未明确陈述的一切 |
第五层是大多数评估会跳过的一层。锁文件描述的是一棵树；供应商风险决策要求供应商为依赖集负责，买方在明确策略下接受或拒绝它。
一次复合仓库审查示例
以下为复合评估——非真实供应商，而是风险负责人经常遇到的代表性模式。
一个标记 v2.4.0 的仓库包含 package-lock.json，解析出 847 个包，于 2026 年 3 月 14 日提交。截至评估日期，四个传递依赖存在已知 CVE。
第 1 层（身份与日期）： 锁文件属于仓库 frontend-console，分支 main，提交 a3f7c12，日期 2026 年 3 月 14 日。一条带日期的观察——仅此而已。
第 2 层（已解析树）： npm 解析出 847 个包。四个带 CVE 的包经由一个上次更新在八个月前的日志工具库进入。
第 3 层（构建与制品匹配）： CI 构建时运行 npm ci，但团队未验证标记 v2.4.0 的容器镜像是否从提交 a3f7c12 构建。标签可被覆盖。
第 4 层（更新与漏洞负责人）： 仓库无 Dependabot 或 Renovate 配置。四个 CVE 在锁文件日期之后才披露——提交时尚不可知，且无自动化流程在交付制品中发现它们。
第 5 层（负责的供应商决定）： 供应商未提供 v2.4.0 的软件物料清单，买方采购检查清单也未要求。已锁定的依赖树已知；交付制品和接受决定未知。
[示意性复合消息——非客户记录] 某供应商工程负责人在技术频道发消息：“锁文件今早更新，所有依赖已到最新稳定版，应该没问题。“风险负责人读到的是一条关于仓库状态的声明。它不能确认同一棵树被用于产生交付制品的构建，也不能确认消息滚出屏幕后谁在负责更新频率。
仍然未知：交付的容器镜像是否从提交 a3f7c12 构建，四个 CVE 在部署语境中是否可被利用，供应商是否会在下一个评估窗口前修补它们。供应商工程团队须验证构建到制品的链条；买方风险团队须决定证据缺口在自己策略下是否可接受。
最有力的反对意见与边界
最有力的反对意见很实际：“锁文件已提交到仓库，所以我们确切知道供应商用了什么。拒绝把它当证据，需要我们没有的资源。”
边界不在于拒绝锁文件。边界在于说清它提供了什么——带日期的依赖树观察——并把超出这条观察的一切视为未经验证，直到额外证据层被满足。资源有限的团队仍可记录缺口：“我们有仓库 frontend-console 日期为 2026 年 3 月 14 日的锁文件。没有证据表明交付制品从该提交构建、四个已知 CVE 已被分类处理、或供应商已在被接受的策略下向我们陈述了依赖集。“这是一项完整、可辩护的发现，比”锁文件看起来没问题“更有力。
强化供应商审查的额外证据层——构建可重现性、分支保护与供应商来源信号——在相关评估中有更详细讨论，可逐步采纳。参见供应商资质与产品来源信号和分支保护作为供应商风险证据。
FAQ
锁文件能证明供应商在积极维护软件吗？
不能。锁文件记录特定日期的已解析依赖树。积极维护需要持续提交活动、漏洞分类和更新频率——静态锁文件无法展示这些。OpenSSF Scorecard 的 Maintained 检查将过去 90 天每周至少一次提交视为最高分，但同时告知外部评估者应考虑通常需要较少活动的软件（Scorecard 检查文档，2026 年 8 月 3 日获取）。
如果锁文件今天没有显示已知漏洞，产品就是安全的吗？
扫描时刻干净的锁文件说明不了交付制品的情况。构建可能引入额外组件，部署版本可能与扫描版本不同，新漏洞在持续披露。锁文件快照是时间点观察，不是安全保证。风险负责人必须验证制品而非仓库快照。
我们的评估应该拒绝不把锁文件提交到仓库的供应商吗？
不应自动拒绝。npm CLI v11 文档声明 package-lock.json“不会被发布”且“在顶层包之外的任何位置被发现时会被忽略”（2026 年 8 月 3 日访问）。有些团队在 CI 中生成锁文件而不提交。缺失只意味着少了一个数据点，本身不代表实践不佳。应询问供应商如何在你所在组织实际收到的制品中锁定和验证依赖。
独立应用五层证据之后，需要超出周期性仓库审查来持续跟踪供应商风险的团队，可从供应商已在使用的沟通渠道中提取候选信号。TOP Prospect 只处理用户主动连接且有权访问的 Telegram 群，产生供人工审核的候选项而非事实认证，最终决定由人做出，且不会自动联系群成员。详情见 Telegram 商业信号情报。
下一次供应商风险审查报告放到你桌上，只勾了“锁文件存在”而没有更多内容时，你有一个具体且低成本的下一步：索要交付制品所基于的提交哈希，答案未到则记录缺口。
常见问题
锁文件能证明供应商在积极维护软件吗？
不能。锁文件记录特定日期的已解析依赖树。积极维护需要持续提交活动、漏洞分类和更新频率——静态锁文件无法展示这些。OpenSSF Scorecard 的 Maintained 检查将过去 90 天每周至少一次提交视为最高分，但同时告知外部评估者应考虑通常需要较少活动的软件（Scorecard 检查文档，2026 年 8 月 3 日获取）。
如果锁文件今天没有显示已知漏洞，产品就是安全的吗？
扫描时刻干净的锁文件说明不了交付制品的情况。构建可能引入额外组件，部署版本可能与扫描版本不同，新漏洞在持续披露。锁文件快照是时间点观察，不是安全保证。风险负责人必须验证制品而非仓库快照。
我们的评估应该拒绝不把锁文件提交到仓库的供应商吗？
不应自动拒绝。npm CLI v11 文档声明 package-lock.json"不会被发布"且"在顶层包之外的任何位置被发现时会被忽略"（2026 年 8 月 3 日访问）。有些团队在 CI 中生成锁文件而不提交。缺失只意味着少了一个数据点，本身不代表实践不佳。应询问供应商如何在你所在组织实际收到的制品中锁定和验证依赖。 --- 独立应用五层证据之后，需要超出周期性仓库审查来持续跟踪供应商风险的团队，可从供应商已在使用的沟通渠道中提取候选信号。TOP Prospect 只处理用户主动连接且有权访问的 Telegram 群，产生供人工审核的候选项而非事实认证，最终决定由人做出，且不会自动联系群成员。详情见 [Telegram 商业信号情报](/zh/telegram-business-signal-intelligence/)。 下一次供应商风险审查报告放到你桌上，只勾了"锁文件存在"而没有更多内容时，你有一个具体且低成本的下一步：索要交付制品所基于的提交哈希，答案未到则记录缺口。