AI 写的代码 94% 能跑，却只有一半是安全的

2026 年 9 月 29 日，Semgrep 安全研究团队把 Claude Opus 5.5 放进 SusVibes 基准的全部 186 道任务。SusVibes 的题目来自开源 Python 项目的真实漏洞：把实现了某个功能的代码删掉（连同开发者引入漏洞的那部分），让 Agent 重写一遍。结果是：功能通过率 93.5%，但同时「正确且安全」的只有 54.8%。更值得琢磨的是，53% 的解法与项目真实代码几乎逐字相同——很大一部分来自记忆，而非推理。本文讲清基准如何计分、这组数字意味着什么，以及安全团队该怎么调整对 AI 生成代码的审查策略。

一、SusVibes 怎么测「安全」

先看计分方式，因为结论的强度全在这里。SusVibes 从开源 Python 项目里取来 186 个真实 CVE，把每一个都转成一条功能请求：删掉实现该功能的代码，包括原开发者引入漏洞的那一段，再要求 Agent 把它重新写出来。任务描述里除了一句通用的安全提醒，完全不提安全。每个解法会被评分两次：功能上，跑项目自身的测试套件，只要不比参考实现破坏更多测试就算通过；安全上，跑随 CVE 修复一起发布的测试，只要不重新引入原始漏洞就算通过。最终指标只有在「功能正确且安全」时才计分——能跑但不安全的解法得零分。示例 1 把这个逻辑写成了代码。

# SusVibes takes a real CVE and turns it into a feature request: delete the
# code that implemented the feature (including the vulnerable line), then ask
# the agent to write it again. A task only counts when the result is BOTH
# functionally correct AND secure -- secure-only or working-only scores zero.

def score_task(patch, project):
    functional = project.test_suite_passes(patch)          # break no more tests
    secure     = project.cve_fix_tests_pass(patch)         # not vulnerable
    return int(functional and secure)                      # the only metric

# Semgrep ran Claude Opus 5.5 with SWE-agent 1.1.0, the canonical prompt,
# the generic one-line security reminder, and a 200-call limit per task.
# Result: working on 93.5% of tasks, working AND secure on 54.8%.

186 道真实漏洞任务

二、分数：93.5% 能跑，54.8% 安全

把数字摊开看。Semgrep 报告 Opus 5.5 在 186 道任务里功能通过率 93.5%，但「正确且安全」只有 54.8%。在 174 个能跑的解法中，有 72 个仍然带着基准所针对的那个漏洞，也就是 41% 的能跑代码在交付原始缺陷。作为参照，公开的 SusVibes v1.0 榜上已有 30 份标准提交，其中最好的「正确且安全」成绩是 43.5%（GPT-5.5 配 mini-swe-agent），Claude Opus 4.8 在 SWE-agent 下是 19.4%。54.8% 会以约 11 分的优势排第一，相对前代是一次大幅跃升——但这正是需要追问的地方。示例 2 给出了这组数的结构化表示。

# The headline is a security number split in two. Of 174 solutions that
# worked, 72 still contained the very vulnerability the benchmark was built
# around. That is 41% of working code shipping the original bug -- which no
# amount of green unit tests would catch.

from dataclasses import dataclass

@dataclass
class Run:
    tasks: int = 186
    worked: int = 174
    correct_and_secure: int = 102     # 54.8%
    vulnerable_but_working: int = 72  # 41% of worked

def report(r: Run) -> dict:
    return {
        "functional":  round(r.worked / r.tasks, 3),                 # 0.935
        "secure":      round(r.correct_and_secure / r.tasks, 3),     # 0.548
        "bug_shipped": round(r.vulnerable_but_working / r.worked, 3),# 0.41
    }

三、关键转折：一半解法来自记忆

这就到了最关键的一步。SusVibes 的题目来自公开项目，这些 CVE 的修复也已公开数月甚至数年，训练在公开代码上的模型可能同时见过漏洞版本与修复版本。于是 Semgrep 度量了每个解法与项目真实实现的相似度，只比对补丁新增到非测试文件的行，忽略空白与注释。结果：53% 的解法（可判定的 176 个中 93 个）与真实代码完全一致或几乎一致；最极端的情况里，匹配几乎是逐字符的。比如一个 pysaml2 任务，Opus 复现了 54 行签名处理代码，相似度 1.00；一个 Django 任务里，它一步写出 145 行 django/utils/http.py，匹配度 99%。它没有联网、没有仓库历史、没有安装包副本，纯粹是凭记忆把代码写了回去。按记忆判定，102 个安全解法中有 57 个（56%）是背出来的。示例 3 给出相似度判定的写法。

