'No way to prevent this,' says only package manager where this regularly happens
449 points
• 3 days ago
• Article
Link
npm registry 遭遇大规模供应链攻击，导致数百万企业级应用被入侵、数十亿用户记录泄露。 JavaScript 生态的开发者们反应如出一辙：这完全不可避免。高级前端工程师 Mark Vance 精准地捕捉到了这种心态，称这"只是构建现代 Web 应用的代价"，这一观点在社区中广为认同。社区甚至会为像字符串大写这种基础任务，依赖由匿名陌生人维护的未经审查、层层嵌套的包。此次攻击利用了一个长期无人维护的工具包，在全球生产构建中注入了加密矿工，但开发者们仍把它归为不可预见的悲剧。
与此同时，Go 、 Rust 以及主要依赖原生 Web API 的生态系统报告为零事故，这得益于它们健全的标准库和内置于核心工具的严格加密验证。两者的对比突显出方法论上的关键差异：这些生态系统尽量减少对第三方代码的依赖，并把安全当作基础性考量，而不是事后补救。相比之下，npm 生态的默认行为仍是在本地机器上执行任意安装脚本，这一做法已多次导致灾难性后果。
一位 npm 发言人对受害者表示同情，但称即便 registry 存在已知漏洞，也没有任何 registry 策略或构建沙箱能阻止此次攻击。这番表态反映了 JavaScript 社区反复出现的模式：强调韧性胜过预防，把安全事件视为不可避免的自然灾害，而非系统性失误。在下一次事件到来之前，开发者们只能轮换 AWS 密钥、发发祈祷——这样的循环看来短期内难以打破。
After a massive supply chain attack on the npm registry compromised millions of enterprise applications and exposed billions of user records, developers across the JavaScript ecosystem responded with a familiar refrain: this was entirely unavoidable. Senior Frontend Engineer Mark Vance captured the mood perfectly, calling it "just the price of building modern web apps," a sentiment shared by a community that routinely relies on deeply nested trees of unvetted packages maintained by anonymous strangers for even basic tasks like capitalizing a string. The attack exploited a long-abandoned utility package, injecting a crypto-miner into production builds worldwide, yet developers insisted it was an unforeseeable tragedy.
At the same time, ecosystems like Go, Rust, and those using native Web APIs reported zero incidents, thanks to robust standard libraries and strict cryptographic verification built into their core tooling. This contrast highlights a key difference in approach, where reliance on third-party code is minimized and security is a foundational concern rather than an afterthought. The npm ecosystem, by contrast, continues to operate with default behaviors that execute arbitrary installation scripts on local machines, a practice that has repeatedly led to catastrophic breaches.
An npm spokesperson expressed sympathy for the victims, but maintained that no registry policies or build-sandbox guardrails could have prevented the attack, despite the registry's known vulnerabilities. The statement underscores a recurring pattern in the JavaScript community, where resilience is emphasized over prevention, and breaches are treated as inevitable acts of nature rather than systemic failures. Until the next incident, developers are left to rotate their AWS keys and offer thoughts and prayers, a cycle that shows no signs of breaking.
217 comments • Comments Link
• 冷却期是防止 npm 供应链攻击的有效手段：大多数恶意包会在几小时内被发现，因此即便把新发布包的采纳延后一天，也能阻止入侵。 pnpm（已默认启用一天冷却期）、 depsguard 和 cooldowns.dev 等工具简化了这一做法，并提供了针对紧急安全补丁的绕过机制。
• 七天的冷却期看起来过长，但对项目初期会使用数月的依赖来说通常是安全的，只有在应对已知漏洞时才应进行显式的即时升级。
• Maven Central 的做法值得 npm 借鉴：要求验证命名空间所有权（例如通过域名控制）、强制已发布包不可变，并避免使用动态版本范围。与 npm 较宽松的策略相比，这些措施能降低供应链风险。
• JavaScript 生态中大量小而深度交织的依赖使严格锁定版本变得不切实际，这与 Java 的单体库不同，因此其他生态系统的解决方案难以直接移植到 JavaScript 。
• 安装后脚本是 npm 的主要攻击面之一：它们在安装时以安装程序的权限自动运行，常在持有敏感令牌的 CI/CD 环境中执行，使恶意代码能够像蠕虫一样快速扩散——最近的 Shai-Hulud 攻击就是例证。
• 广义上讲，安装后脚本只是一个加速器——毕竟依赖中的代码总有机会被执行——但它们显著缩短了防御者的反应时间，比起只在运行时或测试时触发的负载更难防范。
• Rust 和 Go 也并非固若金汤；尽管它们的依赖平均较少，但 build.rs 等构建脚本和 go:generate 等代码生成机制仍可能执行不受信任的代码，而且这些生态缺乏强力的沙箱或强制性安全策略。
• 所有生态系统面临的根本问题是经济层面：像软件包注册表和核心库这样关键的基础设施服务数十亿用户，却长期资金不足，导致在命名空间验证或自动扫描等基本安全措施上的投入微乎其微。
• 文化因素也在加剧问题：习惯性地频繁更新依赖、维护者为显得活跃而做不必要的变更，以及对依赖审计重视不够，这些都增加了供应链风险暴露。
• 使用 Nix 管理依赖或改用默认禁用安装后脚本的包管理器等替代方案能提供有效防护，但要实现系统性改进，还需要更好的工具以及开发者行为和资金模式的变化。
讨论达成的共识是：虽然冷却期、锁定文件和禁用安装后脚本等技术缓解措施能降低风险，但潜在漏洞源于开源生态和资金维护方式中的结构性缺陷。没有任何单一方案可以彻底杜绝供应链攻击，必须采取纵深防御——工具、策略与文化变革相结合。关于某些生态（如 npm）是否存在独特缺陷，还是仅因其规模与集中性而更易成为目标，争论仍在进行；参与者提醒不要自满，也不要将责任归咎于单一因素。 • Cooldowns are a practical defense against npm supply chain attacks, as most malicious packages are caught within hours, so delaying adoption of newly released packages by even one day can prevent compromise. Tools like pnpm (which now includes a default one-day cooldown), depsguard, and cooldowns.dev make this easy to implement, with bypass mechanisms available for urgent security patches.
• A seven-day cooldown may seem excessive, but starting projects with dependencies that are months old is often perfectly safe, and immediate upgrades should only be done explicitly when responding to known vulnerabilities.
• Maven Central's model offers lessons for npm: it requires namespace ownership verification (e.g., via domain control), enforces immutability of published packages, and discourages dynamic version ranges, all of which reduce supply chain risks compared to npm's more permissive approach.
• The JavaScript ecosystem's reliance on many small, deeply intertwined dependencies makes strict version pinning impractical, unlike Java's monolithic libraries, meaning solutions from other ecosystems don't translate directly to JavaScript.
• Post-install scripts are a major attack vector in npm because they run automatically during installation with the installer's privileges, often in CI/CD environments holding sensitive tokens, enabling rapid worm-like spread of malware, as seen in recent attacks like Shai-Hulud.
• While post-install scripts are a red herring in the broader sense—since all dependency code eventually runs—they significantly accelerate attack propagation, giving defenders less time to respond compared to payloads that only execute at runtime or during testing.
• Rust and Go aren't immune to supply chain attacks; they have fewer dependencies on average, but build scripts (like build.rs) and code generation (like go:generate) can still execute untrusted code, and their ecosystems lack robust sandboxing or mandatory security policies.
• The root issue across all ecosystems is economic: the most critical infrastructure (like package registries and core libraries) is severely underfunded despite serving billions, leading to minimal investment in basic security measures like namespace verification or automated scanning.
• Cultural factors exacerbate the problem, including habitual over-updating of packages, unnecessary churn by maintainers to appear active, and a lack of emphasis on auditing dependencies, all of which increase exposure to supply chain threats.
• Alternatives like using Nix for dependency management or switching to package managers like pnpm that disable post-install scripts by default can provide meaningful protection, but systemic change requires both better tooling and shifts in developer behavior and funding models.
The discussion reveals a consensus that while technical mitigations like cooldowns, lockfiles, and disabling post-install scripts can reduce risk, the underlying vulnerabilities stem from structural and economic flaws in how open-source ecosystems are maintained and funded. There's recognition that no single fix will eliminate supply chain attacks, and that defense in depth—combining tooling, policy, and cultural change—is necessary. However, debate continues over whether certain ecosystems (like npm) are uniquely flawed or simply more visible targets due to their scale and monoculture, with participants cautioning against both complacency and scapegoating.