深度学习漏洞检测综述精读：数据、模型与评估复现

做漏洞检测这行的人，书架上迟早会摆上几篇综述，而深度学习方向的那篇（也就是标题里这篇）基本属于绕不开的一本。我第一次读它的时候正在给一个内部扫描工具做规则降噪，规则库越堆越长，误报压不下去，老板问我“能不能上模型”，我当时的回答是“能，但先得搞清楚别人踩过哪些坑”。这篇综述就是我用来回答那个问题的材料。后来顺手把它翻成了中文，翻的过程比读的过程收获更大，因为翻译逼着你把每一句话的逻辑都掰开——模型为什么这么选、数据集为什么这么造、指标为什么这么算，含糊过去的地方在中文里会立刻暴露出来。这篇东西写给三类人看：正在做代码安全工具、想引入深度学习但不知道从哪下手的人；要读这篇综述但英文长句啃不动、需要一份带解读的翻译参考的人；以及接了论文精读任务、想学一套可复用拆解方法的人。下面我会按照我自己的翻译笔记顺序，把这篇综述的核心脉络、技术取舍、以及翻译和复现过程中踩到的坑，一条一条摊开讲。

1. 先把这篇综述的定位搞清楚再动手

1.1 漏洞检测到底是个什么任务

很多人一上来就盯着模型结构看，这是最容易走偏的起点。综述第一章花了不少篇幅在定义任务，翻译到那段的时候我卡了很久，因为英文里“vulnerability detection”这个词覆盖的范围太宽了。落到工程上，它至少分成三种粒度：函数级、切片级、文件或提交级。函数级是把一个函数体当输入，输出“有漏洞/无漏洞”；切片级是先把与某个可疑变量相关的语句抽出来组成一个片段，再判断；提交级是拿一次代码变更（补丁前后的 diff）作为输入，判断这次改动是否在修漏洞。这三者看着只是输⼊长度不同，实际影响的是整个数据管线的形态——函数级需要按函数切分源文件并处理宏和条件编译，切片级需要做程序依赖分析，提交级需要把版本库的提交历史拉下来做配对。综述在这一点上其实交代得比较克制，它默认读者知道这些前置工作有多脏，所以我在译注里补了大段说明，因为这是实操中最耗时间的部分，比调模型久得多。

还有一个必须澄清的点：这里的“检测”是二分类，不是定位。真正的漏洞定位要指出具体哪一行出了问题，那是另一个任务，评估方式也完全不同。综述里提到的一些工作会顺带做行级注意力可视化，但那是解释性副产品，不是任务定义的一部分。我在翻译时专门加了一句注：如果下游要用这个结果给人看，二分类的“这个函数有漏洞”几乎没有可操作性，工程师会问你到底哪一行，这时候要么再上一层切片，要么换任务。这个认知差在落地阶段造成的返工非常多，值得在开头就说清楚。

1.2 深度学习为什么会被拉进来

传统静态分析的核心是规则和模式匹配，优点是路径明确、可解释，缺点是写规则的人和写代码的人永远在赛跑。规则库要靠人工总结漏洞模式，新漏洞出来之后才补，天然滞后；而且规则一多，误报就上来了，工程师看多了就麻木，最后工具形同虚设。综述里反复提到的动机就来自这里：代码里存在大量“语义上的坏味道”，很难用一条正则或者一个数据流规则表达出来，但人看一眼就知道不对劲，这种模糊的模式匹配正是神经网络的强项。

但这里有个容易被忽略的前提：深度学习不是替代静态分析，而是在它之上做一层筛选。我自己的实践感受是，模型最适合的位置是“二次过滤”——先让规则跑一遍把候选集从几万个函数压到几千个，再用模型排序，人只看前几百个。综述里有些工作确实尝试过端到端全量扫描，但很少有人真的把这套东西放到每天几十万次提交的流水线上跑，因为推理成本和上下文缺失的问题绕不过去。翻译那几段的时候我特意保留了作者对“端到端可行性”的谨慎表述，没有为了行文顺畅把它译成肯定的语气，这一点在译稿里很重要——综述作者的语气强弱本身就是信息。

