56% 通过率：Veracode 2026 报告里的 AI 代码安全真相

Veracode 的《2026 GenAI 代码安全报告》给出了一个不太讨喜的结论：模型越来越会写代码，但写出来的代码没有更安全。报告在四年间测试了 100 多个 AI 模型，2026 年轮次新增 11 个模型、覆盖 80 项任务，平均安全通过率停在 56%——相比首份报告的 55%，几乎原地不动；而大约 44% 的生成任务产出了带有已知漏洞的代码。与此同时，现代模型生成的代码在语法上几乎 100% 正确。报告把这句话浓缩成一个短语：语法问题解决了，安全问题没有。对工程与安全负责人而言，这意味着「能不能跑」不再是有效的验收标准。

语法问题解决了，安全问题没有

一、核心结论：安全通过率没有跟上代码量

报告的口径值得先说清楚：超过 100 个模型、四年时间、跨语言与跨漏洞类别测试，平均安全通过率 56%，与首份报告（55%）基本持平；2026 年轮次具体测试了 11 个新模型、80 项任务。Veracode 的解读是，真正变化的不是失败率，而是失败率所覆盖的代码量——在已采用 AI 编码工具的组织中，AI 已经撰写了大约一半的提交代码（Veracode 博客援引外部数据）。这就是为什么他们把 GenAI 代码安全重新定义为「规模问题」：当一半的代码库由 AI 产出，而其中约 44% 的生成任务会引入已知漏洞时，代码评审、修复队列与治理都会面临同一件事的放大——上游做得更快，下游的验证没有跟着变快。

# 1. Gate by vulnerability class, not by a single pass/fail score
#    Veracode 2026 mean security pass rates by class:
#      cryptographic algorithms  87%
#      SQL injection             83%
#      cross-site scripting      15%
#      log injection             12%
HIGH_SCRUTINY = ("cwe-79", "cwe-117")   # XSS and log injection

def review_policy(finding):
    if finding.cwe in HIGH_SCRUTINY:
        return {"required": ["human_review", "sast_rerun", "exploit_test"]}
    if finding.cwe in ("cwe-89",):          # SQL injection: still verify, cheaply
        return {"required": ["parameterisation_lint"]}
    return {"required": ["sast_rerun"]}

二、模型选择已经是一项安全决策

平均值停滞，并不代表分布均匀。报告的快照里，GPT-5.5 以 68% 的安全通过率领跑；11 个夏季 2026 模型中，有 6 个落在 50%–53% 之间。也就是说：最好的模型仍然在近三分之一的安全任务上失手，最差的则在一半上失手。报告还打破了几个人们常有的直觉：为写代码专门训练的模型平均安全通过率 51%，通用模型反而是 52%——更擅长写代码不等于更擅长写安全代码；推理模型平均 56%，高于非推理模型的 51%，说明内部推理似乎有助于在输出前发现不安全构造，但即便如此仍会在近 44% 的任务上失败；模型大小影响也有限，大模型平均 53%，中等与小模型各 51%。Veracode 的结论很直接：在两个都能提效的模型之间，产出漏洞更少的那个不是技术偏好问题，而是风险管理决策。

// 2. Model choice as data, not as folklore
const modelPolicy = {
  default: "gpt-5.5",
  // 2026 GenAI Code Security Report, Summer 2026 dataset:
  securityPassRate: {
    "gpt-5.5": 0.68,        // leads the snapshot
    "six-of-eleven": "0.50-0.53",
    "code-specialised-mean": 0.51,   // vs 0.52 general-purpose
    "reasoning-mean": 0.56,          // vs 0.51 non-reasoning
    "large-mean": 0.53,              // vs 0.51 medium and small
  },
  rule: "A model that fails 1 in 3 security tasks creates less remediation work than one that fails 1 in 2.",
  review: "even the leader needs verification - it still fails nearly 1 in 3",
};

模型选择已经变成一项风险管理决策

三、语言与漏洞类别：把评审资源放到最该放的地方

报告里最有操作性的一组数据是按漏洞类别看的安全通过率：SQL 注入平均 83%，密码学算法 87%，表现相对好；但跨站脚本（XSS）骤降到 15%，日志注入更是只有 12%。这个分布不是偶然——有些安全问题更容易被模型学成可重复的模式，另一些则依赖数据流、应用上下文以及对用户输入如何在系统中流动的深层理解，后者正是原始模型输出最可能失手、也是最需要验证的地方。语言维度上，Java 是本轮改善趋势最明显的语言，同时也是整体最差的语言，平均安全通过率只有 30%。把这两条放在一起，团队就能做出真正有用的取舍：门禁要为 XSS、日志注入、Java 相关代码留出人工评审，而不是对全部代码一视同仁地「多看一眼」。

