💻 computer science

Residual Risk Analysis in Benign Code: How Far Are We? A Multi-Model Semantic and Structural Similarity Approach

该论文提出了一种结合语义与结构相似性分析的残存风险评分（RRS）框架，揭示了约 61% 的高分补丁代码仍包含 13 类潜在安全问题，证明了代码相似性可作为开源软件补丁后风险优先评估的有效信号。

原作者： Mohammad Farhad, Shuvalaxmi Dass

发布于 2026-04-24

📖 1 分钟阅读☕ 轻松阅读

原作者： Mohammad Farhad, Shuvalaxmi Dass

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文探讨了一个非常有趣且重要的问题：当我们给软件“打补丁”修复漏洞后，真的就万事大吉了吗？

想象一下，你家里的门锁坏了（这是漏洞），于是你叫锁匠来修。锁匠换了一个新锁芯，或者把锁舌稍微磨平了一点。现在门能正常开关了，看起来也安全了。但是，这扇门的整体结构、材质，甚至锁匠留下的指纹，可能还和原来那扇坏门一模一样。 如果坏人知道这扇门原来的弱点，他可能还是能找到办法撬开它，或者发现其他隐藏的风险。

这篇论文就是研究：怎么判断这个“修好”的门，到底还残留了多少原来的“坏味道”？

以下是用通俗语言和比喻对论文核心内容的解读：

1. 核心问题：修补后的“隐形风险”

在软件开发中，程序员发现漏洞后会打补丁（Patch）。通常，大家认为只要补丁打上了，代码就变“好”了（Benign）。

现实情况：为了快速修复，程序员往往只改一点点代码（比如加个判断条件），而代码的整体逻辑、结构几乎没变。
比喻：就像给一辆刹车失灵的车换了一个新刹车片。虽然刹车片好了，但这辆车的底盘、引擎甚至驾驶习惯可能还保留着原来的“危险基因”。如果只检查刹车片，可能会忽略其他潜在隐患。

2. 研究方法：给代码做"CT 扫描”

作者提出了一套叫 RRS（残留风险评分） 的新方法，用来给“修好”的代码打分。他们用了三个“探测器”：

A. 语义探测器（代码的“灵魂”）

工具：使用大型人工智能模型（Code LMs，像 CodeBERT）。
比喻：这就像让两个 AI 专家去读“坏代码”和“好代码”。如果两个 AI 觉得这两段代码的意思（灵魂）几乎一模一样，相似度高达 99%，那就说明虽然表面修了，但核心逻辑没变。
发现：大多数修复后的代码，AI 觉得它们和原来的漏洞代码长得太像了，几乎就是“双胞胎”。

B. 结构探测器（代码的“骨架”）

工具：使用 AST（抽象语法树）分析，特别是“局部”对比。
比喻：以前人们看代码结构，是拿整棵树比（比如看整栋房子的图纸）。如果只换了一个灯泡，按旧方法看，好像整栋房子都变了。
创新：作者只看被修改的那一小块（局部）。就像只检查换灯泡的那个角落。
发现：即使只改了一点点，代码的“骨架”大部分还是原来的样子。这种“局部相似”意味着原来的风险模式可能还残留着。

C. 共识探测器（大家的“投票”）

工具：让多个不同的 AI 模型一起看。
比喻：如果只有一个 AI 说“这两段代码很像”，可能是它看走眼了。但如果5 个不同的 AI 专家都异口同声地说“这两段代码太像了”，那这种相似性就非常可信。

3. 核心发现：61% 的“好代码”其实还有隐患

作者把那些“灵魂”和“骨架”都高度相似的代码挑出来，给了一个高分（高 RRS 分），意味着残留风险很高。

然后，他们把这些代码交给专业的“安全警察”（静态分析工具，如 Cppcheck, Clang-Tidy 等）进行严格检查。

结果惊人：在这些高分代码中，约 61% 被安全警察抓出了新的问题！
具体问题：比如空指针引用（就像试图打开一扇不存在的门）、内存泄漏（就像水管漏水没关紧）、缓冲区溢出等。
结论：这些代码虽然被标记为“已修复”，但实际上还留着很多“地雷”。

4. 为什么要这么做？（实际意义）

以前的做法：补丁一打，系统就认为安全了，直接上线。
现在的建议：不要盲目信任补丁。如果一段代码和原来的漏洞代码太像（高 RRS 分），说明它可能只是“打了一层创可贴”，内部可能还有大伤。
比喻：就像医生给病人做手术。如果手术只切除了表面肿瘤，但周围的组织还是坏死的，医生不能直接宣布“治愈”，而需要重点复查。RRS 就是那个提醒医生重点复查的警报器。

总结

这篇论文告诉我们：软件打补丁后，并不等于彻底安全。

很多时候，修复只是“修修补补”，代码的深层结构和逻辑依然保留着漏洞的“影子”。作者发明的这套 RRS 评分系统，就像是一个智能安检仪，能识别出那些“看起来修好了，但骨子里还带着危险”的代码，提醒安全人员去重点检查，防止它们变成未来的“零日漏洞”（Zero-day，即未被发现的新漏洞）。

一句话概括：别只看表面，代码的“旧习气”可能还在，我们需要一种新方法把它们揪出来。

1. 研究背景与问题定义 (Problem)

核心挑战：在软件安全领域，漏洞修复（打补丁）通常被视为将代码从“易受攻击”转变为“良性”的过程。然而，现有的漏洞基准测试往往假设修补后的函数是绝对安全的，忽略了**残留风险（Residual Risk）**的可能性。
现实困境：
- 开发者倾向于进行最小化、局部化的修复（如添加边界检查），而不是大规模重构。
- 这导致修补后的代码在**语义（Semantic）和结构（Structural）**上可能与原始漏洞代码高度相似。
- 这种高度相似性可能意味着潜在的漏洞模式（如空指针解引用、内存分配不安全）并未被彻底消除，从而埋下“零日漏洞”的隐患。
现有局限：传统的静态分析工具（SAST）和基于学习的漏洞预测框架很少量化补丁后代码的语义变化程度，难以区分“完全修复”与“仅修复了特定触发条件但保留了危险逻辑”的代码。

