OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

本文提出了 OSS-CRS 框架，旨在解决 DARPA AIxCC 竞赛中开源的七个网络推理系统因依赖已不存在的竞赛云基础设施而难以复用的问题，通过构建一个可本地部署且具备预算感知资源管理的开放框架，成功移植了冠军系统 Atlantis 并在真实开源项目中发现了 10 个此前未知的漏洞。

要点

这篇论文讲述了一个关于**“如何让 AI 安全专家真正落地干活”**的故事。

为了让你轻松理解，我们可以把整个事情想象成一场**“超级黑客大赛”和随后的“工具大改造”**。

1. 背景：一场精彩的“黑客大赛”

想象一下，DARPA（美国国防部高级研究计划局）举办了一场名为 AIxCC 的“黑客大赛”。

• 任务：参赛队伍要开发 AI 机器人（文中称为 CRS，网络推理系统）。这些机器人不仅要能发现软件里的漏洞（就像发现房子有裂缝），还要能自动修复它们（就像自动把裂缝补好），并且要自己证明“我补好了”。
• 结果：有 7 支顶尖队伍赢了。他们把 AI 机器人造出来了，而且代码都开源了（免费公开）。
• 问题：虽然代码公开了，但没人能用。为什么？因为这些机器人是专门为大赛的“超级豪华赛场”（特定的云环境、特定的服务器集群）量身定做的。一旦离开那个赛场，它们就像离开了水的鱼，完全动不了。

2. 痛点：为什么大家用不了？

作者分析了这 7 个机器人，发现它们有三个致命的“毛病”，就像你买了一套昂贵的乐高积木，但发现：

1. 重复造轮子（基础设施重复）：每个队伍都自己搭了一套完全一样的“后台系统”（比如数据库、消息队列），就像 7 个人为了煮咖啡，每个人都自己建了一个发电厂。
2. 被云厂商“绑架”（云锁定）：这些机器人只认识大赛用的微软 Azure 云环境。比赛结束了，那个环境关了，机器人就“失业”了。它们无法在普通的电脑或本地服务器上运行。
3. 是个“大黑盒”（单体设计）：每个机器人都是一个巨大的、不可分割的整体。你想把 A 队伍的“找漏洞”能力，和 B 队伍的“修漏洞”能力结合起来？不行！因为它们内部没有接口，就像你想把法拉利的引擎装到自行车上，但发现接口完全对不上。

3. 解决方案：OSS-CRS（万能适配器）

作者团队（来自佐治亚理工学院和微软）决定做一个**“万能转换器”**，叫 OSS-CRS。

你可以把它想象成一个**“超级乐高底座”或者“万能插座”**：

• 统一接口：它规定了一套标准规则。不管你是 A 队伍的机器人还是 B 队伍的，只要插上这个底座，就能跑。
• 本地化运行：它把那些依赖“云端巨无霸”的机器人，改造成了可以在你自家电脑（或普通服务器）上运行的版本。
• 资源管家：它像一个精明的管家，帮你控制成本。比如，AI 调用大模型是要花钱的，这个管家会设定预算（比如只花 50 美元），防止机器人乱花钱。
• 自由组合：它允许你把不同机器人的强项拼起来。比如，让擅长找漏洞的机器人把线索交给擅长修漏洞的机器人，大家在一个共享的“文件柜”里交换信息，而不需要直接对话。

4. 实战演练：真的管用吗？

为了证明这个“万能底座”好用，作者把大赛冠军队伍 ATLANTIS 的机器人“移植”到了这个新系统上。

• 场景：他们拿这个机器人去攻击 8 个真实的开源软件项目（就像去检查真实的房子）。
• 成果：在短短时间内，它发现了 10 个以前没人知道的严重漏洞（其中 3 个非常危险），并且自动生成了修复补丁。
• 意义：这证明了，那些原本只能在大赛里“表演”的 AI 技术，现在真的可以拿来解决现实世界的问题了。

5. 核心比喻总结

如果把AI 安全研究比作**“烹饪”**：

