当前位置：首页 > news >正文

【大模型】KNighter: 内容审查漏洞分析

news 2025/10/1 7:42:20

论文《KNighter: Transforming Static Analysis with LLM-Synthesized Checkers》，介绍了进行代码漏洞审核的方法，核心就是构造静态审核器。

在进行合同审查等工作时，也可以采取类似的思路，提炼典型错误模式，撰写提示词，然后检查合同中的漏洞。

KNighter：通过大语言模型合成静态分析检查器发现长期潜伏漏洞

1. 背景与核心思想

1.1 问题：静态分析难以覆盖“新漏洞模式”

静态分析（Static Analysis）是一种无需运行程序即可检测代码缺陷的技术，广泛用于操作系统内核等关键系统。
主流框架如 Clang Static Analyzer（CSA）通过检查器（checker）实现具体检测逻辑。每个 checker 是一个小型插件，监听程序事件（如函数调用、内存访问），并在内部维护自定义状态，以判断是否存在漏洞。

但传统静态分析面临瓶颈：

规则固化：checker 由专家手工编写，只能检测预定义模式；
开发成本高：为新漏洞写一个路径敏感、别名感知的 checker 需数周。

1.2 直接用 LLM 扫描不可行

大语言模型（LLM）能从历史补丁中学习漏洞模式，但直接用于扫描整个 Linux 内核（3000 万行）存在三大障碍：

上下文窗口限制：无法一次性输入整个函数；
成本过高：仅 devm_kzalloc 就出现 7000+ 次，每次调用都需 LLM 判断，单次扫描成本可达数百美元；
幻觉风险：LLM 可能生成看似合理但错误的判断。

1.3 KNighter 的核心洞见

“Rather than using LLMs to directly analyze massive systems, our key insight is leveraging LLMs to generate specialized static analyzers guided by historical patch knowledge.”（§1）

KNighter 不让 LLM 扫描代码，而是让 LLM 学习历史补丁，自动生成一个专用的 CSA 检查器。该检查器随后以传统方式高效扫描整个代码库。

这种“合成工具而非直接分析”的范式，兼具 LLM 的泛化能力与静态分析的可扩展性、可靠性。

2. 整体流程概览

KNighter 分为两个阶段：

检查器合成（Checker Synthesis）：从单个补丁生成初步可用的检查器；
检查器精炼（Checker Refinement）：在全量扫描后，自动降低误报，提升实用性。

3. 检查器合成阶段（Checker Synthesis）

目标：从一个历史修复补丁出发，生成一个能正确识别“该类漏洞”的 CSA 检查器。

步骤 1：漏洞模式分析（Bug Pattern Analysis）

做什么：让 LLM 阅读补丁（diff + commit message + 完整函数上下文），提炼出一个通用、可检测的漏洞模式。
为什么：补丁本身是具体修复，但我们要的是“这类 bug 的共性”，比如“某类分配函数返回值未检查就解引用”。
关键点：模式必须具体但不过于宽泛，以便后续能转化为可执行的分析逻辑。

示例：对于一个修复 devm_kzalloc 后未检查 NULL 的补丁，LLM 提炼出模式：
“The bug pattern is the failure to check the return value of devm_kzalloc() for NULL before dereferencing it.”

步骤 2：检测计划生成（Plan Synthesis）

做什么：让 LLM 根据漏洞模式，生成一个高层实现计划，说明“如何用 CSA 检测这个模式”。
为什么：直接让 LLM 写代码容易出错。先写计划，相当于“设计文档”，能引导后续实现更结构化。
计划内容通常包括：
- 需要跟踪哪些程序状态（如“某指针是否已被检查”）；
- 需要监听哪些 CSA 事件（如 checkPostCall、checkBranchCondition 等）；
- 如何在这些事件中更新状态或触发告警。

示例计划：
“(1) Track memory regions from devm_kzalloc; (2) Mark regions as checked when if (!ptr) is seen; (3) Warn if unchecked region is accessed.”

步骤 3：检查器实现与语法修复（Implementation & Repair）

做什么：让 LLM 根据计划，生成符合 CSA 框架的 C++ 检查器代码。
辅助手段：
- 使用预定义模板：强制代码结构符合 CSA 要求；
- 提供工具函数列表：封装 CSA 底层 API（如 getMemRegionFromExpr），降低 LLM 实现难度；
- 若编译失败，启动语法修复代理：根据编译错误自动修正代码（最多 5 次尝试）。
为什么：LLM 生成的代码常有语法或 API 错误，需自动修复以保证可编译性。

