解析与检测 GitHub Actions 中的智能体工作流注入漏洞

核心问题： GitHub Actions 中基于 LLM 的智能体工作流（agentic workflows）引入了新的注入面，不可信的 GitHub 事件上下文（如 issue 正文、PR 描述、评论）可能被纳入智能体提示词或下游工作流逻辑，导致攻击者影响智能体行为，但现有技术无法有效检测这类漏洞。

• 问题场景与重要性： GitHub Actions 越来越多地用于部署基于 LLM 的智能体执行仓库任务（如 issue 分类、PR 审查、代码修改）。这些智能体工作流扩展了传统 CI/CD 自动化，但也创造了新的攻击面。安全报告（如 PromptPwnd、Clinejection）已记录真实案例，攻击者可通过恶意 issue 或 PR 内容窃取密钥或执行未授权操作。

• 现有方法不足： 现有提示词注入检测技术（如 prompt-to-code、prompt-to-SQL）未针对 CI/CD 工作流设计，无法捕获工作流特有的执行语义（如事件上下文、action 输入输出接口、跨步骤数据通道）。传统 CI/CD 安全工具（如 ARGUS、CodeQL）关注确定性工作流，不建模智能体提示词、派生输出或 LLM 边界的污点传播。

• 核心观察： 作者提出 Agentic Workflow Injection（AWI）是一种工作流级注入缺陷，不可信事件上下文被纳入智能体提示词或智能体消费的输入，并通过智能体工具或下游工作流逻辑转化为攻击者影响的行为。AWI 是提示词注入和脚本注入在智能体工作流中的交集，但不被任一类单独完全捕获。

• 论文贡献： 作者首次系统研究 GitHub Actions 中的 AWI，表征了 1,033 个真实 AI-assisted actions，提取 AWI 特定的污点规范，并设计 TAINTAWI 静态分析工具检测 P2A 和 P2S 漏洞。

• 威胁模型：

  • 攻击者目标： 通过语义影响使智能体执行攻击者期望的操作，如标记 issue、发表评论、修改文件、执行 shell 命令或调用 GitHub API。
  • 攻击者知识： 外部 GitHub 用户或低权限贡献者，可通过正常协作渠道与仓库交互。
  • 攻击者能力： 可创建 issue、提交 PR、发表评论，但不能修改工作流文件、仓库设置、受保护分支或 secrets。
  • 受害系统： 通过 agentic actions 或 CLI 调用 LLM 智能体的 GitHub Actions 工作流，这些工作流在配置的工作流环境中执行，可能继承工作区访问权限、凭证和暴露的智能体能力。

GitHub Actions 与 CI/CD 工作流安全

• Koishybayev et al. [21] 表征了 GitHub CI 工作流的安全属性，指出过度权限、不可信触发器和第三方 action 依赖普遍存在。
• Benedetti et al. [23] 通过自动化评估展示了工作流安全弱点的普遍性；Muralee et al. [24] 提出 ARGUS，一个针对 GitHub 工作流和 actions 的分阶段静态污点分析框架，用于检测代码注入漏洞。
• 近期工作 [22] 重新审视了 GitHub Actions 工作流的安全实践，[25] 比较了工作流扫描器的范围和有效性，[2] 分析了失败的工作流执行以构建失败原因分类法。

LLM 集成系统中的新兴攻击面

• 实证研究识别了 prompt-to-code 执行 [13]、prompt-to-SQL 注入 [11]、prompt-to-anything 漏洞 [12] 以及工具使用智能体中的污点式攻击 [10]。
• 后续工作研究了工具选择中的提示词注入 [14]、跨工具收集和污染 [20]，以及 LLM 智能体中的多工具漏洞 [19]。
• 基准和审计框架（如 Agent Security Bench [46]、AgentAuditor [47]）开始系统化智能体安全评估；新兴审计和扫描工具（如 Trail of Bits 的 Agentic Actions Auditor [48]、Prompt Injection Scanner [37]、Aikido OpenGrep Rules [38]）反映了对这类风险的关注。

基线方法与基准

• 论文对比了四个基线工具：PROMPT INJECTION SCANNER（PISCANNER）[37]，一个启发式工作流扫描器，检测 AI 智能体处理不可信用户输入的不安全模式；Aikido 的 OPENGREP RULES [38]，一个轻量级模式匹配基线；ARGUS [24] 和 CODEQL [39]，两个通用 GitHub Actions 污点分析器。后两者被提供了与 TAINTAWI 相同的 agentic-action 提示词汇点规范以检测 P2A 流，但未添加派生输出规范或 P2S 传播规则。

