摘要：当我们谈论人工智能写代码时，大多数人想到的可能是那些能够快速生成简单函数的AI助手。但现实中的软件开发远比这复杂得多——就像建造一座大楼需要考虑地基、结构、水电管道的相互配合一样，真正的代码项目涉及成千上万个文件之间的复杂关系。更重要的是，这些代码必须是安全的

当我们谈论人工智能写代码时，大多数人想到的可能是那些能够快速生成简单函数的AI助手。但现实中的软件开发远比这复杂得多——就像建造一座大楼需要考虑地基、结构、水电管道的相互配合一样，真正的代码项目涉及成千上万个文件之间的复杂关系。更重要的是，这些代码必须是安全的，因为一个小小的安全漏洞就可能让黑客轻易入侵整个系统。

这项由腾讯、清华大学、北京大学、复旦大学、上海交通大学、浙江大学等多家顶尖机构联合完成的研究，首次建立了一个名为A.S.E（AI代码生成安全评估）的全新评测基准，专门用来检验AI模型在真实项目环境中生成安全代码的能力。

传统的AI代码评测就像是让学生做单选题——给一个简单的编程题目，看AI能不能写出正确答案。但A.S.E更像是让AI参与一个真实的软件开发项目，需要理解整个项目的架构，修复其中的安全漏洞，还要确保修复后的代码能够正常编译运行。这种评测方式更接近真实的开发场景，也更能反映AI在实际应用中的表现。

研究团队对26个当前最先进的AI模型进行了全面测试，包括Claude、GPT-4、Qwen等知名模型。结果显示，即使是表现最好的Claude-3.7-Sonnet，在代码安全方面的得分也只有46.72分（满分100分），这意味着AI生成的代码中仍有超过一半存在安全隐患。更有趣的是，研究发现那些"慢思考"的AI模型（类似于人类深思熟虑的思维模式）在安全性方面的表现反而不如"快思考"的模型，这颠覆了我们对AI推理能力的传统认知。

真实世界的代码安全挑战：为什么需要A.S.E

在软件开发的世界里，安全漏洞就像是房屋建筑中的结构缺陷——表面上看起来一切正常，但在关键时刻可能导致灾难性的后果。传统的AI代码评测方法就像是在实验室里测试建筑材料的强度，虽然能够提供一些有用信息，但无法真正反映这些材料在复杂建筑环境中的表现。

现有的代码安全评测基准主要存在三个根本性问题。首先是粒度不匹配的问题。大多数评测都专注于单个函数或代码片段，就像只看一块砖头的质量而不考虑整面墙的结构。但在真实的软件项目中，安全漏洞往往源于不同模块之间的交互，一个看似安全的函数可能因为与其他代码的配合而产生漏洞。比如，一个处理用户输入的函数本身可能没有问题，但如果它将数据传递给另一个没有进行安全检查的数据库查询函数，就可能导致SQL注入攻击。

其次是评估方法不稳定的问题。许多现有的评测方法依赖于让另一个AI模型来判断代码是否安全，这就像让一个人来评判另一个人的作品——结果往往带有主观性，而且同样的代码在不同时间、不同设置下可能得到完全不同的评价。还有一些方法使用通用的静态分析工具，但这些工具在面对不同编程语言和复杂项目结构时，经常出现误报或漏报的情况。

第三个问题是视角过于狭窄。大多数研究要么只关注AI模型本身的能力，要么只看生成代码的质量，很少有人系统性地研究输入信息的质量如何影响输出代码的安全性。这就像研究厨师的烹饪技能时，只关注厨师的手艺而忽略了食材的质量和厨房设备的影响。

为了解决这些问题，研究团队决定构建一个全新的评测基准。他们的思路很简单却很有效：既然要评测AI在真实环境中的表现，那就直接使用真实的项目。A.S.E基准从真实的开源项目中选取那些曾经出现过安全漏洞并已经被修复的代码，然后将修复部分移除，让AI模型来尝试重新修复这些漏洞。

