Axios 安全策略详解：发行版溯源验证、60 天漏洞披露承诺与仓库级供应链防护

本文围绕 Axios 仓库根目录下的 SECURITY.md 展开，系统讲解该安全策略的三大支柱：受支持的版本范围、基于 npm provenance 的发行版溯源验证、以及 60 天漏洞修复与公开披露承诺。读完本文，你将知道如何验证本地安装的 axios tarball 是否来自可信的 GitHub Actions 构建环境，如何通过私有渠道正确上报漏洞，以及该项目在仓库层面落地了哪些供应链加固措施（OIDC 发布、ignore-scripts、workflow 静态检查、构建可复现性校验等）。

一、受支持的版本与威胁模型入口

SECURITY.md 明确声明维护者只为以下两条版本线提供安全更新：

版本	支持状态
0.x.x	支持（✓）
1.x.x	支持（✓）

这意味着如果你还在使用更早的旧版本线，应当尽快升级到 0.x 或 1.x 的最新补丁版本，否则不会获得安全修复。

文档同时规定：在提交安全报告之前，研究者应先阅读 THREATMODEL.md。该文档对两个相互独立的系统建模：

1. 运行时系统——保护 import axios 的应用免受恶意服务器、网络攻击者、恶意应用输入的影响。文档逐一评估了 SSRF（T-R1）、跨域重定向泄露凭据（T-R2）、CRLF 头注入（T-R3）、原型链污染（T-R4/T-R4b）、解压炸弹（T-R5）、TLS 校验绕过（T-R6）、跨域 XSRF（T-R7）、错误对象携带敏感数据（T-R8）、代理环境变量劫持（T-R9）、恶意拦截器（T-R10）、表单递归 DoS（T-R11）等威胁，并在每项下注明仓库内对应的缓解代码位置；
2. 项目/SDLC 系统——保护发布到 npm 的 axios 包不被供应链攻击者污染，覆盖恶意 PR、开发依赖窃取维护者密钥、钓鱼、运行时依赖被投毒、构建产物篡改、workflow 篡改、tag 重放、typosquatting 等威胁。

维护者的事件响应手册（会话吊销、密钥轮换、下游通知步骤）位于 THREATMODEL.md §3.7 中，包括 0–15 分钟遏制、15–60 分钟评估（含用 npm audit signatures axios@<version> 核对近期发布的溯源证明）、1–4 小时密钥轮换、通知 npm/GitHub 安全团队与下游用户、1–24 小时内的 unpublish/deprecate、以及一周内复盘六个阶段。

二、验证发行版：npm provenance 溯源

SECURITY.md 中“Verifying a release”一节是面向下游消费者最可操作的章节。其核心事实如下：

• npm 上的 axios tarball 全部由 GitHub Actions 发布，并附带 npm provenance attestation（溯源证明），它把包在密码学意义上绑定到产生该包的 workflow 与 commit SHA；
• 默认启用点：1.x 线自 v1.6.1、0.x 线自 v0.31.0 起，所有发布都携带溯源证明；
• 例外情况（文档明确列出）：
  • v0.28.0 与 v0.28.1 早于 0.x 默认启用点，但携带了证明；
  • v1.13.3（1.x 线）与 v0.29.0 至 v0.30.3（0.x 线）未携带证明。

消费者可以用一条命令验证本地锁文件中的全部包（包括 axios）：

# Verify every package in your lockfile, including axios
npm audit signatures

验证通过能证明什么、不能证明什么，文档给出了清晰的边界：

• 能证明：tarball 是在 axios/axios 的 GitHub Actions 环境、由某个已知 commit 构建的，且在构建与进入 registry 之间未被篡改；
• 不能证明：该 commit 里的代码没有 bug（provenance 证明的是"可追溯"，不是"正确"）。

如果 npm audit signatures 对上文标注为"带证明"的 axios 版本报告缺失或无效证明，文档要求将其视为潜在的供应链事件，并通过下文所述的私有渠道报告。

仓库内溯源机制的源码佐证

溯源能力在仓库中的实现链路可以从以下文件直接读到：