作者定位 作者指出，现有研究主要关注一般设置中的 LLM 集成应用和智能体，未充分探索它们与 CI/CD 工作流语义的交互。本文通过系统研究真实 GitHub Actions 工作流中 LLM 能力如何使不可信输入影响下游工作流行为，填补了这一空白。

作者首先定义了 Agentic Workflow Injection（AWI）漏洞类型，识别出两种核心模式：Prompt-to-Agent（P2A）和 Prompt-to-Script（P2S）。在此基础上，设计了 TAINTAWI 静态分析器，通过四个阶段检测 AWI 漏洞：推断 action 级污点规范、构建工作流中间表示（IR）、生成 Agentic Workflow Dependency Graph（AWDG）、执行污点传播和可达性分析。

问题设定与形式化

• AWI 定义： 工作流级注入缺陷，不可信 GitHub 事件上下文被纳入智能体提示词或智能体消费的输入，进而影响智能体行为或下游工作流逻辑。与传统脚本注入不同，AWI 依赖语义影响而非语法有效的代码注入。
• 两种核心模式：
  • P2A（Prompt-to-Agent）： 不可信内容到达智能体提示词边界，可能操纵智能体的特权能力。
  • P2S（Prompt-to-Script）： 攻击者影响先通过模型或智能体派生的输出传播，后被下游工作流逻辑消费。
• 四个安全属性： 智能体能力（Agentic Capability）、提示词可配置性（Prompt Configurability）、访问控制（Access Control）、输出暴露（Output Exposure）。这些属性本身不是漏洞，但当工作流将不可信事件上下文与它们组合时，可能暴露 AWI 风险。

Action 级污点规范推断

• 数据收集： 从 GitHub Actions Marketplace 的 ai-assisted 类别和关键词搜索收集候选 AI-assisted actions，去重后得到 1,035 个唯一 action 仓库，其中 1,033 个包含可分析的 action 元数据文件。
• LLM 辅助分析： 使用 LLM 辅助分析器推断四个安全属性，包括 action 类型（agentic/LLM-assisted/non-LLM）、提示词边界、派生输出和访问控制接口。分析聚焦于暴露给工作流作者的 action 元数据接口。
• 人工验证： 前两位作者独立审查 100 个随机样本，LLM 推断字段与人工标签一致率为 95.9%。对下游引用超过 100 次的 22 个广泛采用 action 进行完整人工审查。

工作流 IR 构建

• 三级层次结构： 将 GitHub Actions 工作流 YAML 文件提升为保留执行语义的中间表示（IR），包括 WorkflowIR（记录触发事件、输入、环境变量、权限、作业列表）、JobIR（记录作业标识、needs 依赖、条件、环境变量、权限、输出、步骤列表）和 StepIR（记录步骤键、ID、uses action、run 脚本、with 输入、环境变量、条件）。
• 语义保留： IR 规范化原始 YAML 语法，捕获触发入口点、作业级控制流和步骤级数据接口，为后续污点分析提供分析就绪的工作流语义。

AWDG 生成与污点传播

• AWDG 构建： 构建有向图 G_W = (V, E_cf, E_df, α)，其中节点表示工作流级值或执行站点，边表示潜在控制流或数据流。控制流边表示执行可能从 u 进行到 v，数据流边表示 u 的值可能流入 v。
• 污点规范： 定义污点源（Src）为攻击者可控制的工作流值（如 issue.title、issue.body、comment.body、pull_request.title、pull_request.body、分支/提交元数据、序列化事件上下文）；汇点（Snk）分为 P2A 汇点（agentic actions 的提示词输入接口）和 P2S 汇点（消费模型/智能体派生数据的下游工作流操作，如 gh issue edit、git push）；净化器（San）包括 action 级守卫（如 allow-users、allowed_non_write_users）和工作流级守卫（如发送者白名单、作者关联检查）。
• 传播规则： 包括源初始化、工作流数据传播、P2A 检测（当污点到达 agentic action 的提示词边界时报告）、模型/智能体输出桥接（当污点到达提示词边界时，将同一调用的派生输出视为受污染）、P2S 检测（当受污染的派生输出到达安全敏感下游汇点时报告）。
• 可达性分析： 检查报告路径是否在工作流执行条件和 action 调用守卫下对攻击者可达，过滤不可达路径。仅当污点路径存在且在应用 action 级和工作流级守卫后仍保持攻击者可达时，才报告漏洞。

