diff options
| -rw-r--r-- | content/weekly/83.md | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/content/weekly/83.md b/content/weekly/83.md index 0bb93a6d..83a246e1 100644 --- a/content/weekly/83.md +++ b/content/weekly/83.md @@ -40,6 +40,23 @@ Jim Nielsen 对此有些思考，他把 Avoid "Click Here" 规则定义为「系 不过这两类人也不是割裂的群体，毕竟爱好者也要吃饭。 +### 用 PNPM 规避供应链攻击 + +> [!note] 📃 +> [Mitigating supply chain attacks](https://pnpm.io/supply-chain-security) + +我已经在[先前的一篇文章](/article/js-problem/#依赖地狱和供应链投毒)中详细地报过菜名，列出了近期的 NPM 供应链投毒事件，结果仅仅过了一个月，[TanStack](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem) 就被投毒了。JavaScript 的包管理生态极度中心化，非常容易成为攻击者的众矢之的，而 NPM 本身的安全措施显然不够有效。如果暂时没办法离开混乱的 Node.js 生态（我们能想象一个没有 Node.js 的前端开发未来吗？），采取措施规避供应链攻击就很重要。 + +首先，大部分供应链攻击都利用 `postinstall`，安装依赖后直接在开发者的电脑上执行代码，偷取储存在本地的密钥等关键信息，那么默认禁用 `postinstall` 脚本执行就能避免这部分攻击。PNPM 默认禁用 `postinstall`，需要显式地设置 [allowBuilds](https://pnpm.io/settings#allowbuilds) 允许指定的依赖执行 `postinstall` 脚本。 + +第二个规避手段也是 PNPM 默认开启的，[blockExoticSubdeps](https://pnpm.io/settings#blockexoticsubdeps) 会影响子依赖的安装（也就是 `package.json` 中没有直接声明的依赖，是依赖的依赖） ，如果子依赖来自远程 Git 仓库或 Tarball 直链，就会默认阻拦，只允许来自受信的目录（registry）、部分受信的 GitHub 仓库和本地路径。这个手段的有效性我持怀疑态度，恶意软件也可能来自受信的目录吧，默认屏蔽所有远程 Git 仓库和 Tarball 直链不也是在让整个 JavaScript 生态变得更加中心化吗？一旦 NPM 这个中心出问题，整个生态都会出问题，而 NPM 的安全性大家有目共睹。 + +第三个规避手段在我看来是最有效的：推迟依赖更新，因为大部分供应链攻击都会在几小时内被发现和修复。v11 版本的 PNPM 默认推迟一天，一天内发布新版本的 NPM 包不会被 PNPM 解析。用户可以把 [minimumReleaseAge](https://pnpm.io/settings#minimumreleaseage) 设置项改得更长一些。 + +第四个手段是 PNPM 的信任策略，默认关闭，需要手动开启。[trustPolicy](https://pnpm.io/settings#trustpolicy) 目前只有一种策略，即 `no-downgrade`。开启后，如果某个包的信任等级在更新之后下降了，更新就会失败。信任等级是通过信任证据（trust evidence），我想应该是发布者的签名之类的，文档里没有写得很清楚。比方说先前的版本中，作者有给包签名，在某次更新中没有签名，那么信任等级就下降了，此时更新就会失败。 + +最后，无论如何都应该使用锁文件（lockfile），锁定依赖的版本号，并且要把锁文件 commit 到 Git 仓库当中。 + --- ## 星群 |