npm 发布时恶意软件扫描上线，代码混淆工具须声明“双重用途”

当天发生了什么

2026-07-28（UTC），GitHub Changelog 宣布 npm 对新发布的包进行发布时恶意软件扫描：包在可安装之前先被扫描，结果可能是正常发布、进入人工审核或被拦截；可用时间通常约 5 分钟，高峰期或大包可能 15 分钟以上，官方说明这不是服务承诺。同一天，npm 发布了《双重用途内容政策》（页面注明最后更新于 2026 年 7 月 28 日），把渗透测试工具、安全研究工具和代码混淆工具列为可能被自动扫描误认为恶意软件的“双重用途”示例。声明方式是在 package.json 中加入 contentPolicy 字段，并在包根目录放置纯文本 DISCLOSURE 文件说明用途；声明一经发布便须在后续版本中保留，且不保证一定能发布。同日 GitHub 还宣布，Dependabot 恶意软件告警开始导入 OpenSSF malicious-packages 数据，覆盖 npm、PyPI 等生态。

对保护自家应用的开发者意味着什么

这一变化同时影响两类团队。若你发布 JavaScript 混淆器、保护 SDK，或在 npm 包里分发经过保护处理的代码，官方政策已明确：这类能力在扫描器眼中可能与恶意软件相似。声明之后发布方式也受限：必须走强制双因素认证的路径。Changelog 与当前政策页对可信发布（OIDC）的描述并不完全一致，政策页写明 OIDC 只能用于暂存发布、不能直接发布，应以政策页为准。若你只是消费 npm 依赖、构建 Electron 或 Node 应用，发布时扫描是供应链上多出的一道闸门，但它只拦截能检测到的恶意代码，锁文件、依赖审查和自己的构建隔离仍由你负责。还要分清边界：恶意软件扫描保护的是安装方，与保护你应用逻辑不被阅读或复制无关；反过来，混淆过的第三方依赖也更难被你自己审查。

可以做的检查

第一，盘点你维护的 npm 包：是否包含混淆后的代码、保护运行时或其他安全相关能力，再对照政策原文判断是否需要声明 contentPolicy 与 DISCLOSURE，并记住声明此后不能移除。第二，检查发布流水线：发布后立即安装或冒烟测试的步骤需要容忍数分钟延迟；双重用途包要确认发布方式满足双因素要求，必要时改为暂存后再推广。第三，在消费 npm 依赖的仓库启用 Dependabot 恶意软件告警，并在构建中固定锁文件，留意依赖树中出现的混淆代码，确认其来源与必要性。第四，在自己的发布说明中如实描述保护措施，不把注册表扫描当作应用保护。

行动清单

• 盘点自家 npm 包是否属于需声明的双重用途内容
• 让发布流水线容忍扫描延迟并满足双因素要求
• 启用 Dependabot 恶意软件告警并审查混淆依赖