我们对AIxCC竞赛形式的技术思考

Michael Brown | 2024年1月18日
aixcc, darpa, events, machine-learning

上月晚些时候，DARPA正式开放了人工智能网络挑战赛（AIxCC）的注册。作为活动的一部分，DARPA还发布了备受期待的竞赛信息：包含示例挑战题目和评分方法的请求评论（RFC）。此前DARPA发布的规则文档和FAQ描绘了竞赛的总体框架，而通过此次发布，一些更精细的细节开始显现。

对于没有时间仔细阅读迄今提供的50多页信息的人，以下是竞赛结构的快速概述以及我们的看法，包括我们认为需要改进或澄清的领域。

AIxCC是DARPA的一项重大挑战，延续了网络大挑战和无人驾驶大挑战的传统。

免责声明：AIxCC的规则和评分方法可能发生变化。本摘要仅供读者了解，并非权威文档。有兴趣参加AIxCC的人员应参考DARPA网站和官方文档获取第一手信息。

竞赛高层概述

参赛团队的任务是构建AI驱动的全自动网络推理系统（CRS），能够识别和修补程序中的漏洞。CRS在发现和修补挑战项目中的漏洞时不能接受任何人工协助。挑战项目是现实世界关键软件的修改版本，如Linux内核和Jenkins自动化服务器。CRS必须提交漏洞证明（PoV）和理解证明（PoU），并可以为每个发现的漏洞提交补丁。这些组件分别和共同评分以确定获胜的CRS。

竞赛分为四个阶段：

• 注册（2024年1月至4月）：开放和小型企业注册通道开放注册。在提交概念白皮书后，最多七家小型企业将被选中获得100万美元奖金，以资助他们参加AIxCC。
• 练习轮（2024年3月至7月）：练习和熟悉轮次让参赛者实际测试他们的系统。
• 半决赛（2024年8月，DEF CON）：在第一轮比赛中，前七支团队晋级决赛，每支获得200万美元奖金。
• 决赛（2025年8月，DEF CON）：在总决赛中，表现最好的前三名CRS分别获得400万、300万和150万美元奖金。

图1：AIxCC活动概述

挑战项目

每个团队的CRS必须处理的挑战项目模拟现实世界软件，且非常多样化。挑战问题可能包括用Java、Rust、Go、JavaScript、TypeScript、Python、Ruby或PHP编写的源代码，但至少一半将是包含内存损坏漏洞的C/C++程序。参赛者应预期的其他类型漏洞将来自MITRE的25个最危险软件弱点。

挑战问题包括源代码、可修改的构建过程和环境、测试工具以及公共功能测试套件。使用这些资源的API，参赛CRS必须采用各种类型的AI/ML和传统程序分析技术来发现、定位、触发和修补挑战问题中的漏洞。为了得分，CRS必须提交PoV和PoU，并可以提交补丁。PoV是一个输入，将通过提供的测试工具之一触发漏洞。PoU必须指定PoV将触发哪些清理器和工具（即漏洞类型，可能是一个CWE编号）以及构成漏洞的代码行。

RFC包含一个示例挑战问题，将2021年披露的一个漏洞重新引入Linux内核。提供的挑战问题示例是一个用C编写的单一函数，具有基于堆的缓冲区溢出漏洞和随附的示例补丁。不幸的是，此示例没有提供模糊测试工具、测试套件或构建工具示例。DARPA计划在未来发布更多具有更多细节的示例，从Jenkins自动化服务器的新示例挑战问题开始。

评分

每个参赛CRS将获得一个总体分数，计算为四个组件的函数：

• 漏洞发现分数：为每个触发随附PoU中指定的AIxCC清理器的PoV授予分数。
• 程序修复分数：如果随附PoV/PoU的补丁阻止AIxCC清理器触发且不破坏预期功能，则授予分数。如果补丁通过代码检查器无误，则应用小奖励。
• 准确性乘数：此乘数乘以总体分数，以奖励高准确性的CRS（即最小化无效或拒绝的PoV、PoU和补丁）。
• 多样性乘数：此乘数乘以总体分数，以奖励处理多样化CWE和源代码语言的CRS。

