OSS-CRS：让 AIxCC 网络推理系统可用于真实开源软件安全

核心问题：AIxCC 竞赛产生的七个自主网络推理系统（CRS）虽然全部开源，但半年多后仍基本无法在原始团队之外部署使用。

• 问题场景：AI 生成的漏洞报告正在加重开源维护者负担（curl 关停 bug bounty、FFmpeg 维护者批评"CVE slop"），而 AIxCC（2023–2025）证明 CRS 能从发现走到验证修复：用 PoV 确认漏洞、合成并验证补丁。作者认为这一能力无法落地，挡住了研究者（无法做可比的跨 CRS 实验）、CRS 开发者（缺少稳定集成契约）和安全从业者（缺少可部署、预算可控的工作流）。
• 现有系统的不足：作者分析全部七个决赛系统的开源代码库，归纳出三个部署障碍：1）基础设施重复建设——各队独立重建了同样的平台服务（如 LLM 预算追踪、计费、模型路由，七队中五队都部署了 LiteLLM）；2）云锁定——所有系统面向竞赛的 Azure/Kubernetes 环境，该环境决赛后已下线，冠军系统 ATLANTIS 需要 20 多台 Azure VM 和 42 TiB 云存储；3）单体设计——分析技术嵌入单体系统，无法跨团队比较或组合（Table 1 中七个系统的 Composable 列均为 ×）。
• 论文的核心观察：作者引用 Zhang et al. 的 SoK 结论——"真正的瓶颈不是技术能力，而是与自主系统的稳健集成"，并指出各队技术具有互补性（如 ATLANTIS 的混合模糊测试、BUTTERCUP 的多智能体补丁），单体结构使这些技术无法被隔离、评估和迁移。
• 论文提出的方案：OSS-CRS，一个开放、本地可部署的框架，提供统一执行模型与标准接口（libCRS）、跨 CPU/内存/LLM 用量的预算感知资源管理，以及跨 CRS 产物交换；采用 OSS-Fuzz 项目格式作为目标接口，使任何接入的 CRS 可面向 1,000 多个 OSS-Fuzz 项目。作者移植 ATLANTIS 验证，报告发现 10 个未知漏洞（3 个高危）。

自主网络推理

• CGC（DARPA Cyber Grand Challenge, 2014–2016）：让自主系统在 DECREE OS 上对定制二进制做漏洞发现与修补。论文指出 CGC 提供的是固定二进制格式和评分 API。
• AIxCC（2023–2025）：把概念扩展到真实开源软件（C/Java），产生七个决赛 CRS；论文指出其提供的是 Azure 基础设施和竞赛专用端点。作者称 OSS-CRS 与两者的区别在于提供超越单次竞赛、可复用的框架。
• Zhang et al. 的 SoK：系统化了全部七个决赛队伍的技术，论文引用其结论支撑"瓶颈在集成"的判断，并指出该综述只能描述各队方法、无法做实验比较。

Fuzzing 基础设施

• OSS-Fuzz：为开源项目提供持续 fuzzing，但只支持单容器、单 fuzzer 执行，无补丁或 LLM 集成；OSS-CRS 直接复用其项目定义作为目标格式。
• FuzzBench / ARVO / Magma / UniFuzz：fuzzer 评测基准或漏洞复现工具，论文指出它们面向单 fuzzer 比较或不提供执行框架，OSS-CRS 与之互补（可与 FuzzBench 集成做 CRS 级比较）。

集成与协作 fuzzing

• EnFuzz、autofz、Cupid、CollabFuzz 等协作 fuzzing 工作：证明固定资源下多 fuzzer 协作优于单一 fuzzer。作者称 OSS-CRS 把这一思路从 fuzzer 集成推广到异构技术的 CRS 集成（含静态分析、LLM 推理、自主补丁）。

LLM 增强的 fuzzing 与修复

• LLM fuzzing（TitanFuzz、Fuzz4All、ChatAFL、ELFuzz、HLPFuzz、G2Fuzz）与 harness 合成（OSS-Fuzz-Gen、SHERPA）：改进单个 fuzzing 组件；作者称 OSS-CRS 提供把这类工具组合成完整 CRS 流水线的编排层。
• LLM 修复基准与代理（SEC-bench、Cybench、AutoPatchBench、CVE-Bench；San2Patch、PatchAgent）：评测或实现 LLM 安全修复；作者称 OSS-CRS 的 LLM 代理按 CRS 追踪成本，可在固定预算下比较 LLM 增强与传统技术。

