DARPA vừa chính thức mở đăng ký cho cuộc thi AI Cyber Challenge (AIxCC). Đồng thời, họ cũng công bố thông tin về cuộc thi, bao gồm một bản yêu cầu đóng góp ý kiến (RFC) chứa một bài toán mẫu và phương pháp chấm điểm.

AIxCC là một thử thách lớn từ DARPA, tiếp nối truyền thống của Cyber Grand Challenge và Driverless Grand Challenge.

Các đội thi sẽ xây dựng các hệ thống lý luận an ninh mạng (CRS) tự động, sử dụng AI để xác định và vá các lỗ hổng trong chương trình. CRS không được phép nhận bất kỳ sự trợ giúp nào của con người trong quá trình tìm kiếm và vá lỗ hổng. Các dự án thử thách là các phiên bản sửa đổi của phần mềm quan trọng ngoài đời thực, chẳng hạn như nhân Linux và máy chủ tự động hóa Jenkins. CRS phải nộp bằng chứng về lỗ hổng (PoV) và bằng chứng về sự hiểu biết (PoU), đồng thời có thể nộp bản vá cho mỗi lỗ hổng mà họ tìm thấy. Các thành phần này được chấm điểm riêng lẻ và tập thể để xác định CRS chiến thắng.

Cuộc thi có bốn giai đoạn:

• Đăng ký (tháng 1–4 năm 2024): Các трек đăng ký Mở và Doanh nghiệp nhỏ đang mở để đăng ký. Sau khi nộp giấy trắng khái niệm của họ, tối đa bảy doanh nghiệp nhỏ sẽ được chọn cho giải thưởng 1 triệu đô la để tài trợ cho sự tham gia của họ vào AIxCC.
• Vòng thực hành (tháng 3–7 năm 2024): Các vòng thực hành và làm quen cho phép các đối thủ cạnh tranh kiểm tra hệ thống của họ một cách thực tế.
• Bán kết (tháng 8 năm 2024 tại DEF CON): Trong vòng thi đầu tiên, bảy đội đứng đầu sẽ tiến vào vòng chung kết, mỗi đội nhận được giải thưởng 2 triệu đô la.
• Chung kết (tháng 8 năm 2025 tại DEF CON): Trong trận chung kết lớn, ba CRS hoạt động hàng đầu sẽ nhận được giải thưởng lần lượt là 4 triệu đô la, 3 triệu đô la và 1,5 triệu đô la.

Các dự án mà CRS của mỗi đội phải xử lý mô phỏng theo phần mềm thực tế và rất đa dạng. Các bài toán có thể bao gồm mã nguồn viết bằng Java, Rust, Go, JavaScript, TypeScript, Python, Ruby hoặc PHP, nhưng ít nhất một nửa trong số đó sẽ là chương trình C/C++ chứa các lỗ hổng hỏng bộ nhớ. Các loại lỗ hổng khác mà đối thủ cạnh tranh nên mong đợi sẽ được lấy từ Top 25 Lỗi Phần Mềm Nguy Hiểm Nhất của MITRE.

Các bài toán bao gồm mã nguồn, quy trình và môi trường xây dựng có thể sửa đổi, bộ kiểm tra và bộ kiểm tra chức năng công khai. Bằng cách sử dụng API cho các tài nguyên này, CRS cạnh tranh phải sử dụng các loại AI/ML và các kỹ thuật phân tích chương trình thông thường khác nhau để khám phá, định vị, kích hoạt và vá các lỗ hổng trong bài toán. Để ghi điểm, CRS phải gửi PoV và PoU và có thể gửi bản vá. PoV là một đầu vào sẽ kích hoạt lỗ hổng thông qua một trong các bộ kiểm tra được cung cấp. PoU phải chỉ định trình dọn dẹp và bộ kiểm tra nào (ví dụ: loại lỗ hổng, có thể là số CWE) mà PoV sẽ kích hoạt và các dòng mã tạo nên lỗ hổng.

