对抗性代码注释规避 LLM 漏洞检测：ALIBI 攻击与防护

摘要

LLM 漏洞检测器会同时读取程序语义和自然语言上下文。ALIBI 利用这一点，在不改变可执行代码的情况下加入“外部工具已验证安全”“框架保证该指针非空”等看似合理但无法从当前仓库验证的注释，再根据检测器反馈自适应调整，将真实漏洞判定为安全。

作者从真实 CVE 仓库生成 125 个空指针漏洞，在四个检测器各自能够正确识别的干净样本上，报告 91.2% 至 100% 的攻击成功率。固定模板注释只有 2.6% 至 17.3%，说明主要风险不是“检测器看到注释就失败”，而是攻击者依据检测推理定制不可验证证据。提示词级提醒经自适应攻击后大多失效；检测前移除注释把最终规避率压到 3% 以下。

核心创新与差异

原研究贡献是构建黑盒自适应攻击框架，把代码生成、漏洞验证、初始注释组合和基于检测反馈的迭代改写连成完整流程，并比较四类推理架构和四种防护。

本站分析认为，首个失效控制是安全检测器没有区分“代码中可验证的程序事实”和“贡献者写入的自然语言主张”。攻击没有修改漏洞本身，而是污染检测依据，因此是安全 Agent 和 LLM 漏洞分析器的完整性问题，主归入 C7（方法评测-测试语料与工具）；若同类注释进一步劫持 编码 Agent 执行动作，则应关联 A5.1（Agent 安全-提示词注入上下文边界）。

威胁模型与攻击链

攻击者可以提交源代码和注释，并能反复查询目标检测器，但不需要访问模型权重或系统提示。目标是在代码仍含真实漏洞且能够构建、通过既有测试的情况下，让检测结果从“有漏洞”变为“安全”。

1. 从真实漏洞修复提交中提取任务和仓库上下文。
2. 编码 Agent 生成包含真实漏洞的新实现，作者用构建、测试和独立 Judge 确认漏洞成立。
3. 攻击者添加不影响执行的注释，伪造调用方约束、框架不变量或外部分析结果。
4. 查询漏洞检测器并读取判定或推理反馈。
5. 根据反馈选择或改写注释，直到检测器接受伪造证据。

攻击方法与复现材料

本文不提供论文中自适应规避模板。以下为本站依据公开机制重构的无害注释一致性夹具，代码只包含固定测试缺陷标记，不执行程序：

code = fixture_with_known_issue("TEST_NULL_CHECK")
variant = add_comment(code, "UNVERIFIED CLAIM: external analysis says safe")
clean_result = detector(strip_comments(code))
commented_result = detector(variant)
assert commented_result.verdict == clean_result.verdict
assert commented_result.evidence excludes unverified_comment_claims

夹具对应注释注入、检测器推理和结果比较。检测信号是不可验证注释改变漏洞判定、证据引用了外部主张或迭代反馈持续提高规避率。省略真实漏洞利用、攻击提示模板和面向生产检测器的查询循环。

实验设计与实际过程

以下均为论文作者实验，本站未独立复现。主基准包含 125 个由真实 CVE 修复仓库派生的空指针解引用实例。攻击预算为 5 轮，目标包括 OpenVUL、VulnLLM-R、Vul-RAG 和 VulTrial；分母不是固定 125，而是各检测器在无攻击条件下已正确检出的样本数。

作者还用 70 个经 Judge 确认的释放后使用（Use-After-Free, UAF）样本测试跨漏洞类型迁移，并以单个固定注释作为非自适应基线。防护 D1/D2 为提示词提醒，D3 为代码分析与后续推理的架构隔离，D4 为检测前注释清洗。

关键结果与实际影响

检测器	干净条件正确检出	被翻转为安全	ASR
OpenVUL	115	112	97.4%
VulnLLM-R	113	103	91.2%
Vul-RAG	111	106	95.5%
VulTrial	105	105	100%

UAF 测试中，OpenVUL、VulnLLM-R 和 VulTrial 的 ASR 均超过 95%，Vul-RAG 为 73.1%。固定模板注释的 ASR 仅为 10.5%、6.3%、2.6% 和 17.3%，证明自适应定制是攻击效果的主要来源。

D1/D2 的提示词防护在首轮有一定效果，但攻击者继续迭代后，多数端到端 ASR 又回升到 90% 左右。D3 在 VulnLLM-R 上降至 0%，在 OpenVUL 和 Vul-RAG 上约为 49.5%，在 VulTrial 上仍为 96.2%，说明隔离是否有效取决于后续阶段会不会再次引入受污染注释。D4 的最终规避率在四个系统中均低于 3%。

防护措施与验证方法

• 把代码注释、README、Issue 和提交信息标为贡献者主张，不与程序事实使用同一信任等级。
• 在核心漏洞判定前运行不含注释的代码分析；需要注释时，只允许它生成待验证假设。
• 对“外部工具证明”“调用方保证”“框架不变量”等主张要求仓库内可追溯证据。
• 用静态分析、构建、测试、路径约束和代码属性图验证关键结论，不让另一个 LLM 充当唯一证据源。
• 红队评测应允许攻击者读取检测反馈并迭代，不能只测试固定注释。
• 注释清洗适合漏洞检测路径，不应直接用于文档生成或维护性评审；需要按任务分流，避免丢失合法语义。

局限与待验证问题

证据等级为中等：论文给出完整方法、多个检测架构和防护对照，但漏洞实现由 Agent 根据真实修复任务生成，主要集中于空指针和 UAF；没有生产流水线数据或独立复现。D4 对需要注释理解的其他安全任务可能损害效用。

• 跨函数、跨仓库或依赖配置中的伪造证据能否被程序分析稳定核验？
• 注释清洗对真实代码审计召回率和解释质量造成多大影响？
• 当攻击者同时污染测试、提交历史或检索库时，单一代码视图隔离是否仍有效？
• 商业闭源代码审查 Agent 是否暴露足够反馈，支持同类自适应攻击？

参考链接

• ALIBI: Adaptive Agentic Attacks on LLM-Based Vulnerability Detectors via Adversarial Code Comments