ARTICLE · 1204222
AI Slop:大模型给漏洞评估带来的可信危机与缓解路径
AI Slop:大模型给漏洞评估带来的可信危机与缓解路径> 文献来源：arXiv:2608.25667，2026‑08‑26，《AI Slop and Hallucinations in Vulnerability Assessment: A Survey on Reasoning Failures and Trustworthy Mitigation》 https://arxiv.org/pdf/2608.25667 > 机构背景：该综述由多所亚太地区高校联合完成，包含澳大利亚新南威尔士大学、伍伦贡大学，中国南京信息工程大学，澳大利亚格里菲斯大学，新加坡南洋理工大学。团队长期从事网络安全、软件漏洞分析、可信大模型方向研究，聚焦LLM在安全领域落地时的推理失效、幻觉问题，从实证、机理、工程方案三个维度完成系统性梳理。 大语言模型已经深度融入漏洞评估工作，从漏洞自动发现、漏洞报告撰写，到生成修复补丁、威胁情报整理，极大降低安全分析的人力门槛。但随之而来出现一类被论文命名为**AI Slop**的安全产物：文本语言流畅、格式看起来专业严谨，但底层语义完全无效，没有真实代码、执行路径作为支撑。 它和传统SAST工具产生的误报有本质区别。传统误报来自规则匹配过于宽泛，人工快速扫读就能识别；而AI Slop模仿真实安全报告的行文逻辑，会编造CWE类型、虚构函数调用、构造看似合理的数据流，浅层阅读很难分辨真伪，大量涌入漏洞赏金平台、开源项目漏洞提交通道，消耗安全研究员和开源维护者大量精力，效果近似对人工漏洞处置流程的拒绝服务攻击。 真实行业案例就是知名开源项目cURL。项目维护者反馈，HackerOne赏金平台提交的报告中，2025年年中约20%都是低质量AI Slop，真正有效的漏洞报告仅占5%。大量报告引用不存在的内部函数，给出可以编译但是无法解决实际问题的补丁，无法复现漏洞利用流程。2026年初cURL直接关停付费漏洞赏金计划，目的就是消除AI批量生成虚假报告带来的激励，这也是AI Slop现实危害最典型的实例。 论文通过系统性文献调研，把安全领域的AI Slop划分成三大类失效模式，现实中经常会混合出现。 模型不是误判已有代码，而是直接**编造漏洞**。即使输入完全安全无害的代码，在提示词引导下，模型依然会输出完整漏洞报告，虚构不存在API、不存在跨函数执行链路，输出的自信程度和真实分析几乎没有差别。 相关研究发现，模型判断漏洞高度依赖表层代码符号，比如看到`malloc`、`memcpy`这类内存操作函数就倾向输出内存损坏漏洞，哪怕上下文已经做了完备校验。如果仅仅修改变量名、调整代码表层写法，不改变程序逻辑，模型给出的漏洞判定结果就会发生反转。它学到的是代码token共现统计特征，而不是程序真实运行语义。 衍生出两类少被研究的风险：提示注入幻觉，被歧义输入诱导生成完全不存在的攻击面；工具调用虚谈，AI安全代理调用编译器、静态分析工具之后，不去读取工具真实返回，而是自行编造工具输出结果，伪装已经完成工具校验。 举个现实场景：把一段经过充分边界校验的C语言代码丢给安全Agent，Agent调用CodeQL之后，不去读取工具返回为空的结果，自己编造出“存在缓冲区溢出，攻击者可远程执行代码”的完整分析，附带伪造的工具输出日志，从文本上看仿佛已经经过工具验证。 模型生成补丁可以正常编译，单元测试能够通过，但治标不治本，没有解决根本漏洞，甚至引入全新安全问题。 很多时候LLM只会添加表层防御，比如增加空指针判断、捕获异常，根源的逻辑缺陷完全保留。在多文件大型仓库场景问题会更加突出，模型只看局部代码片段，忽略跨文件的不变约束，修改A文件代码，破坏B模块的隐含假设。 更危险的是补丁回归问题：补丁修复一个漏洞，同时悄悄引入另一个CWE缺陷。功能测试无法发现这类问题，只有安全视角审查才能暴露。 案例：代码存在一处逻辑漏洞，根源是权限校验逻辑执行顺序错误。大模型输出补丁，增加一个表层参数校验，代码编译运行正常，单元测试全部通过，但核心权限判断顺序完全没有改动，漏洞依旧可被利用，同时新增一处未做过滤的字符串拼接，埋下注入风险。 大模型改写已有安全信息，包装成全新发现。包括改写老旧漏洞、放大普通缺陷的危害等级、把开源仓库中**静默修复漏洞**包装成全新0day提交赏金平台。 开源世界大量真实漏洞修复不会分配CVE编号，没有公开漏洞公告，只有代码提交记录。LLM学习仓库commit diff之后，可以把多年前悄悄修复过的缺陷重新包装成新发现提交赏金平台。因为没有公开CVE记录，检索公开数据库无法识破造假，这是这类Slop最难防御的点。 同时大模型输出文本流畅度会误导人，阅读者主观上更容易相信行文通顺的报告，即使里面技术内容全部错误。当静态分析工具输出大量告警，经过LLM润色改写之后，原本的工具噪声就变成一份份结构完整、煞有介事的漏洞报告，形成报告洪水。 AI Slop本质不是简单的“模型犯错”，而是底层推理范式的根本性鸿沟，这也是论文核心机理分析。 安全专家做漏洞分析，是**因果演绎推理**。拿到代码片段，在脑中构建软件架构模型，追踪跨函数的数据流，逐条验证漏洞利用的全部前置约束，每一条结论都要有可复现的执行路径支撑。即使专家会使用经验启发式快速判断，但最终会去验证可达性、前置条件是否成立，推理过程可以被复盘证伪。 而自回归大模型是**概率token生成**，不会构建程序执行模型。它基于训练学到的统计关联，预测下一个最合理的token。当需要多步跨过程推理，信息超出模型上下文能力，不会返回“无法判断”，而是填充统计上看起来通顺的内容。输出的是“看起来合理”，而不是“经过验证正确”。 模型规模变大并不会消除该问题，只会让编造出来的内容更加流畅、更有欺骗性。 论文指出，思维链CoT、工具调用、RAG检索增强，只能缩小这个鸿沟，无法彻底消除。 论文提出一个可落地衡量指标演绎覆盖分数，通俗理解：把一个漏洞结论拆解成必须全部成立的多条技术约束，统计多少条约束在报告中给出明确证据（代码行号、执行轨迹、输入样例），模糊描述不计入，以此衡量这份报告推理到底有多少真实证据支撑，而不是单纯看文字写得多漂亮。 很多现有防御思路瞄准**溯源**，判断这份报告是不是AI生成，而不是判断报告内容**技术上是否正确**，在安全场景有天生短板。 DetectGPT这类检测器依靠文本困惑度、文本统计特征区分机器生成内容。但漏洞报告本身格式高度模板化，人工写的赏金报告同样句式规整、词汇变化少，会被检测器误判为AI产物。同时对抗改写之后，机器生成文本的统计特征可以无限贴近人类，检测效果会跌到接近随机猜测，会误伤真实安全研究者提交的报告，却拦不住伪造的漏洞结论。 水印在代码、安全场景有很大局限。水印通过修改token选择实现，而程序代码token选择空间高度受限，为打上水印，模型被迫选择语法错误、逻辑错误标识符，反而直接制造AI Slop，水印不能判断漏洞真假，只能证明是谁生成文本，一份带水印签名的报告依旧可以描述完全不存在的漏洞路径。 让研究者用密码学签名提交PoC、执行日志。签名可以确认提交人身份，但签名不能保证内容属实，签名后的报告依旧可以描述虚假漏洞。 > 总结：溯源类手段只能解决“是谁产出”，不能解决“内容对不对”。安全漏洞评估属于高风险逻辑场景，真伪才是核心，不是来源。 论文核心建议，不要把LLM输出当成最终结论，而是把大模型作为**假设生成器**。所有漏洞猜想，必须交给确定性验证组件校验之后，才送到人工分析师手上。 整套神经符号流水线工作流程： 3. 如果验证失败，把错误轨迹回传给LLM做迭代修正； 4. 只有经过多轮校验，具备可复现证据的结论，才转发给人工分析师，同时附加密码签名；验证失败直接拒绝。 每一类验证工具都有自身盲区，单一组件会被攻击者绕过，流水线需要至少两套独立验证都通过，才放行结果，以此抬高AI Slop的通关门槛。把人工分析师从大海捞针识别虚假报告，变成只审核经过机器验证的候选结果。 现有代码大模型评测基准大多只看功能是否跑通，不区分“能运行”和“安全逻辑真实成立”，缺少针对AI Slop的测试数据集。论文提出两套新评测工具。 第一套CVE‑Bench，用来测试漏洞处置流水线分辨真实漏洞和AI编造漏洞的能力。数据集包含真实经过验证CVE样本，同时大量高流畅度的AI虚构漏洞报告。任务包含真假二分类、定位报告中无依据断言、报告排序，专门规避简单检索记忆，用来衡量整套系统识别虚假漏洞的能力。 第二套Slop‑Score，连续量化指标，衡量一份安全文档“语言流畅度”和“可验证实质证据”之间的差距。一份报告文字写得越华丽，但缺少代码证据、不满足漏洞利用约束，分数越高，代表属于AI Slop风险越大。可以定位报告到底是证据缺失，还是约束条件没有验证，方便研发人员定位失效环节。 除此之外还需要对抗防御：攻击者会针对性利用验证组件的盲区，专门构造可以骗过静态分析、符号执行超时的虚假漏洞报告，未来系统需要识别消耗算力的恶意输入，避免验证资源被耗尽。 更高层面的思路转变：不再以自然语言输出作为最终产出，要求模型输出中间推理证据，代码引用、执行轨迹、形式化证明片段，自然语言仅作为解释说明。分析师依靠演绎覆盖分数，直观看到报告哪些断言具备证据支撑，哪些只是口头断言，不再依靠文笔流畅度来判断可信度。 大模型给漏洞评估带来效率提升，但AI Slop带来可信危机，根源在于概率生成和安全领域需要的因果演绎推理之间存在固有鸿沟。思维链、工具增强、RAG只能缓解，无法根除幻觉。 基于文本统计、水印这类溯源检测手段，在安全场景存在根本性限制，不能解决内容真伪。出路是神经符号主动验证架构：LLM负责提出猜想，传统确定化安全工具负责校验猜想真伪，将验证作为必不可少环节。 安全领域可信AI，不是靠提示词调优、更好的模型话术，而是产出每一条结论都要有可独立复现、可检查的客观证据支撑。
# AI Slop：大模型给漏洞评估带来的可信危机与缓解路径
## 引言
## AI Slop的三类主要表现形态
### 1. 幻觉式漏洞生成：凭空捏造安全缺陷
### 2. 看似可行却错误的补丁，引入新安全退化
### 3. 语义重打包，漏洞报告垃圾泛滥
## 根源：人类专家演绎推理 vs LLM概率生成
思维链：对简单单函数漏洞有改善，跨函数多跳推理收益急剧衰减，模型可以写出很长的推理链条，但每一步逻辑都是错的，只是把错误复述一遍； 工具Agent：模型会写出错误工具参数、曲解工具返回结果，工具调用沦为叙事道具，不是真正校验； RAG检索增强：可以减少虚构CVE编号这类事实幻觉，但是解决不了逻辑幻觉——引用真实漏洞类别，却错误判定当前代码属于该漏洞。
## 现有缓解方案的固有缺陷
### 1. 被动统计检测AI生成文本
### 2. 大模型水印技术
### 3. 生态签名证明
## 可行方向：主动神经符号验证架构
LLM输出漏洞报告草稿、猜想、PoC、补丁方案；同时引入RAG，绑定CVE数据库等可信知识库做基础约束； 将猜想交给多套确定性验证组件并行校验：静态分析引擎（CodeQL）、模糊测试、符号执行引擎；
静态分析：基于AST、控制流图核对代码事实，但复杂堆内存、C++虚函数间接调用场景存在漏报； 模糊测试：编译PoC实际运行，验证漏洞是否可触发，但高度依赖LLM写出高质量测试驱动； 符号执行：理论上检查路径约束，但存在路径爆炸，复杂循环、非线性运算会超时；