实验设置

• 被测对象： 13,392 个真实 GitHub Actions 工作流，来自 10,792 个仓库，这些工作流直接调用至少一个 agentic 或 AI-assisted action。
• Action 表征： 1,033 个 AI-assisted actions，其中 160 个为 agentic，572 个为 LLM-assisted；292 个为 AWI 相关候选（113 个 agentic，179 个 LLM-assisted）。
• 基线工具： PISCANNER、OPENGREP、ARGUS、CODEQL。ARGUS 和 CODEQL 被提供与 TAINTAWI 相同的 agentic-action 提示词汇点规范。
• 实现与环境： TAINTAWI 用 Python 实现，在线分析器 3.6 KLoC，完整实现约 4.5 KLoC。实验在单台 Ubuntu 22.04.5 LTS 服务器上进行，256 CPU 核心，1.0 TiB 内存，Python 3.9.15。
• 评估指标： 精度（precision）、真阳性（TP）、假阳性（FP）、覆盖率（coverage）。由于真实世界漏洞检测缺乏完整 ground truth，不报告完整精度或召回率，而是报告全语料库的工作流级警报数和 496 个确认 TP 案例的覆盖率。
• 人工验证： 作者人工审查所有报告案例，确认 496 个可利用，23 个为假阳性。对于假阴性，从每个基线工具随机抽样 100 个仅基线报告的案例（共 400 个），人工审查后识别 13 个 TAINTAWI 的假阴性。

主结果

表格较宽，可左右滑动

工具	#Alerts	#TP Cov.	#P2A	#P2S	#Missed
PISCANNER	2,079	78	78	0	418
OPENGREP	1,658	73	73	0	423
ARGUS	831	66	66	0	430
CODEQL	1,486	76	76	0	420
TAINTAWI	519	496	103	419	0

据 Table V

• 作者解读： PISCANNER 和 OPENGREP 报告大量警报但覆盖率低，因为它们仅启发式识别 AI-like 使用或匹配直接嵌入提示词字段的不可信表达式，不构建工作流级依赖图或建模派生输出。ARGUS 和 CODEQL 在提供 AI 提示词输入作为汇点后能恢复部分 P2A 流，但仍停留在提示词边界，错过 P2S 案例。TAINTAWI 通过建模提示词边界流和派生输出传播，比最强基线多覆盖 418 个 TP。

零日漏洞披露

• 总体结果： TAINTAWI 初始报告 519 个潜在 AWI 漏洞，人工审查确认 496 个可利用（精度 95.6%），23 个为假阳性。在 496 个确认 TP 中，153 个已被社区报告但未修复，343 个为零日漏洞。
• 披露状态： 优先披露 187 个零日案例（仓库有 GitHub stars 或至少一次成功工作流运行历史）。其中 102 个仓库无可用私有披露渠道，85 个通过 GitHub Security Advisories、邮件或仓库特定渠道正式报告。收到 26 个维护者响应，24 个案例已被接受或修复。这些修复或接受的案例影响 23 个唯一仓库，总 stars 超过 130K，涉及多个 AI-assisted actions（据 Table IV）。

消融研究

表格较宽，可左右滑动

变体	#Report	#Covered	#P2A	#P2S
Full TAINTAWI	519	496	103	419
w/o Derived-output Bridging	117	103	103	0
w/o Workflow Bridges	102	89	89	0
w/o Script Analysis	462	442	89	372
w/o Guard Analysis	881	496	103	419

据 Table VI

• 作者解读： 派生输出桥接对 P2S 检测至关重要，禁用后覆盖率从 496 降至 103，且无法检测 P2S 案例。移除工作流桥接进一步降低覆盖率至 89，表明许多 AWI 路径依赖工作流数据通道。脚本分析也有贡献，禁用后覆盖率从 496 降至 442，P2S 覆盖率从 419 降至 372。禁用守卫分析使报告数从 519 增至 881，表明可达性分析有助于控制假阳性。

效率评估

• 性能： TAINTAWI 在 12.32 分钟内完成 13,392 个工作流的在线分析，平均每个工作流 0.054 秒，中位数 0.008 秒，最大 11.360 秒，吞吐量 18.12 工作流/秒。峰值内存 0.276 GB，平均使用 1.11 CPU 核心。

特征分析（RQ3）

