Bridging Code Property Graphs and Language Models for Program Analysis

论文标题

Bridging Code Property Graphs and Language Models for Program Analysis
（ bridging 代码属性图与语言模型用于程序分析）

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

尽管大语言模型（LLM）在软件漏洞管理（如检测、修补）方面展现出潜力，但在处理真实世界的大型代码库时面临三大关键挑战：

1. Token 限制与上下文窗口不足：现代代码库包含数百万行代码和数千个文件。将整个仓库加载到 LLM 的上下文中会超出 Token 限制，导致现有方法只能分析孤立的代码片段，从而遗漏跨函数、跨文件的漏洞。
2. 代码嵌入缺乏语义深度：基于检索增强生成（RAG）的方法通过相似度搜索检索代码片段，但代码嵌入（Embeddings）主要捕捉语法模式，无法有效表示过程间的数据流（例如：函数 A 的返回值如何流入函数 B 的缓冲区写入）或控制依赖关系。
3. 生成复杂静态分析查询的困难：虽然 CPG（如 Joern 引擎）支持强大的查询语言（CPGQL），但 LLM 由于训练语料中缺乏此类领域特定语言，难以生成正确的复杂查询。这导致 LLM 在尝试多跳遍历时常产生幻觉或语法错误的查询，使得直接生成查询不可靠。

核心痛点：现有的 LLM 方法要么因上下文限制而视野狭窄，要么因无法理解跨模块的语义关系而失效，无法像人类安全分析师那样进行全库范围的语义推理。

2. 方法论与系统架构 (Methodology)

为了解决上述问题，作者提出了 codebadger，一个开源的模型上下文协议（Model Context Protocol, MCP）服务器。该系统作为 LLM 与 Joern 静态分析引擎之间的中间件，核心设计理念是“提供分析工具而非要求生成查询”。

2.1 核心架构

• MCP 集成：codebadger 作为一个 MCP 服务器运行，允许 LLM Agent 通过标准接口调用外部工具。
• Joern CPG 引擎：后端利用 Joern 将源代码解析为代码属性图（CPG），该图融合了抽象语法树（AST）、控制流图（CFG）和程序依赖图（PDG）。
• 工具抽象层：codebadger 不直接暴露 CPGQL 查询语言，而是将复杂的图遍历算法封装为高级语义工具。LLM 只需调用这些工具，无需理解底层图结构或查询语法。

2.2 关键工具功能

系统提供了一系列针对安全分析的工具，包括：

• 程序切片 (Program Slicing)：使用后向切片算法，从特定的可疑调用点出发，逆向收集所有相关的数据和控制依赖，将代码库缩小 90% 以上，仅保留漏洞相关的代码片段。
• 污点追踪 (Taint Tracking)：识别污点源（如用户输入）和污点汇（如危险函数），并追踪数据在过程间的传播路径。
• 数据流分析 (Data Flow Analysis)：追踪变量的定义和使用关系，识别未经验证的数据流。
• 调用图提取 (Call Graph Extraction)：构建方法调用关系图，支持跨模块分析。
• 边界检查 (Bounds Checking)：自动验证数组或缓冲区访问是否越界。

2.3 工作流程

1. LLM Agent 调用 create_cpg_session 初始化代码库的 CPG。
2. Agent 根据分析目标调用特定工具（如 find_taint_sources 定位输入点，find_taint_flows 追踪数据流）。
3. codebadger 在后台将高级指令转换为 CPGQL 查询，执行分析，并将结构化的结果（如 JSON 格式的数据流、精简的代码片段）返回给 LLM。
4. LLM 基于这些语义信息进行推理、漏洞判断或生成补丁。

3. 主要贡献 (Key Contributions)

1. 提出了 codebadger 框架：首个将 CPG 引擎与 LLM 通过 MCP 协议深度集成的开源工具，实现了从“暴力读取代码”到“语义导航代码”的范式转变。
2. 解决了 LLM 的查询生成难题：通过预实现的工具抽象，消除了 LLM 学习 CPGQL 语法的负担，使其能专注于逻辑推理。
3. 实现了跨过程（Inter-procedural）的漏洞分析：证明了 LLM 结合 CPG 工具可以追踪跨越多个文件和函数的复杂数据流，这是传统 RAG 方法无法做到的。

4. 实验结果与案例研究 (Results)

作者通过三个实际案例验证了 codebadger 的有效性（使用 Claude Sonnet 4.5 作为 LLM 代理）：

案例 1：大规模代码库理解与审计 (GGML)

• 任务：审计包含 8,667 个方法、19.8 万次函数调用的 GGML 库的内存安全模式。
• 过程：Agent 未读取所有文件，而是通过工具定位了 54 个分配点和 300+ 个危险操作，并追踪了特定的数据流。
• 发现：识别出未加边界的 alloca 使用、整数溢出导致的分配大小计算错误，以及未检查的指针算术问题。
• 意义：证明了系统能在 Token 限制内处理超大规模代码库。

案例 2：发现未报告的漏洞 (libtiff)

• 任务：分析 libtiff 中的 tif_getimage.c 文件。
• 过程：Agent 通过污点追踪发现 col_offset 变量从结构体传递到 gtStripContig 函数时，经过指针算术运算后未进行边界检查。
• 成果：
  • 发现了一个未报告的缓冲区溢出漏洞。
  • 生成了基于 AddressSanitizer (ASAN) 验证的 PoC 利用代码（构造恶意 TIFF 文件触发堆溢出）。
  • 确认该漏洞在修复前未被公开（无 CVE 编号），且修复补丁（增加边界检查）与后续维护者的修复高度一致。

案例 3：漏洞修补 (libxml2, CVE-2025-6021)

• 任务：针对 libxml2 中 xmlBuildQName 函数的整数溢出漏洞（导致缓冲区溢出）生成补丁。
• 过程：Agent 利用 get_program_slice 和 get_data_dependencies 追踪 lenn 和 lenp 变量的来源，识别出 strlen 结果相加可能导致整数溢出，进而导致分配过小的缓冲区。
• 成果：
  • 首次尝试即生成了正确的补丁，无需人工干预。
  • 生成的补丁逻辑（使用 size_t、添加溢出检查）与维护者实际发布的修复方案高度相似。
  • 证明了 LLM 结合静态分析工具具备专家级的漏洞修复能力。

5. 意义与影响 (Significance)

• 范式转变：将 LLM 在安全分析中的角色从“代码阅读器”转变为“分析工具调用者”，解决了上下文窗口和语义理解的瓶颈。
• 自动化安全运营：codebadger 使得 LLM Agent 能够像人类安全专家一样，在大型代码库中进行导航、切片和依赖追踪，支持从漏洞发现、利用验证到自动修补的全流程自动化。
• 开源生态：作为一个开源 MCP 服务器，它降低了将静态分析集成到 AI 工作流中的门槛，促进了 AI 驱动的软件漏洞管理（SVM）的发展。

6. 局限性与未来工作

• 资源开销：Joern 生成 CPG 对超大型仓库（如 Linux 内核）需要大量内存。
• 查询依赖：尽管有高级工具，LLM 偶尔仍需直接调用 CPGQL，此时仍可能出错。
• 动态漏洞：目前主要处理静态分析，对竞态条件等运行时漏洞支持有限。
• 评估：未来需要更大规模的定量基准测试来评估其通用性。

总结：该论文展示了通过codebadger将静态分析引擎（Joern/CPG）的精确性与 LLM 的推理能力相结合，是解决大规模代码库安全分析难题的有效途径，显著提升了 LLM 在漏洞发现、利用生成和自动修补方面的实际能力。