LSCBench：评测 Vibe Coding 代码安全性的综合基准 Last Secure Code Benchmark: Is the Code You Vibe Secure?
六大前沿 Agent 功能通过率近九成，功能与安全双达标最高仅 25.1%。
前置知识
CWE（Common Weakness Enumeration，通用缺陷枚举）
MITRE 组织维护的软件安全弱点标准分类字典，每类弱点对应一个编号，例如 CWE-78 是操作系统命令注入、CWE-502 是不可信数据反序列化、CWE-918 是服务端请求伪造（SSRF）。MITRE 每年发布“CWE Top 25 最危险软件弱点”榜单，另有针对已被在野利用漏洞的 KEV（Known Exploited Vulnerabilities）Top 10 弱点列表。
LSCBench 的全部 24 类漏洞、与其他基准的覆盖面对比（21/25 Top-25、8/10 KEV）以及按弱点族的实验分析都以 CWE 编号组织，不熟悉这套编号体系就看不懂基准构成和图 8、表 11 的结果分解。
Vibe Coding（氛围编程）
用户用自然语言陈述软件“应该做什么”，把具体实现完全交给 AI 编程代理的开发方式。调查显示约 75% 的开发者已在使用且 90% 表示满意。其安全要害在于：用户通常只验证功能是否可用而从不逐行审查代码，而如何处理不可信输入、保护敏感数据、执行访问边界等安全决策被模型隐式做出，无人把关。
这是本文的评测设定来源：LSCBench 的任务规范刻意只写功能需求、对漏洞与修复保持绝对中立，正是为了复现“用户不提安全”的真实 vibe coding 场景，测试 Agent 会不会自发防御。
PoC（Proof of Concept，概念验证攻击）
安全领域指真正利用某个漏洞的最小攻击脚本或输入。本文的安全测试坚持行为级判据：PoC 必须从程序的外部表面（命令行调用、HTTP 端点、上传文件、编译链接的 harness）打入运行中的服务，然后观察可观察的危害行为，例如服务器上出现标记文件、向攻击者控制的监听器发起外呼回调等，而不是在源代码里做字符串匹配。
LSCBench 与先前基准最核心的差异就在于安全判定方式。理解“用 PoC 驱动真实攻击并观察行为”这一判据，才能理解它的“解说候选”反作弊控制和 Figure 7、9、12、13 案例分析里安全测试到底在测什么。
CVE 与 CVE-Factory
CVE（Common Vulnerabilities and Exposures）是公开安全漏洞的统一编号体系，每个 CVE 通常伴随受影响的开源项目、漏洞描述和参考修复补丁。CVE-Factory 是一个提供“可复现 CVE 任务环境”的数据工厂：每个环境包含处于易受攻击状态的项目、参考补丁和测试，覆盖 Python、JavaScript、Go、PHP、C、C++ 等语言。
LSCBench 的 150 个场景中有 115 个来自 CVE-Factory（另 35 个 Java 场景由安全专家手写），整个构建流水线的输入、测试重写的对象和难度打分公式 $D(c)$ 都建立在这些可复现 CVE 环境之上。
pass@1 与 FUNC∧SEC 双轴指标
pass@1 指每个任务只允许一次尝试的成功率，对应真实 vibe coding 中“用户期望第一次就得到能用的代码”。本文定义三个指标：FUNCPASS（功能测试套件通过的任务占比）、SECPASS（安全套件通过的占比）、FUNC∧SEC（两个套件同时通过的占比）。论文特别指出单看 SECPASS 会把“什么都不实现”的空解记为安全（因为空程序不会执行任何攻击载荷），所以 FUNC∧SEC 才是主指标。
所有主结果（图 4、表 10）都围绕这三个指标展开，“功能通过率 91% 但双过率仅 25%”这一核心落差就是 FUNCPASS 与 FUNC∧SEC 的差值，混淆这些指标会完全误读论文结论。
研究动机
编程 Agent 正在接管日常软件开发，但其产出的安全性近乎无人监管：vibe coding 工作流中用户只说“要什么功能”，如何处理不可信输入、保护敏感数据、执行访问边界这些安全决策由 Agent 隐式做出；用户只验证功能、几乎不审查代码，已有报告描述 Agent 写的代码明文存储 API 密钥、上线破损认证，部分甚至已被在野利用。功能测试对此无能为力——一个文档导入器可以正确处理所有普通压缩包，却允许精心构造的压缩包写出目录之外。同时，现有安全代码基准各缺一角：CWEval 只有 119 个文件级任务；SecCodePLT 的 1,345 个任务局限于函数级 Python；SUSVIBES 虽达仓库级但只有 186 个 Python 任务。没有任何基准同时覆盖生成范围（函数/文件/仓库）、语言广度（7 种）与漏洞类别（24 类 CWE）。用户一旦接受功能测试通过的代码，就会在毫无告警的情况下把漏洞一起发布。
本文的目标是本文要回答一个明确的问题：如何判定编程 Agent 在所有 vibe coding 场景下都能稳定生成安全代码？具体目标是构建 LSCBench（Last Secure Code Benchmark）：从 150 个真实世界漏洞场景出发，每个场景在函数、文件、仓库三个粒度上各切出一个独立任务，共 450 个任务，横跨 Java、C、C++、JavaScript、Python、PHP、Go 七种语言，覆盖 24 类 CWE（含 2025 CWE Top 25 中的 21 类和 Top 10 KEV 中的 8 类）。每个任务只陈述功能需求、绝不提及漏洞或修复，以复现真实 vibe coding 中“用户只说想要什么”的决策点；用互相分离的隐藏功能测试与安全测试分别评分，安全测试通过向运行中的程序重放 PoC 攻击判定漏洞行为是否复现。在此之上，系统评测六个前沿 Agent（Claude Fable 5、GPT-5.6-Sol、GLM-5.3、Qwen3.8-Max、DeepSeek-V4-Pro、Kimi-K3），量化“功能正确但暗藏漏洞”的比例、安全能力随实现范围的变化，以及各模型的失败模式。
与已有工作不同的是，本文的独特切入有三点。其一，粒度维度是全新的：同一漏洞场景被切成三个独立任务——补全被掩码的函数、重写整个文件、从零重建源码树——使作者首次能够度量“在某一粒度上避开漏洞是否意味着真正理解了它”，这是先前所有单粒度基准在结构上无法做到的成对比较。其二，规范的安全中立性被工程化：任务说明由物理隔离、从未见过参考补丁的起草 Agent 撰写，每条描述被逐条改写至对易受攻击版本和修复版本同时成立，不给任何方向的安全暗示，把“要不要防御”完全留给被测 Agent 隐式决策。其三，安全判据坚持行为级且从机制上防作弊：安全测试必须让真实攻击穿过程序外部表面并观察行为，每粒度用两个控制运行验证——参考解必须功能与安全双过，而“解说候选”（把补丁行原样贴成注释的易受攻击代码）必须在安全测试上失败——这正是上游 CVE-Factory 测试中实际发现的问题（有测试在页面文本正则上断言，加一行注释即可通过），LSCBench 用该控制从流程上杜绝了文本匹配型测试混入。
核心方法
LSCBench 的直觉：给 Agent 一个带已知漏洞的真实项目，只说“要实现什么功能”，看它是否恰好复现该漏洞。第一步场景筛选：漏洞来自 CVE-Factory 可复现环境与 5 位安全专家手写的 100 个 Java 场景；筛出 CWE 属 Top 25 的 CVE 后，按难度分 $D(c)=\tfrac{1}{3}\left[\mathrm{pct}_P(\mathrm{files}(c))+\mathrm{pct}_P(\mathrm{lines}(c))+\mathrm{pct}_P(\mathrm{repo}(c))\right]$ 每语言取最难并覆盖全部 CWE 类别，得 226 个 CVE，加 Java 共 326 个。第二步（Stage 1）切成三个可执行任务环境，经清扫与双控制验证，315 个中 267 个存活。第三步（Stage 2）由看不到补丁的隔离起草 Agent（Qwen3.8-Max）按“从宽到窄、同一会话”撰写三级规范。第四步（Stage 3）由持补丁的审查 Agent 修正缺陷、5 位专家复核，762 个任务过 oracle/nop 门控，247 个通过，最终精选 150 场景、450 任务。
核心创新是“同源三粒度 + 安全中性规范 + 行为级隐藏安全测试”的组合。第一，先前基准只在单一尺度提问（SecCodePLT 问“补个函数安全吗”、A.S.E 问“改个仓库安全吗”），LSCBench 把同一漏洞在函数（把补丁改动扩成所在最小完整函数打 占位）、文件（删除被补丁触及的文件）、仓库（8,000 行预算内清空源码范围、保留其余代码作基底）三个尺度各出一个任务，因此能报告场景级通过率——三个粒度全部安全才算数，测出安全能力是否随实现范围迁移。第二，任务规范刻意不提安全：起草 Agent 与补丁物理隔离，每条描述都被改写到对易受攻击代码和修复代码同时成立，把评估对准 vibe coding 的真实决策点——用户不说，Agent 要不要防。第三，安全判定不是静态扫描或字符串匹配，而是让 PoC 攻击真正打到运行中的程序（如 CWE-502 场景上传带 !!java.io.FileWriter 标签的 YAML 触发反序列化 gadget 在服务器创建文件），配合“参考解必过、注释版漏洞代码必败”的双控制，保证测试衡量行为而非文本。
方法步骤详情
流水线分七步。①筛选：按 $D(c)$ 每语言配额内最难优先抽取并覆盖全部 CWE 类别，得 226 个 CVE。②重写测试：上游测试多只查源文本而非行为，故用 Qwen3.8-Max 重写两套件，安全测试须从程序外部表面驱动真实攻击；验收条件为漏洞代码功能过/安全败、修复代码双过，326 个中 315 个通过。③切粒度：Function 把补丁改动扩成最小完整函数打 占位（均值 155 行）；File 删除被补丁触及的文件（均值 1,782 行）；Repo 在 8,000 行预算内清空源码范围（均值 4,120 行）。④环境清扫：移除编译产物、包缓存、Git 历史、隐藏测试与提示性注释，镜像压平。⑤双控制：参考解必须双过，把补丁行贴成注释的“解说候选”必须安全测试失败，267/315 存活。⑥起草：无补丁容器的 Agent 先写只述可达性的接口摘要，再同会话按仓库→文件→区域写规范，禁抄测试输入输出、禁安全指引。⑦审查门控：审查 Agent 修正缺陷条款，5 位专家每场景 20–45 分钟复核（双人复评一致率超 93%），762 个任务过 oracle/nop 控制，247 个通过，精选 150 个。
技术新颖性
技术新颖性体现在四个层面。数据结构上，“一景三任务”让跨粒度一致性第一次成为可度量的量，由此得到“功能完成率随范围下降而安全率持平甚至上升”“某一粒度安全不代表其他粒度安全”等单粒度基准原理上测不出的结论。判据工程上，先前基准的安全评估多依赖静态分析（Asleep 用 CodeQL）、字符串断言（SALLM 的文件删除测试只查错误消息却不断言受保护文件仍在）或 LLM 判官，LSCBench 坚持行为级 PoC，并用解说候选控制从机制上证明测试不看文本——上游真实存在一个在页面正则上断言、被一行注释骗过的安全测试。防泄漏流程上，规范起草者与补丁物理隔离、审查与起草职责分离、专家双人复核一致率 93% 以上，形成可审计的质量链。规模覆盖上，450 个任务、三级生成量均值 155/1,782/4,120 行、7 语言、21/25 Top-25 CWE 与 8/10 KEV，全面超过 CWEval、SALLM、SecCodePLT、BaxBench、A.S.E、SecureAgentBench、SUSVIBES；整套流程还被写成防作弊可执行任务的构建 cookbook，本身即方法论贡献。
实验结果
核心发现：“功能近乎满分、安全严重不及格”。450 个任务上六模型 FUNCPASS 为 73.6%–91.3%，但 FUNC∧SEC 最高仅 25.1%（Claude Fable 5），其余为 16.4%–24.7%——功能通过即接受，多半等于发布漏洞。场景级：最佳模型仅 12.0% 场景三粒度全安全，Kimi-K3 仅 2.0%。六模型并集可安全解决 198/450（44.0%），但全安全的仅 19 个，252 个无模型能安全解决。按粒度，功能率随范围下降而安全率持平或上升（GPT-5.6-Sol Repo 达 30.7%）；更多轮次买不来安全：Claude Fable 5 轮次最少却最安全。按弱点族，内存安全 34.3% 最高，OS 命令注入 34.7% 而代码注入仅 4.9%，信息泄露 0.7%、SSRF 2.4% 近零；按语言，C、Python 约 30% 最高，Java/Go/PHP 10%–18% 最低。120 条失败轨迹审计显示各模型失败模式各异。提醒消融：一句提醒使 GPT-5.6-Sol 升 21.5 分至 46.2%，多数模型升 15–17 分，DeepSeek-V4-Pro 仅 +1.1，信息泄露与 SSRF 仍垫底。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 安全代码生成（450 任务，任务级） | FUNC∧SEC（pass@1） | Claude Fable 5：25.1% | 其余五个前沿模型 16.4%–24.7%（GPT-5.6-Sol 24.7%、Kimi-K3 16.4%） | 比第二名 GPT-5.6-Sol 高 0.4 个百分点，比最弱 Kimi-K3 高 8.7 个百分点；但绝对值说明约 3/4 任务产出带漏洞的可用代码 |
| 功能正确性 | FUNCPASS（pass@1） | Kimi-K3 91.3%、Claude Fable 5 91.1%、Qwen3.8-Max 89.3% | DeepSeek-V4-Pro 73.6%（六模型最低） | 功能普遍近九成，与 25% 量级的安全双过率形成约 65 个百分点的落差，落差本身即核心结论 |
| 跨粒度一致性（150 场景全三粒度安全） | 场景级 FUNC∧SEC | Claude Fable 5：12.0% | Kimi-K3 仅 2.0%；GPT-5.6-Sol/Qwen3.8-Max 8.0%、GLM-5.3 7.3%、DeepSeek-V4-Pro 6.7% | 最优模型也仅约 1/8 场景全粒度安全，证明单粒度安全不能外推 |
| 模型并集覆盖 | 至少一个模型安全的任务占比 | 198/450 = 44.0% | 最佳单模型 113/450 = 25.1%；六模型全部安全仅 19 个任务 | +18.9 个百分点，且仍有 252 个任务（56.0%）与 57 个场景无任何模型能安全完成 |
| 安全提醒消融（同 450 任务重跑） | FUNC∧SEC 变化 | GPT-5.6-Sol 46.2%（+21.5）、GLM-5.3 38.2%（+16.9）、Qwen3.8-Max 37.6%（+15.6） | 主实验无提醒：24.7% / 21.3% / 22.0% | 一句话提醒提升 15–21 分而 FUNCPASS 几乎不动（DeepSeek-V4-Pro 仅 +1.1 至 19.1%）；信息泄露与 SSRF 仍近于零 |
| 粒度与安全的关系 | Repo 粒度 FUNC∧SEC | GPT-5.6-Sol 30.7% | 同模型 Function 粒度 20.0%、File 粒度 23.3% | 更大实现范围未降低安全反而上升约 10.7 个百分点；Claude Fable 5 在 Repo 达 26.7% |
| 弱点族差异（六模型池化） | FUNC∧SEC | 内存安全 34.3%（24 场景）最高 | 信息泄露 0.7%（8 场景）、SSRF 2.4%（7 场景）几乎为零；访问控制 18.3%、输入校验 14.6% | 局部检查类防御与“规范中未声明的策略”类防御相差 30+ 个百分点，定位了能力盲区 |
局限与改进
作者承认的局限：所有结果均为 pass@1 单次尝试，未报告方差与置信区间，任务级一两个百分点的排名差距可能落在噪声内；一句安全提醒即提升 15–21 分，说明相当部分失败源于引导缺失而非能力缺失；构建 Agent 与被测模型之一同为 Qwen3.8-Max，作者以“成绩居中”辩护但无法完全排除偏差。我自己的观察：其一，24 个 CWE 分布极不均衡（CWE-284、CWE-400、CWE-862 各仅 1 个场景，C++ 仅 6 个），信息泄露 0.7%、SSRF 2.4% 的置信区间极宽，细分类别结论统计功效薄弱；其二，每场景平均仅 6.8 个安全测试，通过只说明已知攻击向量被防住，不代表无其他漏洞，存在系统性假阴性；其三，沙箱禁网、依赖走镜像内置缓存，与真实开发者可查 CVE 公告的情形不同，可能低估模型上限；其四，五个模型共用 Claude Code scaffold、GPT-5.6-Sol 用 Codex，scaffold 混杂效应未剥离，轮次计数不同也使图 6 比较打折扣；其五，场景偏向有补丁、可复现的成熟开源项目，专有代码库弱点覆盖不足；其六，未报告 token 成本与墙钟时间，仅以 turns 粗略代理。
独立分析的弱点
独立分析五个弱点。第一，判据单点性：一个场景的安全结论由平均 6.8 个 PoC 决定，绕开这些特定向量的不安全实现会被记为安全；改进方向是为每个漏洞类编写多向量、参数化的攻击族，并用变异测试评估套件灵敏度。第二，样本失衡：信息泄露（8 场景）与 SSRF（7 场景）恰恰是模型最弱、结论最惊人的类别，却也是样本最少的类别之一，应把它们扩充到与注入类（40 场景）同量级后再下“几乎为零”的断言。第三，设定偏离真实工作流：真实 vibe coding 用户能看见代码、能装 SAST 插件、能追问“这里有没有安全问题”，而单轮安全中性设定回答不了“Agent 能否在被追问时修复”；建议补充带用户反馈回路的交互式变体，区分“不能防”与“不被提醒就不防”。第四，过程归因仍属定性：失败模式分析基于 120 条人工审计轨迹，若能从轨迹自动提取“是否读取调用方、是否自写对抗性测试、是否验证输出边界”等行为特征并与成败做统计关联，可把“安全是书写时的选择”这一论断变成可检验的相关性。第五，与防御侧工具的关系未探讨：不清楚把 Semgrep/CodeQL 扫描结果注入上下文能挽回多少任务，这是廉价可行的对照实验。
未来方向
作者明确指出的方向有三：其一，端到端训练安全编码 Agent——实现、用自写测试验证安全、再修补，因为数据显示安全“是书写时的选择”而非额外的工作或验证阶段（安全解与漏洞解轮数几乎相同），而提示工程已近天花板（提醒后多数任务仍不安全）；其二，训练监督需要同时给威胁模型与行为打分，弥补“代码看不见的策略”这一系统性盲区——谁能操作、哪些数据该 withhold、拒绝哪些目标地址，这些正是信息泄露与 SSRF 几乎全灭的原因；其三，模型互补性（并集 44.0% 对单模型 25.1%）提示第二模型复审或 ensemble 的实用价值。可延伸的方向：把行为级 PoC 套件转成强化学习的 vulnerability reward，与作者的在线 RL 安全代码工作直接衔接；测安全能力与通用编码能力随模型规模/版本的相对增长曲线，回答“下一代模型会不会自动解决”；将三粒度设计推广到测试编写、代码审查、漏洞修复等其他任务类型；加入供应链与依赖级弱点；考察允许联网检索 CVE 详情是否消除 SSRF/信息泄露盲区；以及研究安全提醒的副作用——是否诱发过度防御而损害功能，为“何时该提醒”提供量化依据。
复现评估
复现条件整体较好。论文发布页标注 GitHub、Leaderboard 与 Harbor Hub 链接：任务镜像经环境清扫并压平后公开发布，评估用开源的 Harbor 框架在独立 verifier 容器中完成，附录 B 给出从场景切分、测试重写、环境清扫到双控制门控的完整 cookbook（含算法 1 与各环节通过/淘汰计数），450 个任务全部带可机检的 oracle/nop 控制记录，评测设置（scaffold、推理档位、轮次上限、禁网）在附录 D 明确列出。算力方面不涉及训练，成本全在推理侧：450 任务 × 6 模型的主实验加上 4 个模型的提醒消融重跑，每任务上限 500 轮、多数数十轮内结束（案例显示单任务约 10–19 分钟），估计是数千至数万美元量级的 API 开销，用开源权重模型自托管可大幅压缩。难点主要在重建而非复用：若按 cookbook 从零再产一批场景，需要 CVE-Factory 管道和数名三年以上经验的安全专家（每场景 20–45 分钟人工复核，双人复评还需加倍工时），并复刻环境清扫、镜像压平等工程细节。综合评价：直接用该基准跑评测为中等偏低难度，复刻数据集构建为较高难度。
论文图表
示意图分上下两半。上半部分展示任务契约与功能规范（范围、接口、无安全提示）与准备好的项目容器（保留代码、依赖、构建/运行脚本，测试与参考补丁被扣留）。下半部分并排展示同一场景的三个独立任务：Function 任务文件在位但区域标 <MASKED>、只许写掩码区；File 任务目标文件缺席、规范在 /file_specs/*.md；Repo 任务整个源码范围缺席、规范在 /app/spec.md。代理停止后只有可编辑范围的文件被复制进独立 verifier，重建、启动服务并运行隐藏的功能与安全套件，双过才记 SecurePass。
这张图精确定义了“一个任务长什么样”和“怎么判分”，是理解独立 verifier 模式（防止代理篡改评分环境）与三粒度差异的最直观材料。