• 发布 workflow（.github/workflows/publish.yml）：仅由 v1.*.* tag 推送触发；job 声明最小权限 contents: read + id-token: write（即通过 OIDC 向 npm 换取发布身份，仓库内不存在长期存储的 NPM_TOKEN）；checkout 使用固定 commit SHA 且设置 persist-credentials: false，构建步骤为 npm ci --ignore-scripts → npm run build → npm stage publish --provenance --access public（第 29–36 行）。--provenance 参数正是上文证明的生成开关；job 还绑定 npm-publish environment，可要求人工审批后才执行；
• 构建可复现性校验（.github/workflows/verify-build-reproducibility.yml）：在触及 lib/**、rollup.config.js、package.json、package-lock.json 等构建相关路径的 PR 上执行两轮构建并逐文件比对 sha256。当前该 job 处于非阻塞模式（continue-on-error: true，第 24 行），差异只会在 CI summary 中显形；THREATMODEL.md §T-S5 说明，一旦构建做到字节级确定性，将移除该开关升级为硬门禁；
• workflow 静态检查（.github/workflows/zizmor.yml）：对每次 PR 与 v1.x 分支推送运行 zizmor，扫描 workflow 文件中的已知危险模式（如把 OIDC token 外发、过大的 permissions），结果通过 code scanning 上报。

从 THREATMODEL.md §3 的资产清单看，该仓库把"npm 包名"、"发布能力"、"tag 推送权限"、"维护者工作站密钥"、"构建确定性"、"运行时依赖完整性"都列为受保护资产，并把 package-lock.json 的 integrity 哈希、npm ci --ignore-scripts、OIDC 发布、Action 全量 SHA 锁定作为对应控制项。

三、漏洞报告流程与 60 天披露承诺

报告渠道

SECURITY.md 明确两条规则：

• 不要通过公开的 GitHub issue 报告安全漏洞；应使用 GitHub 的私有安全渠道提交 security advisory（安全咨询单）；
• 如果漏洞位于第三方库（如 follow-redirects、form-data、proxy-from-env），应直接报告给该库的维护者。

处理流程与 60 天承诺

收到报告后，维护者会指定一名主处理人（primary handler），由其确认问题、确定受影响版本、评估严重性、开发并发布修复，并与报告人协调公开披露的时间点。

文档给出的核心承诺是：每一条有效的安全咨询单，都会在收到报告后的 60 个日历日内被解决并公开披露。60 天时钟的定位是"兜底（backstop），而不是愿望"：

• 如果 60 天内无法发布修复，仍会在第 60 天发布 advisory，并附上可用的缓解建议，让下游用户可以立即行动；随后继续推进修复，就绪后再在 advisory 中补充补丁细节；
• 修复版本与 advisory 分开发布，但 advisory 绝不超过第 60 天；维护者会尽量在公开披露之前发布修复，使用户能在漏洞细节公开前完成打补丁。

例外与延期情形

文档列举了四类例外：

1. 报告人要求更短的禁运期（例如计划在会议上演示该发现）：在可行范围内予以配合；
2. 修复需要破坏性变更、需要协调主要下游用户、或依赖 follow-redirects / form-data / proxy-from-env 的上游发版：可能超过 60 天，但任何延期都会在第 60 天通过 advisory 公开披露，并附修订后的 ETA 与原因；
3. 报告超出范围（例如落入 THREATMODEL.md 中明确声明的非目标项）：在分诊窗口（≤ 3 天）内向报告人解释后关闭，不进入 60 天队列；
4. 正在被主动利用的漏洞按事件（incident）处理：补丁一旦验证通过即与 advisory 一同发布，不遵循 60 天节奏。

对报告人的期望

报告处于禁运期时，维护者请求报告人在"协调好的 advisory 公开发布"与"第 60 天"两者中较早者之前不要公开披露；如果 60 天到期而维护方没有动作，报告人可以自行公开披露——这被视为维护方的失职，而非报告人的问题。

安全更新发布

补丁开发并测试完成后，维护者会：通过项目 GitHub 仓库通知用户、在 GitHub releases 上发布 release notes 与安全 advisory、并将所有含漏洞的版本标记为弃用（deprecate）。

四、仓库落地的供应链加固（策略的"另一半"）

SECURITY.md 是对外承诺，而下列仓库内文件是支撑承诺的控制措施，建议读者对照阅读以评估 axios 的供应链安全姿态：

• .npmrc：单行配置 ignore-scripts=true。这意味着在仓库内执行 npm install / npm ci 时，任何直接或传递依赖的生命周期脚本（preinstall、install、postinstall、prepare）都不会执行，直接堵住了"被投毒依赖在 install 时窃取 ~/.npmrc、~/.ssh 等凭证"这条历史上最常见的攻击路径。副作用是仓库自身的 husky prepare 钩子不会自动运行，需要手动执行一次 npm rebuild husky && npx husky；
• CODEOWNERS（.github/CODEOWNERS）：对运行时源码（/lib/、/index.*）、构建发布基础设施（rollup.config.js、package.json、package-lock.json、.npmrc）、CI 自动化（.github/workflows/、dependabot.yml）以及安全关键文档（THREATMODEL.md、SECURITY.md）设置了路径级归属规则，使这些路径的变更在 PR 评审界面中被显式标记。文档同时坦承：当前为单一维护者，路径规则尚无法强制双人评审，属于预留控制；
• 依赖更新自动化（.github/dependabot.yml）：对 npm 生产/开发依赖与 GitHub Actions 均按周分组更新，保留 7 天冷却期（除非关键漏洞需要维护者手动加速），并忽略 semver-major 的自动升级；
• 发布 workflow（.github/workflows/publish.yml） 中所有第三方 Action 均锁定到完整 commit SHA 而非 tag，且全部 persist-credentials: false，防止被篡改的 tag 或 checkout 后的步骤回推仓库。

五、运行时安全：默认值与调用方的责任边界

与发行版验证相呼应，axios 在运行时的安全默认值也采取"兼容优先、显式加固"的立场。最典型的是解压炸弹防护：maxContentLength 与 maxBodyLength 默认均为 -1（无限制）。恶意或失陷服务器可以返回一个 gzip/brotli 压缩后仅几 KB、解压后数 GB 的响应体，耗尽 Node.js 进程内存。README 的 Security notice 与 安全指南页（docs/pages/misc/security.md） 都给出标准加固写法：

// 针对单次请求：
axios.get('https://example.com/data', {
  maxContentLength: 10 * 1024 * 1024, // 10 MB
  maxBodyLength: 10 * 1024 * 1024,
});

// 或全局生效：
axios.defaults.maxContentLength = 10 * 1024 * 1024;
axios.defaults.maxBodyLength = 10 * 1024 * 1024;

该限制在 Node 适配器（lib/adapters/http.js）中按块流式解压时逐块强制执行，因此设置上限即可中和解压炸弹。默认值之所以不收紧，是因为任何固定上限都会静默破坏合法的大文件下载——为不可信服务器选择安全上限是应用层的责任。

安全指南页 还汇总了其他直接影响安全的请求配置项，可作为审查清单使用：baseURL 不构成路径安全边界（用户可控的 url 中 .. 段可能在最终解析后越出前缀）；socketPath 若来自不可信输入可把流量导向本地特权 socket（可配合 allowedSocketPaths 白名单）；beforeRedirect 在凭据已被 follow-redirects 剥离后运行，重新注入凭据前必须检查目标协议是否为 https:；自定义密钥头（如 X-API-Key）应加入 sensitiveHeaders，axios 会在跨域重定向时大小写不敏感地移除它们；withXSRFToken 应保持 undefined（仅同源）除非后端明确要求跨域校验；redact 可让 AxiosError#toJSON() 递归脱敏 Authorization 等配置键，避免凭据进入错误日志与遥测。

六、安全合作伙伴

SECURITY.md 最后对以下长期合作的机构致谢：Socket.dev 与 GitHub Security Lab。它们与项目共同完成了多次漏洞挖掘与修复工作。

---

适用前提小结：本文所有版本号、workflow 行为与配置均以当前仓库快照为准——受支持版本线为 0.x/1.x，provenance 自 v1.6.1（1.x）/ v0.31.0（0.x）默认启用（含 v0.28.0、v0.28.1 携带与 v1.13.3、v0.29.0–v0.30.3 缺失两组例外），发布链路为 tag 触发 + OIDC + --provenance，60 天披露时钟覆盖所有有效咨询单并以第 60 天公开 advisory 为兜底。若你的组织对 axios 做供应链尽调，建议按"读 THREATMODEL.md → 核对 .github/workflows/ 与 .npmrc → 本地跑 npm audit signatures"的顺序完成验证闭环。