过去一年，开源供应链攻击的目标不再只是单个包。GitHub 在 7 月 28 日的复盘里把攻击链拆得很清楚：维护者账号、CI 工作流、缓存、发布凭证和下游自动更新，任何一环被拿下，恶意代码都可能很快扩散到大量项目。
今天值得看的变化，是几家平台都在把安全动作前移。GitHub 继续改 npm 与 Actions 的默认行为，OpenAI 把 Codex Security 做成可安装的 CLI 和 TypeScript SDK，Vercel 则在 Nuxt 漏洞公开前先部署平台级 WAF 缓解。它们解决的不是同一个漏洞，但方向一致：把风险拦在提交、执行、发布或边缘请求之前。
这对工程团队的影响很直接。以前的安全流程常常依赖事后扫描和人工响应；现在平台开始提供更靠近执行路径的门禁。门禁不是替代升级和审查，而是减少攻击链跑完的机会。
攻击链被拆成几个必须提前拦住的动作
GitHub 把供应链攻击描述成一串互相放大的动作：先拿到项目或维护者入口，再通过 CI/CD 提权，随后找凭证、发包、污染缓存或推动下游自动升级。它特别指出，这类攻击会利用软件包仓库和 CI/CD 系统的弱点，把恶意软件扩散到数百个开源项目，并尝试外传凭证。
对应的防线也变得更具体。高影响 npm 账号在更改邮箱或使用 2FA 恢复码后进入 72 小时只读窗口；actions/checkout 对常见高风险触发器收紧默认行为；低信任工作流不能再写入共享 Actions cache；企业、组织和仓库级策略可以限制谁能触发哪些工作流。
更关键的是发布环节。GitHub 强调，可信发布的目标是把长期凭证从 CI/CD 流程里拿掉；npm staged publishing 则要求额外批准和 2FA，避免凭证一旦泄漏就直接变成发包权限。Dependabot 的默认三天冷却也是同一套思路：让检测信号先出现，再把新版本推给下游。
依赖告警开始接入恶意包数据
GitHub Advisory Database 现在会自动接收 OpenSSF malicious-packages 仓库里的恶意软件 advisory。对已经启用 malware alerting 的项目，Dependabot 会把依赖同这些 advisory 匹配，并在命中时发出告警。GitHub 明确说，覆盖范围扩展到 npm、PyPI 等生态。
这个动作重要，不是因为它能识别所有恶意包，而是因为它把社区维护的恶意包数据接进了日常依赖流。很多团队已经把 Dependabot PR 当作版本更新入口；如果告警和冷却同时存在，下游项目至少不会在攻击刚开始传播时第一时间把包拉进来。
不过这也意味着安全策略要区分版本更新和安全更新。GitHub 的冷却机制不会延迟安全更新，但普通版本更新会等新版本存在至少三天。对依赖大量自动升级的团队来说，这不是一个小优化，而是默认风险偏好的改变。
本地扫描和平台缓解不是同一种保险
OpenAI 的 Codex Security 仓库显示，这个工具是 CLI 和 TypeScript SDK，可以扫描仓库、审查变更、跟踪发现，并在 CI 中运行安全检查。它要求 Node.js 22 或更高版本、Python 3.10 或更高版本，并支持用 API key 跑非交互式 CI 扫描。
这类工具的价值在于把检查放到开发者机器、代码评审和流水线里，而不是等生产事故后再补证据。它不能替代平台侧的默认保护；相反，它适合补平台看不到的上下文，例如一个变更为什么危险、一次修复是否覆盖了相邻路径。
Vercel 的 Nuxt 公告则说明了平台缓解的边界。Nuxt 4.5.1、3.21.10 和 @nuxt/devtools 3.3.1 修复了八个 security advisory，其中包括高危服务端 RCE 和一个开发期 DevTools RCE。Vercel 说它提前部署了平台级 WAF 缓解，但同时提醒用户不要把它当成完整保护，升级依赖仍然必要。
默认安全正在从建议变成产品行为
GitHub Actions 新增的保护更能说明这个变化：当公开仓库中的某些 workflow run 被识别为可能恶意时，运行会先被挂起，直到有写权限的协作者通过认证的网页会话审核批准。GitHub 还明确说，这个保护自动生效，目前只覆盖 github.com 上的公开仓库，不覆盖 GitHub Enterprise Server。
Vercel WAF for Blob 的 beta 也是同一路径。它把 deny、challenge、rate limit 等规则用到 Blob 流量上，不需要改代码、Blob URL 或 @vercel/blob。但它也有清晰限制：规则集不能按 store 单独区分，挑战规则需要浏览器完成，OWASP Core Ruleset 不适合对象存储流量。
这些边界很重要。平台默认值可以让大部分团队少犯低级错，但默认值不会替团队决定资产分级、凭证寿命、谁有发布权，或者哪些自动化流程应该停下来等人看一眼。下一步的工程管理问题不是要不要加安全工具，而是每个门禁到底拦在哪一层，失败时由谁负责解释和放行。