开源风险治理平台“伏羲”在安全补丁迁移中取得重要进展，助力开源软件安全风险缓解

研究背景：安全补丁迁移是开源软件供应链风险缓解的重要手段

随着开源软件的广泛应用，越来越多的软件系统依赖开源组件、复用开源代码，并基于上游项目形成多个长期维护分支或下游衍生项目。当上游项目披露漏洞并发布安全补丁后，相关补丁是否能够及时、准确地迁移到其他受影响分支或下游衍生项目中，直接关系到开源软件供应链的整体安全水平。

然而，在真实开源生态中，安全补丁的迁移既不全面也不及时。一项针对26个流行开源项目、806个 CVE 的实证研究表明，超过80%的CVE-分支对从未完成补丁迁移；在这些未修复漏洞中，47.39%属于高危或严重漏洞；即使最终完成修复，平均也需要 40.46 天。更值得关注的是，约20%的漏洞已经存在公开PoC，这意味着攻击者可以在补丁尚未迁移到受影响分支或下游项目之前，利用已公开信息实施攻击 [1]。

针对安全补丁难以及时迁移的问题，学术界和工业界已经开展了一系列研究。现有自动化补丁迁移技术大致可以分为两类：基于模式匹配的方法和基于大模型的方法。

第一类是基于模式匹配的补丁迁移方法。例如FixMorph [2]和TSBPORT [3]通过分析历史补丁，总结补丁修改模式，并在目标分支中寻找相似代码位置进行补丁适配。这类方法在处理结构相对稳定、修改模式较为明确的补丁时具有较好效果，但其能力高度依赖预先定义或学习到的补丁模式。当目标分支与原始分支之间存在较大语法结构差异、控制流重构或辅助函数变化时，模式匹配方法往往难以准确完成迁移。

第二类是基于大模型的补丁迁移方法。例如PPatHF [4] 尝试利用大语言模型理解源分支与目标分支之间的代码差异，并自动生成适配目标分支的补丁。相比传统模式方法，大模型具备更强的代码理解和生成能力，能够处理更加灵活的代码变化。然而，现有大模型方法为了压缩上下文而进行的预处理可能删除与漏洞相关但未被修改的关键代码；此外，PPatHF的大模型微调任务与真实补丁迁移任务不匹配，导致跨项目泛化能力受限；同时缺少有效的自动检查机制，模型生成的补丁一旦出现语义偏差或语法错误，难以及时发现和修正。

为了更直观地说明目前工作在安全补丁迁移中的局限，我们选取了两个真实漏洞补丁迁移案例进行分析。第一个案例来自OpenSSL 中的CVE-2023-0465。如图一所示，该漏洞源于check_policy函数对EXFLAG_INVALID_POLICY标志处理不当，可能导致证书链校验中的安全绕过。主分支中的原始补丁新增了针对异常策略标志的检查逻辑和错误处理逻辑，但当该补丁迁移到OpenSSL_1_1_1-stable分支时，由于两个分支在错误处理方式和控制流结构上已经存在差异，直接使用git cherry-pick会产生冲突，无法完成自动迁移。进一步地，基于模式的补丁迁移工具TSBPORT [3]虽然尝试生成目标分支补丁，但由于过度依赖预定义修改模式，错误地插入了重复检查，并将错误处理逻辑适配到不正确的条件分支中，最终破坏了原有校验流程，使函数无法按预期返回成功结果。该案例说明，安全补丁迁移不能只依赖局部代码块的语法模式匹配；当分支之间存在函数级语义差异时，工具必须理解漏洞修复逻辑与目标分支上下文之间的对应关系。

图一 CVE-2023-0465示例，（a）为master分支补丁，（b）（c）分别是由人类开发者和TSBPORT将master分支的补丁迁移到OpenSSL_1_1_1-stable分支的迁移补丁

第二个案例来自Wireshark中的CVE-2023-1994。如图二所示，该漏洞位于dissect_gquic_frame_type函数中，当指针gquic_info为空时，后续代码仍会将其传入被调用函数并访问其中字段，从而可能导致拒绝服务。人工补丁的核心修复非常直接：在使用gquic_info 之前增加空指针检查；并且该补丁在主分支和 release-3.6 分支中几乎一致，git cherry-pick和TSBPORT [3] 都能够成功迁移。然而，基于大模型的PPatHF [4] 反而迁移失败。其原因在于，PPatHF为压缩上下文会将未修改的复合代码块替换为占位符，但这一过程同时删除了与漏洞触发密切相关的关键调用语句；随后模型又错误移动了占位符位置，导致人工补丁中应出现的空指针检查没有正确生成；最后在恢复占位符对应代码后，生成结果同时出现语法错误和语义错误，危险的空指针使用仍未被修复。该案例说明，大模型具备代码生成能力并不意味着可以直接可靠地完成补丁迁移；补丁迁移仍然需要显式保留漏洞相关语义、对齐真实迁移任务，并对生成结果进行语法和语义层面的检查。

