CyberGym Benchmark Dijelaskan: Apa yang Sebenarnya Diukur oleh Skor E2E

Skor CyberGym yang paling luas beredar — angka dalam postingan peluncuran, yang dibandingkan lintas model — adalah tingkat keberhasilan tugas pada 131 tugas tersaring, dengan keberhasilan berarti agen menghasilkan input proof-of-concept yang membuat build C/C++ yang belum ditambal crash, menulis patch yang menghentikan crash tersebut, dan tidak merusak tes yang ditulis pengembang proyek. Dalam kompilasi BenchLM, MiMo-V2.6-Flash memimpin dengan 95.1% dan MiMo-V2.6-Pro dengan 94.0%, sementara DeepSeek-V4.1-Flash tertinggal beberapa poin di kisaran tinggi delapan puluhan. Hampir tak seorang pun yang mengutip tabel itu menyebutkan tiga hal yang menentukan apakah angka-angka tersebut sebanding: benchmark tersebut ada dalam lebih dari satu implementasi, sebagian besar barisnya adalah laporan mandiri penyedia, bukan uji independen, dan tahap yang paling menarik dicatat tetapi tidak dihitung. Itulah standar atribusi yang sama yang arsip insiden AIterapkan pada entri-entrinya sendiri — klaim tanpa sumber bukanlah hasil — dan korpus CyberGym lebih sering gagal memenuhinya daripada yang disiratkan reputasinya.

Ini adalah panduan tentang apa yang diminta benchmark kepada agen untuk dilakukan, bagaimana kumpulan tugas dibangun, di mana implementasinya berbeda, dan apa yang seharusnya dan tidak seharusnya disimpulkan seorang defender dari skor yang tinggi.

Tugas: temukan, reproduksi, tambal — tanpa merusak apa pun

CyberGym berasal dari Berkeley Center for Responsible, Decentralized Intelligence, dan premisnya sengaja dibuat sempit. Setiap tugas menyasar kerentanan keamanan memori dalam proyek C/C++ open-source yang banyak digunakan. Agen harus menemukan bug, menulis input proof-of-concept yang memicu crash sanitizer, lalu menambal kode sehingga crash tersebut tidak lagi dapat direproduksi — sementara tes milik proyek itu sendiri tetap lulus. Urutan itulah inti persoalannya. Benchmark yang hanya meminta "temukan bug" akan memberi imbalan pada pengenalan pola; mewajibkan input crash yang berfungsi dan patch yang tidak merusak memaksa agen menutup lingkaran dari kecurigaan menuju defect yang terbukti hingga perbaikan.

RDI menyelenggarakan benchmark ini di dalam observatorium yang lebih luas yang melacak kapabilitas siber AI pada tahap serangan dan pertahanan, dan cara pembingkaiannya layak diperhatikan: CyberGym adalah salah satu instrumen di bangku uji, bersama ExploitGym dan varian end-to-end. Membacanya sebagai papan peringkat mandiri akan kehilangan konteks itu, yang menjadi salah satu alasan angka-angka tersebut sulit dibawa dengan baik.

Empat tahap, tiga di antaranya memberi poin

Aturan penilaian adalah bagian benchmark yang paling kurang dilaporkan, karena di sinilah skor yang terdengar masuk akal dapat menyimpang dari apa yang sebenarnya terjadi.

Tahap 1 adalah reproduksi: apakah input proof-of-concept dari agen membuat build yang belum ditambal crash. Tahap 2 adalah patch: apakah perubahan yang dikirimkan menghentikan crash spesifik tersebut. Tahap 3 adalah regresi: apakah tes fungsionalitas yang ditulis pengembang masih lulus. Ketiganya menghasilkan skor.

Tahap 4 menanyakan apakah patch memperbaiki kerentanan ground-truth yang sebenarnya, dan hal ini dicatat sebagai diagnostik, bukan dihitung. Asimetri itu perlu direnungkan sejenak, karena itulah perbedaan antara "agen dapat membuat crash hilang" dan "agen dapat memperbaiki bug". Keduanya adalah klaim yang berguna; keduanya bukan klaim yang sama. Agen yang menekan crash dengan menangkap sinyal, memperlebar pemeriksaan batas melewati overflow, atau menonaktifkan jalur kode sepenuhnya akan mendapat skor pada tahap 1 sampai 3 dan gagal pada tahap 4. Jika sebuah laporan menuliskan satu angka tanpa menyebutkan apakah tahap 4 diperiksa, Anda tidak dapat mengetahui mana dari dua hal itu yang diukur — dan diagnostik itu ada justru supaya Anda dapat bertanya.

Bagaimana 131 tugas itu dipilih — dan apa pengaruhnya terhadap skor

