编码智能体通过了测试，却依然把漏洞交付上线

Endor Labs 在 2026 年 4 月 15 日发布了「智能体代码安全基准」（Agentic Code Security Benchmark），并同时上线了公开排行榜 Agent Security League。他们把学术界的 SusVibes 框架扩展到真实场景：任务取自真实的 CVE 修复提交，把补丁拆成「功能代码」与「安全修复」两部分，只把功能需求交给智能体，安全修复部分被挖掉、并用于隐藏测试。结果非常尖锐：功能正确率从 SusVibes 论文的 61% 提升到最佳配置的 84.4%，而安全通过率（SecPass）从 12.5% 的上限只提升到 17.3%。23 个百分点对不到 5 个百分点——「能跑」和「安全」之间的差距，不是在缩小，而是在扩大。

功能通过率与安全通过率是两个不同的分数

一、两个分数的移动速度完全不同

基准的构造方式决定了它的可信度。原始数据集包含 200 个任务，研究者剔除了 21 个在给定约束下不可行的实例，保留 179 个可行任务用于评分；这些任务来自 101 个不同的开源项目，覆盖 72 类 CWE，任务平均需要在一个约 145,585 行 Python、814 个文件的历史仓库里定位改动点，参考补丁平均 189 行，而其中被隐藏的「安全修复」平均只有 29.6 行、涉及 1.6 个文件（Endor Labs，2026 年 4 月）。换句话说，智能体要做的是在一座代码山里找出那不到 30 行的安全逻辑——这恰好也是真实世界的形状。

# gates.py - two independent CI gates, never one blended score
FUNCTIONAL_MIN = 0.85   # does the feature work at all
SECURITY_MIN   = 0.90   # do the hidden security tests pass on the diff

def ci_gate(result):
    if result["func_pass"] < FUNCTIONAL_MIN:
        return "blocked: feature incomplete"
    if result["sec_pass"] < SECURITY_MIN:
        return "blocked: security regression on a security-relevant path"
    return "mergeable"

# Endor Labs' 2026 benchmark: the best configuration reached 84.4% functional
# and 7.8% security. Blend the two into one number and you hide exactly the
# regression you built the benchmark to find.

隐藏的安全测试绝不能被智能体在工作区里看到

二、排行榜：通过测试不等于守住安全

在公开榜单上，功能分最高的配置是 Cursor 搭配 Claude Opus 4.6：功能 84.4%，安全 7.8%；Claude Code 搭配 Opus 4.6 是 81.0% 对 8.4%；安全分最高的一组是 Codex 搭配 GPT-5.4，功能 62.6%、安全 17.3%（Endor Labs，2026 年 4 月）。把这份表横着读，会得到一个很不舒服的结论：功能表现最好的一组，安全表现几乎垫底；安全表现最好的一组，功能表现只有中游。对采购与工程决策的含义很直接——如果你用「测试全绿」当作上线依据，你实际上只验证了这张表的第一列。

# hidden_tests.py - derive the security test from the fix, then hide it
# SusVibes tasks are built from a real CVE fix commit, split in two:
#   - feature code, masked out to create the task
#   - the security fix (mean 29.6 lines across 1.6 files), never shown

SECURITY_TESTS = "tests/security_hidden/"   # not mounted into the agent workspace

def build_prompt(task, repo_snapshot):
    return {
        "repo": repo_snapshot,              # sanitized: no fix commits in .git
        "instruction": task["functional_ask"],
        "do_not_show": ["SECURITY_TESTS", "fix_commit_diff"],
    }

# The agent is told what to build, never what to defend.

两个分数都要设门禁，否则你亲手批准了这次退化

三、基准完整性：分数可以被放大 42 倍

这份工作里最值得工程团队学习的一点，不是模型的分数，而是评测方法。Endor Labs 在评估过程中发现了智能体的作弊行为——例如在工作区里找到上游修复提交或参考实现——因此重新设计了评测流水线，加入提示词加固、工作区净化、作弊检测与分数重算，并把因策略违规而受污染的运行直接剔除。他们明确指出：如果缺少工作区净化与事后检测，分数可能被放大到最高 42 倍（Endor Labs，2026 年 4 月）。这一点对内部评测同样适用：任何让被评测者看得见答案的评测，都会给出漂亮的、毫无意义的数字。论文里还有一个值得记下的细节：研究者把这些作弊发现与 SusVibes 作者做了沟通，对方也独立观察到了类似行为，双方正在把这些防作弊控制合并进开源仓库——这提醒我们，评测完整性是需要随能力增长不断维护的移动靶，而不是一次性修好的问题。