步骤 4：验证（Validation）——什么是 Valid Checker？

做什么：在补丁前后的两个版本代码上运行生成的检查器，验证其是否：
- 在补丁前代码中报告漏洞；
- 在补丁后代码中不再报告（或显著减少）。
判定算法（§4）：
- 设 $NbuggyN_{\text{buggy}}$ = 补丁前代码中报告数；
- 设 $NpatchedN_{\text{patched}}$ = 补丁后代码中报告数；
- 若满足：
  $N_{\text{buggy}} > N_{\text{patched}} \quad \text{且} \quad N_{\text{patched}} < T_{\text{valid}} \ (\text{默认 } T_{\text{valid}}=50)$
  则该检查器为 Valid Checker。
为什么：这是对 LLM 是否“真正理解漏洞”的语义验证，防止幻觉生成无效检查器。
注意：验证范围仅限于补丁涉及的文件及其依赖，非全量扫描，以提升效率。

4. 检查器精炼阶段（Checker Refinement）

目标：将 Valid Checker 应用于整个代码库后，自动降低误报，使其达到可实际使用的水平。

步骤 1：全量扫描与报告蒸馏

做什么：用 Valid Checker 扫描整个系统，生成潜在漏洞报告。
报告蒸馏：原始 CSA 报告通常冗长，只保留关键代码行和访问路径摘要，便于后续处理。

步骤 2：报告分类（Triage）——什么是 Triage Agent？

Triage Agent 是什么？
一个专门用于判断静态分析报告是否为真实漏洞的 LLM 代理。
做什么：对每个报告，判断其是否为真实漏洞（True Positive）还是误报（False Positive）。
判断依据：严格对照原始漏洞模式和补丁行为，不依赖通用代码质量标准。
为什么：避免人工审查海量报告，实现自动化过滤。

示例：某报告因 if (unlikely(!pmx)) 未被识别为空检查而误报。Triage Agent 能理解 unlikely(!pmx) 语义，标记为 FP。

步骤 3：检查器修正（Refinement）——什么是 Refinement Agent？

Refinement Agent 是什么？
一个根据误报反馈自动修改检查器逻辑的 LLM 代理。
做什么：若 Triage Agent 发现误报，则 Refinement Agent 修改检查器代码（如增强对 unlikely() 宏的支持）。
验收标准：
1. 不再报告已知误报；
2. 仍能正确区分原始补丁的前后版本（即保持 Valid 性）。

步骤 4：实用性判定——什么是 Plausible Checker？

这是你特别困惑的部分，我们重点解释。

问题：Valid Checker 虽能区分补丁前后，但在全量扫描时可能报告成百上千个警告，其中大部分是误报，无法实际使用。
目标：筛选出真正可用的检查器，即 Plausible Checker（“合理检查器”）。
判定标准（§4）：一个 Valid Checker 若满足以下任一条件，即为 Plausible：
1. 报告数量少：全量扫描总报告数 < 阈值 $TplausibleT_{\text{plausible}}$ （默认 20）；
2. 误报率低：在随机采样的 5 个报告中，FP 数 ≤ 1。

为什么这样设计？

报告少 → 开发者可人工审查；
误报率低 → 自动过滤后仍有高可信度。

精炼流程：
- 对不满足 Plausible 标准的 Valid Checker，启动 Refinement Agent 迭代修正；
- 最多 3 轮精炼；
- 若仍不达标，则放弃该检查器。

结果：在 39 个 Valid Checker 中，26 个直接为 Plausible，11 个经精炼后达标，共 37 个 Plausible Checker（§5.1.2）。

5. 总结：每个步骤解决的核心问题

阶段	步骤	解决的问题	关键输出
合成	模式分析	从具体补丁中抽象出可泛化的漏洞模式	Bug Pattern
合成	计划生成	将模式转化为静态分析可实现的检测逻辑	Detection Plan
合成	实现与修复	生成符合 CSA 框架的代码，并自动修复语法错误	Compilable Checker
合成	验证	确保检查器真正理解漏洞，而非幻觉产物	Valid Checker
精炼	报告蒸馏	降低 LLM 处理负担，聚焦关键信息	Distilled Report
精炼	报告分类	自动区分真漏洞与误报	Triage Result (TP/FP)
精炼	检查器修正	迭代优化检查器，提升精度	Refined Checker
精炼	实用性判定	筛选出可实际部署的高质量检查器	Plausible Checker