PRWeaver：用208个可执行验证的对抗攻击，检验LLM代码审计者能否防住长时程隐蔽PR攻击
PRWeaver: Evaluating LLM-Based Code Auditors against Long-Horizon Malicious Pull Requests

当前对LLM代码审计工具的评测大多假设漏洞是无意引入的、且集中在单个diff里。但真实世界的供应链攻击者会有意识地把恶意改动拆解成多个提交，分散在正常的开发节奏中，用看似合理的工程叙事包装每一步，等待审计者的注意力被稀释。论文的核心问题是：当攻击被刻意拆分为跨越多个PR的长时程序列，并与真实的良性开发活动交织在一起时，现有的LLM审计agent（不管给不给它们仓库历史访问权限）还能不能可靠检测出来？这直接关系到"仅凭访问代码仓库历史"这种防御思路是否站得住脚。

第一步由"仓库分析agent"读遍目标仓库的架构、可达接口和特权操作，提出候选攻击（须明确攻击者可控触发点、目标安全属性、具体未授权后果、可达代码路径），按影响力和PoC可行性排序后由构造agent生成完整恶意补丁+PoC，要求清洁状态不可利用、打补丁后可利用、且不破坏宿主测试。第二步是关键创新："有序链分解"（ordered-chain decomposition）agent把完整补丁拆成k≥2个组件，遵循合理的工程边界而非机械等分，再实例化为四种审查呈现方式：
R0（整体式）：所有组件压成一个PR；
R1（分解式）：按依赖顺序逐个PR提交；
R2（交织式）：在R1各PR之间插入真实的上游开发PR做掩护；
R3（载体融合式）：把每个恶意组件与真实上游diff融合在同一个PR里，配上攻击者撰写的、看似合理的描述。
第三步用构建测试、PoC复现、留一法（验证每个组件是否真的必要）、以及两名人工评审员的可信度判定共同校验，标注一致率达94.1%（Cohen's κ=0.87），确保每个攻击"确实需要拆分才能生效"而非凑数。

仓库分布：Pretix(60)、Django(46)、Flask(22)、Wagtail(19)、django-allauth(14)、Bottle(14)、Vendure(13)、Flaskr(7)、Werkzeug(7)、DRF(6)，语言以Python为主（195个，另13个TypeScript）。风险类别覆盖访问控制与授权、财务与账务完整性、工作流与可用性、认证与身份、数据/文件/网络暴露、注入与不安全输入，各类样本量在28-39之间较均衡。攻击链长度2-8个PR，中位数为3，95.2%的攻击只需2-3个组件即可完整实现，说明这些不是刻意堆砌复杂度的极端案例，而是贴近真实攻击者会采用的最小拆分粒度。四种呈现方式各实例化一次，共832个渲染实例。评测覆盖三个审计agent框架（OpenCodeReview、Claude Code、GitHub Copilot Code Review）×两种模型配置，共六套审计系统，用DeepSeek V4 Flash作为不知晓审计者身份、模型或渲染方式的"盲评判官"来判定检测报告是否正确归因攻击。

以逐PR审查协议为基准，R1相对R0的检测率变化只有0-5个百分点，说明单纯把攻击拆成多个提交并不能有效欺骗审计者——只要审计者一个PR一个PR地看，拆分本身作用有限。真正致命的是接下来两步：N=16时的R2交织式审查相对R1使检测率下降5-13个百分点；R3载体融合式审查则带来更稳定的10-18个百分点下降。更关键的对比是审查协议本身：把审查窗口从"逐PR"换成"整窗"（whole-window，把多个PR一次性摊开给审计者看），OpenCodeReview检测率从56%骤降到16%，Claude Code从67%降到22%，Copilot从61%降到22%——降幅远超单纯增减历史访问权限带来的影响。

论文单独测了"是否给审计agent完整仓库历史访问权限"这一变量（N=16下Enabled vs Hidden）：OpenCodeReview从55%降到44%，Claude Code从65%降到61%，Copilot从56%降到52%。这个降幅（4-11个百分点）明显小于审查窗口从逐PR切到整窗带来的降幅（如OCR从55%到16%，接近40个百分点）。作者据此得出核心结论：真正决定隐蔽效果的不是"审计者能不能翻历史"，而是"良性变更与恶意变更是否被迫共同占据审计者当前的活跃审查上下文"，以及攻击是否用一个合理的声明目的掩盖了携带攻击内容的差异。

这篇论文对"agent自动化代码审查能否作为安全边界"给出了一个警示性的量化答案：不能，至少现在不能。它的价值不在于又造了一个漏洞检测benchmark，而在于第一次系统区分了两类防御失效——"信息缺失型"（审计者看不到足够上下文）和"注意力稀释型"（审计者看得到但被交织的良性内容冲淡了判断）。数据显示后者才是主因，这对所有把LLM agent当作代码审查关卡的团队都是重要提醒：单纯扩大上下文窗口或给agent更多仓库访问权限，边际收益有限，真正需要的可能是跨PR的因果链路追踪能力和面向"声明目的与实际diff是否一致"的可疑度评估机制。对于我关注的duplex agent / 实时交互场景，这个发现也有旁证意义——审计场景和实时交互场景共享一个结构性弱点：当agent的"审查窗口"或"响应窗口"被外部输入的节奏和排列方式操纵时，深度推理能力本身无法弥补上下文呈现方式带来的系统性盲区。这提示无论是代码审计agent还是duplex交互agent，都需要专门设计对抗"呈现方式操纵"的鲁棒性机制，而不能假设更强的底层模型就能自动免疫。