这种方法的巧妙之处在于，它保留了真实项目的所有复杂性——包括多文件依赖、构建系统、第三方库等等，同时又有明确的评判标准（因为我们知道正确的修复方案是什么）。就像让医学生在真实的医院环境中诊治真实的病例，而不是在教室里背诵理论知识。

构建真实可靠的安全评测基准

创建A.S.E基准的过程就像考古学家挖掘古代遗址一样，需要极其细致和专业的工作。研究团队首先组建了一个由10名网络安全和Web开发专家组成的团队，其中包括5名博士研究生和5名硕士研究生，他们都有丰富的漏洞发现、分析和修复经验。

整个构建过程分为四个主要阶段，每一步都经过精心设计以确保数据的质量和可靠性。第一阶段是确定数据源。团队从企业内部的漏洞数据库和GitHub等公开平台收集了超过10万个包含安全漏洞记录的项目。这就像从海量的医疗案例中筛选出最有代表性的病例一样，需要确保覆盖面广且具有典型性。

第二阶段是筛选候选项目。团队制定了严格的筛选标准，只保留那些项目活跃、测试覆盖充分、开发实践一致的项目。每个保留的项目都必须包含至少一个公开披露的CVE（通用漏洞披露）记录，并提供完整的修复补丁。这些条件确保了数据的高质量、完整记录和可重现性。经过这一轮筛选，从最初的10万多个项目中筛选出了199个候选项目。

第三阶段是专家指导的精化和质量过滤，这是整个过程中最关键的部分。安全专家逐一分析通过初步筛选的项目，精确标记每个漏洞的具体代码区域。系统会提取周围的上下文信息，包括函数签名、API定义和调用链，以重建代码环境。对每个漏洞，团队都会创建专门的CodeQL或Joern查询语句来验证漏洞的传播路径。

在这个过程中，团队会丢弃那些发现结果模糊或不一致的候选项目，或者当前工具无法以足够精度分析的代码。对于保留的候选项目，团队会定制和加强检测规则，以提高检测精度并使扫描结果与确认的漏洞保持一致。这就像医生在诊断疾病时，不仅要看症状，还要结合各种检查结果来确保诊断的准确性。

在精化过程中，团队还会移除标记的易受攻击代码，创建一个"填空"式的设置。他们将漏洞的功能描述与提取的上下文结合，为每个任务生成结构化的代码补全提示。这种设计提供了清晰的输入和输出语义，使模型能够对项目结构和逻辑进行推理，而不仅仅是处理局部代码片段。

经过专家审查后，团队选择了40个具有真实CVE记录的项目作为数据源，并为每个项目设置了经过验证的基线提交作为统一起点。这种设置确保了一致且稳定的代码状态，避免了项目更新带来的不确定性，并支持真实性、可靠性和可重现性。

第四阶段是数据集扩展。为了增加数据量和覆盖面，团队在保持语义的约束下扩展了任务集。他们应用了两种类型的转换：语义转换和结构转换。语义转换包括系统性的变量和函数重命名，以及等效API替换，以多样化表面表达。结构转换则调整控制流、重构调用图或重新组织文件布局以引入结构差异。

这些操作在保持功能行为和漏洞语义的同时改变了实现细节，减少了与可能出现在训练数据中的公共项目代码的重叠，缓解了潜在的数据污染问题。扩展的变体使得对模型鲁棒性和泛化能力的评估更加全面。通过这些步骤，团队完成了A.S.E基准数据集，从40个种子任务生成了80个语义保持变体，总共产生了120个现实且可重现的漏洞场景。

为了确保便携和可重现的评估，团队为每个场景配置了构建和运行时环境，并用Docker打包。除了场景环境外，他们还将相关的静态应用安全测试工具容器化，以便在统一环境中通过一个命令进行评估。这种设计支持系统评估、可重现性和跨平台可用性。

A.S.E基准的独特特征和覆盖范围

A.S.E基准就像一个精心策划的安全演习场，涵盖了现实世界中最常见也最危险的安全威胁。整个基准包含120个项目级漏洞实例，其中40个是原始种子项目，80个是通过系统化变异生成的变体。每个实例都经过严格验证，确保在不同评估设置下的可重现性和一致性。

