Skip to content
ToLO Knowledge Base

QLCoder 用 agent 从 CVE 元数据合成 CodeQL 查询

一句话

据论文,QLCoder 把 LLM 包进 agentic 合成循环,直接从 CVE 元数据自动产出可在 CodeQL 上执行的查询。

为什么读这篇

QLCoder 是 IRIS 同作者团队的后续工作。如果 IRIS 是 “LLM 推 spec + 跑 taint”,QLCoder 走得更激进:“LLM 直接写整条 CodeQL 查询”。

读这篇之前,你可能会想:既然 LLM 这么强,为什么不让它把 CodeQL 查询从头到尾写出来?读完之后,你会看到这条路的实际成功率(53.4%)和剩余难点,从而理解**为什么 ToLOScanner 选择”人工固定 spec + LLM 辅助 triage”**而不是纯 LLM-synth。

核心贡献

  • 提出从 CVE 元数据到 CodeQL 查询的 agentic 合成框架
  • 用 MCP 接口把 Language Server 与 RAG 接入合成回路
  • 在 Java CVE 基准上把正确率从 10% 提到 53.4%

它解决的问题

写一条有效的 CodeQL 查询要:

  1. 知道目标 CWE 的 source / sink 形态
  2. 熟 CodeQL QL 语法
  3. 熟项目特定 codebase 结构
  4. 经过多轮调试,确认 “vulnerable 版本告警 / patched 版本不告警”

这通常需要资深安全研究员花数小时到数天。QLCoder 的目标:让 LLM 在 agent 循环里自己完成这套工作。

方法摘要

据论文,系统以 LLM 为合成核心,围绕其搭建一个执行反馈驱动的 agent 循环。

关键组件

LLM (Claude / GPT-4 等)
   │
   ├── Language Server Protocol (LSP)
   │      用 CodeQL 语言服务给出语法引导、类型查询、补全
   │
   ├── RAG database
   │      已有 CodeQL 查询 + 官方文档的语义检索
   │
   └── CodeQL engine (execution feedback)
          每次合成查询后真实跑一遍:
            - vulnerable 版本上是否告警?
            - patched 版本上是否不告警?
          反馈回灌给下一轮 LLM 推理

reasoning 通路被一个自定义 MCP 接口约束为两条结构化通道。底层 agent runtime 基于 Claude Code 框架。

正确性判据

合成的查询要在 CodeQL 引擎上真实执行:

✓ vulnerable 版本上告警(检出原 bug)
✓ patched 版本上不告警(不误报修复后代码)

满足两个条件,该 CVE 算”成功合成”。

与 ToLO 的关联

QLCoder 不直接对应七子类中的任何一类,它处理的是 “如何自动写检测查询” 这一方法论问题。

对本站的价值在于:它代表 LLM-synth-CodeQL 这条基线路线 —— 以 CVE 元数据驱动 LLM 自动产出查询,与 ToLOScanner 走人工 spec + source/sink/sanitizer 显式建模的路线形成自然对照。

论文未涉及 source 集合 S_LLM 的污点建模,也未把 sanitizer 显式形式化为 C_SAFE 五类,因此不直接落到攻击者通道 C1-C5 或数据流五边界中的某一具体位置。

实验与结论要点

据论文,基准:

  • 111 个 Java 项目 + 176 个 CVE
  • 正确性以 “vulnerable 版本告警 且 patched 版本不告警” 为标准
方法正确率
Baseline Claude Code(纯 LLM,无 LSP/RAG)10%
QLCoder53.4%

差距说明 LSP 语法引导与 RAG 检索对查询合成质量贡献明显。abstract 未给出按 CWE 类别拆分的细分结果或消融,需要查正文确认。

局限与开放问题

  • 评测仅限 Java 与 CodeQL,Python / 其它语言生态未覆盖。
  • 正确性判据是 vulnerable / patched 双版本对比,未量化误报与召回。
  • 53.4% 仍意味着近一半 CVE 上自动合成失败,失败模式与是否可恢复未在公开摘要中说明。
  • 不区分**“自动合成”与”人工 spec + LLM 辅助合成”**:后者可能用更少 LLM 调用得到更高成功率。

对本站的启发

为本站的 “baseline: LLM-synth-codeql” 基线槽位提供具体方法实例。可在 ToLOScanner 实验设计里作为对照 —— 它代表”无 ToLO 先验知识、纯靠 CVE 描述驱动 LLM 写查询”这条路。

结果暗示:即使配上 LSP 与 RAG,纯 LLM-synth 仍卡在过半失败率。这间接支持本站把 source class S_LLM 与 sanitizer class C_SAFE 显式形式化、再喂给查询作者(无论人或 LLM)的设计。

无需扩展 taxonomy。

对 ToLOScanner 实验设计的具体启发

Setting B0: 默认 CodeQL 规则(传统 CWE source)
Setting B1: IRIS(LLM 推 spec + taint)
Setting B2: QLCoder(LLM 合成整条 query)
Setting C:  ToLOScanner(固定 `S_LLM` / 七子类 / `C_SAFE` spec)

在 LLM 编排框架 CVE 集上跑,可以验证 Setting C 是否显著优于 B0/B1/B2 —— 因为这些 baseline 都没有专门的 LLM 输出 source 建模。

如果 Setting B2 在足够多 ToLO CVE 上能 close gap,那 ToLOScanner 的研究价值就需要重新论证。这是一个关键对照实验。

ToLO 一行标注

- / - / - / 对照 baseline (LLM-synth-CodeQL) / -

读完检查

  • QLCoder 和 IRIS 的主要差别?
    • IRIS: LLM 推 spec → 跑 taint;QLCoder: LLM 写整条 query → 直接跑 CodeQL。前者更接近”LLM 辅助传统流程”,后者更接近”LLM 取代规则作者”。
  • 如果 QLCoder 把 LLM 应用 CVE 也加进 benchmark,可能命中 ToLO 吗?
    • 部分。QLCoder 看 CVE description 写 query,如果 description 里说”LLM 输出进入 eval”,LLM 可能能写出对应 query。但它没有 S_LLM 作为先验,所以对那些 description 含糊或非典型的 ToLO 路径会漏。

外部链接

内部互链