原始标题: Securing npm is table stakes (Interview)
发布日期: 2026-01-29 | 来源频道: @changelog
📝 深度摘要
1. 节目元数据 (Meta Info)
- 标题：Securing npm is table stakes (Interview)
- 时长：1 小时 21 分钟
- 发布日期：2026-01-29
- 频道：The Changelog
- 嘉宾：Nicholas Zakis（ESLint 创建者）
- 主持人：Jerod Santo、Adam Stacoviak
2. 核心摘要 (The TL;DR)
本期节目邀请了 ESLint 创建者 Nicholas Zakis，深入探讨 npm 生态系统的安全问题。Nicholas 直言不讳地批评了 GitHub 对 npm 安全问题的消极应对态度，认为平台方将安全责任过度转嫁给维护者，而自身投入的安全资源严重不足。他提出了一系列具体可行的改进建议，包括对包含 pre/post install 脚本的包强制要求大版本号升级、实施额外的安全审查机制、引入预发布等待期等。节目还回顾了 2025 年 9 月单月高达 500 个 npm 包遭受攻击的严峻形势，并讨论了 JSR 作为潜在替代方案的兴衰历程——Dino 团队曾对其寄予厚望，但最终因资源有限而被迫放弃。Nicholas 预测，除非发生灾难性的安全事件，否则 GitHub 不太可能大幅增加对 npm 的安全投入。在对话尾声，他分享了对 AI 在软件开发中影响的乐观看法，认为 AI 能够带来 10 倍生产力提升，并鼓励尚未拥抱 AI 的开发者从 2026 年开始尝试。
3. 深度技术剖析 (Deep Dives)
NPM 安全责任归属的深层矛盾
Nicholas Zakis 在节目中明确指出，npm 作为全球最大的 JavaScript 包管理器，其安全状况直接影响着数百万开发者的项目和终端用户的安全。然而，GitHub 在收购 npm 之后，对安全问题的响应却显得相当被动。Nicholas 认为，平台方往往将安全责任推给包维护者自身，但维护者个人往往缺乏足够的资源和专业知识来应对日益复杂的攻击手法。这种责任分配的不对称性，导致了 npm 生态系统中安全隐患的持续累积。
Nicholas 进一步阐述了他对 GitHub 动机的分析。他指出，GitHub 作为商业公司，需要在资源分配上做出权衡。虽然 npm 安全问题的影响面极广，但除非发生具有广泛媒体曝光度的灾难性安全事件，否则公司层面不太可能投入大量资源来从根本上解决这一问题。这种"事后补救"的心态，使得 npm 安全问题长期处于治标不治本的状态。
具体的改进建议与实现路径
Nicholas 提出了一系列针对 npm 安全问题的具体改进方案。首先，他建议当一个包添加了 pre/post install 脚本时，应该强制要求进行大版本号升级。pre/post install 脚本是 npm 包中潜在风险最高的功能之一，因为它们可以在用户安装包时在本地系统上执行任意代码。强制大版本号升级可以让依赖该包的项目明确意识到潜在的风险，并给予开发者更明确的信号来评估是否继续使用该包。
其次，Nicholas 建议对包含脚本的包进行额外的安全审查。这一建议的核心思路是，通过自动化工具和人工审查相结合的方式，对包含 pre/post install、postpublish 等敏感脚本的包进行更严格的检查。审查的重点应该包括脚本的来源、意图以及是否包含可疑的网络请求、文件操作或系统命令调用。
第三，Nicholas 提出了预发布等待期的概念。他建议新的 npm 包或者包的重大版本更新，在发布后需要等待一定时间（比如 24 小时或 72 小时）才能被其他包依赖。这一等待期可以起到"冷却"的作用，让社区有时间为新包进行安全审计，同时也为潜在受害者提供宝贵的响应窗口期。
2025 年 9 月：npm 安全史上最黑暗的时刻
节目中回顾了 2025 年 9 月发生的大规模 npm 攻击事件，这是 npm 生态系统有记录以来最严重的安全事件之一。单月之内，超过 500 个 npm 包遭到攻击或被恶意发布。这些攻击通常采用以下模式：攻击者通过社会工程学手段获取合法维护者的账号权限，或者利用 npm 注册表的漏洞，然后发布包含恶意代码的更新版本。由于 npm 的依赖链极长，一个恶意包可能会影响到成千上万个下游项目。
这次事件深刻揭示了 npm 生态系统的脆弱性。即使是经验丰富的开发者，也可能因为依赖了某个被攻击的包而中招。更糟糕的是，由于 npm 的去中心化特性，恶意代码的传播速度极快，而溯源和清理工作却异常艰难。
JSR 的兴衰：Deno 团队的尝试与放弃
节目还讨论了 JSR（JavaScript Registry）作为 npm 替代方案的命运。JSR 最初由 Deno 团队推出，旨在创建一个更加安全、现代化的 JavaScript 包注册表。JSR 在设计上进行了一些有趣的创新，比如默认不执行任何脚本、采用更严格的权限模型等。Nicholas 表示，Deno 团队最初对 JSR 寄予厚望，希望它能够成为 npm 的安全替代品。
然而，现实是残酷的。JSR 最终因为资源问题被迫放弃。Nicholas 在节目中分析了其中的原因：首先，迁移成本是一个巨大的障碍。npm 生态系统经过十多年的发展，已经积累了海量的包和依赖关系，想要让开发者放弃成熟的 npm 转向 JSR，需要付出巨大的迁移努力。其次，生态系统建设需要时间。即使 JSR 的技术架构更加安全，如果没有足够的包支持，开发者也不会愿意使用。第三，商业模式的挑战。维护一个高质量的包注册表需要持续的资源投入，而 JSR 未能找到可持续的商业模式。
Nicholas 由此得出结论，在可预见的未来，npm 仍然将是 JavaScript 生态系统的中心。除非发生根本性的变化，否则很难出现能够真正挑战 npm 地位的新玩家。
AI 对软件开发的深远影响
在节目的后半部分，话题转向了 AI 对软件开发的影响。Nicholas 表达了他对 AI 技术的乐观态度。他认为，AI 工具已经能够为开发者带来显著的生产力提升，保守估计也有 10 倍的效率提升。这种提升不仅体现在代码生成方面，还体现在代码理解、调试、重构等多个环节。
Nicholas 以自己的使用体验为例，说明了 AI 如何改变了他的开发工作流程。他表示，现在他已经离不开 AI 辅助编程工具，因为它们能够帮助他快速理解陌生代码库的逻辑、生成样板代码、以及发现潜在的 bug。对于那些仍然对 AI 持怀疑态度的开发者，Nicholas 给出了明确的建议：从 2026 年开始尝试拥抱 AI。他认为，AI 技术的发展速度极快，现在开始学习和适应 AI 工具，将为开发者在未来的竞争中占据优势。
4. 行业洞察与"暴论" (Industry Insights & Hot Takes)
Nicholas 在节目中提出了几个颇具争议性的观点。首先，他认为 GitHub 对 npm 安全的投入不足是"故意的"。在他看来，GitHub 作为微软旗下的公司，并不缺乏资源和能力来改善 npm 的安全状况，但他们选择将资源投入到其他看起来更有"卖点"的功能上。这种选择性的投入，导致了 npm 安全问题的长期存在。
其次，Nicholas 对 JSR 的失败表达了某种"早在意料之中"的态度。他指出，任何试图挑战现有生态主导者的尝试，都面临着巨大的挑战。npm 的网络效应太强大了，即使技术上存在缺陷，也很难被取代。这反映了技术行业的一个普遍现象：市场领先者往往能够凭借其生态优势，即使在产品并不完美的情况下也能保持领先地位。
第三，Nicholas 对 AI 的态度虽然乐观，但也带有一定的谨慎。他承认 AI 工具目前还存在一些问题，比如生成代码的质量参差不齐、对上下文的理解有时不够准确等。但他认为，这些问题会随着技术的进步而逐步解决，而开发者现在需要做的是尽快熟悉和掌握这些工具。
5. 工具雷达 (Tool Radar & Shoutouts)
- ESLint：Nicholas Zakis 创建的 JavaScript/TypeScript 代码 linting 工具，已成为前端项目标配
- npm (Node Package Manager)：Node.js 默认包管理器，全球最大的 JavaScript 包生态系统
- JSR (JavaScript Registry)：Deno 团队推出的 JavaScript 包注册表，最终因资源问题放弃
- Deno：Node.js 原作者 Ryan Dahl 创建的 JavaScript/TypeScript 运行时
- GitHub：全球最大的代码托管平台，收购了 npm
- AI 辅助编程工具：Nicholas 在节目中推荐开发者尝试的提升生产力的工具
6. 金句摘录 (Golden Quotes)
- “GitHub 将安全责任推给维护者，但维护者个人往往缺乏足够的资源和专业知识来应对日益复杂的攻击手法。”
- “除非发生灾难性的安全事件，否则 GitHub 不太可能大幅增加对 npm 的安全投入。”
- “当一个包添加了 pre/post install 脚本时，应该强制要求进行大版本号升级。”
- “npm 的网络效应太强大了，即使技术上存在缺陷，也很难被取代。”
- “AI 能够带来 10 倍生产力提升，建议尚未拥抱 AI 的开发者从 2026 年开始尝试。”
7. 赞助商与商业信息 (Sponsors)
本期节目未包含明确的赞助商口播内容。
📺 播客地址
播客时长: 82分钟