• 以前的 AIxCC 比赛：就像 7 位大厨在米其林三星的专属厨房里做出了绝世好菜。但他们的厨具是特制的，离开那个厨房，连个鸡蛋都打不开。
• 现在的 OSS-CRS：作者们做了一个**“标准化厨房套件”**。他们把大厨们的菜谱（核心算法）拿出来，配上了通用的锅碗瓢盆（标准接口），让任何人在自家厨房（本地服务器）都能照着做，还能控制买菜的钱（预算管理），甚至可以把 A 大厨的切菜技术和 B 大厨的调味技术结合起来。

6. 这对我们意味着什么？

• 对开源社区：以前维护者被 AI 生成的“假警报”淹没，现在有了能自动修复的工具，能真正减轻负担。
• 对研究人员：大家不再需要重复造轮子，可以专注于改进算法，甚至把不同团队的最强技术组合起来，像搭积木一样创造更强的安全系统。
• 对安全：让顶尖的 AI 安全能力从“实验室”走向“千家万户”，真正保护我们的软件安全。

一句话总结：
这篇论文把原本只能在“比赛专用赛场”运行的 AI 安全机器人，改造成了能在“普通家庭”里自由使用、还能互相配合的开源安全工具，并成功在真实世界中抓到了 10 个漏洞。

技术摘要

OSS-CRS 论文技术总结

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

背景：
DARPA 的 AI 网络挑战赛（AIxCC）证明了“网络推理系统”（CRS）不仅能发现漏洞，还能自主确认漏洞并生成修复补丁。七支决赛队伍在赛后开源了他们的系统，理论上可以将这种能力应用于任何开源项目。

核心问题：
尽管系统已开源，但在实际部署中面临巨大的采用差距（Adoption Gap），导致这些系统几乎无法在原始团队之外使用。主要障碍包括：

1. 基础设施重复建设 (Infrastructure Duplication)： 每个团队独立重建了相同的平台服务（如容器编排、LLM 网关、成本追踪逻辑），导致大量重复劳动。
2. 云厂商锁定 (Cloud Lock-in)： 所有系统都深度绑定于比赛特定的 Azure 和 Kubernetes 基础设施。比赛结束后，该环境已下线，且许多系统（如冠军系统 ATLANTIS）依赖特定的云 SDK 和大量虚拟机，无法在本地运行。
3. 单体架构设计 (Monolithic Design)： 各团队的 CRS 是高度集成的单体系统，缺乏模块化接口。研究人员无法提取、比较或组合不同团队的优势技术（例如，无法将 A 团队的模糊测试器与 B 团队的补丁生成器结合）。

这些障碍阻碍了学术界进行可复现的对比实验，也阻碍了安全从业者将 CRS 技术应用于真实的开源项目。

2. 方法论与系统设计 (Methodology & System Design)

为了解决上述问题，作者提出了 OSS-CRS，这是一个开源的、可本地部署的框架，旨在运行和组合 CRS 技术。

2.1 核心架构

OSS-CRS 本身不是一个 CRS，而是一个运行 CRS 的平台。其架构包含以下关键组件（见图 1）：

• 统一执行模型 (Unified Execution Model)： 将 CRS 生命周期分为三个阶段：
  1. Prepare (准备)： 构建 CRS 容器镜像（与目标项目无关）。
  2. Build Target (构建目标)： 编译目标项目，生成带插桩的二进制文件。
  3. Run (运行)： 启动 CRS 容器进行分析。
     这种分离允许缓存和模块化，避免每次运行都重新构建。
• libCRS 接口库： 注入到每个 CRS 容器中的 Python 库，提供标准化的 API（如提交构建产物、注册共享目录、提交 PoV/补丁、验证补丁等）。CRS 只需关注分析逻辑，无需关心底层基础设施。
• 资源管理与隔离：
  • 计算与内存： 使用 Docker cgroups 为每个 CRS 分配独立的 CPU 核心集和内存限制。
  • 网络隔离： 每个 CRS 运行在独立的 Docker 网络中，防止端口冲突和未受控的带宽消耗。
  • LLM 预算管理： 将 LLM API 成本视为一级资源。通过 LiteLLM 代理，为每个 CRS 生成独立 API Key 并设置预算上限（如$50），防止成本失控。
