AI技术在代码安全领域正展现出前所未有的突破性应用——大幅提升代码漏洞的检出能力，从而为业务数据安全筑起更坚实的防线。本文将围绕几个核心内容展开：大模型技术在代码安全领域的应用背景与实践价值；代码漏洞对业务安全的实际影响，以及传统检测方法为何渐显乏力；以及腾讯啄木鸟团队如何借助大模型技术，在代码评审（Code Review，以下简称CR）场景下显著提升漏洞检出能力，并分享具体的落地案例。

大模型技术的涌现，为行业不断突破安全防护的能力上限提供了新的契机。我们将大模型引入安全垂类领域的尝试已沉淀出一系列实践，本文作为开篇，重点介绍在代码安全领域“安全左移”的落地经验。后续还将推出更多关于大模型在研发安全、网络安全、威胁情报等方面的探索成果。

隐藏在代码中的安全漏洞，就像一条通往核心数据资产的隐秘通道，极易被黑客盯上并利用。及时识别和修复这些漏洞，是防止入侵和数据泄露的关键。借助混元大模型，腾讯啄木鸟代码安全团队在CR场景下的安全漏洞检出能力取得了显著提升——日均发现和阻断300个以上的代码安全风险，大大增强了公司核心数据资产的安全性。

一、背景

代码漏洞作为一种特殊的代码缺陷，是黑客窃取数据的主要途径。业界因代码漏洞导致的安全事件频繁发生。2023年5月，著名文件传输系统MoveIt Transfer被曝存在SQL注入漏洞，导致2095个组织和超过6200万人的数据被泄露。同样是2023年5月，梭子鱼发现其邮件网关产品存在远程命令执行漏洞，且已被黑客利用超过8个月。

CR是保证代码质量的重要手段，通过CR可以在开发阶段提前发现并修复漏洞，避免漏洞流入线上造成严重数据泄露，并极大提升漏洞风险闭环的效率。Steve McConnel在《Code Complete》中提到，通过CR能够发现高达60%至65%的潜在缺陷，而大多数测试的潜在缺陷发现率仅在30%左右。SmartBear经过实际调研发现，引入代码CR可以节约六成代码修复成本。

图1 CR阶段漏洞修复流程说明

由此可见，代码漏洞如果不能在上线之前及时解决，一旦流入线上环境，不仅对业务影响大，而且发现难度极高。在CR阶段发现并修复漏洞，能更及时、高效地避免安全威胁，保障业务安全稳定运营。

二、传统代码漏洞检测方法的弊端

代码本质上是一种高维的自然语言。在大模型技术涌现之前，代码漏洞检测主要依赖静态分析：先将代码解析成低维的语法结构，通过数据流和污点分析对代码进行扫描，检测漏洞。静态分析通常需要提供完整的上下文信息，包括source点（用户控制入口）、sink点（漏洞作用位置）和数据流（传播路径），因此只适用于项目级代码扫描。

图2 代码静态分析流程图

CR场景中，用户合入的代码通常是代码片段，只包含项目代码的一小部分。直接使用静态分析方法扫描整个项目，会产生大量冗余的扫描动作，效率极低。据统计，静态分析工具对项目级的扫描耗时平均需要20分钟以上。如果用户合入代码后要等几十分钟甚至数小时才能获取结果，这远不能满足快速迭代的要求。而如果只基于合并的代码片段进行漏洞检测，由于缺乏完整数据流，静态分析方法也难以奏效。

得益于大模型天然的代码理解和分析能力，将代码漏洞检测回归到语义层面理解，为代码片段的漏洞检测问题提供了新的契机。

三、大模型应用于片段代码漏洞检测的可行性探究

（1）利用大模型代码理解能力分析代码功能

CR场景下检测代码漏洞的基础是理解代码功能。以SQL注入为例，检测风险的关键是识别不合理的SQL语句拼接。然而变量命名、函数用法等在代码层面有各式各样的写法，单纯从语言规则层面难以辨别。

图3 大模型对各式各样的SQL代码拼接识别情况示例

利用大模型在代码理解方面的强大能力，可以正确识别此类代码功能。

（2）利用大模型上下文理解能力分析数据流

虽然代码片段缺乏项目级数据流，但我们依然需要基于代码片段的上下文，分析sink点信息是否会被外部可控。例如数据是否从安全的上下文中获取，或者代码片段中是否存在过滤函数等。

图4 利用大模型上下文理解能力分析数据流示例

利用大模型，可以准确捕获代码片段的上下文信息，并聚焦与漏洞相关的代码，规避误报，提高检测准确率。

四、基于大模型的CR场景代码漏洞检测落地实践

