2026-10-24 10:18:06 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

深度学习顶会ICLR 2026论文点评丨从漏洞描述到检测规则：QLCoder如何让静态分析查询自动写出来？

原创

曹琰卫子涵
曹琰卫子涵

信息网络安全杂志

2026年10月20日 20:00
上海

去阅读

一、引子

静态分析是软件安全检测的核心手段之一，但检测能力的上限始终受限于查询规则的覆盖度与精准度。以CodeQL为代表的静态分析框架，虽支持通过自定义查询实现复杂的漏洞模式匹配，但编写高质量查询要求研究者同时精通漏洞原理、程序分析理论与CodeQL的专用语法体系，人力成本高、产出周期长，难以跟上每年数万条新增CVE的披露节奏。

Claire Wang 等人在ICLR 2026发表的QLCoder: A Query Synthesizer for Static Analysis of Security Vulnerabilities，针对这一痛点提出了自动化的漏洞查询合成方案。该工作以CVE元数据为输入，通过大模型代理结合结构化工具约束与执行反馈闭环，自动生成可编译、可验证、可复用的CodeQL漏洞检测查询，将自然语言描述的漏洞知识转化为可落地的程序分析规则。

二、论文速览

QLCoder 的任务目标十分明确：输入CVE文本描述、漏洞版本代码、修复版本代码与补丁差异信息，输出一条满足三项标准的CodeQL查询：其一，语法合法，可正常编译运行；其二，语义准确，能在漏洞版本中检测到流经补丁区域的真实漏洞数据流；其三，具备修复区分度，在修复后的代码版本中不会对同一路径产生误报。

实现这一目标需要突破三类核心挑战：

第一是语法层面的脆弱性。CodeQL 语言表达能力强但语法约束严格，谓词名称、节点类型、依赖库版本的微小偏差，都可能导致查询编译失败，或是生成语法正确但语义无效的结果。

第二是数据流的跨域性。真实漏洞的污染链路往往分散在不同函数、不同文件甚至不同组件中，输入源（source）、触发点（sink）、净化节点（sanitizer）与传播步骤无法通过单点模式匹配完整覆盖。

第三是规则的区分度要求。查询必须能精准区分漏洞状态与修复状态，若规则过于宽泛，虽能命中漏洞版本，但也会在修复版本中产生大量误报，失去实际使用价值。

针对上述挑战，QLCoder 设计了代理式迭代合成框架，核心是“生成—验证—反馈—优化”的闭环机制。框架以大模型为核心生成单元，通过自定义的 MCP（模型上下文协议）接口接入两类工具，对生成过程进行结构化约束：

一是向量数据库，存储CWE漏洞定义、CodeQL官方文档、精选示例查询与目标项目补丁区域的 AST 片段，为大模型提供语义层面的按需检索支撑；

二是CodeQL语言服务器，提供语法补全、错误诊断、符号定义跳转等能力，从语法层面降低生成错误率。

同时，框架内置 CodeQL 验证器，每一轮都会将大模型生成的候选查询分别在漏洞版本与修复版本上执行，返回编译状态、命中数量、目标方法覆盖率、误报位置与优化建议等结构化反馈。大模型根据反馈持续调整查询逻辑，直到满足成功条件，或是达到预设的迭代上限。

三、深度解剖

1、框架定位与落地场景

QLCoder 的核心价值，是将大模型的生成能力转化为可沉淀、可复用的安全检测资产。

QLCoder 的输入输出与三类典型应用场景如下：输入的 CVE 漏洞描述与补丁代码片段； QLCoder 合成的完整 CodeQL 查询；查询的三类落地方向。第一类是同仓库的回归测试：将合成的查询集成到 CI 流水线中，在后续代码迭代中持续检测，避免同类漏洞重复引入。第二类是跨仓库的变体分析：基于一条 CVE 生成的查询，可批量在多个同类项目中执行，挖掘同原理的潜在漏洞。第三类是补丁有效性验证：通过查询在漏洞版本与修复版本的命中差异，验证补丁是否完整阻断了漏洞路径。

与直接让大模型阅读代码并输出漏洞结论的方案相比，QLCoder 的输出具备可编译、可执行、可追溯的特性，能够直接接入现有安全工程流程，也支持安全人员的人工复核与持续迭代。

2、迭代合成架构与工具链设计

QLCoder 的效果提升，并非单纯依赖更强的大模型能力，而是来自工具约束与执行反馈形成的双重闭环。

框架的迭代运行逻辑：通过 MCP 协议接入的两大工具集，是大模型生成查询时的辅助能力；“大模型生成器 + CodeQL 验证器”的循环链路；验证器返回的结构化反馈，是每一轮迭代的优化依据。