图二 CVE-2023-1994示例，由人类开发者（绿色部分）和 PPatHF（红色部分）在release-3.6分支中对dissect_gquic_frame_type函数进行补丁迁移

研究进展：基于语法语义增强大模型的自动化安全补丁迁移工具Mystique

为了解决安全补丁在多分支和上下游开源生态中难以及时迁移的问题，复旦大学CodeWisdom团队软件供应链安全小组在开源风险治理平台“伏羲”中进一步拓展了安全补丁治理能力，提出了自动化安全补丁迁移技术Mystique。相关研究成果发表于FSE 2025 [5]，并获得ACM SIGSOFT杰出论文奖。Mystique的核心思想是：面向安全补丁迁移任务，首先精准抽取漏洞修复相关的语义信息和语法结构，其次利用任务对齐的大模型进行补丁初步迁移，最后通过自动检查与迭代优化机制提高迁移结果的可靠性。如图三所示，该技术框架主要包括五个模块。

图三 Mystique整体框架图

（一）补丁函数语义与语法签名提取模块。该模块利用Joern生成代码属性图（CPG），针对增删的语句执行双向的数据依赖切片以及控制流切片（提取直接支配和后验支配语句）。然而，单纯的依赖切片会破坏代码的语法闭环，因此Mystique引入Tree-sitter构建抽象语法树（AST），对切片后的孤立片段进行严格的语法补全。这包括向上追溯并补全控制语句（如if、switch及对应的case）、补齐程序出口和跳转点（如break、return、goto）以及补全缺失的控制流大括号，从而生成既包含丰富语义又具备完整层级结构的特征名和。

（二）目标漏洞函数语义与语法签名提取模块。目标分支的代码通常已发生演进，变量名或逻辑可能已发生改变，因此直接套用原补丁往往会失效。该模块首先需要建立精准的语句映射。Mystique首先在该模块中计算补丁中删除的语句与目标漏洞函数中各候选语句的莱文斯坦距离（Levenshtein distance），当文本及结构相似度超过预设阈值（默认设为 0.55）时，建立候选映射。若直接匹配失败，会沿控制流迭代搜索支配和后验支配语句，以圈定大致的漏洞代码块。定位完成后，Mystique会对映射语句执行与模块一相同的CPG切片与AST语法补全流程，最终输出目标分支的漏洞特征名。

（三）补丁迁移提示词生成模块。该模块负责将提取的结构化签名转化为大模型易于解析的提示词。为了有效降低长上下文的Token消耗并直观凸显补丁前后的变更逻辑，Mystique将补丁签名巧妙地转化为类似git diff的格式，表示为 。更重要的是，提示词模板中植入了四项硬性约束指令（C1-C4）：

- C1 强迫模型对补丁进行必要的环境适配；

- C2 限制模型不得进行与漏洞无关的修改，以防破坏原有功能分支的特性；

- C3 严禁模型增删或移动用于掩盖无关代码的“占位符”（Placeholders）；

- C4 警告模型切勿自行填充缺失的代码片段，以此规避幻觉带来的潜在语法错误。

（四）面向补丁迁移任务的大模型微调模块。为了使开源大模型（如CodeLlama）真正掌握跨分支移植的内在规律，Mystique摒弃了常规的代码生成预训练范式，转而构建了专门针对移植任务对齐的微调数据集。Mystique从历史真实项目中提取出时间跨度较长、针对同一漏洞的“原补丁-目标补丁”函数对，提取其签名组合 。在训练阶段，模型采用低秩自适应（LoRA）技术，将庞大的模型权重分解为低秩矩阵以极大降低显存开销。模型以生成正确的目标后置签名为监督信号，通过 AdamW优化器不断最小化损失函数 ，确保微调后的模型能力与复杂的补丁移植任务深度契合。

（五）修复函数生成与迭代检查。即便经过定向微调，大模型仍不可避免地会产生逻辑谬误或语法瑕疵，因此该模块引入了基于启发式规则的“生成-检查-优化”闭环。模型首先生成初始签名，随后Mystique利用三道防线执行严格的异常拦截：

- 语义异常（A1）：Mystique分别计算补丁前后的演进差异与的编辑辑距离。若两者差距超过阈值（如 ），Mystique即可判定模型发生了“过度修复”（破坏了目标分支逻辑）或“修复不足”（未有效移植漏洞逻辑）；

