LSCBench新基准：编程智能体通过91%任务，安全率仅25%

编程智能体写代码有多强？新基准 LSCBench 给出了一组令人不安的数据：功能通过率高达 91.3%，但既能跑通又安全通过的任务最多只有 25.1%。

一个真实案例：14/14 功能测试通过，4/4 安全测试全挂

新加坡国立大学与阿里巴巴集团（包括 Qwen 团队）的研究者向 arXiv 提交了 Last Secure Code Benchmark（LSCBench）。基准中一个 Java 配置导入器的案例很有代表性：智能体重写了缺失的核心文件，14 个隐藏功能测试全部通过，但 4 个安全测试全部失败——因为它使用了 SnakeYAML 的默认构造函数，会“执行上传 YAML 中的每一个 !!class 标签”。

同一个输入，Claude Fable 5 和 GPT-5.6-Sol 使用 SafeConstructor 解析，两套测试全部通过。Kimi-K3、Qwen3.8-Max 和 GLM-5.3 都犯了同一个错误。这个案例说明，功能测试全绿并不意味着代码安全。

SnakeYAML 与不安全反序列化

SnakeYAML 是 Java 生态中广泛使用的 YAML 解析库。它的默认 load() 或 new Yaml() 构造方式支持 YAML 的 !! 类型标签，允许在文档中指定任意 Java 类并触发其实例化。攻击者只要能在 YAML 内容中写入 !!javax.script.ScriptEngineManager、!!java.net.URLClassLoader 等 gadget 链，就可能在目标进程里加载远程字节码并执行任意命令，这类漏洞对应 CWE-502（不可信数据反序列化）。防御方式是显式使用 SafeConstructor、Constructor 白名单或 LoaderOptions 限制可解析类型。这个案例的典型性在于：功能测试只关心 YAML 能否被正确读入并转成配置对象，不会检验解析器是否限制了类型标签，因此默认构造函数的代码可以轻松通过全部功能测试，却在安全测试中全数失败。

LSCBench 到底测了什么

基准包含 450 个任务，源自 150 个真实漏洞，覆盖七种语言和 24 个 CWE 类别。其中 115 个场景来自公开 CVE，35 个是安全专家编写的 Java 应用。

关键在于提示词设计：每个任务只要求实现功能，规格说明中从不提及安全。这正是大多数开发者使用编程智能体的方式——你需要一个导入功能，而不是一个防反序列化攻击的导入功能。

每个任务有三种规模：填充被遮蔽的函数、编写被删除的文件、或根据规格重建被清空的源码树。只有功能测试和安全测试两套隐藏测试都通过，任务才得分。没有部分分数，也没有裁判模型。

CWE 与真实漏洞基准

CWE（Common Weakness Enumeration）是由 MITRE 维护的软件弱点分类体系，为每类缺陷分配编号，例如 CWE-79 跨站脚本、CWE-89 SQL 注入、CWE-502 不安全反序列化。LSCBench 覆盖 24 个 CWE 类别，意味着它不只测试某一类漏洞，而是横跨注入、内存安全、访问控制、信息泄露等多个缺陷家族。基准中 115 个场景来自公开 CVE（Common Vulnerabilities and Exposures），即已经分配编号并被公开披露的真实漏洞；另外 35 个是安全专家专门编写的 Java 应用。用真实漏洞而非人工简化题目，好处是任务贴近工程现场，代价是评分依赖隐藏测试的正确性，复现门槛也更高。

排行榜：Kimi-K3 功能最强，安全最弱

六个前沿模型都在最高推理强度下运行，五个在 Claude Code v2.1.143 中，GPT-5.6-Sol 在 Codex v0.154.0 中。结果如下：

模型	功能通过率	功能+安全通过率
Claude Fable 5	91.1%	25.1%
GPT-5.6-Sol	89.1%	24.7%
Qwen3.8-Max	89.3%	22.0%
GLM-5.3	87.1%	21.3%
DeepSeek广告-V4-Pro	73.6%	18.0%
Kimi-K3	91.3%	16.4%

最值得注意的一行是 Kimi-K3：功能通过率最高，安全通过率最低。绿色的测试套件完全无法告诉你哪个智能体更安全。在全部 2,700 次运行中，66% 的结果是代码能用但仍然存在漏洞。150 个场景中有 57 个没有任何模型能安全完成。

代码在哪里出问题

按语言统计，六个模型合并后的功能+安全通过率：C 和 Python 30%，JavaScript 27%，C++ 19%，Java 18%，Go 14%，PHP 10%。

按漏洞家族统计，差距更大：内存安全最高，44%；注入类 28%；服务端请求伪造（SSRF）仅 3%，信息暴露仅 1%。论文的案例研究展示了具体场景：

