2026 年 3 月底，Axios npm 包遭遇供应链攻击，攻击者通过 compromise 维护者账号发布了两个恶意版本（v1.14.1 和 v0.30.4），成功在依赖链中植入远程访问木马（RAT）。这次事件之所以引发广泛关注，不仅因为 Axios 每周下载量超过一亿次、存在于约 80% 的云与开发环境中，更因为攻击发生在供应链的上游发布环节 —— 恶意版本直接通过被窃取的维护者凭证发布，绕过常规的 CI/CD 审核流程。事件曝光后，社区迅速开展了事后分析（post-mortem），但对于工程团队而言，真正值得思考的问题是：在攻击发生之前，我们能否通过自动化的 CI/CD 流水线将类似风险拦截下来？本文聚焦这一前置防御视角，系统阐述如何通过 lockfile 完整性校验与依赖审计的自动化流水线，实现供应链攻击的预防性检测。
供应链攻击的演进与防御范式转移
传统的供应链安全防护主要依赖漏洞扫描与依赖审计工具，例如 npm audit、Snyk、Dependabot 等。这些工具的核心逻辑是在已知漏洞数据库中匹配依赖版本，发现问题时及时告警。然而，Axios 攻击事件揭示了一个关键盲区：攻击者并非在已知漏洞层面动手脚，而是通过供应链的上游注入 —— 在发布环节植入全新的恶意依赖（plain-crypto-js），而这个依赖本身不在任何漏洞数据库中。传统扫描工具无法识别 “正常的未知依赖”，因为从版本号和包名来看，plain-crypto-js 没有任何异常标记。
这一攻击特征推动了防御范式的根本转移：从 “检测已知漏洞” 转向 “验证完整性与来源”。具体而言，工程团队需要在依赖安装之前和之后两个阶段分别建立防线：安装前验证 lockfile 与 package.json 的一致性、检测异常依赖引入；安装后验证包的行为是否符合预期、检查是否存在可疑的 postinstall 脚本或网络行为。CI/CD 流水线正是实现这一防御体系的核心载体。
Lockfile 完整性校验：从信任链的源头做起
npm 生态中的 lockfile（package-lock.json、pnpm-lock.yaml、yarn.lock）本质上是依赖树的确定性快照。理论上，只要 lockfile 被严格遵守，每次安装都会得到完全相同的依赖树 —— 这为供应链安全提供了最基本的信任链。然而，在实际工程实践中，许多团队仍然使用 npm install 而非 npm ci，前者会根据 package.json 中的 semver 范围自动升级依赖，从而引入不确定性。攻击者正是利用这一漏洞，通过发布新版本或劫持依赖包的方式，在用户下次安装时悄悄植入恶意代码。
自动化校验的第一道门槛是强制使用 npm ci 命令。npm ci 会根据 lockfile 进行完全确定的安装，当 lockfile 与 package.json 存在不一致时会直接报错并退出。这意味着任何未经授权的依赖变更都会导致 CI 构建失败。在 GitHub Actions、GitLab CI 或 Jenkins 中，只需将安装命令从 npm install 替换为 npm ci 即可实现这一防线。但仅有点击此处还不够 —— 团队还需要在代码提交阶段就拦截 lockfile 的异常变更。
一个实用的做法是在 CI 流水线中引入预检查步骤：对 lockfile 的 diff 进行分析，标记新增依赖、版本升级或注册表 URL 变更。当检测到这些变更时，流水线可以自动要求人工审核或触发额外的安全扫描。GitHub Actions 中可以使用 actions/github-script 来解析 lockfile 变更并生成报告。这种机制能够在恶意依赖被引入的第一时间被发现 —— 远早于其在生产环境中被执行。
依赖审计的自动化分层策略
Lockfile 校验解决的是 “依赖树是否被篡改” 的问题，而依赖审计解决的是 “依赖本身是否安全” 的问题。两者需要结合使用，形成纵深防御。自动化审计可以划分为三个层次，每一层对应不同的检测能力和响应机制。
第一层是漏洞扫描，即使用 npm audit 对已知 CVE 进行检测。建议在 CI 中设置明确的失败阈值，例如 npm audit --audit-level=high，仅当不存在高级别或严重漏洞时才允许构建通过。这一层的局限在于只能检测已收录在漏洞数据库中的问题，对于零日攻击或全新植入的恶意依赖无效。
第二层是行为分析，典型工具如 Socket.dev。这类工具不依赖漏洞数据库，而是通过静态分析和行为监控来识别可疑模式：异常的 postinstall 脚本、高频网络请求、过度要求的权限（如文件系统访问、网络访问）。在 CI 流水线中引入行为分析工具，可以在依赖安装前对其进行分析，一旦检测到恶意行为特征立即终止构建。Axios 事件中的 plain-crypto-js 如果经过行为分析，会被标记为在安装后尝试连接外部 C2 服务器的行为异常。
第三层是来源验证，即使用包签名和 provenance（来源证明）机制。npm 近期支持了基于 Sigstore 的 provenance attestations，允许发布者在发布包时生成加密证明，声明包的构建来源和构建环境。消费者在安装时可以验证这些证明，确认包确实由声称的构建流水线生成。这一机制从根本上解决了 “攻击者窃取凭证后伪装成维护者发布恶意版本” 的问题 —— 即使凭证被盗，没有对应的构建流水线私钥也无法生成有效的 provenance。
自动化流水线的工程实践参数
将上述防御层次整合到 CI/CD 流水线中，需要在工程细节上做出一系列可量化的决策。以下是关键参数与阈值建议，适用于主流的 GitHub Actions 环境，也易于迁移到其他 CI 平台。
在安装阶段，推荐使用 npm ci --ignore-scripts 作为初始安装命令。--ignore-scripts 参数会阻止所有 postinstall、preinstall、prepare 等生命周期脚本执行，这是防止恶意代码在安装阶段就被触发最直接的手段。完成依赖安装后，可以选择性地对可信白名单内的包启用脚本，通过 .npmrc 文件的 ignore-scripts=false 配合 scoped 配置来实现精细控制。
在审计阶段，建议执行三层门禁：第一步运行 npm audit --audit-level=high，将高危和严重漏洞作为硬性拦截条件；第二步运行 npm audit signatures（如果项目已启用 provenance）验证包来源；第三步集成 Socket.dev CLI 或类似工具进行行为扫描。三层门禁中任意一层失败都应阻止构建进入后续阶段。
在发布阶段，如果团队有发布私有包或向 npm 发布自定义包的需求，强烈建议启用 provenance 并在 CI 中配置 OIDC（OpenID Connect）认证。通过将发布流程与 CI 流水线的身份验证绑定，即使攻击者窃取了 npm token，也无法在没有有效 provenance 的情况下发布包。
以下是一个简化的 GitHub Actions 配置文件示例，展示了完整的防御流水线结构：
name: Secure Dependency Pipeline
on:
pull_request:
paths:
- 'package.json'
- 'package-lock.json'
push:
branches: [main]
jobs:
security-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Verify lockfile integrity
run: npm ci --ignore-scripts
- name: Audit known vulnerabilities
run: npm audit --audit-level=high
- name: Behavioral security scan
run: npx @socket-sdk/cli audit package.json
env:
SOCKET_API_KEY: ${{ secrets.SOCKET_API_KEY }}
- name: Verify package provenance
run: npm audit signatures
持续监控与响应：从自动化到可观测
自动化流水线并非银弹 —— 它能拦截大多数异常依赖变更，但无法保证 100% 的防御覆盖率。因此，建立供应链安全的可观测性体系同样重要。工程团队应当持续监控以下指标：依赖树的变更频率、异常大版本升级、新引入的包数量趋势、安装阶段的网络外发请求特征。
一个实用的做法是将依赖审计结果（npm audit JSON 输出）定期归档到安全信息与事件管理（SIEM）系统中，通过时序分析发现依赖健康状况的劣化趋势。当某个依赖突然引入大量漏洞或出现异常行为时，团队可以第一时间收到告警并开展排查。
此外，针对 Axios 这类广泛使用的核心依赖，建议在 SIEM 中预设专项监控规则：当检测到新版本发布时，自动对比新版本与当前锁定版本的依赖树差异，如果发现新增依赖（如 plain-crypto-js 此类此前从未出现的包），立即触发安全评审流程。这种基于版本发布事件的主动监控，能够捕捉到传统漏洞扫描无法覆盖的供应链上游攻击。
面向未来的供应链安全架构
Axios 供应链攻击事件之所以值得深入分析，不仅因为其技术细节（跨平台 RAT、多阶段载荷、持久化机制）具有代表性，更因为它暴露了传统防御体系的结构性缺陷 —— 我们过于依赖已知漏洞的检测，而忽视了完整性验证与来源可信这一底层防线。随着包管理器对 provenance 机制的支持日趋成熟，以及行为分析工具的检测能力不断增强，工程团队有能力构建更加完善的自动化防御体系。
核心的设计原则可以归纳为三点：第一，lockfile 是信任链的基石，任何依赖安装都必须严格遵守 lockfile，任何变更都必须经过自动化校验；第二，防御层次需要从 “漏洞检测” 扩展到 “完整性验证” 和 “行为分析”，形成多层纵深；第三，自动化流水线应当与监控告警系统联动，将安全检测从离散的构建环节扩展为持续的运营能力。只有将这三者结合，才能在下一个类似的供应链攻击窗口期中实现真正的预防性拦截。
参考资料
- Wiz Threat Center: 《Axios NPM Distribution Compromised in Supply Chain Attack》（2026 年 3 月 31 日）
- PkgPulse: 《How to Secure Your npm Supply Chain in 2026》