1.3 综述的组织逻辑与阅读顺序

这篇综述的骨架其实是一条很清晰的流水线：数据从哪来、代码怎么变成向量、模型怎么设计、结果怎么评、还有什么没解决。作者的分类维度主要落在“代码表示”和“模型家族”两个轴上，前者决定输入形态，后者决定学习方式。这个二维分类法我建议翻译时原样保留，因为后面所有对比表格都是按这个框架排的，一旦为了中文顺畅把归类打散，读者就再也对不上原表的行和列了。

我自己的阅读顺序和作者的行文顺序是反的。作者从背景讲起，先讲传统方法再讲深度学习，我是先跳到最后的挑战与展望章节，把那几条“还没解决”读完，再回头按需看中间的模型部分。原因是这个领域的工作迭代太快，综述写作时的新方法到出版时可能已经不算新了，但“没解决的问题”通常更长寿。翻译时我也按这个顺序组织译注：在展望章节标注哪几条到今天依然成立，在模型章节标注哪些对比已经过时。这种带时效标注的译稿，比纯译文有用得多，也更容易在自己写东西时被引用。

2. 数据与标签：综述里最容易被翻过去的一章

2.1 合成样本与真实样本的取舍

综述在数据集这一节的对比表格信息密度极高，也是我翻译时花时间最多的地方。它把数据来源大致分成两类：一类是通过人工往安全代码里注入缺陷生成的合成样本，另一类是从真实项目的修复提交里挖出来的样本。前者数量大、标签干净、可控性强，你想造多少有多少，还能指定缺陷类型；后者贴合真实分布，但噪声大、正负样本极不均衡、标签依赖提交信息与代码变更的对应关系，很多时候还得靠启发式规则去推断。

这个取舍在工程上是有明确答案的：预训练和消融实验用合成数据，最终评估一定要用真实数据。原因是合成样本的注入方式往往带着强烈的“模式痕迹”，模型很容易学到“只要看到这种奇怪的写法就是漏洞”，而不是学到真正的语义缺陷。我做过一个很小的验证实验：在一个纯合成集上训练，测试集换成一个真实项目集，F1 直接从 0.87 掉到 0.3 出头，掉得毫无悬念。综述里对这类“跨分布泛化”的讨论散在各处，我在译稿里把它们集中到了数据集一节的末尾，做成一个小结，方便后来人一眼看到。

还有一点必须提：真实数据集的正负样本比例通常在 1:10 到 1:50 之间，有的项目甚至更极端。综述里多数工作对这一点处理得很轻描淡写，实际做的时候如果直接按原始比例训练，模型会学成“永远输出无漏洞”，准确率高达 97%，然后什么用都没有。这也是为什么综述在评估章节特别强调不能只看准确率——这句话在中文里看起来很平，但在实操中它是保命的。

2.2 标签是怎么造出来的

这一点综述讲得不深，但对复现至关重要，我在译注里补写了一大段。真实数据的标签构造通常走这样一条链路：先从版本库拉提交记录，用提交信息里的关键词做初步筛选，再把变更前后的代码配对，然后用“修改前有缺陷、修改后无缺陷”这个假设生成正负样本。这条链路每一步都有漏洞：关键词筛选会漏掉不用标准写法的提交，也会把只是重构的提交误判为修复；变更配对在跨文件移动代码时会错位；最要命的是“修改前有缺陷”这个假设本身并不总是成立，很多提交只是改了个日志或者加了个判空，严格说算不上安全缺陷。

所以当你看到某个工作在某个数据集上刷到 0.95 的 F1，第一反应不该是“这个模型强”，而是“标签有多干净”。综述里引用的若干对比结果差异巨大，一部分原因就来自这里——不同工作用的标签构造规则不一样，横向比较的意义有限。我在翻译那几张对比表时，在每个表下面加了一行小字注，说明各行的数据来源和标签构造方式可能不同，不建议直接比数值。这种注释在正式译文里显得啰嗦，但在自己的笔记版里非常必要。