2. 方法论 (Methodology)

作者提出了一种名为 残留风险评分（Residual Risk Scoring, RRS） 的统一框架，旨在通过量化良性代码与原始漏洞代码之间的接近程度来评估残留风险。该方法结合了三种信号：

2.1 语义相似性 (Semantic Similarity)

技术：利用多种预训练代码语言模型（Code LMs），包括 CodeBERT, UniXCoder, GraphCodeBERT, CodeT5-base, CodeT5-770M。
实现：将漏洞函数 ( $f_v$ ) 和良性函数 ( $f_b$ ) 编码为向量嵌入（Embeddings）。
度量：计算向量间的 余弦相似度（Cosine Similarity）。
发现：大多数修补后的代码在语义嵌入空间中与原始代码高度相似（均值约 0.99），表明功能行为未发生根本性改变。

2.2 局部结构相似性 (Localized Structural Similarity)

技术：使用 Tree-sitter 构建抽象语法树（AST）。
创新点：摒弃了传统的全局树编辑距离（Global Tree Edit Distance, TED），因为全局 TED 会将未修改的大块代码视为整体替换，从而掩盖微小的关键修改。
实现：采用 局部树编辑距离（Localized TED, LTS），仅关注补丁引入的修改子树。
度量：计算归一化的局部结构相似度。
发现：补丁通常只引起极小的结构变化（局部 TED 相似度均值 0.82，中位数 0.93），证实了“最小化修复”的普遍性。

2.3 跨模型一致性 (Cross-Model Agreement)

目的：评估不同模型对相似性判断的一致性，作为表示鲁棒性的信号。
实现：计算多个模型输出的相似度的方差。方差越低，说明不同模型对“代码未发生本质变化”的判断越一致。

2.4 RRS 评分公式

最终评分 $RRS(f_v, f_b)$ 是上述三个信号的加权组合：
$RRS = \alpha \cdot \bar{S}_{sem} + \beta \cdot R_{struct} + \gamma \cdot C_{agree}$
其中：

$\bar{S}_{sem}$ ：多模型平均语义相似度。
$R_{struct}$ ：局部结构相似度。
$C_{agree}$ ：跨模型一致性得分。
$\alpha, \beta, \gamma$ 为权重系数（示例设置为 0.5, 0.3, 0.2）。

高 RRS 分数意味着代码在语义和结构上都与漏洞版本高度相似，且模型间共识度高，暗示存在较高的残留风险。

3. 主要贡献 (Key Contributions)

提出了 RRS 框架：首次形式化地通过表示层面的接近度（语义 + 结构 + 模型一致性）来量化良性代码中的残留风险。
揭示了局部 AST 分析的重要性：证明了局部 AST 分析比全局树指标更能准确捕捉补丁引起的细微变化，避免了全局指标对未修改区域的过度惩罚。
实证验证了 RRS 的有效性：利用最先进的静态分析工具（Cppcheck, Clang-Tidy, Facebook Infer）和人工审查，验证了高 RRS 分数确实对应着实际存在的潜在安全问题。

4. 实验结果 (Results)

研究基于 PrimeVul 数据集（3,789 对 C/C++ 漏洞 - 良性函数对）进行了实验：

RQ1（相似性保持）：
- 良性函数在语义上高度保留漏洞版本的特征（CodeBERT 平均相似度 0.9988）。
- 结构上，大多数补丁仅引入局部修改（局部 TED 相似度中位数 0.93）。
- 结论：补丁往往保留了原始代码的大部分语义和结构属性。
RQ2（风险估计的鲁棒性）：
- 将代码对分为四个象限。象限 I（高语义相似度 + 高结构相似度）占比约 29.5%，代表风险最高的区域（最小化修改）。
- 敏感性分析表明，RRS 在不同权重配置下表现稳定，高风险评估结果不依赖于特定的参数选择。
RQ3（静态分析验证）：
- 对高 RRS 分数的代码（象限 I）使用 Cppcheck, Clang-Tidy, Infer 进行扫描。
- 关键发现：约 61% 的高 RRS 函数被至少一个工具标记出安全问题（如内存安全违规、边界错误、空指针解引用等）。
- 其中，43% 被两个工具标记，27% 被三个工具同时标记。
- 人工验证确认了 13 类 不同的残留问题，包括未初始化变量、死存储、资源泄漏等。

5. 研究意义与结论 (Significance & Conclusion)

打破二元假设：挑战了“补丁即安全”的二元假设，指出修补后的代码可能仍保留危险模式。
提供优先级排序信号：RRS 并非旨在直接检测漏洞，而是作为一个**优先级排序（Prioritization）**信号。它帮助安全团队从海量补丁中筛选出那些“看似已修复但结构/语义变化极小”的代码，进行重点人工审查。
提升软件维护可靠性：在开源软件生态中，该方法为自动化补丁验证和残留风险评估提供了可扩展的解决方案，有助于防止零日漏洞的产生。
未来方向：计划将方法扩展到其他编程语言，并结合动态分析以进一步细化风险评估。

总结：该论文通过结合多模型语义嵌入和局部 AST 结构分析，证明了大量“良性”补丁实际上与漏洞代码高度相似，并提出了 RRS 指标来量化这种风险。实验表明，高 RRS 分数能有效预测静态分析工具能发现的潜在安全问题，为软件供应链安全提供了新的分析视角。