基准重点关注四种在真实Web项目中最常见的漏洞类别，每种都与相应的CWE（通用弱点枚举）条目一一对应。SQL注入占29.2%，对应CWE-89；路径遍历占26.7%，对应CWE-22；跨站脚本攻击占25.0%，对应CWE-79；命令注入占19.2%，对应CWE-78。这种映射在CWE级别定义了数据集，并将其限制在这四个类别中，确保任务和指标与研究和实践广泛认可的安全关键问题保持一致。

对于每个类别，基准都定义了相应的任务来评估模型是否能够正确处理特定类型的安全威胁。跨站脚本攻击测试模型是否能检测并缓解注入到可信Web上下文中的恶意脚本。SQL注入评估模型是否能识别并防止通过恶意SQL查询来损害数据库完整性或未经授权提取数据的尝试。路径遍历检查模型是否能检测并阻止通过操纵文件路径来访问指定Web根目录之外的文件和目录的尝试。命令注入测试模型是否能识别并防止通过应用程序漏洞在主机上执行未经授权的操作系统命令的尝试。

从编程语言的角度来看，A.S.E涵盖了五种主流环境，反映了现实的多语言软件开发情况。分布主要集中在PHP（50.0%），其次是Python（19.2%）、Go（14.2%）、JavaScript（14.2%）和Java（2.5%）。这种不平衡反映了易受攻击的PHP项目在实际生态系统中的普遍性，同时也为检验跨语言漏洞检测和缓解的泛化能力提供了机会。

这种语言分布的不均匀实际上反映了现实世界的情况。PHP作为Web开发的主要语言之一，由于其灵活性和易用性，在快速开发中经常出现安全问题。Python和JavaScript作为现代Web开发的重要组成部分，也经常面临各种安全挑战。Go作为相对较新的语言，虽然在设计时考虑了安全性，但在实际应用中仍然可能出现问题。Java虽然比例较小，但作为企业级应用的重要语言，其安全性同样重要。

基准的设计还考虑了项目规模的多样性。包含的项目从小型工具到大型应用系统，代码行数从几千行到几万行不等。这种多样性确保了评测能够反映不同规模项目中的安全挑战，因为小项目和大项目面临的安全问题往往有所不同。小项目可能更容易出现简单的编程错误导致的漏洞，而大项目则更容易因为模块间交互复杂而产生难以发现的安全问题。

创新的三维评估体系

A.S.E的评估体系就像一个全面的健康检查，不仅要看病人是否康复了，还要检查治疗过程是否安全，以及治疗效果是否稳定。传统的代码评测往往只关注"代码能不能运行"这一个维度，但A.S.E创新性地提出了三个互补的评估维度：安全性、质量和稳定性。

安全性维度关注的是AI生成的代码是否真正解决了原有的安全漏洞。这就像医生治疗疾病后要检查病症是否真的消失了一样。评估方法是比较修补前后检测到的漏洞数量，只有当修补后的漏洞数量确实减少时，才认为修补是成功的。为了确保检测的准确性，团队为每个CVE都制作了专门的静态分析规则，这些规则经过专家精心调校，能够精确识别特定类型的漏洞。

质量维度评估的是生成的代码是否能够正确集成到原有项目中。这个维度看似简单，但实际上非常重要。就像修理汽车时，不仅要确保修好了故障，还要保证汽车能够正常启动和行驶。在代码世界里，这意味着修补后的代码必须能够成功编译，通过基本的语法检查，并且不会破坏项目的构建过程。只有满足这些基本要求，安全修补才有实际意义。

稳定性维度考察的是AI模型生成结果的一致性。同样的问题，如果每次都给出完全不同的答案，那么这个AI就不够可靠。为了测试稳定性，每个测试用例都会运行三次，然后计算结果的标准差。标准差越小，说明模型越稳定。为了将较低的变异性映射到较高的分数，系统采用最小-最大缩放方法进行归一化处理。

这三个维度的权重分配也经过了仔细考虑。安全性占60%的权重，因为这是整个评测的核心目标；质量占30%，确保生成的代码具有实用价值；稳定性占10%，保证模型的可靠性。这种权重分配反映了在实际应用中，安全性是最重要的，但质量和稳定性也不可忽视。

