研究数据：AI编程工具生成的代码45%存在安全漏洞，三大解决方案

关于 AI 生成代码安全的研究，在以数据形式抵达工程团队之前，往往先以轶事的形式传开。以下是数据层面的呈现。

过去 24 个月的三项独立研究表明了一个一致的模式：AI 编程助手生成的代码在开发者审查中的通过率高于其实际应得的水平；安全差距并未随着模型变大而缩小；大多数工程组织没有正式管理这一风险的流程。这三个问题都有已知解决方案。第一步是了解实际影响范围。

AI 生成代码安全研究揭示了什么

BrassCoders 的 N=15 AI 生成代码语料库在使用完整 12 个扫描器栈进行扫描时，在全部 15 个文件中均检测到至少一个安全问题——这是一个受控的研究样本，而非部署规模的数据集。该语料库发布在 coppersun.dev/benchmarks 上：15 个由安全相关提示词生成的 Python 文件，包含可复现的扫描说明。外部研究在更大规模上运行，得出了相似结论。

Veracode 2025 年 7 月发布的 GenAI 代码安全报告测试了超过 100 个大语言模型，覆盖 80 个独立的安全相关任务。核心数据：45% 的 AI 生成代码样本未通过安全测试。按语言细分，Java 失败率达 72%，C# 为 45%，JavaScript 为 43%，Python 为 38%。跨站脚本测试在相关测试案例中的失败率达 86%。对工程领导者而言最重要的发现是：更新、更大的模型相比更早的模型并未表现出持续的安全改进。扩大模型规模并不能弥合漏洞差距。

Perry 等人（CCS 2023，47 名参与者）开展了一项对照实验，将开发者分配到使用 AI 编程助手或不使用 AI 编程助手两组。在 ECDSA 签名任务中，AI 辅助组有 3% 的人写出了安全代码，而对照组这一比例为 21%（p=0.039）。ECDSA 任务之所以是一个有效的探测手段，是因为正确实现需要对非密码学专业人士而言较为微妙的参数选择——nonce k 必须是随机的且不能重复使用，而不正确的实现从结构上看对不了解该约束的审查者来说是正确的。该研究使用了 codex-davinci-002，这是 2022 年的模型；当前的前沿模型生成的代码更加流畅。它们是否已经弥合了密码学正确性方面的差距，这是一个开放的研究问题。Veracode 2025 年的发现表明，这一差距在不同代际的模型中持续存在。

Checkmarx 的《2025 应用安全未来》报告（1,519 名受访者，2025 年 8 月）测量了组织层面的应对：98% 的组织报告了可归因于漏洞代码的安全事件，而仅有 18% 的组织对 AI 编程工具制定了治理策略。AI 工具的采用率领先于治理水平 82 个百分点。

为什么 AI 助手会产生不安全代码

BrassCoders 的 N=15 语料库显示，AI 生成的文件中存在三类反复出现的 bug：通过格式化字符串组装 SQL 查询导致的 SQL 注入、配置和初始化代码中的硬编码凭证，以及不安全的加密调用。这三类问题有相同的结构性根源——AI 生成的代码满足了所声明的提示词要求并通过了本地测试，但对代码将面临的生产环境攻击面没有任何建模。

通过格式化字符串组装进行 SQL 注入是最清晰的案例。从"write a user lookup by ID"生成的 Flask 数据库查询会产生：

cur.execute("SELECT id, name, email FROM users WHERE id = %s" % user_id)

该查询在开发过程中返回正确的行。测试通过。漏洞——通过用户可控的 user_id 进行的 SQL 注入——只有在攻击者向端点发送精心构造的字符串时才会显现。标准测试不会覆盖这一路径，除非测试套件专门为测试注入抗性而编写。BrassCoders 通过 Bandit B608 和 Semgrep 污染分析将其标记为 CRITICAL。修复方法是使用参数化查询：

cur.execute("SELECT id, name, email FROM users WHERE id = ?", (user_id,))

硬编码凭证遵循相同的模式。从"write an HMAC signing key setup"生成的配置模块会产生 SECRET_KEY = "s3cr3t-signing-key-change-me"。字面字符串满足了提示词要求；在开发过程中工作正常；当开发者运行 git add 时会提交到版本控制。BrassCoders 的 SecretsScanner 将其标记为 HIGH 并从 YAML 输出中编辑掉凭证值——代码片段和文件路径会保留，但字面秘密值不会。修复方法是：SECRET_KEY = os.environ.get("HMAC_SECRET_KEY", "")。

密码学案例需要更多的上下文阅读。hashlib.md5() 没有 usedforsecurity=False 参数会触发 Bandit B324，因为 MD5 在认证和签名场景已被破解——碰撞攻击允许攻击者用一个产生相同哈希值的不同输入来替换。对于内容去重（问"这些字节相同吗？"），碰撞攻击无关紧要。AI 为所声明的使用场景生成了正确的代码。扫描器正确地标记了结构性模式。该发现是否是真正的漏洞取决于摘要值在下游的用途。这是扫描器无法读取的上下文。AI 审查者可以处理它。

过度自信问题

