现代 JavaScript 生态高度依赖第三方包，npm 作为全球最大包管理器，其供应链已成为攻击者首要目标。从恶意包 typosquatting、lockfile 注入到维护者账户劫持，攻击面持续扩大。2025 年 9 月 qix 账户遭钓鱼攻陷，18 个高下载量包被植入恶意代码，周下载量超 20 亿次，虽因维护者快速响应未酿成大祸，却暴露了生态脆弱性。防御不能依赖运气，必须构建自动化、可审计、最小权限的工程化防线。本文聚焦三项可立即落地的核心实践：锁定文件审计、脚本执行控制与 CI 最小权限策略。
第一道防线：用 lockfile-lint 审计锁定文件，堵住供应链注入漏洞。 锁定文件（package-lock.json 或 yarn.lock）本为确保可重现构建，却因可被篡改而成为攻击入口。攻击者通过 PR 提交看似无害的依赖更新，实则在 lockfile 中将合法包解析 URL 替换为恶意源（如 GitHub Gist），并更新 integrity 校验值，使 npm install 无声无息拉取恶意代码。更危险的是，CI 系统自动运行 npm install 时，恶意代码可窃取环境密钥。防御方案是引入 lockfile-lint，在 pre-commit 和 CI 中强制校验。关键参数：--allowed-hosts npm yarn 限制仅从官方源下载；--validate-https 强制 HTTPS；--validate-package-names 确保包名与解析 URL 一致。例如，若 lockfile 中声明包名为 string-width-cjs 但 resolved URL 指向 string-width，工具即报错阻断构建。同时，禁止外部贡献者直接修改 lockfile，依赖升级应由 Renovate 或 Snyk 等可信机器人自动完成，确保来源纯净。
第二道防线：全局启用 --ignore-scripts，遏制任意命令执行。 npm install 默认执行包的 preinstall、postinstall 等生命周期脚本，这是供应链攻击的黄金窗口。攻击者可在恶意包中植入脚本，窃取 SSH 密钥、挖矿或部署后门。2023 年 node-ipc 事件即因维护者在 postinstall 脚本中写入破坏性代码引发。简单粗暴的防御是在所有 npm install 命令后添加 --ignore-scripts，但这会破坏依赖包的正常初始化（如编译原生模块）。折中方案是：1) 在项目根目录创建 .npmrc 文件，写入 ignore-scripts=true，使所有协作者与 CI 默认禁用脚本；2) 对必须执行脚本的可信包，使用 can-i-ignore-scripts 工具分析，生成白名单，在 .npmrc 中通过 ignore-scripts=false 临时放行特定包。此策略将风险面从“所有包”收缩至“已审计白名单包”，大幅提升攻击成本。
第三道防线：CI 配置遵循最小权限原则，隔离构建环境风险。 GitHub Actions 等 CI 系统默认拥有仓库读写权限和 Secrets 访问权，若被恶意代码利用，后果灾难性。防御核心是显式降权：在 workflow 文件中设置 permissions: contents: read，禁止写入仓库；对 Secrets，仅按需授予特定步骤（如部署步骤），而非整个 job。同时，禁用自动依赖更新——任何 npm update 或 ncu -u 必须经人工 Code Review 与安全测试。更进一步，建立私有 npm 仓库（如 Verdaccio），所有依赖先经安全扫描（npm audit、Snyk）后同步至私有源，CI 仅从私有源拉取，彻底隔离公共 registry 风险。最后，强制所有 npm 维护者启用双因素认证（2FA），GitHub 已于 2022 年起强制要求，这是防止账户劫持的最后屏障。
综上，防御性 npm 管理不是单一工具，而是环环相扣的工程实践：用 lockfile-lint 守住依赖解析入口，用 --ignore-scripts 控制代码执行边界，用最小权限 CI 隔离环境风险，再辅以私有仓库与 2FA。每项措施均有明确参数与工具链支持，无需等待组织变革，团队可立即实施。供应链安全是集体责任，唯有将防御左移至开发日常，方能在下一次“qix 事件”中，不靠侥幸，而靠体系化防线化险为夷。