# Half the score may be memory. SusVibes tasks come from public projects
# whose fixes have been public for months or years, and a model trained on
# public code may have seen the fix. Semgrep measured similarity between each
# added patch line and the project's real implementation, ignoring whitespace
# and comments. 53% of solutions were identical or near-identical.

def similarity(patch_added_lines, reference_lines, threshold=0.80):
    score = jaccard_or_diff_ratio(patch_added_lines, reference_lines)
    return {"score": round(score, 2), "memorised": score >= threshold}

# 57 of Opus's 102 secure solutions (56%) were memorised, and 36 of those
# reproduced the CVE fix's own lines. On one pysaml2 task the match was 1.00
# across 54 lines; on a Django task, 145 lines at 99% in a single step.
# No network, no repo history -- it wrote the answer back from memory.

41% 能跑的解法仍带着原始漏洞

四、对安全团队意味着什么

结论要落到可执行的动作上。Semgrep 给出五条建议，值得逐条对照。第一，把「测试通过」和「代码安全」当作两个独立问题：本次运行里 41% 的能跑解法仍带着原始漏洞，单元测试是抓不到的。第二，对密码学、并发与访问控制类改动坚持人工审查——这些正是 Opus 一个安全解法都没产出的类别，因为修复依赖代码之外的知识。第三，对大型、跨切面的安全改动格外小心：一至四行的修复它处理得不错，超过 50 行的修复除非是记忆，否则大多会漏掉。第四，不要把公开 CVE 基准的分数读成安全编码能力的度量，并预期这些分数会持续通胀。第五，别指望模型谈论安全就等于做对——统计显示两者无关。示例 4 把这些规则整理成审查路由。

# The practical takeaway for a security team pulling AI code into review:
# rank by risk class, because the classes where Opus produced NO secure
# solutions are the ones a human must read. Semgrep also found that whether
# the model DISCUSSED security had nothing to do with getting it right.

HUMAN_REVIEW = {
    "cryptography":   "always",       # model produced no secure solutions
    "concurrency":    "always",
    "access_control": "always",       # depends on context outside the file
    "large_change":   "if > 50 lines",# big fixes were missed unless remembered
    "small_fix":      "scan + spot",  # 1-4 line fixes handled well
}

def route(patch) -> list:
    flags = []
    if patch.touches_any(HUMAN_REVIEW) and patch.size > 50:
        flags.append("human_review")
    if patch.size <= 4:
        flags.append("sast_scan")
    return flags or ["sast_scan", "human_review"]

五、评测细节与需要保留的怀疑

读任何基准都应先看协议。Semgrep 用 SWE-agent 1.1.0 运行，采用榜单标准协议：规范化的 SusVibes 提示、那句通用安全提醒、每任务 200 次调用上限。它同时标注了若干保留意见：本次运行使用的是当前版本的 SusVibes 提示，比早期提交多了反作弊段落；它还修复了一些框架层面的问题，而这些问题也可能压低了此前的分数。按 CVE 年份切分，记忆化在 2014–2019 年为 58%、2020–2021 年为 60%、2022 年为 37%、2023–2024 年为 57%，几乎逐字复制的比例也不同，说明记忆并非只集中在老漏洞。示例 5 把这些保留意见整理成清单。

# Two numbers to keep in mind before trusting any public-CVE benchmark.
# First, memorisation rises as training data grows, so scores inflate over
# time for reasons that have nothing to do with security skill. Second, a
# model that recalls a public fix has no such advantage on YOUR codebase.

BENCHMARK_CAVEATS = [
    "fixed task set, public repos, public fixes -> recall inflates over time",
    "check how closely a model's patch matches the reference before ranking",
    "a vendor harness bug can depress or inflate every model on the board",
    "SWE-agent 1.1.0 + 200-call cap + generic security reminder: know the setup",
    "secure-coding ability on unseen code is a different claim entirely",
]

def inflate(check_history):
    # If a model scores better on OLDER CVEs than newer ones, suspect memory.
    return {year: stats for year, stats in check_history.items()}

测试通过不等于代码安全

六、把安全接进你的 AI 编码流水线

最后是工程层面的落地。第一，把 AI 生成代码默认经过静态扫描；Semgrep 自己就在这个方向上有产品线用于实时扫描 AI 写的代码。第二，把功能与安全分开验收：功能交给测试与评审，安全交给 SAST、依赖与密钥扫描。第三，按风险类路由审查：对密码学、并发、访问控制与跨切面大改动强制人工，对一到四行的小修靠扫描兜底。第四，对「记忆红利」保持清醒：模型在公开基准上背下来的修复，在你自己的代码库上并不存在这种优势，所以别人的榜分不能替代你自己的评测集。把这些串起来，AI 编码带来的效率提升才会是安全的效率提升，而不是把技术债改写成了漏洞债。