2.3 数据泄漏检查必须自己做

综述在方法论部分提到了数据划分的问题，但没有把它提到应有的高度。实际情况是，这个领域里相当一部分“高指标”来自数据泄漏：同一个函数的不同版本被分到了训练集和测试集，或者同一个项目的相似代码同时出现在两边。函数级划分最容易出这个问题，因为一个项目里的函数风格高度一致，模型学到的可能只是“这个项目的代码长这样”。

我在复现时固定用三步检查：第一步按项目去重，同一个仓库的所有样本只能落在同一个划分里；第二步做近似去重，把函数体做归一化（去注释、去空白、变量名统一替换）之后算哈希或者相似度，超过阈值的只留一个；第三步按时间切分，用较早的提交训练、较晚的提交测试，模拟真实部署场景。这三步做完，指标通常会掉一大截，但掉完之后剩下的数字才是可信的。综述里有一小段提到了时间切分，我把它扩写成了译注里的独立小节，因为这是从“论文指标”走向“能用”的分水岭。

提示：如果你正在评估别人的开源模型，先看它的数据划分脚本，而不是看它的模型代码。划分方式决定了指标天花板，模型结构只决定你能不能摸到那个天花板。

3. 代码表示与模型结构：综述的主干部分

3.1 从 token 序列到图结构

综述把代码表示按信息丰富度排了一条线：原始 token 序列、抽象语法树、控制流图、程序依赖图，以及它们的组合。这条线的逻辑很好理解——越往后，保留的语义结构越多，模型能利用的先验越强，但预处理成本也越高，而且信息损失的风险并没有消失，只是换了个位置。

token 序列最简单，把源码当自然语言处理，词法分析之后直接送进网络。优点是管线短、通用性强、对任何语言都能用；缺点是丢掉了括号匹配、作用域、控制流这些结构信息，模型只能靠位置和共现去猜。抽象语法树把结构补回来了，但树是非欧几里得结构，必须用能处理树的方法，早年的做法是把树序列化成路径或者用递归网络，前者丢信息，后者不好并行。控制流图补的是执行顺序，程序依赖图补的是数据依赖和控制依赖，这两个图对漏洞检测尤其关键，因为大量漏洞本质上是“污染数据没有经过检查就流到了危险操作”，这正是依赖图上的一条路径。

我在翻译这一节时最大的感受是，作者对“哪种表示更好”其实没有给结论，只是把各自的适用场景摆出来。这符合综述的定位，但读者容易看完仍然不知道选哪个。我的经验判断是：如果你的目标是快速搭一个能跑的基线，token 序列加大规模预训练模型性价比最高；如果你要做的是特定类型的缺陷（比如资源泄漏、越界访问），依赖图带来的收益明显更大，因为它直接对应缺陷的成因；如果团队里没人能维护图构建管线，那就别碰，因为解析失败率在真实项目上会让你怀疑人生。

3.2 几类主模型的定位差异

综述按模型家族分了几类：卷积类、循环类、图神经网络类、以及基于注意力机制的预训练模型。这个分法今天看有点过时，但用来理解演进脉络仍然清楚。

卷积类的思路是把代码当成一维序列做局部特征提取，感受野有限，擅长捕捉相邻几行之间的模式，比如“分配之后没有释放”这种局部结构。它的优势是训练快、参数少、对小数据集友好，缺点是抓不住长距离依赖。循环类补的正是长距离依赖，早年的工作把函数体按行或者按 token 送进 LSTM，让它自己学什么时候该记住前面的检查、什么时候该忘掉。问题是代码的长度分布极不均衡，几百行的函数很常见，循环网络在长序列上的衰减非常明显，而且训练慢。