定位：作者将 OSS-CRS 定位为上述工作的编排与基础设施层，而非新的分析技术；论文没有与其他系统做实验对比的基线。

整体思路：OSS-CRS 本身不是 CRS，而是开发、部署和组合 CRS 的平台，对应三个障碍提供三项能力：统一三阶段执行模型与标准接口（消除基础设施重复）、本地执行加资源控制（消除云依赖）、跨 CRS 产物交换（支持组合异构技术）。

三阶段执行模型与配置

• 三阶段生命周期：prepare 构建与目标无关的 CRS 容器镜像（可跨项目复用、摊销配置成本）；build-target 编译目标项目；run 启动所有 CRS 容器执行分析活动，可设超时。与 OSS-Fuzz 把构建和运行合为一体不同，分离设计支持缓存和模块化。
• 单一配置：用户只需提供目标项目源码和一个 crs-compose.yaml（指定部署哪些 CRS、资源分配、LLM 设置），增删 CRS 只改这一个文件。
• 定向分析：默认分析整个代码库；也可提供 code diff（delta 分析，面向 CI/CD 检查 PR）或 SARIF 格式的 bug-candidate 报告来限定分析范围。

libCRS 标准接口

• 定位：自动注入每个 CRS 容器的 Python 库，CRS 的分析逻辑通过它与基础设施交互，部署环境变化时 CRS 代码不变。
• 四类命令（Table 2）：构建产物交接（submit-build-output）、运行时设置（register-shared-dir）、产物交换（register-submit-dir/register-fetch-dir/submit/fetch）、补丁验证（apply-patch-build/run-pov/run-test）。
• Builder sidecar：build-target 阶段对编译完成的目标做 Docker 镜像快照；补丁候选通过 apply-patch-build 发给 sidecar，恢复快照、打补丁、增量重编译，再 run-pov 重放崩溃输入、run-test 跑回归测试。sidecar 运行在 CRS 自己的资源配额内，重建成本计入该 CRS。

资源管理与 LLM 服务

• 计算与内存隔离：每个 CRS 声明 cpuset 和 memory limit，由 Docker cgroups 强制执行；每个 CRS 独立 Docker 网络，跨 CRS 数据只能走文件系统交换机制。作者称放弃 Docker-in-Docker 改用扁平 Docker 架构，是因为 DinD 使构建缓存、cgroup 强制和调试都更困难。
• LLM 预算作为一等资源：每个 CRS 可声明美元计价的 llm_budget；启动时为每个 CRS 生成独立 API key，LiteLLM 代理追踪累计成本、超预算即拒绝请求。作者称这使不同成本特征的 CRS 可以公平比较（同样结果花 50 美元优于花 500 美元）。
• 统一端点与模型别名：所有 CRS 用 OpenAI 兼容 API 调用单一代理，按逻辑名（如 gpt-4o）引用模型，YAML 配置映射到具体提供商；支持 internal（默认）、external（外部代理）、disabled（不用 LLM）三种部署模式。

产物交换

• 交换模型：每个 CRS 写私有 submit 目录、读共享 fetch 目录；exchange sidecar 把各 submit 目录同步进共享交换区，按类型组织（seeds、povs、patches、bug-candidates）；CRS 内部数据（覆盖率图、中间状态）不共享。
• 去重与容错：产物按内容哈希命名，重复发现只出现一次（哈希去重为基线策略，作者称可扩展为覆盖率或堆栈签名去重）；CRS 间无直接通信，各自轮询，单个 CRS 崩溃不影响其他 CRS。

CRS 集成方式

• crs.yaml 清单：分 prepare_phase、target_build_phase、crs_run_phase 三段声明；框架注入环境变量（目标名、cpuset、内存上限、LLM 代理端点和密钥，Table 4）。
• 已集成五个 CRS（Table 3）：CRS-LIBFUZZER（无 LLM 基线，构建脚本仅两行）、ATLANTIS 的三个 bug-finding 子系统（MULTILANG/JAVA/C）、CLAUDE CODE（LLM 补丁生成，不含任何构建逻辑）。移植 ATLANTIS 涉及四类改动：编写清单、用 libCRS 替换竞赛 API、统一 builder.Dockerfile 构建流程、用 prepare 阶段做镜像缓存；核心分析逻辑保持不变，但 MULTILANG 和 JAVA 子系统去掉了 concolic 执行引擎，ATLANTIS-C 去掉了备用 fuzzing 引擎和 harness 调度器。

