package-lock.json 是否也意味着提高通过子资源完整性检查构建的应用程序的安全性？

Question

我已阅读以下有关package-lock.json文件的内容：

\n\n

\n

该文件旨在提交到源存储库中，并用于多种目的：

\n\n

\n
• 描述依赖关系树的单一表示，以便保证团队成员、部署和持续集成安装完全相同的依赖关系。
\n
• 为用户提供一种工具，可以将 \xe2\x80\x9ctime-travel\xe2\x80\x9d 恢复到 node_modules 的先前状态，而无需提交目录本身。
\n
• 通过可读的源代码控制差异来提高树更改的可见性。
\n
• 并通过允许 npm 跳过先前安装的软件包的重复元数据解析来优化安装过程。
\n

\n

\n\n

请参阅NPMJS 文档 package-lock.json 描述。

\n\n

但在同一链接的另一个片段中我看到：

\n\n

\n

完整性\xc2\xa7

\n\n

这是该资源的标准子资源完整性。

\n\n

\n
• 对于捆绑的依赖项，无论来源如何，都不包括在内。
\n
• 对于注册表源，这是注册表提供的完整性，或者如果\xe2\x80\x99t 在 shasum 中提供了 SHA1。
\n
• 对于 git 源，这是我们克隆的特定提交哈希。
\n
• 对于远程 tarball 源，这是基于文件 SHA512 的完整性。
\n
• 对于本地 tarball 源：这是基于文件 SHA512 的完整性字段。
\n

\n

\n\n

请参阅NPMJS 文档 package-lock.json 依赖项完整性。

\n\n

通过标准子资源完整性 (SRI) 的链接，我发现了以下内容：

\n\n

\n

1.1. 目标

\n\n

\n
• 第三方服务的妥协不应自动意味着包含其脚本的每个站点的妥协。内容作者将拥有一种机制，通过该机制他们可以指定对其加载的内容的期望，这意味着例如他们可以加载特定的脚本，而不是任何碰巧具有特定 URL 的脚本。
\n

\n

\n\n

请参阅W3C 子资源完整性

\n\n

所以我想知道为什么NPMJS 文档中的package-lock.json的描述中没有提到/列出安全目的。\n我个人也喜欢使用 package-lock.json 来提高应用程序安全性的想法（通过仔细检查锁定的实际依赖项并更改签入到我的 VCS 存储库的锁定文件，同时对我的package.json进行一些更改，以防止任何被篡改的依赖项进入我的应用程序）。
\n但也许我遗漏了一些东西，并且由于某些原因，锁定文件无法用于我上面解释的安全目的。

\n