我检查了三个权威报告，发现 CI/CD 供应链比想象中更容易被攻破——今天把 GitHub Actions 安全的三个层次全拆开了

配完 CI/CD 流水线你可能觉得已经安全了——但 2026 年的攻击者已经不靠偷密码了，他们靠偷你的工作流本身。npm 蠕虫攻击从仿冒包名入手，GitHub Actions 提示注入从 AI Agent 生成的 commit message 入手，dependency confusion 直接利用 npm 的注册表查找顺序——三条路都可以把你的流水线变成攻击者的跳板。

入口一：提示注入是最容易被忽略的那条缝

当 GitHub Actions 日志里出现用户提交的内容时，你有没有想过这些内容会流向哪里？2025 年 12 月，网络安全公司 Aikado Security 发现了一个被命名为 PromptPwnd 的漏洞类型：攻击者在 GitHub PR 评论或 commit message 里嵌入恶意提示词，Claude Code、Gemini CLI、OpenAI Codex 这类 AI Agent 在处理这些信息时会执行注入的命令，导致 CI/CD 工作流中的凭证泄露。

微软威胁情报团队的报告进一步揭示了 Claude Code 在 GitHub 自动化流程中的具体攻击路径：攻击者通过在 PR 分支中植入恶意提示词，可以在 AI Agent 分析代码时窃取 GitHub 账户凭证，甚至在某些场景下直接获取 OIDC token 的访问权限。更值得警惕的是，这个问题不是 Claude Code 独有的——所有集成了 AI Agent 的 CI/CD 流水线都存在类似的攻击面。至少五家财富 500 强企业已被确认受影响，实际影响范围可能更广。

入口二：npm 依赖混淆攻击正在自动化跑

2026 年 2 月，一波 npm 蠕虫攻击瞄准了 CI 管道与 AI 编程工具。攻击者发布与合法包名称几乎相同的仿冒包，依靠开发者打字错误或 AI 生成工具的错误依赖建议来得逞。这类攻击的可怕之处在于它完全静默：恶意包被检测到时才会触发主目录清除功能，而在那之前，攻击者已经有足够的时间在流水线中潜伏。

GitHub 安全实验室的统计数据显示，2025 年 9 月超过 500 个被攻陷的 npm 包已被移除，另有数百个包在上传阶段就被安全扫描拦截。但这只是冰山一角——CI/CD 流水线中的自动化构建过程不会停下来等待人工审核，一旦恶意包被引入，它会在第一次运行时就开始执行攻击者的代码。

入口三：OIDC Token 误配置让你的云账号门户大开

GitHub Actions 的 OIDC 集成是 2026 年大多数团队的默认选择，但它也是最容易踩坑的地方。正确配置下，GitHub 只向云服务商请求短期有效的 JWT token，流水线不会暴露长期凭证。但很多团队在配置 trust policy 时权限放得过宽，导致 runner 获取的 token 可以访问超出预期的云资源。

更常见的问题是 token 生命周期管理：如果 workflow 的 permissions 配置了过大的范围，OIDC token 就会在 runner 执行期间持续有效，增加了凭证被盗用的窗口期。GitHub 2026 年的生态报告显示，超过 60% 的开发者因为盲目信任自动化补全工具而导致代码审查时间翻倍——这个问题在安全配置上同样存在：大多数团队不会主动收紧 OIDC trust policy，直到出了问题才去修复。

三层防御体系

第一层是输入过滤。所有来自用户输入的 GitHub Event 数据（PR 描述、commit message、issue 内容）在进入 CI 流水线前都需要做脱敏处理，尤其是当你的流水线接入了 AI Agent 时。微软的研究建议将 AI Agent 的输出与敏感操作之间加入人工审批环节。

第二层是依赖锁定。不要依赖 npm 的默认查找顺序，用 npm provenance attestation 绑定构建产物与源码的链路——GitHub Actions 基于 Sigstore 的 Artifact Attestations 可以签名并验证软件制品的完整性，确保你安装的包确实来自你自己的源码构建。

第三层是 OIDC 最小权限。检查你的云服务商 trust policy，确保 audience、subject 和 repository 条件都精确到具体工作流，不要用通配符。用 permissions 限制每个 job 的 token 作用域，并在 workflow 结束后主动 revoke 会话。

下一步

今天回去检查你的 GitHub Actions permissions 配置，逐一确认每个 job 是否真的需要 write 权限。如果你的流水线接入了 AI Agent，检查那些会处理 PR 描述和 commit message 的步骤，确认没有把未经处理的用户输入直接传给 LLM。最关键的是：不要等到出事了才想起来加安全门。