RFC chứa một bài toán mẫu tái tạo một lỗ hổng đã được tiết lộ vào năm 2021 trở lại nhân Linux. Ví dụ về bài toán được cung cấp là một hàm duy nhất được viết bằng C với lỗ hổng tràn bộ đệm dựa trên heap và bản vá mẫu đi kèm. Thật không may, ví dụ này không đi kèm với các bộ kiểm tra fuzzing mẫu, bộ kiểm tra hoặc bộ xây dựng. DARPA đang lên kế hoạch phát hành thêm các ví dụ với nhiều chi tiết hơn trong tương lai, bắt đầu với một ví dụ bài toán mới từ máy chủ tự động hóa Jenkins.

Điểm số tổng thể của mỗi CRS cạnh tranh sẽ được tính bằng một hàm của bốn thành phần:

• Điểm khám phá lỗ hổng: Điểm được trao cho mỗi PoV kích hoạt trình dọn dẹp AIxCC được chỉ định trong PoU đi kèm.
• Điểm sửa chữa chương trình: Điểm được trao nếu bản vá đi kèm với PoV/PoU ngăn trình dọn dẹp AIxCC kích hoạt và không phá vỡ chức năng mong đợi. Một phần thưởng nhỏ được áp dụng nếu bản vá vượt qua trình kiểm tra mã mà không có lỗi.
• Hệ số nhân độ chính xác: Điều này nhân điểm số tổng thể để trao CRS với độ chính xác cao (tức là giảm thiểu PoV, PoU và bản vá không hợp lệ hoặc bị từ chối).
• Hệ số nhân đa dạng: Điều này nhân điểm số tổng thể để trao CRS xử lý các bộ CWE và ngôn ngữ mã nguồn đa dạng.

Có một số phức tạp liên quan đến cách thuật toán chấm điểm kết hợp các thành phần này. Ví dụ: việc vá thành công một lỗ hổng được phát hiện được khuyến khích cao để ngăn đối thủ cạnh tranh chỉ tập trung vào việc khám phá lỗ hổng và bỏ qua việc vá. Nếu bạn quan tâm đến toán học chi tiết, vui lòng xem chấm điểm RFC để biết chi tiết.

Nhìn chung, AIxCC sẽ giúp thúc đẩy đáng kể trạng thái hiện tại của kỹ thuật phát hiện và khắc phục lỗ hổng tự động. Định dạng cuộc thi này là một bước tiến lớn so với Cyber Grand Challenge về tính thực tế vì một số lý do—cụ thể là các bài toán 1) được tạo từ phần mềm và lỗ hổng thực tế, 2) bao gồm mã nguồn và được biên dịch thành các định dạng nhị phân thực tế và 3) có nhiều ngôn ngữ nguồn khác nhau cho nhiều ngăn xếp tính toán khác nhau.

Ngoài ra, chúng tôi nghĩ rằng việc tập trung vào CRS dựa trên AI/ML cho cuộc thi này sẽ giúp tạo ra các lĩnh vực nghiên cứu mới bằng cách khuyến khích các cách tiếp cận mới đối với các vấn đề phân tích phần mềm mà các cách tiếp cận thông thường không thể giải quyết được (do các giới hạn cơ bản như bài toán dừng).

DARPA đã thu hút phản hồi về thuật toán chấm điểm và các thử thách mẫu của họ bằng cách phát hành chúng dưới dạng RFC. Chúng tôi đã trả lời RFC của họ vào đầu tháng này và nhấn mạnh một số lo ngại hàng đầu trong tâm trí chúng tôi khi chúng tôi bắt đầu xây dựng hệ thống của mình. Chúng tôi hy vọng rằng những tháng tới sẽ mang lại sự làm rõ hoặc thay đổi để giải quyết những lo ngại này.

Chúng tôi có hai mối quan tâm chính liên quan đến các bài toán. Đầu tiên, có vẻ như các thử thách sẽ được xây dựng bằng cách đưa các lỗ hổng đã được tiết lộ trước đó trở lại các phiên bản gần đây của một dự án nguồn mở. Cách tiếp cận này, đặc biệt đối với các lỗ hổng đã được giải thích chi tiết trong các bài đăng trên blog, gần như chắc chắn có trong dữ liệu huấn luyện của các mô hình ngôn ngữ lớn (LLM) thương mại như ChatGPT và Claude.