- 占位符异常（A2）：Mystique通过AST锚定各个占位符的父子兄弟节点，以此核对模型是否在生成过程中非法挪动或删除了占位符；

- 语法异常（A3）：Mystique将占位符背后的真实代码块复原为完整的初始修复函数，并调用强类型的静态分析工具Clang-tidy进行编译级的语法纠错；

实验评估：Mystique在安全补丁迁移任务上的准确性与实用性

我们在694个CVE/1,359个漏洞函数上做了系统评测，对比对象包括2个模式方法（FixMorph、TSBPORT）、1个LLM方法（PPatHF）、4个通用大模型（GPT-3.5、GPT-4o、CodeLlama、StarCoder）。

工具有效性评估：如表一所示，在针对694个CVE（包含 1,359 个漏洞函数）的大规模基准测试中，Mystique展现出了卓越的补丁迁移能力。在函数级别（Function Level）和CVE级别，Mystique分别达到了0.954和0.924的修复成功率（Success Rate）。这一成绩显著超越了现有的最优方法，相比于基于模式匹配的先进工具TSBPORT，其在函数级和CVE级的成功率分别提升了13.2%和12.3%；而相比于直接使用顶尖的闭源大模型GPT-4o，其在函数级也高出18.5%。即使在少数迁移失败的案例中，Mystique生成代码的Code BLEU（C-B）得分也达到了0.921（为所有对比工具中最高），这说明其失败的输出与人类真实补丁的相似度依然极高，具备很好的参考价值。

表一 Mystique有效性实验结果

工具泛化性评估：如表二所示，Mystique在四个不同维度上证明了其强大的泛化能力。当替换底层的LLM（如换为StarCoder）、进行跨项目迁移（在 Linux 和其他项目间交叉测试）、处理非安全类的常规C语言Bug、甚至是跨越编程语言去修复Java漏洞时，Mystique依然保持了极高的成功率，全面且大幅地领先于现有基线工具。

表二 Mystique泛化性实验结果

工具实用性评估：为了验证该框架在真实软件开发环境中的实用性，我们将Mystique部署到开源生态中。如表三所示，Mystique自动为C和Java仓库的16个真实CVE成功迁移了34个补丁。团队将这些迁移结果作为拉取请求（PRs）提交给了上游仓库，最终共有29个PR获得了官方开发者的认可并被成功合并，表明了其在工业界的潜在落地价值。

表三 Mystique实用性实验结果

关于“伏羲”

“伏羲”是复旦大学CodeWisdom团队推出的开源风险治理平台，旨在推动学术与产业合作交流，提升开源软件供应链风险分析与治理能力。“伏羲”在高质量开源软件供应链知识汇聚的基础上，结合代码差异分析、调用图分析、程序切片、大模型辅助分析等技术，提供漏洞库、组件库、漏洞传播影响分析、生态投毒检测、同源漏洞检测、风险缓解等服务。安全补丁迁移是“伏羲”面向开源软件供应链安全治理的重要能力之一。未来，“伏羲”将继续围绕漏洞修复、组件版本升级、组件迁移等方向持续攻关，进一步提升开源生态中已知漏洞的自动化缓解效率，助力开发者更及时地降低软件供应链安全风险。

往期回顾：

开源风险治理平台“伏羲”v0.1首次发布

“伏羲”在开源生态投毒检测中取得重要进展

“伏羲”对Go生态进行了大规模分析

“伏羲”在漏洞影响组件识别中取得重要进展

“伏羲”在开源生态投毒检测中取得进一步重要进展

开源风险治理平台“伏羲”在漏洞传播影响分析中取得重要进展，助力开源软件安全治理

开源风险治理平台“伏羲”在同源漏洞检测中取得重要进展，助力开源软件安全治理。

参考文献

[1] Tan, Xin, et al. “Understanding the Practice of Security Patch Management across Multiple Branches in OSS Projects.” Proceedings of the ACM Web Conference 2022.

[2] Shariffdeen, Ridwan, et al. “Automated Patch Backporting in Linux.” Proceedings of ISSTA 2021.

[3] Yang, Su, et al. “Enhancing OSS Patch Backporting with Semantics.” Proceedings of CCS 2023.

[4] Pan, Shengyi, et al. “Automating Zero-shot Patch Porting for Hard Forks.” Proceedings of ISSTA 2024.

[5] Wu, Susheng, et al., “Mystique: Automated Vulnerability Patch Porting with Semantic and Syntactic-Enhanced LLM.” Proceedings of FSE 2025.

作者：

吴苏晟，陈碧欢