Dataset sumber lebih besar daripada kumpulan yang dinilai, dan pemfilteran adalah pengungkit tunggal terbesar untuk komparabilitas. Dataset RDI berisi 920 kerentanan di 139 proyek sumber terbuka, yang diambil dari OSS-Fuzz milik Google. Varian end-to-end yang digunakan oleh pelacak pihak ketiga mempersempitnya menjadi 131 tugas, dengan satu tugas per proyek, dipilih berdasarkan kesulitan, tidak termasuk tugas dengan kebocoran oracle atau batasan kompatibilitas sandbox.

Tiga konsekuensi mengikuti secara langsung. Pertama, satu tugas per proyek berarti skor didominasi oleh keluasan alih-alih kedalaman: agen yang rata-rata di banyak proyek akan mengungguli agen yang sangat baik pada tiga proyek, yang merupakan pilihan desain yang dapat dipertahankan dan pengukuran yang berbeda dari "berapa banyak kerentanan yang dapat diperbaiki agen ini". Kedua, mengecualikan kebocoran oracle menghapus tugas yang jawabannya dapat ditemukan dari lingkungan alih-alih disimpulkan melalui penalaran, sehingga kumpulan yang tersisa lebih sulit dalam cara tertentu — ini menghilangkan jalan pintas alih-alih menghilangkan tugas yang mudah. Ketiga, anggaran 90 menit per tugas di dalam sandbox yang dibangun dari image OSS-Fuzz proyek adalah bagian dari definisi keberhasilan, bukan detail, karena porsi besar pekerjaan kerentanan nyata dibatasi oleh persis jenis kendala seperti itu dan agen yang bergantung pada eksplorasi tanpa batas akan gagal di sini sementara berhasil di tempat lain.

Perbandingan apa pun yang mengabaikan aturan pemilihan tugas sedang membandingkan dua tes berbeda yang kebetulan memiliki nama yang sama.

Dua implementasi, dan mengapa keduanya tidak harus sama

Di sinilah sebagian besar kebingungan berada. CyberGym-E2E ada sebagai benchmark RDI dan sebagai implementasi yang dijalankan oleh evaluator pihak ketiga, dan keduanya tidak dijamin menghasilkan angka yang sama untuk model yang sama. Dokumentasi evaluator itu sendiri menyatakannya secara gamblang: implementasinya menggunakan kumpulan tugas yang difilter sebanyak 131 tugas, satu per proyek, yang dipilih berdasarkan tingkat kesulitan, dan implementasi itu menjalankan setiap tugas dalam sandbox terisolasi yang dibangun dari image OSS-Fuzz proyek tersebut menggunakan harness agen miliknya sendiri dengan anggaran 90 menit per tugas.

Kalimat itu memuat dua variabel yang menentukan skor. Harness adalah loop tempat agen berjalan — bagaimana ia mengamati keluaran alat, berapa langkah yang dapat ia ambil, bagaimana ia pulih dari upaya yang gagal. Harness yang lebih kuat dengan model yang lebih lemah dapat mengalahkan kebalikannya, dan harness bukan bagian dari bobot model. Anggaran berinteraksi dengan keduanya. Jadi angka CyberGym ditulis dengan tepat sebagai "model ini, dalam harness ini, dalam implementasi ini", dan angka yang dikutip tanpa implementasinya adalah angka tanpa penyebut.

Ada efek orde kedua yang perlu dikemukakan: karena harness melakukan pekerjaan nyata, peningkatan skor CyberGym antara dua versi model dapat sebagian merupakan peningkatan harness, dan vendor yang melaporkan hasil harness-nya sendiri sedang melaporkan kemampuan sistem, bukan kemampuan model. Keduanya sah; mencampuradukkannya tidak.

Membaca tabel pelacak dengan jujur

Tabel yang paling sering orang temui adalah kompilasi sekunder, dan tabel itu mencantumkan asal-usulnya sendiri — yang merupakan bagian berguna, jika Anda membaca labelnya. Dari 29 baris, 7 berasal dari pemilik benchmark atau eksekusi independen, 21 merupakan laporan mandiri penyedia, dan satu adalah laporan sekunder. Kompilasi tersebut menyatakan secara terang-terangan bahwa tabel ditampilkan sebagai referensi dan tidak memberi peringkat berdasarkan tabel itu, serta menyarankan pembacaan dengan hati-hati karena sebagian besar baris adalah laporan mandiri. Catatan saturasinya sendiri adalah baris paling berguna di halaman itu: tiga teratas tersebar sekitar 70 poin sementara sepuluh teratas berada dalam kisaran sekitar 10, jadi tabel masih memisahkan model — tetapi tidak di bagian atas rentang, tempat urutannya tipis.