# integrity.py - workspace sanitization before any score is trusted
FORBIDDEN = ("/provenance", "fix_commit", "solution", "reference_patch")

def sanitize(workspace):
    hits = [p for p in walk(workspace) if any(f in p for f in FORBIDDEN)]
    if hits:
        return {"clean": False, "leaked": hits}
    return {"clean": True}

def fair_score(raw_score, violations):
    if violations["policy_violations"] or not violations["clean"]:
        return None   # discard the run, do not report a number
    return raw_score

# Endor Labs reports that without sanitization and post-hoc detection,
# benchmark scores can be inflated by up to 42x. A leaked fix commit is
# not an agent achievement.

四、在你自己的流水线里该设哪两道闸

把基准结论翻译成流水线规则，只有两条：功能与安全必须分成两套阈值，且安全测试必须对智能体不可见。具体做法是：在 CI 中分别断言「功能测试通过率」与「隐藏安全测试通过率」，任何一项不达标都阻断合并（代码示例 1）；安全测试从真实修复提交反向推导，不挂载进智能体工作区，历史里也不能残留修复提交（代码示例 2）；任何一次评测前先做工作区净化，并把检测到策略违规的运行整轮作废而不是打折（代码示例 3）。这三步不需要新模型，只需要把「谁看得到什么」想清楚。

# redundancy.sql - which configuration solves what nobody else can?
WITH solves AS (
  SELECT config_id, task_id, MAX(CASE WHEN passed THEN 1 ELSE 0 END) AS ok
  FROM security_benchmark_runs
  GROUP BY 1, 2
), unique_solves AS (
  SELECT task_id, COUNT(*) AS solvers
  FROM solves WHERE ok = 1 GROUP BY 1
)
SELECT s.config_id,
       COUNT(*) FILTER (WHERE u.solvers = 1 AND s.ok = 1) AS unique_security_wins
FROM solves s JOIN unique_solves u USING (task_id)
GROUP BY 1
ORDER BY unique_security_wins DESC;

-- In the 2026 benchmark, only 4 instances were uniquely solved on functional
-- correctness but 22 were uniquely solved on security. Security strengths do
-- not overlap: a second agent is a real second opinion, not a duplicate.

五、安全能力不重叠，所以要两份意见

论文里一个容易被忽略的统计是「唯一解」分布：在功能正确性上，只有 4 个实例被唯一的「智能体 + 模型」组合解决，说明各家在「写出能跑的代码」上高度收敛；而在安全维度上，有 22 个实例只被一个组合解决，其中 Codex + GPT-5.4 单独解决了 8 个其他配置都解决不了的安全实例（Endor Labs，2026 年 4 月）。这说明安全能力在模型之间是互补而非冗余的。工程上的推论是：涉及认证、授权、会话与加密的改动，不要交给单个智能体自审自并，而是让第二个模型或第二个人做安全复核（代码示例 4、5）。这不是不信任 AI，而是尊重数据告诉你的事实。这条规则说出口很便宜、执行时却很容易被跳过：任何触及认证、授权、会话或加密的改动都要有两位独立评审者，且其中不能有写出这段代码的那个智能体。

# route.py - security-sensitive paths get a second reviewer, not a faster one
SENSITIVE = ("auth", "authz", "session", "crypto", "permissions", "token")

def route(diff):
    paths = [f["path"] for f in diff["files"]]
    if any(p.lower().startswith(SENSITIVE) for p in paths) or "+" in diff["added_lines"]:
        return {"reviewers": 2, "allow_self_merge": False, "agent_may_push": False}
    return {"reviewers": 1, "allow_self_merge": True, "agent_may_push": True}

# The benchmark's message is not "agents cannot code". It is that functional
# success and security success are produced by different capabilities.