图神经网络类是把前面说的那些图结构真正用起来的方法，节点是语句或者变量，边是控制流或数据依赖，信息沿边传播。这类方法在理论上最贴合漏洞的成因，实际效果在多项对比中也更稳，代价是图构建的质量直接决定上限，解析器在宏密集或者模板密集的代码上经常崩。注意力类的方法近年占了主流，核心思路是先在大规模代码语料上做自监督预训练，再在下游任务上微调。它吃的是 token 序列，但通过预训练获得了远超数据集的语义先验，在小样本场景下优势明显。综述写作时这类方法刚兴起，篇幅不多，我在译注里补了一段现状说明，提醒读者不要按综述里的占比去判断今天的重要性。

3.3 表示与模型的匹配关系

这一节是我在译稿里额外加的，原文没有单独成节，但分散在各处的信息合起来能得出一个很实用的判断：表示和模型必须匹配，错配是很多实验失败的隐形原因。你把图结构序列化成一串节点标签喂给卷积网络，等于把结构信息扔了还多付了构建成本；你把纯 token 序列喂给图网络，就得先造出一张毫无意义的完全图，训练必然发散。

我整理了一张对照表放在译注里，用来快速判断一个方案是否自洽：

这张表不是从综述里抄的，是我按自己的实验记录整理的，放上来是为了让读综述的人有个落点。综述的价值在于把地图画出来，但地图不告诉你哪条路能走通，这部分只能靠自己的实验补。

4. 评估协议：数字背后的门道

4.1 指标选择为什么影响结论

综述在评估章节列了一串指标：精确率、召回率、F1、AUC、MCC 等等。翻译这一段时我特意保留了每个指标的公式，因为在中文语境里很多人把它们混着用。这里的关键不是公式本身，而是每个指标对类别不平衡的敏感度完全不同。精确率和召回率是一对矛盾体，单看任何一个都能做出漂亮数字；F1 是调和平均，对少数类更敏感一些，但仍然掩盖了阈值选择的问题；AUC 衡量的是排序能力，和阈值无关，在极度不平衡时容易虚高，因为它把大量容易判负的样本也算进了分母；MCC 同时考虑四个混淆矩阵格子，在不平衡数据上最保守，也最能反映真实水平。

我的建议是报告至少三个：F1、MCC、以及固定误报率下的召回率。最后一个最贴近工程实际，因为用的人关心的是“给我一百条告警，里面有几条是真的”，这个问题的答案就是精确率，而工具能不能用取决于在可接受的精确率下能捞回多少真漏洞。综述里多数工作只报 F1 和准确率，这是学术惯例，但落地时不够用。我在译稿的评估章节末尾加了一段说明，解释了为什么工程侧要额外看固定误报率下的召回，这段注解后来被同事引用得最多。

4.2 划分方式与结果可信度

前面提过数据泄漏，这里从评估角度再讲一次，因为它是综述里最容易被低估的部分。同一个数据集，随机划分和按项目划分能差出二三十个点的 F1，按时间划分往往还要再降。综述在对比不同工作时，很少去核对各家的划分方式是否一致，所以那些横向对比表读的时候要打折扣。

我在复现实验里固定用三套划分同时报数：随机划分、按项目划分、按时间划分。三套数字放在一起看，能立刻判断一个模型是真学到了语义，还是只记住了项目风格。随机划分高、项目划分低，说明模型在记项目特征；项目划分也高、时间划分低，说明模型对代码风格的演化不鲁棒；三套都还不错的，才值得继续投入。这套做法成本不高，但能省下大量在错误方向上优化的时间。综述里提到过跨项目评估的重要性，只是没有给出这么具体的操作建议，这部分属于我自己的补充。

4.3 最小可复现实验该怎么搭

综述读完最容易产生的冲动是“我也要搭一套”，然后一头扎进图神经网络和依赖分析里，两周之后连数据管线都没跑通。我的建议是先做一个最小闭环：选一个中等规模的真实数据集，按函数级切分，用 token 序列加一个轻量模型跑通全流程，指标不用好看，能端到端跑起来就行。这个闭环的价值在于让你把所有脏活都过一遍——源码解析、函数抽取、标签对齐、划分、训练、评估、报告，每一环都会暴露问题，早暴露早解决。