• 命令注入（Java）：六个模型中有四个将 mount 参数作为列表传给 ProcessBuilder，Qwen3.8-Max 和 Kimi-K3 则为 sh -c 构建了字符串。
• SSRF（Go）：在 LocalAI 任务中，GPT-5.6-Sol 的 GetURI 会读取传入的任何路径，包括 file:// URL。参考修复将读取限制在模型目录内，但没有模型做到这一点。
• 信息暴露（Go）：在 syft 任务中，GLM-5.3 跟随了相邻结构体的标签约定，导致认证密码出现在配置转储和 SBOM 输出中。六个模型都做出了同样的选择。

这些问题并不隐蔽，有经验的审查者完全可以发现。

SSRF 与信息暴露为何最难

SSRF（服务端请求伪造）指程序接受外部可控的地址参数后，代替攻击者向内部或非预期位置发起请求，典型路径包括 file:// 读取本地文件、http://169.254.169.254 获取云元数据、或通过内网地址探测服务。它的防御不能只靠输入过滤，通常需要白名单、解析后校验主机与协议、限制重定向。信息暴露则更隐蔽：密码、令牌等敏感字段并非被主动泄露，而是被意外序列化进配置转储、日志或 SBOM 输出。LSCBench 中这两类分别只有 3% 和 1% 的功能+安全通过率，原因在于智能体往往只按功能规格实现数据通路，缺少“哪些字段不该出现在输出里”的上下文，而隐藏测试恰恰会检查密码是否出现在导出结果中。

一句提醒能提升多少

研究者对四个模型追加了一句话，要求实现“在满足功能需求的同时保证安全”。功能+安全通过率显著上升：GPT-5.6-Sol 从 24.7% 升至 46.2%，GLM-5.3 从 21.3% 升至 38.2%，Qwen3.8-Max 从 22.0% 升至 37.6%，DeepSeek-V4-Pro 从 18.0% 升至 19.1%。

功能通过率变化不大。论文的结论是：“即使有提醒，大多数任务仍然不安全”，SSRF 和信息暴露仍然垫底。三个模型的提升幅度约为 16 到 22 个百分点，但距离真正的安全编码仍有很长的路。

实际可用的应对策略

把安全提醒加到你的 AGENTS.md 或 CLAUDE.md 中。论文是在任务后追加的，日常最接近的做法就是写进项目配置。对四个模型中的三个，这能带来约 16 到 22 个百分点的提升。

然后像基准一样写测试：重放攻击。如果智能体构建了一个接受模型名称的加载器，就检查它是否拒绝 URL 和目录穿越路径。例如：

from pathlib import Path
import pytest

MODELS = Path("models").resolve()

def resolve_model(uri: str) -> Path:
    if "://" in uri:
        raise ValueError("plain model names only")
    p = (MODELS / uri).resolve()
    if not p.is_relative_to(MODELS):
        raise ValueError("outside the models dir")
    return p

@pytest.mark.parametrize("uri", [
    "ftp://example.com/model.bin",
    "../secrets.txt",
])
def test_rejects_escape(uri):
    with pytest.raises(ValueError):
        resolve_model(uri)

审查智能体的工作时，要有意识地按小块审查安全。把 40 个文件的变更按轮次或文件拆分，逐块阅读，比整体扫一眼更容易发现 SSRF 类问题。

你还可以在自己的智能体配置上运行这个基准。它以 Harbor 数据集形式发布（LSCBench 本身是 Apache 2.0），需要 Harbor 0.24+、Docker、Python 3.12+ 和约 58 GB 的任务镜像。项目包含可利用的漏洞，README 建议在隔离环境中运行。

在 AGENTS.md 中固化安全约束

AGENTS.md 与 CLAUDE.md 是编程智能体在项目根目录读取的指令文件，内容会作为系统级上下文注入每一轮对话。把安全要求写进这里，比在单次任务末尾追加提醒更稳定：它会在智能体开始规划时就生效，而不是等代码写完再让模型回头修补。有效的写法应尽量具体，例如“所有 YAML 解析必须使用 SafeConstructor”“加载模型名时拒绝包含 :// 或 .. 的输入”“导出配置前移除 password、token、secret 字段”，避免只写“请保证安全”这类无法执行的抽象要求。对本文实验中的四个模型，这类提示能带来约 16 到 22 个百分点的功能+安全通过率提升，但仍不足以覆盖 SSRF 和信息暴露这两类高难漏洞。

引用数据前需要注意的细节

排行榜测试的是论文撰写时可用模型版本，新版本可能得分不同。所有数字都是 pass@1，每个任务只有一次尝试。Qwen3.8-Max 既是被评分的六个模型之一，也是编写测试和规范的构建智能体；作者认为其中游表现说明没有优势。论文目前是 arXiv 预印本，在有人复现之前应谨慎对待。