• 跨 CRS 工件交换 (Artifact Exchange)： 基于文件系统的交换机制。CRS 将发现（如 PoV、补丁、种子）写入私有目录，由"Exchange Sidecar"同步到共享目录。其他 CRS 可从中读取。这实现了多 CRS 协同工作（如一个负责发现，一个负责修复），而无需直接通信。
• 补丁验证侧车 (Builder Sidecar)： 负责接收补丁、应用补丁、增量重建项目并运行回归测试，将构建复杂性从 CRS 逻辑中剥离。

2.2 集成流程

CRS 开发者只需编写一个 crs.yaml 清单文件，定义三个阶段（prepare, build, run）的容器配置和资源需求。OSS-CRS 负责编排容器、管理资源并注入环境变量（如目标名称、LLM 密钥等）。

3. 关键贡献 (Key Contributions)

1. 实证分析与障碍识别： 对七支 AIxCC 决赛队伍的代码进行了深度分析，明确指出了阻碍实际部署的三大障碍（基础设施重复、云锁定、单体设计）。
2. OSS-CRS 框架： 提出了首个支持本地部署、资源感知（CPU/内存/LLM 预算）且支持跨系统技术组合的开源框架。它通过标准化接口（libCRS）和统一执行模型消除了重复建设。
3. 真实世界验证： 将冠军系统 ATLANTIS 成功移植到 OSS-CRS 框架中，并在 8 个 OSS-Fuzz 项目上进行了测试。
   • 成果： 发现了 10 个以前未知的漏洞（其中 3 个为高严重性），包括内存安全漏洞、逻辑漏洞和未定义行为。
   • 修复： 生成的补丁已通过自动验证，并已向维护者提交。
4. 开源发布： 框架、集成代码及评估数据均已公开，促进了社区对 CRS 技术的比较和改进。

4. 实验结果 (Results)

• 移植工作量： 将 ATLANTIS 的三个子系统集成到 OSS-CRS 仅需约 3-4 人天/子系统。主要工作集中在配置编写、I/O 适配（替换比赛 API 为 libCRS 命令）和构建流程标准化，核心分析逻辑未做修改。
• 漏洞发现能力： 在单台机器（32 核 CPU, 128GB RAM）上，对 8 个不同规模（3k 到 1960k 行代码）和领域（数据库、解析器、加密库等）的项目进行了 24 小时测试。
  • 发现 10 个漏洞，涵盖 C/C++ 和 Java。
  • 漏洞类型多样，不仅限于崩溃（Crash），还包括空指针、模式验证错误和数值转换问题。
  • 3 个漏洞已被上游维护者修复，1 个已确认，6 个待审核。
• 资源效率： 每个项目分配 16 核和 64GB 内存，LLM 预算控制在$50/项目。证明了在有限预算下，竞争级 CRS 技术可以在本地环境中有效运行。

5. 意义与影响 (Significance)

1. 打破“黑盒”与“云依赖”： OSS-CRS 成功将 AIxCC 的竞赛成果从特定的云基础设施中解耦，使其能够在本地、低成本的环境中运行，极大地降低了使用门槛。
2. 促进技术组合与创新： 通过模块化设计，研究人员可以像搭积木一样组合不同团队的最优组件（例如：A 的模糊测试 + B 的补丁生成），进行消融实验和性能对比，加速 CRS 技术的迭代。
3. 推动开源安全自动化： 该系统不仅发现漏洞，还自动生成并验证补丁，解决了当前 AI 安全工具“只报不修”的痛点，减轻了开源维护者的负担。
4. 建立新的基准： 为未来的 CRS 研究提供了标准化的评估环境和接口，有助于建立类似 FuzzBench 的 CRS 基准测试套件。

总结：
OSS-CRS 是连接 AI 网络挑战赛竞赛成果与现实世界开源安全需求的关键桥梁。它通过解决基础设施、部署和架构上的根本性障碍，证明了自主网络推理系统可以在脱离竞赛环境后，依然高效地发现并修复真实世界的软件漏洞。