实验设置

• 被测系统：移植到 OSS-CRS 的 ATLANTIS bug-finding 子系统（论文称主要验证对象是 ATLANTIS，理由：成绩最好且原本不支持本地执行）；CRS-LIBFUZZER 作基线验证最小接口；CLAUDE CODE 验证补丁生成与 ensemble 机制。
• 目标：8 个 OSS-Fuzz 项目，覆盖 C/C++ 和 Java，规模 3 kLoC 至 1,960 kLoC，涵盖数据库、解析器、网络服务器、密码库等域，fuzzing 成熟度从新接入到多年重度 fuzz 不等；作者称未按预期漏洞产出挑选项目。论文未列出 8 个项目的名称。
• 运行环境：单台 32 核 CPU、128 GB 内存的机器，Ubuntu 22.04、Docker 27；每次活动给 bug-finding CRS 分配 16 核和 64 GB 内存。
• 预算与时长：每个目标项目 24 小时超时；LLM 预算每次活动 50 美元，经 OSS-CRS 代理使用 Claude 和 GPT-4o 混合模型（论文未写明具体模型版本）。
• 产出判定：漏洞以 PoV（触发崩溃或 sanitizer 违规的输入）确认；补丁经 apply-patch-build 重建、run-pov 重放、run-test 回归测试自动验证后，人工复审再上报上游。
• 重复次数：论文未报告每个项目运行的次数。

主结果

指标	数值	出处
发现的未知漏洞总数	10	§5.1
其中高危漏洞	3	摘要、§1
目标项目数	8（OSS-Fuzz）	§5
已被上游维护者修复	3	§5.1、§5.2
已确认未修补	1	§5.1、§5.2
等待初步回复	6	§5.1、§5.2

• 作者称漏洞多数是 C 语言内存安全问题，也包含逻辑漏洞和未定义行为（CWE-476、CWE-674、CWE-681），即不限于 fuzzer 常见的崩溃类问题。
• 作者称这表明竞赛级 CRS 技术可以不依赖云基础设施部署；论文未给出逐项目的漏洞分布或运行成本明细。
• 三个案例的详细信息将在修复后 30 天窗口期过后公布（作者计划）。

移植工作量与系统改动

• 测了什么：把 ATLANTIS 三个子系统和 CLAUDE CODE 移植到 OSS-CRS 接口所需的工作量与改动范围。
• 结果：ATLANTIS-MULTILANG 约 3 人日；ATLANTIS-C 超过 4 人日（与竞赛专用构建流水线耦合更紧）；ATLANTIS-JAVA 和 CLAUDE CODE 各约 1 人日（§6.1）。改动集中在配置、I/O 适配、构建集成和镜像优化四类，核心分析算法未动。
• 作者解读：移植工作量取决于原系统与这四类改动之间的差距；核心分析技术可以独立于部署基础设施。

架构与集成机制验证

• 扁平 Docker vs DinD：作者报告最初用 DinD 包装 CRS 的尝试使资源控制、构建缓存和调试变复杂，遂改用扁平架构；代价是需要显式网络策略隔离跨 CRS 通信，作者认为可接受（§6.1）。
• Builder sidecar：CLAUDE CODE 通过 apply-patch-build/run-pov/run-test 三步流水线验证补丁，实现中不含构建逻辑（§4.4）；作者称跨 CRS 产物交换在实践中可行（§3.6），但相对单 CRS 运行的性能增益尚未量化，留作未来工作。
• 构建系统多样性：竞赛环境预置的构建假设在不同目标项目上频繁失效，OSS-CRS 通过 OSS-Fuzz 官方构建流程缓解（§6.1，无定量数据）。

其他消融与分析

• 被排除的 concolic 组件在原竞赛中仅贡献 ATLANTIS 结果的 1.7%（§6.2，引自 ATLANTIS 原论文），作者据此预期对 bug-finding 能力影响很小。
• Table 1 给出七个决赛 CRS 的部署特征：容器镜像数从 1（ROBO DUCK）到 53（ARTIPHISHELL）不等；仅一半队伍赛后提供本地执行支持；七个系统 Composable 均为 ×。
• 论文未报告集成运行相对单 CRS 的漏洞产出对比、LLM 成本实测数据或补丁接受率的统计。