BrassCoders 在提交时捕获 SQL 注入、硬编码凭证和命令注入模式——在这些代码进入审查周期之前，而在 Perry 等人的过度自信发现变得代价高昂之前。该研究的核心结论很明确：AI 辅助的开发者对自己代码安全性的评价高于对照组对自身代码的评价，而实际上却写出了安全性更低的代码。模型的表面自信转移到了审查其输出的开发者身上。

这是一个审查校准问题，而非一次性的训练修复。流畅、结构良好的 AI 生成代码携带的摩擦信号低于看起来不确定或不一致的代码。触发对可疑 SQL 插值产生警觉的犹豫——"等等，那是可注入的吗？"——当周围代码看起来很专业时会变得更安静。机制并非粗心大意。这是格式规范、语法正确的代码对被训练成信任该信号的审查者所传达的信息。

对工程团队有两个实际意义。首先，AI 生成 PR 的同行审查流程应包含明确的扫描步骤，而不仅仅是视觉审查。扫描器捕获的是在过度自信条件下视觉审查会漏掉的结构性模式。其次，PR 审查者应该知道他们审查的是 AI 生成的代码——Perry 过度自信效应部分上是校准问题，知道代码来源的审查者可能会对输出施加更严格的审查。

Veracode 2025 年软件安全状态报告显示，安全缺陷的平均修复时间在过去五年中增加了 47%，达到 252 天。随 AI 生成提交进入生产环境的 bug 与任何其他生产安全 bug 走相同的修复流程：检测、日志审计以界定暴露窗口、如窗口不确定则轮换凭证、如在监管数据范围内则进行合规通知。AI 编程工具提供的提交速度并不能压缩这一时间线。能够压缩时间线的是 bug 被捕获的时机。在提交时被捕获，只需要几秒钟。在生产环境中被捕获，需要数月。

BrassCoders 的扫描器输出发送到 Claude Code 或 Cursor 进行 AI 辅助分类——AI 审查者读取 YAML，针对原始文件对每个发现进行源码验证，并将每个发现分类为真实漏洞或误报，同时提供可执行的修复建议。这种分工（BrassCoders 作为确定性模式匹配器，AI 审查者作为上下文感知分类层）是其技术架构。治理层面的问题是：该架构是否是 AI 生成代码合并前所必需的。

Checkmarx 2025 年的数据使这一差距具体化：82% 使用 AI 编程工具的组织对 AI 生成提交需要何种审查没有定义流程。工具问题可以在一个下午解决。治理问题则是关于需要何种流程的管理决策。

三个决策定义了一个最小的 AI 编码治理策略：

合并前运行哪些扫描。最低限度是覆盖 AI 助手结构性漏掉的类别的静态分析扫描：SQL 注入、硬编码凭证、不安全的子进程调用，以及 AI 幻觉产生的幻影导入。BrassCoders OSS 核心版无需注册账号即可覆盖所有这些类别。

谁审查扫描结果。自动化扫描产生发现结果；人工来闭合这个环。AI 审查者（Claude Code、Cursor）做上下文感知的分类。开发者确认。没有定义的负责人，发现结果就会在队列中无人审查。

已验证误报的处理流程是什么。某些发现在上下文中是误报。.brassignore 捕获这些决策，以免它们在未来的扫描中消耗审查周期。像 file_dedupe.py 这样的 glob 规则压制来自特定文件的所有发现；像 :brass.python.taint.sql-injection 这样的类型规则在项目范围内压制特定的 Semgrep 检查。没有压制流程，团队在第一波噪音之后就会关闭扫描器。

这三个决策不需要新工具。它们需要的是管理决策——确认 AI 生成代码有定义的审查流程。这正是那 18% 拥有治理策略的组织所做的决定。

为 AI 生成代码构建安全门

BrassCoders 可以通过一条命令安装，无需账号即可离线运行——OSS 核心版捕获 AI 编程助手产生的结构性 bug，没有任何数据离开开发者的机器。

pip install brasscoders
brasscoders scan /path/to/project

扫描输出 YAML 到 .brass/findings.yaml，结构化以供 Claude Code 或 Cursor 消费。每个发现包含严重级别、检测器、文件路径、行号和代码片段。AI 审查者读取文件，针对源码验证每个发现，并生成分类输出：带修复建议的真实 bug，或带推理的误报。扫描器是确定性的第一层。AI 审查者是上下文感知的第二层。

CI 集成在每次提交时运行扫描：

# .github/workflows/brasscoders.yml
steps:
  - name: BrassCoders scan
    run: pip install brasscoders && brasscoders scan .

BrassCoders 付费版（$12/开发者/月）增加了语义去重通道和项目签名重排，将 1500+ 发现的原始扫描结果精简为约 300 个优先级发现。富化通道处理已编辑过的发现结果和从 README、manifest 和入口点元数据派生的项目签名——没有原始源代码离开机器。对于原始发现过多导致 AI 辅助分类在大规模下不可行的团队，富化通道是使流程可行的关键。

工程领导者的版本是二元的：门禁在 CI 中合并前运行，否则不运行。Perry、Veracode 和 Checkmarx 描述了不运行时会发生什么。门禁的接线成本是一个下午，每次提交运行时间只需几秒钟。