Với băng thông ghi nhớ cao, CRS dựa trên các mô hình này sẽ được hưởng lợi một cách không công bằng khi phát hiện và vá các lỗ hổng này so với các cách tiếp cận khác. Cùng với thực tế là LLM được biết là hoạt động kém hơn đáng kể trên các trường hợp mới của vấn đề, điều này cho thấy mạnh mẽ rằng CRS dựa trên LLM đạt điểm cao trong AIxCC có thể gặp khó khăn khi được sử dụng bên ngoài cuộc thi. Do đó, chúng tôi khuyên DARPA không nên sử dụng các lỗ hổng lịch sử đã được tiết lộ trước kỷ nguyên đào tạo cho các mô hình thương mại do đối tác cung cấp để tạo ra các bài toán cho cuộc thi.

Thứ hai, có vẻ như tất cả các bài toán sẽ được tạo bằng các dự án nguồn mở mà đối thủ cạnh tranh sẽ biết trước cuộc thi. Điều này sẽ cho phép các đội thực hiện phân tích trước quy mô lớn và chuyên biệt hóa LLM, fuzzers và trình phân tích tĩnh của họ cho các dự án nguồn đã biết và các lỗ hổng lịch sử của chúng. Các CRS này sẽ quá cụ thể đối với cuộc thi và có thể không sử dụng được trên các dự án nguồn khác nếu không có nỗ lực thủ công đáng kể để nhắm mục tiêu lại các CRS. Để giải quyết vấn đề tiềm ẩn này, chúng tôi khuyên ít nhất 65% các bài toán được tạo cho các dự án nguồn được giữ bí mật trước mỗi giai đoạn của cuộc thi.

Chúng tôi lo ngại về khả năng thuật toán chấm điểm từ chối PoV/PoU hợp lệ nếu trình dọn dẹp AIxCC quá chi tiết. Ví dụ: CWE-787 (ghi ngoài giới hạn), CWE-125 (đọc ngoài giới hạn) và CWE-119 (hoạt động bộ đệm ngoài giới hạn) đều được liệt kê trong báo cáo 25 điểm yếu hàng đầu của MITRE. Cả ba đều có thể hợp lệ để mô tả một lỗ hổng duy nhất trong một bài toán và được tham chiếu chéo trong cơ sở dữ liệu CWE. Nếu nhiều trình dọn dẹp được cung cấp cho mỗi CWE này nhưng chỉ một được coi là chính xác, thì có thể các bài nộp hợp lệ khác sẽ bị từ chối vì không phân biệt đúng cách giữa ba trình dọn dẹp có liên quan rất chặt chẽ. Chúng tôi khuyên rằng trình dọn dẹp AIxCC phải đủ thô để tránh việc phạt không công bằng đối với các PoU đã gửi.

Theo thiết kế hiện tại, các số liệu hiệu suất (ví dụ: thời gian chạy CPU, chi phí bộ nhớ, v.v.) không được giải quyết trực tiếp bởi các lĩnh vực xuất sắc của cuộc thi, cũng như không được tính vào điểm chức năng cho các bản vá. Hiệu suất là một yêu cầu phần mềm phi chức năng quan trọng và là một khía cạnh quan trọng của hiệu quả và khả năng chấp nhận của bản vá. Chúng tôi nghĩ rằng điều quan trọng là các bản vá do CRS cạnh tranh tạo ra phải duy trì hiệu suất của chương trình trong một ngưỡng chấp nhận được. Nếu không có sự xem xét này trong chấm điểm, các đội có thể gửi các bản vá hợp lệ và chính xác nhưng cuối cùng lại hoạt động kém đến mức chúng sẽ không được sử dụng trong một tình huống thực tế. Chúng tôi khuyên rằng điểm chức năng của cuộc thi nên được tăng cường bằng một thành phần hiệu suất.

Mặc dù chúng tôi đã nêu ra một số lo ngại trong phản hồi RFC của mình, nhưng chúng tôi rất hào hứng cho sự khởi động chính thức vào tháng 3 và cuộc thi thực tế vào cuối năm nay vào tháng 8.