跑通之后再做增量：先把模型换成更强的预训练模型，看指标涨多少；再把输入换成切片或者加图结构，看涨多少；每次只改一个变量。我在做这个对比时的记录是，从轻量模型换到预训练模型带来的提升最大，从 token 换到图结构带来的提升在特定缺陷类型上明显、在整体指标上反而没那么突出，而且工程复杂度上升了一个量级。这个结论不一定普适，但至少说明“先上大模型再上图结构”是一条更划算的路径，和很多人的直觉相反。

5. 翻译这篇综述的完整实操流程

5.1 术语表先行，别边翻边定

这是我翻任何技术长文的第一条铁律。综述里反复出现的核心术语有十几个，如果每次遇到都临时决定译法，最后整篇的用词一定是乱的。我的做法是先通读一遍目录和摘要，把这批高频术语抽出来，做成一张三列的对照表：英文原词、中文译法、首次出现时的简短释义。译法一旦定下来，全文统一，包括图表标题和注释。

举几个我当时的取舍：把“representation”统一译成“表示”而不是“表达”，因为后面要跟“代码表示”这个固定搭配；“slice”译成“切片”，但在首次出现时注明它指的是按依赖关系抽取的语句子集，避免读者误解成数组切片；“ground truth”译成“标注真值”，比“地面真相”这种直译可读得多。还有一类词要小心，就是作者自己造的分类名，这类词千万别意译得太花哨，保留英文原词加括号注是最稳的做法，因为读者可能需要拿这个词去检索原文。

5.2 长句拆解的固定套路

英文学术写作喜欢用长定语从句加嵌套，一句话能套三层。直译过来就是灾难。我用的方法叫三段式：先找主干（谁做了什么），再把修饰成分拆成独立的短句，最后按中文的因果或时间顺序重排。举个抽象的例子，原文可能是“A method, which leverages B to capture C, is proposed to address D”，直译是“一种利用B来捕获C的方法被提出以解决D”，读起来很别扭。拆开就是“针对D这个问题，有工作提出了一种方法。它借助B来捕获C。”两句话，信息一点没少，可读性完全不同。

还有一类句子要特别处理：作者表达谨慎态度的句子，比如“may”“suggest”“appear to”这类词。这类词在学术写作里承载的是作者的判断强度，翻译时如果一律译成肯定语气，就把作者的保留意见抹掉了。综述类文章的价值恰恰在于这种分寸感，所以我在这类地方会刻意保留“可能”“倾向于”“目前看来”这样的表述，宁可中文显得啰嗦一点。

5.3 图表和公式的处理方式

综述里的表格信息量往往比正文大，翻译表格的难度也更高，因为单元格里塞的都是压缩过的短语。我的原则是表格里的术语必须和正文完全一致，不能为了省空间换同义词。另外原表里的缩写要展开，中文读者不一定熟悉那些缩写，第一次出现时补全，后面再用缩写。

公式部分我保留了原始符号，只在第一次出现时加中文解释，说明每个符号代表什么、取值范围是什么。强行把符号改成中文变量名是自找麻烦，因为后面的对比表会引用这些符号。至于流程图，综述里通常有整体的框架图，这类图不要试图用文字复刻，在译稿里保留原图的位置说明即可，然后用一段文字解释这张图想表达的分类逻辑，比硬画一张图有用。

5.4 校对的三个动作

译完之后我做三遍不同目的的检查。第一遍只看术语一致性，用查找替换的方式确认每个核心术语全篇只有一种译法；第二遍只看数字和引用编号，确认表格里的数值、文中的引用标号和原文一一对应，这一步最容易出错，因为改句子的时候经常不小心把编号带跑；第三遍出声读一遍，凡是读起来需要回头的句子全部重写。