• 守卫路径： 在 881 个具有 AWI 相关污点路径的工作流中，362 个（41.1%）包含有效守卫；306 个（34.7%）仅使用 action 级守卫，27 个（3.1%）仅使用工作流级守卫，29 个（3.3%）两者都使用。
• AWI 模式： 在 496 个确认案例中，issue 标题/正文是主要来源（429 例，86.5%），其次是 PR 字段（50 例，10.1%）和评论/审查正文（24 例，4.8%）。P2S 是主要汇点模式（419 例，84.5%），P2A 出现 103 例（20.8%）。
• 安全影响： GitHub 写入/API 操作出现在 391 例（78.8%），shell 或工具执行 307 例（61.9%），文件/工作区写入 81 例（16.3%）。
• 生态分布： 496 个确认案例跨越 440 个唯一仓库，总 stars 421,098。最大集群来自 actions/ai-inference（393 例，79.2%）。

作者指出的局限与后续方向

• 静态过近似： TAINTAWI 是静态分析器，可能报告语法可行但实际难以利用的路径（由于仓库特定策略、不可用 secrets、失败的工作流运行或第三方 actions 的未记录运行时行为）。作者通过可达性分析和人工验证缓解，但完全建模 GitHub 运行时行为和每个 action 的内部实现仍具挑战性（§ VII-B）。
• Action 语义不完整： TAINTAWI 依赖 action 级污点规范，但 GitHub Actions 生态系统快速演变，长尾或新发布的 actions 可能暴露尚未建模的提示词或输出接口。缺失或过时的规范可能导致假阴性（§ VII-B）。
• 嵌入式脚本分析有限： TAINTAWI 目前对常见 shell run 步骤进行轻量级分析，使用 YASA 分析 actions/github-script 中的内联 JavaScript，但不提供完整的数据流分析。复杂 shell 语义、跨文件脚本和动态生成的命令可能被遗漏。作者认为更完整的多语言脚本分析是重要的未来工作（§ VII-B）。

实验覆盖范围

• 被测工作流： 13,392 个真实 GitHub Actions 工作流，来自 10,792 个仓库，这些工作流直接调用至少一个 agentic 或 AI-assisted action（§ VI-A）。
• Action 表征： 1,033 个 AI-assisted actions，其中 292 个为 AWI 相关候选（113 个 agentic，179 个 LLM-assisted）（§ IV-B）。
• 基线对比： 与四个基线工具（PISCANNER、OPENGREP、ARGUS、CODEQL）在全语料库上对比，ARGUS 和 CODEQL 被提供相同的 agentic-action 提示词汇点规范（§ VI-A）。
• 人工验证规模： 人工审查所有 519 个报告案例；从基线工具抽样 400 个仅基线报告的案例进行假阴性评估（§ VI-C）。
• 论文未报告： 完整的 ground truth（因此不报告完整精度或召回率）；TAINTAWI 使用的具体 LLM 模型名称或版本（仅描述为"LLM-assisted analyzer"）；假阴性评估的详细错误分析（仅归因于不完整的污点规范、脚本级汇点模式和传播语义）。

本文研究 GitHub Actions 中基于 LLM 的智能体工作流的安全问题。作者定义了 Agentic Workflow Injection（AWI）这一新型工作流级注入漏洞，其中不可信的 GitHub 事件上下文（如 issue 正文、PR 描述）被纳入智能体提示词或下游工作流逻辑，导致攻击者影响智能体行为。AWI 包括两种模式：Prompt-to-Agent（P2A）和 Prompt-to-Script（P2S）。

作者表征了 1,033 个真实 AI-assisted actions，发现仅 21 个提供显式调用者身份访问控制。基于此，设计了 TAINTAWI 静态分析器，通过推断 action 级污点规范、构建工作流中间表示（IR）和 Agentic Workflow Dependency Graph（AWDG），执行污点传播和可达性分析来检测 AWI 漏洞。

在 13,392 个真实工作流上的评估显示，TAINTAWI 报告 519 个潜在漏洞，人工确认 496 个可利用（精度 95.6%），其中 343 个为零日漏洞。与四个基线工具相比，TAINTAWI 多覆盖 418 个确认案例。消融研究表明派生输出桥接对 P2S 检测至关重要。作者优先披露 187 个零日案例，24 个已被接受或修复。

作者认为，AWI 是由可重用 agentic actions 引起的实际风险，需要默认安全的 action 接口和更安全的工作流组合实践。对于 action 开发者，应提供内置访问控制、分离可信指令与不可信内容、暴露类型化输出；对于工作流开发者，应将 GitHub 事件上下文视为不可信，实施工作流级访问控制，验证模型派生输出。