我们对AIxCC竞赛形式的技术见解 - Trail of Bits博客
Michael Brown | 2024年1月18日
aixcc, darpa, events, machine-learning
上月晚些时候，DARPA正式开放了人工智能网络挑战赛（AIxCC）的注册。作为活动的一部分，DARPA还发布了备受期待的竞赛信息：包含样本挑战题和评分方法的请求评论（RFC）。先前发布的规则文档和FAQ描绘了竞赛的总体框架，而通过此次发布，更多技术细节开始显现。
对于没有时间研读50多页文档的读者，以下是竞赛结构的快速概述以及我们的技术观点，包括我们认为需要改进或澄清的领域。
AIxCC是DARPA发起的一项重大挑战，延续了网络大挑战和无人驾驶大挑战的传统。
免责声明：AIxCC的规则和评分方法可能变更。本文仅为读者提供信息，非权威文档。参赛者应参考DARPA官网和官方文件获取第一手信息。
竞赛高层架构
参赛团队需要构建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 Top 25最危险软件弱点列表。
每个挑战项目包含源代码、可修改的构建流程与环境、测试套件和公共功能测试集。CRS必须通过API使用AI/ML和传统程序分析技术来发现、定位、触发和修复漏洞。评分需提交PoV和PoU，补丁为可选。PoV是通过测试套件触发漏洞的输入，PoU必须指定触发的检测器类型（如CWE编号）和漏洞代码位置。
RFC包含的样本挑战题将2021年披露的漏洞重新引入Linux内核。该示例是用C语言编写的单个函数，存在堆缓冲区溢出漏洞并附有样本补丁。但缺少模糊测试套件和构建工具链。DARPA计划发布更多示例，包括基于Jenkins的新挑战题。
评分技术细则
CRS总评分由四个组件构成：
- 漏洞发现分数：成功触发指定检测器的每个PoV获得积分
- 程序修复分数：补丁能阻止检测器触发且不破坏功能时得分，通过代码检查器可获得额外奖励
- 准确度乘数：基于提交有效性对总分进行加权
- 多样性乘数：根据处理的CWE类型和源代码语言多样性进行加权
评分算法通过复杂机制组合这些组件。例如，成功修复漏洞会获得高激励，以防止参赛者只关注发现而忽略修复。详细数学公式请参阅RFC评分章节。
对AIxCC技术框架的总体评价
我们认为AIxCC将显著推动自动化漏洞检测与修复的技术发展。相比网络大挑战，本次竞赛在真实性方面取得重大进步，体现在：1）采用真实软件和漏洞 2）包含源代码并编译为真实二进制格式 3）支持多种编程语言和计算栈。
此外，聚焦AI/ML驱动的CRS将通过创新软件分析方法解决传统方法因根本限制（如停机问题）无法解决的难题，从而开辟新的研究领域。
RFC响应中提出的技术关切
挑战项目构建问题
我们主要关切两点：首先，挑战题似乎通过将历史漏洞重新注入开源项目新版本来构建。这种方法尤其适用于已在博客文章详细解释的漏洞，几乎肯定包含在ChatGPT等商业大语言模型（LLM）的训练数据中。基于这些模型的CRS在检测和修复这些漏洞时将获得不公平优势。结合LLM在新问题实例上表现较差的事实，表明在竞赛中得分高的LLM型CRS在实际应用中可能表现不佳。我们建议DARPA避免使用合作伙伴提供的商业模型训练周期之前披露的历史漏洞。
其次，所有挑战项目似乎都使用参赛者事先知晓的开源项目构建。这将允许团队进行大规模预分析，并专门针对已知源项目及其历史漏洞优化其LLM、模糊测试器和静态分析器。这类CRS过于特定于竞赛，在不同源项目上可能无法使用。我们建议至少65%的挑战项目使用在竞赛各阶段前保密的源项目。
PoU粒度问题
我们担心如果AIxCC检测器过于细化，评分算法可能拒绝有效的PoV/PoU。例如CWE-787（越界写入）、CWE-125（越界读取）和CWE-119（越界缓冲区操作）都列入MITRE Top 25弱点列表，三者可能都适用于描述单个漏洞且在CWE数据库中交叉列出。如果为每个CWE提供多个检测器但仅一个被视为正确，可能导致有效提交因未能区分三个密切相关的检测器而被拒绝。我们建议AIxCC检测器保持足够粗粒度以避免不公正处罚。
评分机制优化
当前设计未直接处理性能指标（如CPU运行时间、内存开销等），也未将其纳入补丁功能评分。性能是关键的非功能性软件要求，也是补丁有效性和可接受性的重要方面。我们认为竞赛CRS生成的补丁应将程序性能维持在可接受阈值内。若评分不考虑此因素，团队可能提交有效但性能极差、无法实际使用的补丁。建议在功能评分中增加性能组件。
下一步计划
尽管在RFC响应中提出了关切，我们对3月的正式启动和8月的实际竞赛充满期待。请关注本系列下一篇文章，我们将讨论以往工作如何影响高层技术方案，并探讨竞赛中最令人着迷的技术领域。
如果您喜欢本文，请分享至：
Twitter | LinkedIn | GitHub | Mastodon | Hacker News
页面内容导航：竞赛高层架构 | 挑战项目 | 评分 | 对AIxCC格式RFC的总体评价 | RFC响应中提出的关切 | 挑战项目构建 | PoU粒度 | 评分 | 下一步计划
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
公众号二维码
