AIxCC竞赛赛制深度解析

竞赛概览

参赛团队需要构建AI驱动的全自动网络推理系统(CRS)，能够自动识别和修补程序漏洞。CRS在挑战项目中发现和修补漏洞时不能接受任何人工协助。挑战项目基于现实关键软件（如Linux内核、Jenkins自动化服务器）的修改版本。CRS必须提交漏洞证明(PoV)和理解证明(PoU)，并可选择提交补丁。这些组件将分别和综合评分以决定获胜者。

竞赛分为四个阶段：

注册阶段（2024年1月-4月）：开放和小型企业注册通道，最多7家小企业将获得100万美元资助
练习轮次（2024年3月-7月）：供参赛者实际测试系统
半决赛（2024年8月DEF CON）：前7名团队晋级决赛，各获200万美元奖金
决赛（2025年8月DEF CON）：前三名分别获得400万、300万和150万美元奖金

挑战项目

挑战项目模拟真实软件，具有高度多样性。挑战问题可能包含Java、Rust、Go、JavaScript、TypeScript、Python、Ruby或PHP编写的源代码，但至少一半将是包含内存损坏漏洞的C/C++程序。其他漏洞类型来自MITRE的25大最危险软件弱点。

挑战问题包含源代码、可修改的构建流程和环境、测试工具链以及公共功能测试套件。CRS必须使用AI/ML和传统程序分析技术来发现、定位、触发和修补漏洞。

评分机制

CRS总评分基于四个组成部分：

漏洞发现分数：每个触发指定AIxCC净化器的PoV获得分数
程序修复分数：补丁阻止净化器触发且不破坏功能时得分，通过代码检查器可获得额外奖励
准确度乘数：奖励高准确率的CRS（最小化无效提交）
多样性乘数：奖励处理不同CWE和编程语言的CRS

评分算法鼓励成功修补漏洞，防止团队只关注发现而忽略修复。

对AIxCC格式RFC的总体看法

我们认为AIxCC将显著推进自动化漏洞检测和修复的技术水平。相比网络大挑战，本次竞赛在真实性方面有重大进步：挑战项目基于真实软件和漏洞、包含源代码并编译为真实二进制格式、支持多种编程语言和计算栈。

聚焦AI/ML驱动的CRS将有助于创建新的研究领域，推动解决传统方法无法解决的软件分析问题。

RFC回应中提出的关切

挑战项目构建

我们主要关切两点：首先，挑战可能通过将已披露漏洞重新注入开源项目来构建，这可能存在于商业大语言模型的训练数据中，给基于LLM的CRS带来不公平优势。建议不使用合作伙伴提供的商业模型训练周期前的历史漏洞。

其次，所有挑战项目都使用赛前已知的开源项目，允许团队进行大规模预分析，可能导致CRS过度专门化。建议至少65%的挑战项目在每阶段比赛前保持保密。

PoU粒度

担心评分算法可能因AIxCC净化器过于细化而拒绝有效的PoV/PoU。例如CWE-787、CWE-125和CWE-119可能都适用于描述同一个漏洞。建议净化器保持足够粗粒度以避免不公平处罚。

评分

当前设计未直接考虑性能指标（CPU运行时间、内存开销等），也未纳入补丁功能评分。性能是关键的软件非功能需求，建议在功能评分中增加性能组件。

下一步计划

尽管提出了一些关切，我们对3月的正式启动和8月的实际比赛充满期待。后续文章将讨论我们在此领域的前期工作如何影响高层方法，并探讨比赛中最引人入胜的技术领域。