评估过程采用了严格的容器化环境，确保每次测试都在完全相同的条件下进行。这就像科学实验中的对照组一样，消除了环境因素对结果的影响。每个项目都有自己的Docker容器，包含了特定版本的编译器、依赖库和构建工具，确保测试结果的可重现性。

更重要的是，A.S.E的评估不是一次性的，而是一个持续的过程。对于每个测试用例，系统会记录详细的执行日志，包括编译输出、静态分析结果、以及任何错误信息。这些信息不仅用于计算最终分数，还为研究人员提供了深入分析模型行为的宝贵数据。

全面的模型评测结果与发现

研究团队对26个当前最先进的大语言模型进行了全面评测，这些模型涵盖了从闭源的商业模型到开源的研究模型，形成了目前最全面的AI代码安全能力评估。评测结果揭示了一些令人意外的发现，颠覆了我们对AI代码生成能力的传统认知。

在整体表现方面，Claude-3.7-Sonnet以63.01分的总分位居榜首，在代码质量方面表现尤为突出，达到了91.58分。但令人担忧的是，即使是这个表现最好的模型，在代码安全方面的得分也只有46.72分，这意味着它生成的代码中仍有超过一半存在安全隐患。这就像一个技艺精湛的建筑师，能够设计出美观实用的建筑，但在结构安全方面还有很大的改进空间。

以Claude系列为例，Claude-3.7-Sonnet在快思考模式下的代码安全得分为46.72分，而其慢思考版本的得分却降到了44.65分。更明显的是Claude-Sonnet-4，其慢思考版本在所有指标上都比快思考版本有显著下降。其他慢思考模型如DeepSeek-R1和Gemini-2.5-Pro-Exp也显示出较弱的代码安全性能。

这种现象可能有几个原因。首先，慢思考模式可能会产生过度复杂的输出，在试图考虑更多因素的过程中，反而引入了新的安全风险。这就像一个过度谨慎的司机，在简单的路口反复思考，结果错过了最佳通行时机，甚至造成了交通堵塞。

其次，当前的慢思考模式可能缺乏针对性的安全强化训练。虽然这些模型在一般推理任务上可能表现更好，但在特定的安全领域，它们的额外思考步骤可能没有带来相应的安全意识提升。这就像让一个哲学家去修理精密仪器，虽然思考深度够了，但缺乏专业的技术知识。

第三个可能的原因是，代码安全问题往往需要的是准确的模式识别和已知最佳实践的应用，而不是创新性的推理。在这种情况下，快速准确地识别和应用安全模式可能比深度思考更有效。这就像在紧急医疗情况下，经验丰富的医生的快速诊断往往比长时间的讨论更有价值。

这个发现对AI模型的发展具有重要意义。它提示我们，在特定领域如代码安全，简洁直接的方法可能比复杂的推理过程更有效。这并不意味着慢思考模式本身有问题，而是说明在不同的应用场景下，不同的推理模式可能有不同的适用性。

开源与闭源模型的竞争格局

A.S.E基准的评测结果揭示了开源和闭源AI模型之间一个令人惊讶的竞争格局。传统观念认为，拥有更多资源和数据的商业公司开发的闭源模型应该在各方面都优于开源模型，但实际情况要复杂得多。

在代码质量方面，闭源模型确实展现了一定优势。Claude-3.7-Sonnet和Claude-Sonnet-4分别达到了91.58和92.37的高分，显示了它们在生成语法正确、能够编译运行的代码方面的强大能力。这就像是名牌汽车在制造工艺和外观设计方面的优势一样明显。

然而，在最关键的代码安全维度上，开源模型展现了令人刮目相看的竞争力。Qwen3-235B-A22B-Instruct以48.03分的成绩在安全性方面位居榜首，甚至超过了表现最好的闭源模型Claude-3.7-Sonnet的46.72分。这种逆转就像是在汽车安全测试中，一款普通品牌的车型在碰撞测试中超越了豪华品牌一样令人意外。