作者指出的局限与后续方向

• 仅移植了一个 AIxCC 系统（§6.2）：只验证了 ATLANTIS，移植更多 CRS 可能暴露接口缺口或设计假设问题；作者称正在移植其他决赛系统。
• concolic 组件被排除（§6.2）：其 instrumentation 在多样目标项目上引入兼容性问题；作者称该组件在原竞赛中仅贡献 1.7% 的结果，预期影响很小。
• 目标格式假设（§6.2）：目前只支持 OSS-Fuzz 兼容项目（需标准构建脚本、容器化环境、语言限制、至少一个 fuzz harness）；未接入 OSS-Fuzz 的项目需要自行开发 harness，不在框架范围内。
• LLM 非确定性（§6.2）：LLM 组件输出不确定，结果反映特定模型版本和提示词配置，不同模型或 API 版本可能得到不同发现。
• 集成增益未量化（§3.6）：跨 CRS 产物交换的可行性已验证，但相对单 CRS 运行的性能增益留作未来工作。
• 三个未来方向（§6.3）：跨 CRS 技术分析（哪些单项技术最有效、哪些组合最好，种子去重和 PoV 分诊是前提）；CRS 基准套件（类比 FuzzBench）；更广的目标覆盖。

实验覆盖范围

• 主要验证在单个系统（ATLANTIS 的三个 bug-finding 子系统）上进行；CRS-LIBFUZZER 和 CLAUDE CODE 用于验证接口与补丁流程。
• 目标为 8 个 OSS-Fuzz 项目，覆盖 C/C++ 和 Java，规模 3 kLoC 至 1,960 kLoC；论文未列出项目名称。
• 运行环境为单台 32 核、128 GB 内存机器；每次活动 16 核、64 GB 内存、24 小时超时、50 美元 LLM 预算。
• 论文未报告每个目标的运行次数、LLM 的具体版本与用量明细、逐项目漏洞分布。
• 10 个漏洞的披露状态以人工复审后上报为准；论文未报告补丁被上游接受的数量统计（仅 3 个已修复、1 个确认、6 个待回复）。

一篇系统框架论文：针对 AIxCC 七个开源 CRS 无法脱离竞赛环境部署的问题，提出本地可部署的 OSS-CRS 框架并做了真实世界验证。

• 问题：作者分析全部七个决赛 CRS 的代码库，归纳出三个部署障碍——基础设施重复建设（各队独立重建 LLM 预算追踪、计费、路由等平台服务）、云锁定（全部面向已下线的 Azure/Kubernetes 环境，冠军系统 ATLANTIS 需 20 多台 Azure VM）、单体设计（Table 1 中七个系统均无法做组件级抽取与跨队组合）。
• 方法：OSS-CRS 提供三阶段执行模型（prepare/build-target/run）与 libCRS 标准接口；用 Docker cgroups 做 CPU/内存隔离、独立网络、按 CRS 的美元计价 LLM 预算强制（LiteLLM 代理）；通过文件系统的 exchange sidecar 做跨 CRS 产物交换与内容哈希去重。移植 ATLANTIS 时核心分析逻辑保持不变，改动集中在配置、I/O、构建集成和镜像缓存四类。
• 主要结果：在单台 32 核/128 GB 机器上，以每项目 24 小时、50 美元 LLM 预算运行移植后的 ATLANTIS，在 8 个 OSS-Fuzz 项目（3 至 1,960 kLoC）中发现 10 个未知漏洞，其中 3 个高危；3 个已被上游修复、1 个确认、6 个待回复。移植工作量：MULTILANG 约 3 人日、ATLANTIS-C 超 4 人日、JAVA 与 CLAUDE CODE 各约 1 人日。
• 作者结论：竞赛级 CRS 技术可以不依赖云基础设施部署到真实开源项目；作者认为框架产出的不仅有 PoV 还有经验证的补丁，使自动化倾向于防御一方。框架已开源，作者计划推进跨 CRS 技术比较、CRS 基准套件和更广目标覆盖，并邀请社区移植更多系统。