不在我的 Git 领地：在提交和发布时拦截后门

# 非我Git院：在提交和发布时捕获后门  
**来源：** [https://arxiv.org/html/2607.26719](https://arxiv.org/html/2607.26719) \\correspondingauthor  
**会议：** 第41届IEEE/ACM自动化软件工程国际会议论文集；2026年10月12–16日；德国慕尼黑  
第41届IEEE/ACM自动化软件工程国际会议论文集 (ASE ’26), 2026年10月12–16日, 德国慕尼黑  
**DOI:** [10.1145/3832783.3834352](https://doi.org/10.1145/3832783.3834352)  
**ISBN:** 979-8-4007-2882-2/2026/10  
**CCS:** 安全与隐私 软件安全工程  
**CCS:** 软件及其工程 软件测试与调试  
**CCS:** 安全与隐私 恶意软件及其缓解  

**Dimitri Kokkonis**  
[https://orcid.org/0009-0009-5171-2992](https://orcid.org/0009-0009-5171-2992)  
邮箱：[[email protected]](mailto:[email protected])  
**隶属关系：** 巴黎-萨克雷大学，法国原子能与替代能源委员会，List，法国巴黎-萨克雷  

**Michaël Marcozzi**  
[https://orcid.org/0000-0002-8087-0537](https://orcid.org/0000-0002-8087-0537)  
邮箱：[[email protected]](mailto:[email protected])  
**隶属关系：** 巴黎-萨克雷大学，法国原子能与替代能源委员会，List，法国巴黎-萨克雷  

**以及**  

**Stefano Zacchiroli**  
[https://orcid.org/0000-0002-4576-136X](https://orcid.org/0000-0002-4576-136X)  
邮箱：[[email protected]](mailto:[email protected])  
**隶属关系：** LTCI, 巴黎综合理工学院电信分部, 巴黎综合理工学院, 法国帕莱索  

**收到日期：** 2026年6月18日  

---

**摘要**  
代码级后门——通过秘密触发器授予隐藏权限的隐蔽代码修改——对开源软件构成持续威胁。已知的通过恶意提交、篡改的发布包或被入侵的第三方依赖项将此类后门注入广泛使用项目的尝试，仅因运气和人工审查才得以阻止。现有的持续集成 (CI) 流水线无法检测到这些攻击，而下游的二进制分析工具则需要大量的人工操作。本文我们提出 **Lily**，一种自动化方法，旨在加强开源开发和发布流程以抵御后门注入。**Lily** 将后门检测机制集成到：(1) CI 流水线以阻止恶意提交，以及 (2) 发布审核工作流，以防止被篡改的发布或被入侵的依赖项进入 Linux 发行版等大型生态系统。  

**Lily** 提出了两项关键贡献。首先，它增强了与 CI 兼容的模糊测试能力，能够基于历史和当前的软件执行情况检测可疑行为的触发器。这使得快速、精确的后门检测适用于 CI 和更新验证工作流。其次，它将代码变更分析与模糊测试数据相结合，即使在发布更新修改了数百万行代码时，也能精确地将维护人员指向揭示后门的代码区域。我们还概述了攻击者可能用来规避 **Lily** 的五种策略，并评估了相应的防御措施。我们在数百个良性和植入后门的提交及发布上进行的实验表明，**Lily** 以低误报率实现了高检测准确度，可靠地识别恶意代码，抵抗对抗性尝试，并且本可以防止现实中的后门事件。  

**关键词：** 模糊测试，动态分析，后门，持续集成，发布审核，软件供应链安全  

††cc‑license:by  

---

## 1. 引言  

**背景**  
*代码级后门*（Thomas and Francillon, 2018 ([https://arxiv.org/html/2607.26719#bib.bib46](https://arxiv.org/html/2607.26719#bib.bib46)); Kokkonis et al., 2025 ([https://arxiv.org/html/2607.26719#bib.bib22](https://arxiv.org/html/2607.26719#bib.bib22))）——嵌入在源代码中的隐藏功能，允许知晓其存在的个人通过秘密触发器获得提升的权限或未授权的功能——对开源软件构成持续威胁。涉及对 PHP 公共仓库的恶意提交（php, 2021 ([https://arxiv.org/html/2607.26719#bib.bib2](https://arxiv.org/html/2607.26719#bib.bib2))）、篡改 ProFTPD 和 vsFTPd 发布包（NIST, 2010 ([https://arxiv.org/html/2607.26719#bib.bib29](https://arxiv.org/html/2607.26719#bib.bib29)); NIST, 2011 ([https://arxiv.org/html/2607.26719#bib.bib30](https://arxiv.org/html/2607.26719#bib.bib30))），或通过被入侵的 XZ Utils 依赖项注入后门（NIST, 2024 ([https://arxiv.org/html/2607.26719#bib.bib31](https://arxiv.org/html/2607.26719#bib.bib31))）的事件在数天内未被发现，仅通过人工检查和偶然机会才得以揭露。错过此类威胁的后果是严重的，尤其是在软件依赖项不断扩大的生态系统放大了单个入侵事件的潜在影响（Decan et al., 2019 ([https://arxiv.org/html/2607.26719#bib.bib8](https://arxiv.org/html/2607.26719#bib.bib8))）的情况下。  

**问题**  
当前的开源软件开发和发布体系缺乏针对后门注入攻击的系统性防御。在上游，*持续集成 (CI) 流水线*运行自动化测试——通常在每次提交时——通过编译检查和回归测试确保代码质量。*模糊测试*，已集成到主要项目的 CI 流水线中（The libsndfile team, 2025 ([https://arxiv.org/html/2607.26719#bib.bib42](https://arxiv.org/html/2607.26719#bib.bib42)); The PHP Foundation, 2025 ([https://arxiv.org/html/2607.26719#bib.bib43](https://arxiv.org/html/2607.26719#bib.bib43)); OpenSSL, 2025 ([https://arxiv.org/html/2607.26719#bib.bib32](https://arxiv.org/html/2607.26719#bib.bib32)); Sudo Project, 2025 ([https://arxiv.org/html/2607.26719#bib.bib41](https://arxiv.org/html/2607.26719#bib.bib41))），通过对修改后的代码进行暴力测试，针对崩溃和内存安全漏洞。由于 CI 必须提供快速反馈，模糊测试运行时间很短，通常限制在约 10 分钟（Huang and Lemieux, 2024 ([https://arxiv.org/html/2607.26719#bib.bib18](https://arxiv.org/html/2607.26719#bib.bib18)); Klooster et al., 2023 ([https://arxiv.org/html/2607.26719#bib.bib21](https://arxiv.org/html/2607.26719#bib.bib21)); Fowler, 2024 ([https://arxiv.org/html/2607.26719#bib.bib11](https://arxiv.org/html/2607.26719#bib.bib11))）。然而，现有的 CI 机制无法检测植入后门的提交，如硬编码的凭证或隐藏的反向 shell。最近一种分析 Git 元数据的机器学习方法（Ganz et al., 2023 ([https://arxiv.org/html/2607.26719#bib.bib13](https://arxiv.org/html/2607.26719#bib.bib13))）可能提供部分解决方案，但仍会产生许多误报。在下游，最先进的后门检测工具（Schuster and Holz, 2013 ([https://arxiv.org/html/2607.26719#bib.bib35](https://arxiv.org/html/2607.26719#bib.bib35)); Shoshitaishvili et al., 2015 ([https://arxiv.org/html/2607.26719#bib.bib38](https://arxiv.org/html/2607.26719#bib.bib38)); Thomas et al., 2017a ([https://arxiv.org/html/2607.26719#bib.bib45](https://arxiv.org/html/2607.26719#bib.bib45)); Thomas et al., 2017b ([https://arxiv.org/html/2607.26719#bib.bib47](https://arxiv.org/html/2607.26719#bib.bib47)); Kokkonis et al., 2025 ([https://arxiv.org/html/2607.26719#bib.bib22](https://arxiv.org/html/2607.26719#bib.bib22))）帮助最终用户审核二进制文件，但需要人工操作来逆向工程代码或排除误报，限制了其可扩展性。  

**目标与挑战**  
我们的目标是加固开源开发和发布流水线，引入一种能够阻止大多数后门注入攻击的机制，并将其集成在两个阶段：(1) 在 CI 流水线中，以及 (2) 在发布审核阶段，之后更新的包才能进入 Linux 发行版等主要生态系统。这样做需要解决三个挑战：  

1.  **(1)** CI 和发布审核流水线在严格的时间限制下运行，因此后门检测必须是完全自动化的，并且在这些限制内实现高检测率以确保其集成的价值。同时，任何误报都可能中断开发或发布过程，因此高精确度对于保持开发者生产力和维护者信任至关重要。  
2.  **(2)** 需要检查的代码变更（提交或发布差异）可能跨越数千到数百万行代码，这需要精确的报告来定位可疑位置，供 CI 操作员或分发维护者查看。  
3.  **(3)** 广泛采用可能会促使对手开发规避技术，这些技术必须被评估和反制。  

**提案**  
我们提出 **Lily**，一种新的防止开源开发中后门注入的方法。**Lily** 在现有 10 分钟的 CI 模糊测试活动中，增加了用于检测后门触发器的运行时监控机制，并扩展这些活动以审核新的软件包发布。  

1.  **(1)** 在修改后的代码进行模糊测试时，**Lily** 监控其运行时行为。仅当同时满足以下两个条件时，它才标记一个潜在的后门：(i) 它观察到在修改前代码中不存在的行为，以及 (ii) 观察到的行为显著偏离修改后代码的典型行为，这种典型行为是通过在先前版本审核时进行的模糊测试活动中导出的回归测试套件上执行修改后代码来表征的。  
2.  **(2)** **Lily** 将来自提交和发布的静态代码变更信息与来自模糊测试和监控的动态数据相关联，从而能够精确地定位揭示后门的代码区域。  
3.  **(3)** 我们系统地评估了五种可能的规避策略——CI 绕过、模糊器干扰、分段或对抗性后门模式以及回归测试套件投毒——并评估了它们的可行性和对策。  

**评估**  
我们通过对来自 13 个流行开源项目的 432 个安全提交和 13 个植入后门的提交，以及 50 个安全发布和 50 个植入后门的发布进行 20 次 10 分钟的检测试验来评估 **Lily**。后门来自 **Rosarum** 语料库——真实和合成的——在 ICSE’25 上引入，作为检测工具的基准，遵循既定的模糊测试评估实践（Kokkonis et al., 2025 ([https://arxiv.org/html/2607.26719#bib.bib22](https://arxiv.org/html/2607.26719#bib.bib22)); Schloegel et al., 2024 ([https://arxiv.org/html/2607.26719#bib.bib34](https://arxiv.org/html/2607.26719#bib.bib34))）。**Lily** 在提交级别实现了 90% 的平均检测率，在发布级别实现了 83% 的平均检测率，表明它本可能防止三起真实的后门注入事件（CVE-2010-20103, CVE-2011-2523, 和 PHP 攻击 (php, 2021 ([https://arxiv.org/html/2607.26719#bib.bib2](https://arxiv.org/html/2607.26719#bib.bib2)))）。误报率保持较低——安全提交平均为 0.2%，安全发布平均为 4.3%——并且主要发生在可预测的场景中，例如大型合并提交或测试框架修改。我们的消融研究证实，仅当一个行为既是新颖的又是异常的时才将其报告为潜在后门，这大大减少了误报。即使在发布之间相差数千到数百万行代码的最坏情况下，**Lily** 也将人工审查持续减少到十几行以内，并且总是能定位到揭示后门的代码。我们的对抗性分析确定了可能的规避策略，但它们需要大量努力，无法保证成功，并且会增加攻击者的暴露风险。对策，包括我们的强化模式，提高了弹性并防止回归测试套件投毒。  

**贡献**  
总而言之，我们的主要贡献是：  

1.  **(1)** **Lily**，一种自动化的后门检测方法，系统性地加固开源开发和发布流水线以抵御注入攻击。在修改后的代码进行模糊测试期间，**Lily** 跟踪运行时行为，并在出现相对于原始代码的新执行模式且这些模式偏离修改后代码的正常行为时标记潜在后门。它进一步将代码变更分析与模糊测试数据相结合，即使在修改了数百万行代码的发布中，也能精确地引导维护人员定位到揭示后门的代码区域。  
2.  **(2)** 在数百个安全和植入后门的提交及发布上的全面评估，显示了高检测率与低误报、对揭示后门代码的精确定位，以及在包括多种不同攻击向量及其对策的对抗性条件下的鲁棒性。它还表明 **Lily** 本可以防止几起真实的后门事件（NIST, 2010 ([https://arxiv.org/html/2607.26719#bib.bib29](https://arxiv.org/html/2607.26719#bib.bib29)); NIST, 2011 ([https://arxiv.org/html/2607.26719#bib.bib30](https://arxiv.org/html/2607.26719#bib.bib30)); php, 2021 ([https://arxiv.org/html/2607.26719#bib.bib2](https://arxiv.org/html/2607.26719#bib.bib2))）。  

---

## 2. 背景  

### 2.1 发布周期与持续集成  

在现代软件工程中，项目开发通常组织为*发布周期*，在此期间，*发布*（即程序的新版本）定期交付给最终用户。每个发布提供一组更新（例如，新功能、错误修复）。在发布之间，通常的做法是依赖版本控制系统 (VCS) 如 Git（Git, 2025 ([https://arxiv.org/html/2607.26719#bib.bib15](https://arxiv.org/html/2607.26719#bib.bib15))）（对于开源项目，其历史记录通常是公开的）来促进协作并确保可追溯性。这种工作流程通常由*持续集成* (CI) 系统补充，通常称为“CI 流水线”。其主要目标是通过自动执行一系列*任务*（即作业）来提供持续的质量保证，这些任务检查最近提交到 VCS 的变更是否维护了软件的完整性。典型的例子包括编译软件和运行相关的回归测试套件。当贡献者引入了 CI 任务可以检测到的缺陷时，CI 流水线会报告错误，并通常阻止将有缺陷的变更集成到上游代码库。负责该变更的个人会收到通知，并需要检查 CI 日志、诊断问题并提交修正。  

### 2.2 开源开发中的模糊测试  

*灰盒模糊测试*（Godefroid, 2020 ([https://arxiv.org/html/2607.26719#bib.bib16](https://arxiv.org/html/2607.26719#bib.bib16))）是一种有效的自动化测试技术，它为被测程序 (PUT) 生成测试输入，并使用覆盖反馈来指导程序探索（Fioraldi et al., 2020 ([https://arxiv.org/html/2607.26719#bib.bib10](https://arxiv.org/html/2607.26719#bib.bib10))）。模糊测试器监控 PUT 的执行——通常使用消毒器（Song et al., 2019 ([https://arxiv.org/html/2607.26719#bib.bib39](https://arxiv.org/html/2607.26719#bib.bib39))）——并报告揭示内存错误或断言失败等问题的崩溃输入。Google 的 OSS-Fuzz（Arya et al., [n. d.] ([https://arxiv.org/html/2607.26719#bib.bib3](https://arxiv.org/html/2607.26719#bib.bib3))）于 2016 年启动，为开源项目提供免费的模糊测试支持，支持 AFL++ 模糊测试器等引擎（Fioraldi et al., 2020 ([https://arxiv.org/html/2607.26719#bib.bib10](https://arxiv.org/html/2607.26719#bib.bib10))）。开发人员提供一个*模糊测试框架*，将模糊测试器链接到项目 API；例如，libpng 的框架（The PNG Development Group, 2025 ([https://arxiv.org/html/2607.26719#bib.bib44](https://arxiv.org/html/2607.26719#bib.bib44))）加载并处理模糊测试生成的 PNG 文件。框架设计强烈影响模糊测试质量，因为它决定了代码库的哪些部分以及在何种条件下被执行。截至 2023 年 8 月，OSS-Fuzz 已帮助在 1,000 个项目中修复了超过 10,000 个漏洞。为了尽早发现问题，一些项目还将模糊测试集成到 CI 流水线中。OSS-Fuzz 提供 CIFuzz [1](https://google.github.io/oss-fuzz/getting-started/continuous-integration)，它构建每个提交，运行一次简短的模糊测试活动（通常 10 分钟（Huang and Lemieux, 2024 ([https://arxiv.org/html/2607.26719#bib.bib18](https://arxiv.org/html/2607.26719#bib.bib18)); Klooster et al., 2023 ([https://arxiv.org/html/2607.26719#bib.bib21](https://arxiv.org/html/2607.26719#bib.bib21)); Fowler, 2024 ([https://arxiv.org/html/2607.26719#bib.bib11](https://arxiv.org/html/2607.26719#bib.bib11))）），并记录任何崩溃及其堆栈跟踪和输入。  

### 2.3 注入代码级后门  

#### 2.3.1 代码级后门  
尽管在计算机系统的各种组件中已经识别出多种形式的后门（Lokhande and Vidyarthi, 2019 ([https://arxiv.org/html/2607.26719#bib.bib28](https://arxiv.org/html/2607.26719#bib.bib28)); Fang et al., 2021 ([https://arxiv.org/html/2607.26719#bib.bib9](https://arxiv.org/html/2607.26719#bib.bib9)); Kostyuk and Landau, 2022 ([https://arxiv.org/html/2607.26719#bib.bib24](https://arxiv.org/html/2607.26719#bib.bib24)); Chen et al., 2017 ([https://arxiv.org/html/2607.26719#bib.bib7](https://arxiv.org/html/2607.26719#bib.bib7))），但本工作集中于*代码级后门*（Thomas and Francillon, 2018 ([https://arxiv.org/html/2607.26719#bib.bib46](https://arxiv.org/html/2607.26719#bib.bib46)); Kokkonis et al., 2025 ([https://arxiv.org/html/2607.26719#bib.bib22](https://arxiv.org/html/2607.26719#bib.bib22))）。这些是直接嵌入在常规程序源代码中的隐藏功能，使知晓其存在的个人能够通过秘密输入触发它们来获得提升的权限或未授权访问。一个著名的例子是官方的 vsFTPd 发布版本，曾有报道称（NIST, 2011 ([https://arxiv.org/html/2607.26719#bib.bib30](https://arxiv.org/html/2607.26719#bib.bib30))）包含后门。在此案例中，使用字符串 “:)” 作为 FTP 用户名将在托管后门 vsFTPd 的受损系统上打开一个远程 root shell。  

#### 2.3.2 在开源项目中注入后门  
尽管...