# 3. Scan the diff an agent produced, before it becomes a pull request
def precommit_gate(diff):
    changed = languages_in(diff)
    findings = []
    for lang in changed:
        findings += sast.scan(diff, language=lang)
    # Java is the most improved language in the 2026 report and still the
    # lowest, with a mean security pass rate of only 30% - keep the gate open
    # for it rather than trusting generated patterns.
    blocking = [f for f in findings if f.severity in ("high", "critical")]
    return {"block": bool(blocking), "findings": findings}

# Roughly 44% of tested AI generation tasks produced code with a known
# vulnerability. A diff-scoped gate is the cheapest way to catch it upstream.

四、把数据接进流程：四个可以本周就做的动作

第一，门禁按漏洞类别分级，而不是单一总分：为 CWE-79 与 CWE-117 设定强制人工评审与复扫，为 SQL 注入类只保留低成本的参数化检查（代码示例 1）。第二，把模型选择写成策略数据而不是口头传说，把各模型的通过率放进配置文件，并在决策记录里写明「接受残余风险」——即便是领跑者也仍需验证（代码示例 2）。第三，扫描要针对智能体产出的 diff 而不是整个仓库，让问题在变成 PR 之前暴露（代码示例 3）。第四，为修复本身建立度量：哪个模型写的、哪个模型修的、30 天内是否复发、人改了多少行（代码示例 4）。如果 AI 辅助修复不断复现同一个 CWE，那么团队消耗的是评审产能而不是降低风险。

# 4. Instrument remediation, because "AI fixed it" is not a measurement
REMEDIATION_FIELDS = (
    "finding_id", "cwe", "model_that_wrote_it", "model_that_fixed_it",
    "reintroduced_within_30d", "human_edits", "time_to_fix_minutes",
)

def weekly_report(rows):
    return {
        "opened": len([r for r in rows if r["state"] == "open"]),
        "ai_fixed": len([r for r in rows if r["model_that_fixed_it"]]),
        "ai_reintroduced_30d": len([r for r in rows if r["reintroduced_within_30d"]]),
        "median_human_edits": median([r["human_edits"] for r in rows]),
    }

# If AI-assisted fixes reintroduce the same CWE, review capacity is being
# spent on churn, not on risk reduction.

评审资源应该投在模型最常失手的地方

五、把它放到更大的风险图里

这组数据的紧迫性来自它落地的时机。Veracode 在同一篇分析里引用了 Verizon《2026 数据泄露调查报告》：软件漏洞已成为首要入侵入口，占 31%，超过了被盗凭据；同时其《2026 软件安全现状》报告显示，安全债务影响 82% 的组织、关键安全债务影响 60%，高风险漏洞同比增长 36%。把这些信号叠在一起，问题的性质就变了：不再是「AI 会不会引入风险」，而是「已经有太多未解决风险的存量系统里，又要更快地流入更多可能带洞的代码」。给管理层的建议也因此不该是限制使用，而是把安全能力做进流程：用类别化的门禁替代印象式评审、用可度量的修复管线替代「AI 帮我修好了」的说法、并把每次模型选择都留成可审计的记录（代码示例 5）。

{
  "governance_record": {
    "decision": "select_model_for_code_generation",
    "model": "gpt-5.5",
    "evidence": "2026 GenAI Code Security Report - strongest security pass rate in the Summer 2026 snapshot",
    "accepted_residual_risk": "still fails on nearly one in three security tasks",
    "compensating_controls": ["diff-scoped SAST gate", "CWE-79 and CWE-117 human review", "remediation instrumentation"],
    "reviewed_by": "appsec + platform",
    "review_due": "quarterly",
    "context": {
      "ai_authored_share_of_committed_code": "roughly half in adopting organisations",
      "software_vulnerabilities_as_top_breach_entry_point": "31% (Verizon 2026 DBIR, cited by Veracode)",
      "security_debt": "affects 82% of organisations; critical debt 60%; high-risk vulnerabilities up 36% year over year"
    }
  }
}