从上文可知，大模型的通用代码理解能力为代码漏洞检测提供了良好基础。接下来，具体介绍如何设计代码漏洞检测提示词，以更好地发挥大模型的能力。

（1）CoT提升大模型漏洞检测推理能力

借鉴思维链（Chain-of-Thought，CoT）思想，在提示词中给出漏洞检测详细且明确的推理过程示例，并引导大模型逐步分析。

图5 利用思维链提升大模型检测推理能力示例

由于大模型会将已输出的内容作为上下文的一部分，因此显式输出推理过程可以有效引导大模型得到正确结果，显著提升准确性。

（2）大模型与传统规则相结合

即使提供了详细的推理步骤，大模型还是存在偶发事实认定错误的情况。例如在明文账密场景，只有当账密直接暴露在代码中才有泄露风险，但大模型会偶发将变量识别成字符串常数，从而误判存在账密泄露。这种现象存在一定随机性，难以通过固定prompt模板彻底解决。起初尝试用规则消除这种随机性带来的误报，但在代码域难以用规则或正则全部枚举所有情况。因此，借助大模型的代码理解和生成能力，先让其将关键代码内容按指定模式输出，然后在固定模式下通过规则规避误报。

图6 大模型+传统规则实现明文密钥硬编码检测示例

（3）大模型输出结果结构化

如何让大模型输出结构化的结果是一个常见问题。在CR漏洞检测场景中，代码存在漏洞时需要向用户反馈结果，并提示漏洞所在具体代码行、漏洞类型、漏洞描述。因此，要求大模型反馈的信息较多且结构化要求高。初期尝试让大模型在每一部分加入指定前缀以便后续解析，但经常遇到不按指定格式输出——如增加换行、冒号等字符，或输出额外信息，导致解析失败。为解决这一问题，选择让大模型按JSON格式输出。JSON是通用的结构化数据，大模型经过广泛预训练可以很好地输出JSON格式，使结果更准确。

图7 大模型结构化输出示例

五、CR场景漏洞检测效果

经过多轮优化，漏洞检出准确率从26%提升至95%，提升69%；日均发现300个以上代码安全风险，能在代码上线前提前阻断风险。

图8 大模型应用于CR场景漏洞检测效果说明

典型案例1：成功检出某业务Web前端代码中存在AKSK硬编码。若直接发布到线上环境，黑客扫描网页即可获取相应AKSK，进而使用该账号下的所有资源，可能造成严重的数据泄露事故。

图9 Web前端代码中存在AKSK硬编码漏洞的危害说明示意图

典型案例2：某订单系统项目中，业务同学在提交代码时直接将上游变量拼接到SQL语句中，引入SQL注入漏洞，被模型成功检出。若该缺陷代码发布到线上环境，黑客可从客户端入口构造恶意输入，直接操作后端DB，窃取用户信息和订单信息，获取业务核心数据。

图10 订单系统代码中SQL注入漏洞的危害说明示意图

六、总结和展望

本文主要介绍了传统静态分析方法应用于CR场景漏洞检测的弊端，以及基于混元大模型底层技术和专家规则结合的方案在该场景的落地实践与提升效果。

在相关工作的落地过程中，还有很多问题值得进一步深入探索和解决。

（1）长上下文失焦问题

随着覆盖的漏洞种类增多，每种漏洞都需要在prompt中指定分析步骤，平均每个漏洞规则需要500+ token描述，加上用户输入的代码片段，进一步增加了上下文长度，这会导致大模型更容易遗忘CoT中的重要步骤，无法按预期推理，影响结果准确性。

解决思路：可以借鉴MoE模型的思路，针对多种多样的漏洞场景构建一个MoE模型，每个子模型单独解决一类漏洞问题，不仅减少上下文数量，还能针对不同漏洞针对性设计prompt和输出格式，更加灵活精准。

（2）大模型幻觉问题

幻觉问题是大模型落地过程中的常见问题，某些情况下大模型会无中生有、编造事实，影响结果准确性。虽然从整体来看发生概率非常低，但特定场景下不可避免。

解决思路：可以通过多模型投票方案解决。

（3）格式化输出的副作用

格式化输出会在一定程度上限制大模型的推理能力，从而影响CoT的效果。有研究人员提出，格式化输出和CoT兼容的方法是二次转换：先让大模型自由发挥，再将其生成结果转换成JSON格式。但这无疑会增加CR的整体耗时和大模型调用次数。

解决思路：可以调用两次模型：第一次不限制输出格式，提高准确性；第二次基于第一次输出的事实，做简单的总结和格式化输出，提高结果可用性。