Skip to content
ToLO Knowledge Base

IRIS 用 LLM 辅助污点规格推断

一句话

核验状态:pending。 本页按论文自述做阅读笔记;venue、DOI、benchmark 数字、检出数和新漏洞声明仍需回到官方来源核验。正文中的数字均应读作”据论文报告”。

据论文,IRIS 用 LLM 推断 taint sources / sinks,并结合全仓污点分析检测 Java 项目中的传统安全漏洞。

为什么读这篇

IRIS 是 ToLOScanner 的方法学近邻基线:二者都把 LLM 放进静态污点分析流程。

但对照点关键:IRIS 让 LLM 在 detection time 生成 spec;ToLOScanner 应固定 spec(S_LLM / 七子类 / C_SAFE),只把 LLM 用于 triage / 解释。

读完它,你应能精确说出:“LLM-assisted SAST 不等于 ToLOScanner”。两者都用 LLM 辅助,但 LLM 的角色完全不同。

先对齐术语

  • SAST(Static Application Security Testing):不运行程序,直接分析源码或中间表示来发现安全路径。
  • Taint specification(污点规格):定义哪些表达式是 source、哪些调用是 sink、哪些检查是 sanitizer。
  • Detection-time spec:每次检测时由系统临时推断或生成的规格;IRIS 属于这一类。
  • Fixed ToLO spec:ToLOScanner 应固定 S_LLM、七类 sink 与 C_SAFE 规则,使结果可审计、可复现。
  • Triage:对静态分析告警排序、解释或过滤;它不应改变 ToLO 的 source/sink/sanitizer 定义。

核心贡献

  • 提出 LLM-assisted static analysis 工作流
  • 据论文,构建 CWE-Bench-Java —— 120 个真实 Java 项目漏洞基准
  • 用 LLM 过滤候选污点路径(post-analysis triage)

它解决的问题

传统 SAST(CodeQL / Semgrep / Coverity)的痛点:

  1. 写 spec 成本高:每种 CWE / 每个框架,都要手写 source / sink / sanitizer。
  2. 覆盖率低:CodeQL 的 standard library 覆盖热门框架,但长尾框架基本没人写。
  3. 误报多:静态分析路径合并产生很多 path 实际 unreachable。

IRIS 用 LLM 解决:

  1. 让 LLM 看代码 + CWE 描述,自动写 spec。
  2. 让 LLM 看候选路径,过滤明显误报。

方法摘要

据论文,IRIS 流程:

Step 1: 输入 = (项目源码, 目标 CWE)
   ↓
Step 2: LLM 推断 taint specification:
   - source: 哪些 API / 字段是 untrusted input?
   - sink: 哪些 API 是危险操作?
   - sanitizer: 哪些函数算清洗?
   ↓
Step 3: 用推断的 spec 跑全仓 taint analysis(基于 CodeQL)
   ↓
Step 4: LLM contextual analysis 对候选路径**排序和过滤**
   - 阅读路径上下文,判断是不是真的可达
   - 输出 ranked alerts

其目标是减轻人工编写 CodeQL / Semgrep 规则的负担。

与 ToLO 的关联

IRIS 是 ToLOScanner 的方法学近邻基线:

维度IRISToLOScanner
用 LLM 做什么生成 spec + 过滤路径(可选)triage + 解释
Spec 来源LLM 推断人工固定(S_LLM / 七子类 / C_SAFE)
适用 source传统 CWE source(HTTP 等)S_LLM 五子集
适用 sink传统 CWE sink相同 sink(复用)
评测语言JavaPython(可扩)
工程稳定性依赖 LLM spec 输出稳定spec 固定 → 输出稳定

关键差异:IRIS 在 detection-time 让 LLM 生成 source / sink spec;ToLOScanner 应固定 ToLO spec,只把 LLM 用于 triage / 解释。

因此 IRIS 不是 ToLO 防御,也不以 S_LLM 为 source。

为什么这对 ToLO 重要

IRIS 帮助界定 ToLOScanner 的研究贡献:不是”把 LLM 接到 CodeQL 上”本身,而是把 LLM 输出形式化为新的 source family。如果检测时每次都让 LLM 猜 source,那 S_LLM 这个概念会变得不可审计,也难以证明默认 SAST 为什么漏报。

对 ToLO 来说,更稳妥的使用方式是:人工固定 S_LLM、S_DANGER 与 C_SAFE,让 LLM 做 long-tail source 建议或告警 triage,但所有规则进入仓库前必须人工 review。

实验与结论要点

据论文,CWE-Bench-Java 含 120 个真实 Java 项目漏洞。

工具检出数FDR 变化
CodeQL(默认规则)27baseline
IRIS with GPT-455较 CodeQL 平均 FDR 降低 5 百分点

论文还报告 4 个 previously unknown vulnerabilities(发现新漏洞),该声明仍按 pending 处理。

局限与开放问题

  • 评测集中在 Java 与少数 CWE,尚未覆盖 ToLO 的 S_LLM source。
  • detection-time spec 依赖 LLM 输出,规格稳定性需单独评估 —— 同一项目两次跑可能得到略不同的 spec。
  • LLM 调用成本(GPT-4 全仓 spec 推断 + 路径过滤)在大型项目上不小。
  • 没有显式 sanitizer 类型匹配检查 —— LLM 可能把错配的 sanitizer 当成 valid。
  • 它不回答哪些 LLM framework 字段应属于 S_LLM^{framework}、S_LLM^{parsed} 或 S_LLM^{structured};这些仍是 ToLOScanner 的核心建模工作。

对本站的启发

IRIS 支持把”LLM-assisted taint”作为 baseline,但不要求扩展 ToLO taxonomy。

对本站更重要的对照点是:ToLOScanner 应把 novelty 固定在 source / sanitizer 形式化上,而不是每次检测都让 LLM 重新定义规则。

为什么这种差异重要

风险IRIS(LLM 生成 spec)ToLOScanner(固定 spec)
规则不一致高(同样 codebase 两次跑可能不同)低
规则可审计难(spec 在 LLM 内)易(spec 明确写在仓库里)
复现性弱强
应对新框架自动适应(LLM 推)需要扩展 source 模块
学术 baseline适合适合

ToLOScanner 选”固定 spec”路线的原因:ToLO 的研究价值在 source 端的形式化 —— 这必须是稳定、可审计、可对照的。让 LLM 每次都重写 spec,会让 source class S_LLM 失去研究意义。

对 ToLO 实验设计的具体启发

可以把 IRIS 作为对照 baseline:

Setting A: 默认 CodeQL(传统 source)
Setting B: IRIS(LLM 生成 spec)
Setting C: ToLOScanner(固定 S_LLM spec)

在 LLM 编排框架的 CVE 集上跑,看 Setting C 是否能检出 Setting A / B 漏掉的 ToLO。

ToLO 一行标注

- / 不固定 / - / 对照 baseline / -

阅读顺序

建议在读完 ToLO 的 Sources and Sinks 后读本文,再读 QLCoder。IRIS 代表”LLM 推 spec + taint”,QLCoder 代表”LLM 写 query”,两者共同构成 ToLOScanner 的方法学对照。

读完检查

  • IRIS 适合直接拿来做 ToLO 检测吗?
    • 不太合适。它生成的 spec 是针对传统 CWE 的;ToLO 的 source 类需要 LLM 学习”什么是 AIMessage.content”,但 IRIS 论文没有专门做这件事。
  • IRIS 和 ToLOScanner 共有的设计?
    • 都用 CodeQL 做底层 taint engine、都在 post-analysis 用 LLM 做 triage / 解释。

外部链接

内部互链