Laporan mandiri penyedia adalah bukti yang dapat ditampilkan. Ini bukan pengukuran independen, dan perbedaan itu lebih penting dalam tolok ukur ini dibandingkan di sebagian besar kasus lain, karena variabel harness memberi vendor ruang yang cukup besar untuk menyetel angka yang dilaporkannya. Ketika laporan mandiri dan proses independen tidak sepakat, hasil independen yang menang. Ketika hanya ada laporan mandiri, pembacaan yang jujur adalah "belum terverifikasi, masuk akal, tidak ada dasar pembanding".

Peringatan yang sama berlaku secara terbalik terhadap jebakan yang dipasang benchmark ini bagi pembaca: model tanpa baris CyberGym belum mendapat nilai nol. Model itu belum diukur dalam harness tersebut, yang merupakan pernyataan berbeda. Menganggap ketiadaan sebagai kegagalan adalah cara sebuah tabel berhenti menjadi pengukuran dan berubah menjadi papan peringkat.

Apa yang dapat dan tidak dapat disimpulkan dari skor tinggi bagi seorang bek

Pertanyaan yang sebenarnya dimiliki tim keamanan bukanlah "model mana yang menduduki peringkat teratas", melainkan "apa yang dilakukan agen yang mendapat skor baik dalam hal ini terhadap risiko saya". Tolok ukur ini menjawab pertanyaan yang lebih sempit daripada yang diajukan, dan kesenjangan itu layak disebut.

Ini memang berarti agen dapat, dalam 90 menit dan di dalam build yang diketahui, menemukan bug keamanan memori dalam kode sumber terbuka nyata, menghasilkan input crash yang berfungsi, dan menulis perubahan yang menghentikan crash tanpa merusak tes. Itu adalah kemampuan yang nyata, langsung relevan dengan triase dan pekerjaan patch, dan itu adalah jenis tugas di mana agen yang kompeten secara signifikan mempersingkat antrean analis.

Ini tidak berarti agen memahami basis kode Anda, model ancaman Anda, atau deployment Anda. Tugas-tugasnya diambil dari target OSS-Fuzz publik dengan kerentanan ground-truth yang diketahui dan rangkaian tes yang memberi tahu agen apakah sudah selesai. Kode produksi tidak memiliki oracle semacam itu. Ini juga tidak berarti agen akan menemukan bug tersebut, bukan sembarang bug: tahap 4 ada karena keduanya berbeda, dan tahap 4 tidak dihitung.

Dan hal itu tidak terbawa ke sisi ofensif, yakni sisi ketika kapabilitas yang sama dimaknai secara berbeda. Agen yang dapat menemukan dan mereproduksi cacat keamanan memori dapat melakukannya pada kode yang tidak diberi izin untuk diuji, itulah sebabnya kapabilitas pada tingkat ini justru menjadi alasan kontrol akses di tingkat model, bukan sekadar pernyataan penyangkalan dalam prompt sistem.

Apa yang perlu ditanyakan sebelum memercayai angka CyberGym

Lima pertanyaan, yang dapat dijawab dari laporan yang ditulis dengan baik dan biasanya tidak dapat dijawab dari postingan peluncuran.

• Implementasi yang mana? Tolok ukur RDI, atau varian tersaring dari evaluator pihak ketiga. Jika laporan tidak menyebutkannya, angka tersebut tidak dapat dibandingkan dengan apa pun.

• Dijalankan oleh siapa? Evaluasi independen atau laporan mandiri penyedia. Tabel kompilasi memberi label ini per baris; kebanyakan materi pemasaran tidak.

• Harness apa, dan berapa anggarannya? Jika harness tersebut milik vendor sendiri dan tidak dijelaskan, anggap hasilnya sebagai klaim tingkat sistem tentang konfigurasi produk tertentu.

• Apakah tahap 4 dikonsultasikan? Tingkat yang dilaporkan beserta diagnostik di sampingnya memberi tahu Anda apakah patch memperbaiki bug atau sekadar membungkam crash.

• Set tugas yang mana? 131 tugas satu per proyek yang dipilih berdasarkan tingkat kesulitan adalah set yang umum; filter yang berbeda adalah pengujian yang berbeda.

Cybergym adalah tolok ukur yang dibangun dengan baik untuk tugas nyata yang sulit, dan konstruksinya lebih menarik daripada papan peringkatnya. Tahapan-tahapannya memberi tahu Anda apa yang harus dilakukan seorang agen; penyaringannya memberi tahu Anda skor itu adalah skor dari apa; harness-nya memberi tahu Anda siapa yang berhak mendapat kredit. Angka yang datang dengan ketiganya terlampir benar-benar berguna. Angka yang datang sendiri hanyalah siaran pers dengan tanda persen.