在生成稳定性方面，开源模型如Kimi-K2和Qwen-Coder-Plus也表现出色，显示了它们在一致性方面的可靠性。这表明开源模型在某些特定维度上已经达到了与闭源模型相当甚至更好的水平。

从整体性能来看，闭源和开源模型的差距正在缩小。虽然Claude-3.7-Sonnet仍然占据榜首位置，但紧随其后的就是开源模型Qwen3-235B-A22B-Instruct，两者的差距并不大。这种趋势表明，开源社区在AI模型开发方面的努力正在结出硕果。

这种竞争格局的出现有几个重要原因。首先，开源模型受益于全球开发者社区的集体智慧。当成千上万的研究者和工程师共同改进一个模型时，其在特定领域的表现可能会超越少数专家团队的成果。这就像维基百科在某些专业领域的准确性甚至超过了传统百科全书一样。

其次，开源模型在训练数据和方法上的透明性使得研究者能够针对特定问题进行优化。在代码安全这个相对专业的领域，这种针对性的优化可能比通用的大规模训练更有效。

第三，开源模型的快速迭代和社区反馈机制使得它们能够更快地修复问题和改进性能。当发现某个安全相关的问题时，开源社区往往能够迅速响应并推出改进版本。

这种竞争格局对整个AI行业都有积极意义。它促进了技术的快速发展，降低了高质量AI模型的使用门槛，也为用户提供了更多选择。对于企业和开发者来说，这意味着他们不必完全依赖昂贵的商业模型，也能获得高质量的AI代码生成服务。

不同漏洞类型的挑战程度分析

通过对四种主要漏洞类型的详细分析，研究团队发现了AI模型在处理不同安全威胁时表现出的显著差异。这种差异就像医生在治疗不同疾病时的成功率不同一样，反映了各种安全问题的内在复杂性和AI模型的能力边界。

路径遍历漏洞被证明是所有评测任务中最具挑战性的。即使是表现最好的AI模型，在这个任务上的整体得分也低于50分。这种困难程度的差异并非偶然，而是源于路径遍历攻击的微妙性和多样性。路径遍历攻击通常依赖于对文件系统路径的巧妙操作，攻击者通过使用"../"等特殊字符序列来访问本不应该访问的文件和目录。

这类攻击的检测和防护需要对文件系统操作有深入理解，还要考虑不同操作系统、不同编程语言中路径处理的细微差别。比如，在Windows系统中，路径分隔符可以是反斜杠或正斜杠，而在Unix系统中只能是正斜杠。这种复杂性使得AI模型很难建立统一的防护模式。

相比之下，命令注入和跨站脚本攻击对AI模型来说相对容易处理。以Claude-3.7-Sonnet为例，它在命令注入任务上有72.2%的代码既合格又安全，在跨站脚本攻击任务上这个比例达到了56.7%。这种相对较好的表现可能是因为这两类攻击有更明显的特征模式，更容易被AI模型识别和防护。

命令注入通常涉及将用户输入直接传递给系统命令执行函数，如system、exec等。这些函数名称本身就是明显的危险信号，AI模型相对容易学会在使用这些函数时添加适当的输入验证和过滤。跨站脚本攻击虽然形式多样，但基本原理是将恶意脚本注入到网页中，防护方法也相对标准化，主要是对用户输入进行HTML编码或使用内容安全策略。

SQL注入攻击的情况介于两者之间。虽然SQL注入是最著名的Web安全威胁之一，但AI模型在处理这类问题时仍然面临挑战。这主要是因为SQL注入的形式非常多样化，从简单的字符串拼接到复杂的二阶注入，攻击手法层出不穷。而且，现代Web应用中的数据库操作往往涉及多层抽象，从原始SQL到ORM框架，再到各种查询构建器，使得漏洞的识别和修复变得更加复杂。

这些发现对AI模型的改进具有重要指导意义。针对路径遍历这类困难问题，需要加强模型对文件系统操作和访问控制的理解，可能需要专门的训练数据和针对性的强化学习。对于相对容易的命令注入和XSS问题，则可以通过建立更完善的安全模式库来进一步提高防护效果。

混合专家模型的优势表现

