一句话看懂：npm 在包发布时增加了自动恶意软件扫描，并推出“双用途内容”元数据声明机制，要求声明此类内容的包必须启用双因素认证（2FA）并永久保留声明文件。这意味着 npm 从发布环节主动拦截恶意软件，同时给合法但敏感的工具类包（如安全测试、渗透工具）留出合规通道。
事件核心：发生了什么
GitHub 旗下的 npm 包管理器推出两项安全新规。第一，所有新发布的包在正式可用前会经过自动扫描，扫描结果决定包是正常发布、被暂扣人工审核或被直接阻止。这个流程会引入约 5 分钟的发布延迟，高峰时段或包体积较大时可能延长至 15 分钟以上。在扫描期间，npm dist-tag 仍可操作，但 npm deprecate 和 npm unpublish 等依赖已发布版本的操作将不可用，直到包变为可用。被阻止的包会收到通知，发布者可以申诉。
第二，针对那些可能被误判为恶意软件但实际有合法用途的“双用途内容”（例如安全测试工具、代理扫描器），npm 引入了 contentPolicy 字段。声明此字段的包必须在根目录附带一个纯文本 DISCLOSURE 文件，描述双用途功能和合法使用场景。这类包必须通过强制 2FA 的方式发布（如 OIDC 可信发布、交互式登录或分阶段发布），且一旦声明就不能在后续版本中移除该字段或文件，否则发布会被拒绝。
为什么重要
这是 npm 在供应链安全领域的一次关键补位。此前 npm 主要依赖事后检测和报告机制，如今将扫描前置到发布时，能显著降低恶意包对下游开发者造成的影响。双用途内容元数据则为渗透测试工具、命令行辅助脚本等灰色地带包提供了明确的合规路径，避免了“一刀切”封杀带来的生态损失。同时，强制 2FA 和持久化声明的做法，也提高了攻击者伪装成双用途包的门槛。从行业角度看，npm 作为全球最大的 JavaScript 包注册表，此举可能推动其他包管理器（如 PyPI、RubyGems）跟进类似的发布时扫描和元数据声明机制。
对用户/开发者/创作者的影响
普通开发者：安装包时会更安全，因为恶意软件在发布后被扫描，降低了自己项目被植入后门的风险。但需要注意，如果自动化流水线假设包立即可用，需要调整为容忍几分钟的延迟。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
包作者/维护者：发布工具包（尤其是涉及网络、文件系统操作、代码执行等敏感能力的包）时，需要提前评估是否属于双用途内容。如果属于，必须添加 contentPolicy 字段和 DISCLOSURE 文件，并确保发布方式支持 2FA。已有双用途包且未声明的，可能在未来被默认阻止，GitHub 会通过邮件联系相关维护者补充声明。
企业开发者/DevOps 团队：如果内部使用了 npm 私有源或代理，需要评估新策略对镜像同步、CI/CD 发布流水线的影响。延迟和 2FA 要求可能影响自动化发布流程，建议提前适配。
值得关注的后续
- 扫描覆盖率和误报率：npm 表示正持续改进检测和缩短扫描时间。实际运行中误报导致合法包被延迟或阻止的频率，将决定开发者对该机制的接受度。
- 双用途声明的审核标准：Trust & Safety 团队人工审核的具体标准尚未完全公开，未来是否会形成类似“安全工具白名单”的机制值得关注。
- 生态连锁反应：其他包管理器（如 PyPI 的 Puppet、Go module registry）是否会参考 npm 的做法推出类似发布时扫描和双用途声明，将影响整个开源供应链安全格局。
