论文技术总结：LLM 赋能的开源系统漏洞实证研究

论文标题：LLM-Enabled Open-Source Systems in the Wild: An Empirical Study of Vulnerabilities in GitHub Security Advisories
发表会议：FSE Companion '26 (2026 年 7 月)
作者：Fariha Tanjim Shifat 等 (密苏里科技大学等)

---

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）被广泛集成到现代开源软件（OSS）生态系统中（如作为开发助手、运行时组件或自主代理），软件架构发生了根本性变化。传统的软件组件通常具有固定的输入输出结构，而基于 LLM 的系统则处理自然语言提示并产生概率性输出，这些输出可能触发文件系统操作、命令执行或 API 调用。

核心问题：
现有的漏洞披露框架（如 GitHub 安全公告 GHSA）和分类标准（如 CWE）主要关注代码层面的缺陷（如注入、反序列化），但是否足以捕捉由模型中介（model-mediated）引发的风险尚不明确。

• 局限性：CWE 描述了代码如何失效，但未能反映漏洞是否通过模型推理、提示操纵或代理自主性被触发、放大或传播。
• 缺失视角：缺乏对架构层面风险（如供应链风险、过度代理权限、提示注入）的系统性量化分析。

2. 研究方法 (Methodology)

本研究采用实证分析方法，结合定量统计与定性标注，具体流程如下：

1. 数据收集：

   • 从 GitHub 安全公告数据库（GHSA）收集了 2025 年 1 月至 2026 年 1 月 期间发布的 295 条明确引用 LLM 相关组件的安全公告。
   • 提取了受影响的包名、生态系统、严重程度、CVE 及 CWE 分类等信息。

2. 数据过滤与分类：

   • 从 295 条公告中提取出 133 个唯一受影响的软件包。
   • 通过人工审查（基于仓库文档、项目描述等），将软件包分为三类：
     • LLM 相关 (LLM-associated)：核心功能是实现或编排 LLM 功能（如推理引擎、LangChain）。
     • 可能 LLM 相关 (Possible LLM-associated)：非 LLM 专用，但在 LLM 流程中常作为基础设施（如向量数据库）。
     • 非 LLM 相关：与 LLM 系统无关。
   • 最终样本包含 226 条 LLM 相关公告和 34 条可能相关公告。

3. 人工标注 (Annotation)：

   • 从上述相关样本中随机抽取 100 条公告。
   • 依据 OWASP Top 10 for LLM Applications 2025 标准进行人工标注。
   • 两名标注者独立工作，Cohen's Kappa 系数为 0.76，Gwet's AC1 为 0.95，表明一致性高。
   • 分析重点在于识别架构层面的暴露模式（如供应链、过度代理等），而不仅仅是代码缺陷。

3. 主要贡献 (Key Contributions)

1. 实证特征分析：基于 295 条公告，首次系统性地刻画了 LLM 相关 GitHub 安全公告中的 CWE 模式。
2. CWE 与 OWASP 映射：通过人工标注 100 条公告，建立了传统代码缺陷（CWE）与 LLM 特定架构风险（OWASP）之间的系统性映射关系。
3. 揭示元数据缺陷：提供了证据表明当前的 GHSA 元数据缺乏对"LLM 参与”和“模型中介暴露机制”的结构化指示，限制了对模型相关风险的自动化分析。

4. 关键研究结果 (Results)

研究回答了四个核心研究问题（RQs）：

RQ1: LLM 相关公告中最常见的 CWE 类别是什么？

• 结论：未发现 LLM 系统特有的新实现级弱点类别。
• 主导缺陷：绝大多数公告映射到传统的 CWE 类别，主要是：
  • 注入类：代码注入 (CWE-94, 24 次)、命令注入 (CWE-77/78, 41 次)。
  • 不安全反序列化：CWE-502 (22 次)。
  • 资源管理：如不控制资源消耗 (CWE-400)。
• 意义：LLM 生态系统主要继承了现有的软件弱点，而非创造全新的代码级漏洞。

RQ2: 现有公告元数据如何表示 LLM 参与？

• 结论：效果不佳。
• GHSA 元数据（包名、严重程度、CWE）无法区分传统库与实现模型推理/提示处理的包。
• 必须通过人工分类才能识别模型中介的暴露模式，现有的结构化数据缺失了"AI 参与”这一关键维度。

RQ3: 映射到 OWASP Top 10 (2025) 后出现了哪些暴露模式？

• 结论：架构风险模式显著且频繁共存。
  • 供应链风险 (Supply Chain, LLM03)：占比最高 (44%)，表明风险集中在依赖项、插件和编排层。
  • 过度代理 (Excessive Agency, LLM06)：占比 20%，涉及 LLM 触发执行路径或特权操作。
  • 提示注入 (Prompt Injection, LLM01)：占比 18%，常作为下游影响的触发条件。
  • 多标签模式：37% 的公告表现出多标签组合（如 LLM03+LLM06 或 LLM01+LLM05+LLM06），表明漏洞往往通过“提示处理 -> 输出处理 -> 执行权限”的链条传播。

RQ4: OWASP 风险类别如何对应底层的 CWE 弱点？

• 结论：架构风险通过传统实现弱点具体化。
  • 供应链 (LLM03)：对应广泛的 CWE，包括命令注入 (CWE-78)、缺少认证 (CWE-306) 和代码注入 (CWE-94)。
  • 过度代理 (LLM06)：高度集中在命令注入 (CWE-77/78) 和代码注入 (CWE-94)，反映了代理权限滥用导致的执行风险。
  • 提示注入 (LLM01)：主要映射到命令注入 (CWE-77) 和跨站脚本 (CWE-79)，显示提示操纵如何转化为代码执行。

5. 研究意义与启示 (Significance)

1. 实施级弱点仍是核心：LLM 集成系统的漏洞分析不能脱离传统的代码安全分析。注入、反序列化等经典弱点依然是主要威胁，现有的代码级缓解技术依然有效。
2. 架构暴露决定风险：LLM 系统的独特风险在于架构设计。风险往往不是模型内部产生的，而是通过提示处理、输出验证、编排层和执行权限的交互链条被放大。安全分析必须关注组件间的交互路径。
3. 元数据需要进化：当前的漏洞披露标准（GHSA）仅捕捉了“代码缺陷”，遗漏了“交互路径”。未来的安全元数据需要显式编码 LLM 参与度和模型中介机制，以便更准确地评估风险。
4. CWE 与 OWASP 互补：
   • CWE 解释了“代码如何失效”（Implementation）。
   • OWASP LLM 解释了“系统如何在架构层面暴露”（Architecture）。
   • 只有结合两者，才能全面理解 LLM 集成系统的风险概况。

总结

该论文通过实证研究指出，LLM 并未引入全新的代码级漏洞类型，而是将传统的软件弱点（如注入）置于新的、更复杂的架构交互中（如提示注入导致命令执行）。现有的漏洞披露机制在捕捉这种“模型中介”风险方面存在不足，建议未来的安全实践应结合 CWE 和 OWASP LLM 视角，并改进元数据标准以反映 AI 组件的特殊性。