npm 12默认禁用依赖安装脚本 供应链攻击防线升级

一、npm 12发布：从默认信任转向默认拒绝

2026年8月，Node.js生态的核心包管理器npm发布12.0大版本，这是近年来规模最大的一次安全导向变革。新版最核心的变化是：依赖包的生命周期脚本（preinstall、postinstall等）默认不再执行，除非项目根包通过allowScripts策略显式放行。这意味着开发者安装依赖时，第三方包自带的安装脚本不会自动运行，必须先使用npm install-scripts approve记录审批，再通过npm rebuild执行已获批的脚本。对于依赖隐式构建的包，同样需要显式批准，安装行为全面转为"opt-in"。

与此同时，npm 12将allow-git与allow-remote两个配置项的默认值改为none，即默认拒绝从git仓库地址或用户提供的远程压缩包URL安装依赖，确有必要时须显式设置为all或root。此外，未知的.npmrc配置项、未知命令行参数、缩写参数等此前仅告警的用法，新版一律直接报错；npm adduser、npm shrinkwrap等旧命令被移除，许可证默认值也由ISC改为空。这一系列"默认拒绝"的收紧，标志着npm官方正式把供应链安全置于开发便利性之上。

二、安装脚本为何是供应链攻击的重灾区

依赖安装脚本长期被视为开源供应链攻击的"第一入口"。npm包被安装时，package.json中的preinstall、postinstall等脚本会在用户机器上以当前用户权限自动执行，攻击者只要在包中植入恶意脚本，就能在开发者毫无察觉的情况下完成信息窃取、挖矿、后门植入等操作，且攻击代码仅安装阶段短暂存在，常规审计难以发现。

此类案例不胜枚举：2018年event-stream事件中，攻击者劫持了周下载量超百万的流行包，通过postinstall脚本在开发机植入窃取比特币钱包的恶意代码；2021年ua-parser-js三个版本被投毒，下载量一度达每周800万次；同期eslint-scope、flatmap-stream等事件同样利用安装脚本完成恶意载荷投放。近两年，仿冒热门包名的投毒攻击持续攀升，安全机构多次披露npm、PyPI上的恶意包在安装阶段外传环境变量、SSH密钥等敏感信息。

问题的根源在于旧版npm的"默认信任"模型：任何依赖的脚本都无条件执行，开发者几乎不可能在安装前逐一审查传递依赖的脚本内容。npm 12的默认阻断，等于从工具层面给这条攻击链上了一把锁，把"安装即执行"的风险挡在源头。

三、新机制实操：脚本审批与来源白名单

对开发者而言，npm 12需要适应新的工作流。安装依赖后，若某个包确实需要执行安装脚本（如原生模块编译），终端会提示脚本被拦截，此时可通过npm install-scripts approve查看并逐项审批；审批记录完成后执行npm rebuild，即可运行已批准的脚本。企业内网团队还可结合allowScripts策略，在项目根配置统一的脚本白名单，实现"根部放行、依赖默认拒绝"的分层管控。

来源限制同样值得关注：allow-git与allow-remote默认none后，在package.json中直接引用GitHub仓库地址或任意tarball URL的存量项目，需要显式配置才能继续安装。这一变化对CI/CD流水线影响明显——流水线中若存在git源依赖，须在构建配置中显式声明，否则构建会失败。建议团队升级前先用npm 12的dry-run模式检查依赖树，识别所有需要审批的脚本与非常规来源，避免升级后构建中断。

从生态视角看，npm 12与近期各主流语言生态的包安全举措一脉相承，供应链安全正从"事后审计"走向"源头管控"。社区中也有不同声音：部分维护者担忧默认阻断会拖慢原生模块的安装效率，npm官方则以"安全优先、可显式放行"回应，并表示后续将持续优化脚本审批体验。

四、对青海政企软件供应链安全的启示

青海正处于数字政府与智慧城市建设加速期，政务、医疗、教育等单位的业务系统大量依赖开源组件，软件供应链安全是等保2.0与数据安全合规的刚性要求。npm 12的发布给本地政企带来三点启示：其一，开发团队应尽快评估内部项目的npm版本，制定升级计划并配套脚本审批制度，把"默认拒绝"理念写入开发规范；其二，在CI/CD流水线中集成依赖来源审计与脚本扫描，对git源、tarball源依赖建立台账，防止未知来源组件流入生产环境；其三，对已建成的业务系统，可通过供应链清单（SBOM）盘点第三方组件，重点核查历史安装脚本执行记录，发现异常及时处置。

开源生态的安全水位提升，最终要落到每个使用者的管理制度与技术工具上。对青海本地信息化服务商而言，率先落地npm 12的供应链管控机制，既是自身安全的保障，也是面向政企客户交付时的差异化竞争力。