包管理器需要全局钩子：构建去中心化的软件供应链安全防线

背景

当前，我们赖以生存的打包生态系统正面临持续不断的攻击与威胁。为了应对这些风险，业界正在探索几种主要的防御机制，其中最引人注目的包括“依赖冷却期”（Dependency Cooldowns）和“依赖策略”（Dependency Policies）。例如，Homebrew 就实施了一项冷却机制：在从 Python 或 NPM 生态系统中自动提升（bump）一个包之前，会强制等待一天。

与此同时，几乎所有主流的安全供应商都推出了针对包管理的“防火墙”解决方案，如 Socket、Datadog 和 Safedep 等。这些工具通常通过以下几种方式运作：

• 注册表模式（Registry Mode）：将包管理器指向本地注册表，由其代理请求并根据安全判断阻断访问。
• Shell 包装器（Shell Wrapper）：通过别名（alias）包装包管理器命令，拦截用户指令。然而，Shell 别名构成的安全边界非常脆弱。
• 中间人模式（MITM Mode）：将其配置为 HTTPS 代理，从而拦截并检查网络流量。

作者对这些现有的防御手段并不满意。上述所有方案都严重依赖于注册表 API 或命令架构。此外，作者也不喜欢那些需要额外基础设施（如托管式透传注册表进行扫描）的机制，因为这些基础设施通常只有大型企业才能负担和访问，普通个体开发者难以企及。

核心内容

作者提出了一种激进但更具普适性的包管理器改进理念：每个包管理器都应支持“全局钩子”（Global Hooks）。

什么是全局钩子？

“全局钩子”指的是在包管理器工作流的各个阶段之前，配置并运行的全局代码。这与“本地包钩子”（Local Package Hooks）有本质区别：

• 本地包钩子：是针对特定包的代码，在包安装期间、之前或之后运行。
• 全局钩子：是全局配置，作用于整个系统或工作区，独立于单个包的存在。

作者认为，“冷却期”和“依赖策略”仅仅是具体的实现细节，一个完善的钩子系统应当能够原生支持这些功能的实现，而无需重新发明轮子。

现有生态的局限性

作者通过构建一个基于 StepSecurity OSS Feed 和 pnpm 钩子系统的依赖策略概念验证（PoC），展示了全局钩子在安全检测中的潜力：每次包安装时，都会针对威胁情报源进行检查，若发现恶意软件则抛出异常。然而，现有的主流包管理器在此方面存在明显短板：

1. pnpm：其钩子系统基于工作区（workspace）级别，无法为全局安装运行钩子，也无法进行全局配置。
2. NPM：目前不支持钩子功能。
3. Yarn：虽然拥有供插件使用的钩子 API，但是否支持全局配置尚不明确。

跨平台的解决方案

尽管 Node.js 生态存在局限，但在其他包管理器中，同样的系统思路可以解决类似问题。以 Arch Linux 的 AUR（Arch User Repository）助手为例：

• 助手可以添加钩子脚本。
• 用户可以将自己的威胁情报源或恶意软件扫描器配置为 PreClone（预克隆）或 PreBuild（预构建）阶段的钩子。
• 关键点：钩子本身不必是一个“包”，它应当被视为一种全局配置。

行动呼吁

我们不应在每个包管理器中重复发明防御功能。作者呼吁社区向各自的包管理器提出支持全局钩子的功能请求：

• pnpm：已提交功能请求。
• uv：存在相关 Issue。
• Paru：已支持 PreBuild 钩子。
• yay：其钩子系统已升级，支持 UpgradeSelect 事件，可用于执行冷却检查，且易于扩展以支持威胁情报源。

关键要点

• 去中心化安全：现有的包管理安全方案（如注册表代理、MITM 代理）依赖额外基础设施，对个体开发者不友好。全局钩子提供了一种无需额外基础设施的本地化解决方案。
• 配置即代码：将安全策略（如冷却期、依赖策略）从硬编码或外部服务中解耦，转化为可配置的全局钩子脚本，提高了灵活性和可维护性。
• 当前生态缺陷：主流 Node.js 包管理器（NPM, pnpm, Yarn）在全局钩子支持上存在缺失或局限，导致无法统一实施全局安全策略。
• 通用性原则：安全检测（如恶意软件扫描、威胁情报匹配）应作为包管理器工作流（如安装前、构建前）的标准扩展点，而非特定于某个包或某个注册表的特性。
• 社区驱动改进：作者通过具体的 Issue 和 PR 链接，推动 pnpm、uv、Paru 和 yay 等项目完善钩子系统，旨在建立行业通用的安全标准。

意义与影响

这一提议标志着软件供应链安全从“中心化防御”向“边缘化、用户可控防御”的转变。

1. 降低安全门槛：通过允许个体开发者配置全局钩子，无需部署昂贵的企业级扫描基础设施，即可实现类似的安全防护。这使得安全能力下沉到每一个开发者的本地环境。
2. 标准化防御接口：如果所有包管理器都支持全局钩子，安全厂商和开源社区可以开发通用的钩子脚本或插件，直接分发给用户，而非针对每个包管理器开发专用的代理或插件。这将极大降低安全工具的开发和维护成本。
3. 增强透明度与控制权：用户不再完全依赖注册表或第三方代理的黑盒判断，而是可以通过查看和配置钩子脚本，明确知道在安装或构建过程中发生了什么，以及为何被阻断。
4. 推动包管理器架构演进：这一需求可能促使 NPM、Yarn 等老牌包管理器重新审视其架构设计，引入更强大的扩展机制，以应对日益复杂的软件供应链攻击。

总之，全局钩子不仅是技术实现上的优化，更是赋予开发者更多控制权、构建更 resilient（弹性）的软件生态系统的关键一步。