大模型应用实践：AI 助力 Code Review 安全漏洞发现

大模型应用实践：AI 助力 Code Review 安全漏洞发现

文章摘要

隐藏在代码中的安全漏洞如同一条通往业务核心数据资产的隐秘通道，极易被黑客盯上和利用。及时识别和修复代码漏洞对防止黑客入侵和数据泄露至关重要。

借助混元大模型，腾讯云 AI 代码助手与代码安全团队合作，推出代码评审（Code Review，下文简称CR）之安全漏洞检出能力，可极大提升公司核心数据资产安全性。

背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

即使提供了详细的推理步骤，但是大模型还是存在偶发事实认定错误的情况。例如在明文账密的场景，只有当账密直接暴露在代码中，才有泄露风险。但是大模型会偶发识别错误，将变量认定成字符串常数，从而认为存在账密泄露问题。

这种现象存在一定随机性，难以通过固定 prompt 模板彻底解决。起初，我们尝试利用规则的方式消除这种随机性带来的误报。然而在代码域难以用规则或正则全部枚举所有情况。

因此我们借助大模型的代码理解和生成能力，先让大模型将关键代码内容按照指定模式输出，然后在一个固定模式下，通过规则规避误报情况。

如何让大模型输出结构化的结果是一个常见的问题。

在 CR 漏洞检测场景中，我们在代码存在漏洞的情况下，需要向用户反馈结果，并提示漏洞所在具体的代码行、漏洞类型、漏洞描述。由此可知，CR 场景要求大模型反馈的信息较多且结构化要求高。

初期我们尝试了让大模型在每一部分加入指定前缀，便于后续内容解析，但是经常遇到大模型不按指定格式输出的情况。如：增加换行、冒号等字符，输出格式外的额外信息等，最终导致解析失败。

为了解决这一问题，我们选择让大模型按照 json 格式输出。由于 json 是一种通用的结构化数据，大模型经过广泛的预训练可以很好输出 json 格式数据，使得输出结果更加准确。

CR场景漏洞检测效果

经过多轮优化，漏洞检出准确率提升 69%（26%->95%)，日均发现 00+个代码安全风险，可起到在代码上线前提前阻断风险的效果。

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

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

典型案例 ：非安全扫描案例，但同样的，对代码文件扫描出空指针异常、哈希算法优化、代码逻辑优化空间成功检出。在实际用法中，我们将安全扫描和代码评审封装成 “/cr” 命令，使大模型能力更加综合，用法更加高效。

总结和展望

本文主要介绍了传统静态分析方法应用于 CR 场景漏洞检测的弊端，以及基于混元大模型底层技术和专家规则结合的方案在该场景的落地实践和提升效果。基于大模型技术为 AI 智能代码评审带来了新的机遇与挑战，腾讯 AI 代码助手团队和 CR 团队基于腾讯集团开发人员与腾讯云广大开发人员/企业客户的 MR/CR 场景，结合大模型技术推出了智能代码评审解决方案，即在腾讯云 AI 代码助手，可以实现智能评审意见生成、代码问题 AI 评审修复意见生成等功，全面助力广大开发人员提升评审效率与代码质量。

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

长上下文失焦问题

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

解决思路：

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

大模型幻觉问题

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

解决思路：

幻觉问题可以通过多模型投票方案解决。

格式化输出的副作用

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

解决思路：

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