评分算法如何组合这些组件涉及许多复杂性。例如，成功修补发现的漏洞受到高度激励，以防止参赛者仅专注于漏洞发现而忽略修补。如果您对详细数学感兴趣，请查看RFC评分以获取详细信息。

对AIxCC格式RFC的总体看法

总体而言，我们认为AIxCC将显著推动自动化漏洞检测和修复的技术水平。这种竞赛形式在网络大挑战的基础上迈出了一大步，更具现实性，原因有几个——即挑战问题1）由现实世界软件和漏洞制成，2）包括源代码并编译为现实世界二进制格式，以及3）涉及许多不同计算栈的多种不同源语言。

此外，我们认为本次竞赛对AI/ML驱动的CRS的关注将通过鼓励传统方法无法解决的软件分析问题的新方法（由于停止问题等基本限制）帮助创建新的研究领域。

我们在RFC响应中提出的关切

DARPA通过发布RFC征求了对其评分算法和示例挑战的反馈。我们在本月早些时候回应了他们的RFC，并强调了我们开始构建系统时最关心的几个问题。我们希望未来几个月能带来澄清或变化以解决这些关切。

挑战问题的构建

我们有两个与挑战问题相关的主要关切。首先，挑战似乎是通过将先前披露的漏洞重新注入开源项目的最新版本来构建的。这种方法，特别是对于在博客文章中详细解释的漏洞，几乎肯定包含在商业大语言模型（LLM）（如ChatGPT和Claude）的训练数据中。

鉴于它们的高记忆带宽，基于这些模型的CRS在检测和修补这些漏洞时将比其他方法具有不公平的优势。结合LLM在新问题实例上表现显著较差的事实，这强烈表明在AIxCC中得分高的基于LLM的CRS在竞赛外使用时可能会遇到困难。因此，我们建议DARPA不要使用在合作伙伴提供的商业模型训练时期之前披露的历史漏洞来创建竞赛的挑战问题。

其次，似乎所有挑战问题都将使用竞赛前参赛者已知的开源项目创建。这将允许团队进行大规模预分析，并将其LLM、模糊测试器和静态分析器专门针对已知源项目及其历史漏洞进行优化。这些CRS将过于特定于竞赛，可能无法在不同源项目上使用，而无需大量手动工作来重新定位CRS。为了解决这个潜在问题，我们建议至少65%的挑战问题为在竞赛每个阶段前保密的源项目制作。

PoU粒度

我们担心如果AIxCC清理器过于细粒度，评分算法可能会拒绝有效的PoV/PoU。例如，CWE-787（越界写入）、CWE-125（越界读取）和CWE-119（越界缓冲区操作）都列在MITRE前25个弱点报告中。所有三个都可能有效描述挑战问题中的单个漏洞，并在CWE数据库中交叉列出。如果为每个这些CWE提供多个清理器但仅一个被视为正确，则可能拒绝其他有效的提交，因为它们未能正确区分三个非常密切相关的清理器。我们建议AIxCC清理器足够粗粒度以避免对提交的PoU的不公平惩罚。

评分

按当前设计，性能指标（例如CPU运行时、内存开销等）未直接纳入竞赛的优秀领域，也未纳入补丁的功能分数。性能是关键的非功能性软件要求，是补丁有效性和可接受性的重要方面。我们认为参赛CRS生成的补丁将程序性能维持在可接受阈值内非常重要。没有在评分中考虑这一点，团队可能提交有效且正确但最终性能如此差以至于在现实世界场景中不会使用的补丁。我们建议竞赛的功能分数增加性能组件。

下一步是什么？

尽管我们在RFC响应中提出了一些关切，我们对3月的正式启动和今年8月的实际竞赛感到非常兴奋。请关注我们本系列的下一篇文章，我们将讨论我们在此领域的先前工作如何影响我们的高层方法，并讨论本次竞赛中最吸引我们的技术领域。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 近期文章 使用Deptective调查您的依赖项 系好安全带，AIxCC的评分轮正在进行中！ 使您的智能合约超越私钥风险 Go解析器中意想不到的安全隐患 我们审查Silence Laboratories的首批DKLs23库的收获 © 2025 Trail of Bits. 使用Hugo和Mainroad主题生成。