第三遍听起来很土，但效果最好。中文技术写作的通病是句子太长、修饰语堆在前面，出声读会立刻暴露这些问题。我自己的经验是，出声读一遍能砍掉三成左右的冗词，而且能发现那些“看起来通顺但逻辑不通”的句子，这类句子只有读出来才会觉得别扭。翻完这篇之后我把这套流程固定下来了，后面翻别的长文效率明显提高。

6. 常见问题与排查速查表

6.1 指标虚高的几种典型来源

这是我在复现和评审里见得最多的问题，按出现频率排一下。第一种是数据泄漏，前面讲过了，症状是随机划分和项目划分差距巨大。第二种是标签噪声，症状是模型在训练集上收敛很快但验证集震荡，且人工抽查发现大量标错的样本。第三种是负样本采样偏差，为了让训练集平衡而随机丢弃负样本，结果测试时用的还是原始分布，指标自然虚高。第四种是阈值调优泄漏，在测试集上挑最佳阈值再报指标，这是最常见也最隐蔽的一种，正确做法是在验证集上定阈值。第五种是重复样本，同一段代码经过轻微的格式修改后同时出现在训练和测试里。

排查顺序我建议从后往前：先做去重，再检查划分，再抽查标签，最后才怀疑模型。因为模型出问题的概率远低于数据出问题，而数据问题的排查成本又远低于调模型。综述里对这几点的讨论是分散的，我把它整理成了一张速查表，放在译稿附录里，自己也一直在用。

6.2 翻译和阅读中最容易误解的表述

有几处我在翻译时反复推敲过，值得单独提。第一处是综述里对某类方法“有效”的描述，英文里“effective”和“efficient”经常挨着出现，前者说的是效果，后者说的是效率，中文里都容易译成“有效”，但含义完全不同，译错会误导读者对方法定位的判断。第二处是“scalable”，这个词在论文里通常指能处理大规模数据，不是“可扩展”，译成“可扩展”读者会以为说的是架构。

第三处是作者在总结某类工作时用的“however”，这个转折后面往往跟着该方法的关键局限，是全文最有价值的信息之一，翻译时不能为了句子顺而把它弱化或者挪走。第四处是数据集描述里的“balanced”和“imbalanced”，这两个词直接决定了实验设置，译文中必须保留并加粗。这些细节单看都不起眼，但它们决定了读者能不能从综述里读出真正有用的判断。

6.3 落地时的一份检查清单

最后给一份我自己每次启动新项目都会过一遍的清单，和综述里的挑战章节基本对得上，但更偏操作层面。

• 数据来源是否明确，合成还是真实，比例多少，标签怎么造的
• 划分方式是否做了项目级去重、近似去重、时间切分三件事
• 代码表示是否和模型匹配，有没有为了用图而用图
• 评估指标是否包含 MCC 和固定误报率下的召回
• 阈值是否在验证集上定的，有没有在测试集上调过
• 推理耗时是否可接受，单次扫描的延迟和吞吐量测过没有
• 有没有留出人工复核的接口，模型输出能不能解释到具体的代码片段
• 版本管理是否完整，数据、配置、模型权重能不能复现出同一个数字

这几条里，最容易漏的是最后一条和倒数第二条。前者决定了你三个月后还能不能解释当时的结论，后者决定了这个东西到底能不能交到工程师手里。综述里对可解释性和工程可用性的讨论放在了展望部分，语气比较轻，但从落地的角度看，这两点比再涨两个点的 F1 重要得多。

最后分享一个我自己反复验证过的判断：读这类综述，收益最大的部分往往不是模型章节，而是数据章节和评估章节。模型部分一年半载就会过时，但“数据怎么造、标签怎么来、指标怎么算、划分怎么做”这些东西是稳定的，而且是决定一个方案能不能落地的真正变量。我翻译这篇的时候，模型章节的译注写得最少，数据和评估两章的译注写得最多，后来回看，那部分确实是用得最多的。至于综述最后提到的那些开放问题，比如跨项目泛化、标签自动清洗、模型决策的可追溯性，到今天依然没有标准答案，谁能在自己的场景里把它们啃下来一小块，谁的东西就真的能用。