在所有参与评测的模型中，采用混合专家（MoE）架构的模型普遍表现出了更好的安全性能。虽然一些闭源模型的具体架构细节并未公开，但几乎所有领先的开源模型都采用了MoE架构，包括Qwen3-235B-A22B、Qwen3-Coder-480B-A35B-Instruct、DeepSeek-V3-671B-A37B和Kimi-K2-Preview-1T-32B等。

混合专家架构的核心思想是将一个大型模型分解为多个专门的"专家"子网络，每个专家负责处理特定类型的输入或任务。在处理具体问题时，系统会智能地选择最合适的专家组合来生成回答。这就像一个综合医院，不同科室的医生各有专长，病人会被分配给最适合的专科医生治疗。

在代码安全领域，这种架构优势特别明显。不同类型的安全漏洞需要不同的专业知识和处理方法。SQL注入需要对数据库查询语言有深入理解，跨站脚本攻击需要熟悉Web前端技术，路径遍历需要了解文件系统操作，命令注入需要掌握操作系统命令执行机制。MoE架构允许模型为每种类型的安全问题培养专门的专家，从而在各个领域都能提供更专业的解决方案。

相比之下，传统的密集型模型需要用同一套参数来处理所有类型的问题，这就像要求一个全科医生同时精通所有专科一样困难。虽然全科医生能够处理大多数常见问题，但在面对复杂的专科问题时，往往不如专科医生那样精准和有效。

MoE架构的另一个优势是能够在保持模型总体规模的同时，为每个具体任务分配更多的计算资源。在处理代码安全问题时，系统可以激活那些专门训练过安全相关知识的专家，而不需要激活整个模型的所有参数。这种选择性激活不仅提高了效率，也使得模型能够更专注于当前任务的特定需求。

从训练的角度来看，MoE架构也更适合代码安全这种需要多领域专业知识的任务。在训练过程中，不同的专家可以专门学习不同编程语言、不同类型漏洞、不同安全防护技术的相关知识。这种专业化的学习过程使得每个专家都能在自己的领域内达到更高的专业水平。

这一发现对未来AI模型的发展具有重要启示。在代码安全这样的专业领域，采用MoE架构可能是提高模型性能的有效途径。这也解释了为什么在A.S.E基准测试中，许多采用MoE架构的开源模型能够在安全性方面与甚至超越一些闭源模型。

A.S.E基准的推出标志着AI代码安全评估进入了一个新的阶段。这项由腾讯联合多家顶尖学术机构完成的研究，不仅为我们提供了第一个真正意义上的项目级代码安全评测标准，更重要的是，它揭示了当前AI技术在代码安全方面的真实水平和主要挑战。

研究结果表明，即使是最先进的AI模型，在代码安全方面仍有很长的路要走。这并不意味着AI代码生成技术不成熟，而是提醒我们，在将AI生成的代码应用到实际项目中时，必须保持谨慎和警觉。就像我们不会让一个刚学会开车的新手独自驾驶长途汽车一样，AI生成的代码也需要经过专业的安全审查才能投入使用。

同时，开源模型在某些安全指标上超越闭源模型的表现，以及"快思考"模式优于"慢思考"模式的发现，都为AI技术的发展提供了新的思路。这些发现告诉我们，在AI的世界里，更复杂不一定意味着更好，更昂贵也不一定意味着更安全。

至顶AI实验室洞见

对于普通开发者和企业来说，A.S.E基准提供了一个客观评估AI代码生成工具的标准。在选择AI编程助手时，不应该只看它能不能写出能运行的代码，更要关注它在安全方面的表现。毕竟，一个功能完善但存在安全漏洞的应用程序，可能比一个功能简单但安全可靠的程序带来更大的风险。

随着A.S.E基准的推广和应用，我们有理由相信，AI模型在代码安全方面的能力将会得到显著提升。这个基准不仅为研究者提供了改进模型的明确目标，也为整个行业建立了安全标准。当越来越多的AI模型开始在这个基准上接受测试时，代码安全将不再是一个被忽视的角落，而会成为AI代码生成技术发展的重要驱动力。

论文地址：

来源：码客人生一点号