其中向量数据库的作用是提供语义参考。数据库中预先存入了CWE官方漏洞定义、CodeQL API文档、高质量的官方与社区示例查询，以及从目标项目补丁区域提取的AST代码片段。大模型在生成查询的过程中，可根据当前漏洞类型按需检索相关内容，既避免了凭空编造API或漏洞模式，也解决了全量文档塞入提示词导致的上下文冗余与干扰问题。

CodeQL 语言服务器的作用是提供语法层面的实时约束。通过这套接口，大模型可以获得类似程序员使用 IDE 的体验：获取谓词补全推荐、实时语法错误诊断、符号定义跳转等能力。这一设计针对性解决了 CodeQL 作为低资源语言的生成错误问题，大幅提升了查询的编译通过率。

在每一轮循环中，验证器会从两个维度对候选查询进行评估：一是编译维度，校验语法是否合法、是否存在类型错误；二是执行维度，分别在漏洞与修复两个代码版本上运行查询，返回命中结果数量、目标方法覆盖率、误报具体位置，以及程序化生成的优化建议。

消融实验验证了各组件的必要性：在20个CVE的测试集中，完整QLCoder框架的查询成功率为55%；移除CodeQL语言服务器后，成功率降至25%；移除文档与参考查询后，成功率降至20%；仅保留大模型与基础迭代反馈时，成功率仅为10%。这一结果充分说明，结构化的工具约束是提升查询合成质量的核心因素。

3、漏洞语义的精准建模逻辑

QLCoder 生成的查询能够实现高精准度的漏洞检测，核心在于它完整刻画了漏洞的端到端数据流链路，并利用补丁信息引入sanitizer约束，保证查询的修复区分度。

以CVE-2025-27136的XXE漏洞为例，直观展示了真实漏洞代码与合成查询的对应关系。左侧为漏洞的完整数据流：HTTP请求体作为外部污染输入（source），经过XmlMapper对象构造、服务工厂注册等跨组件的传播步骤，最终流入XmlMapper.readValue XML解析方法（sink），触发XXE漏洞；补丁通过为XMLInputFactory设置SUPPORT\_DTD=false禁用DTD解析，作为净化节点（sanitizer）阻断了攻击路径。

右侧对应了合成查询的四个核心组成部分：

HttpRequestSource类：定义污点输入源的AST匹配规则，识别所有 HTTP 请求体进入程序的位置；

XmlParsingXxeSink类：定义漏洞触发点的匹配规则，识别XML解析的危险调用；

XmlXxeSanitizer类：定义补丁引入的净化逻辑，匹配禁用DTD的配置代码，用于过滤修复版本中的安全路径；

自定义污点传播步骤：补全CodeQL默认数据流分析无法覆盖的跨组件传播链路，比如工厂注册、对象传递等场景。

最终，这四部分通过CodeQL的全局污点追踪模块整合为完整的路径查询，实现对漏洞全链路的精准检测。这种建模方式避免了两类常见问题：一是仅匹配危险函数导致的高误报，二是仅关注补丁区域导致的漏报。通过完整的source-sink-sanitizer链路刻画，查询既能准确命中漏洞，也能正确识别修复后的安全代码。

四、局限与展望

QLCoder的方案仍存在一定的适用边界与优化空间。

第一，迁移适配成本。当前工作主要在Java语言与CodeQL分析体系下完成验证，若迁移到其他编程语言或Semgrep、Infer等其他静态分析框架，需要重新适配语言特性、分析API与数据流模型，存在一定的工程成本。

第二，输入依赖较强。方案的运行依赖完整的CVE元数据，包括漏洞文本描述、漏洞与修复版本的可编译代码、补丁diff信息。它更适合将已知漏洞转化为检测规则，无法直接用于发现完全未知的0day漏洞。

第三，时间与成本较高。当前单条查询的平均合成时长约3712秒，平均成本约2.90美元。在大规模批量处理CVE的场景下，仍需优化检索效率、增加结果缓存机制、设计合理的早停策略与自动失败诊断能力。

未来，若能将静态查询合成与动态污点分析、单元测试验证、人工反馈闭环结合，进一步提升查询的准确率与可靠性，将能更大程度释放该方案的工程价值。

五、写在最后

QLCoder 为大模型与程序分析的结合提供了一个清晰且可落地的范式：大模型不替代静态分析工具，而是作为规则合成器承担探索、组合与优化的工作；静态分析引擎则作为验证器，承担语法校验、路径执行、结果判定的工作。二者形成的闭环，既发挥了大模型的知识整合与推理能力，也保留了静态分析的确定性与可解释性。

点评专家：曹琰教授；卫子涵博士研究生；朱岩松硕士研究生

专家单位：郑州大学

原文标题：QLCoder: A Query Synthesizer for Static Analysis of Security Vulnerabilities

原文作者：Claire Wang, Ziyang Li, Saikat Dutta, Mayur Naik