Apa yang terjadi
Para peneliti memperkenalkan FuzzingBrain-Bench V1, sebuah yang dirancang untuk mengukur penemuan bug terbuka oleh model bahasa besar. Daripada meminta model untuk mereproduksi kerentanan yang diketahui, benchmark memberikannya proyek sumber terbuka dan rangkaian pengujian yang diinstrumentasi pembersih di dalam image Docker mandiri. Model harus menghasilkan masukan yang memicu sebanyak mungkin tanda kerusakan yang berbeda.
Penulis menggambarkan FuzzingBrain-Bench V1 sebagai evaluasi kemampuan model AI untuk menemukan bug dalam perangkat lunak sumber terbuka tanpa target yang telah ditentukan. Setiap tantangan menyediakan proyek dan rangkaian instrumen pembersih dalam image Docker mandiri. Tugas model adalah menghasilkan masukan yang menyebabkan kerusakan melalui rangkaian kabel tersebut. Hal ini mengubah pertanyaan evaluasi dari “Dapatkah model mereproduksi kegagalan yang diketahui ini?” hingga “Berapa banyak kegagalan berbeda yang dapat ditemukan model dalam pengaturan pengujian yang tidak biasa?”
Tolok ukur ini menilai setiap tantangan berdasarkan jumlah tanda kerusakan berbeda yang dihasilkan. Skor dibatasi pada maksimum yang telah ditentukan dan ditimbang berdasarkan koefisien kesulitan. Versi pertama berisi 77 tantangan yang diambil dari 43 proyek sumber terbuka: 36 tantangan C, 32 tantangan C++, dan sembilan tantangan Java/JVM. Makalah ini adalah pracetak arXiv setebal 21 halaman yang diserahkan pada 25 Agustus 2026, dan penulis mengatakan korpus dan rangkaian tersedia untuk umum.
Para peneliti mengevaluasi Claude Haiku 4.5, Claude Sonnet 4.6 dan Claude Opus 4.8 di seluruh penuh. Menurut sumber tersebut, Opus 4.8 memiliki kinerja terbaik, memicu crash di 60 dari 77 tantangan dan menerima skor 196 dari 579. Tak satu pun dari ketiga model tersebut memicu crash di 13 tantangan. Sumber tersebut tidak memberikan skor penuh untuk kedua model lainnya atau menjelaskan masing-masing proyek yang memberikan hasil.
Mengapa itu penting
Tolok ukur tersebut mengatasi keterbatasan dalam banyak evaluasi yang ada: suatu model mungkin menemukan kegagalan valid yang tidak sesuai dengan kerentanan yang dipilih oleh perancang tolok ukur, namun tidak menerima penghargaan. Pengujian yang lebih terbuka dapat memberikan ukuran yang berguna tentang kinerja sistem AI selama penemuan kerentanan dan pengujian perangkat lunak, sekaligus menunjukkan di mana kemampuan sistem tersebut masih belum lengkap.
Evaluasi terbuka penting karena target yang telah ditentukan dapat mempersempit apa yang dianggap sebagai keberhasilan. Jika model menghasilkan error valid yang berbeda dari kegagalan target, tolok ukur spesifik target mungkin menganggap hasilnya salah atau tidak relevan. FuzzingBrain-Bench berupaya untuk menangkap kemampuan penemuan yang lebih luas dengan menghitung tanda-tanda kerusakan yang berbeda daripada memerlukan satu masukan pembuktian konsep tertentu. Desain tersebut dapat membuat perbandingan menjadi lebih informatif bagi pengembang yang menilai alat pengujian yang dibantu AI.
Hasilnya juga membatasi klaim tentang pengkodean AI dan kemampuan keamanan saat ini. Opus 4.8 memicu setidaknya satu crash di sebagian besar tantangan, namun skor keseluruhannya adalah 196 dari 579, dan ketiga model yang diuji gagal memicu crash di 13 tantangan. Crash adalah bukti bahwa suatu masukan menyebabkan program yang diinstrumentasi gagal; hal ini tidak dengan sendirinya merupakan bukti kerentanan keamanan yang dapat dieksploitasi dari jarak jauh, cacat dengan tingkat keparahan tinggi, atau patch yang berguna. Oleh karena itu, tolok ukur ini mengukur satu tahap penemuan yang penting, bukan penelitian kerentanan yang lengkap.
Korpus publik dan serangkaian rangkaian pengaman dapat memberikan peneliti keamanan perangkat lunak landasan pengujian umum untuk mempelajari perilaku model. Hal ini dapat membantu mengungkap apakah sistem hanya menemukan kegagalan yang nyata, apakah sistem dapat menjelajahi jalur kode yang tidak dikenal, dan bagaimana kinerjanya berubah seiring dengan kemampuan model atau desain tugas. Namun sumbernya adalah laporan tunggal dan tidak menetapkan bahwa pemeringkatannya akan berlaku pada repositori, bahasa, harness, versi model, atau lingkungan operasional lain.
Mekanisme Interaktif: Cara Kerja Sebenarnya
Jelajahi teknologi yang mendasari di balik perkembangan ini secara interaktif.
Which component of an AI application is the machine-learning model itself?
Apa yang harus ditonton selanjutnya
Pertanyaan utamanya adalah apakah menghasilkan hasil yang dapat diulang di seluruh model dan tim peneliti, seberapa cocok tanda kerusakan dengan bug perangkat lunak asli atau kerentanan keamanan, dan apakah kinerja dapat ditransfer di luar proyek sumber terbuka yang dipilih. Sumber melaporkan skor tolok ukur, namun tidak menetapkan kemampuan eksploitasi, tingkat keparahan, perbaikan, insiden di dunia nyata, atau validasi independen.
Tindak lanjut yang penting adalah replikasi independen. Sumber tersebut mengatakan korpus dan tali pengamannya tersedia untuk umum, namun tidak melaporkan hasil dari tim luar. Menjalankan kembali tantangan dengan versi model tetap, anggaran, dan izin alat akan membantu menentukan apakah peringkat yang dilaporkan kuat atau sensitif terhadap permintaan, waktu pencarian, infrastruktur, dan pilihan penerapan lainnya.
Para peneliti dan praktisi perlu mengkaji bagaimana tolok ukur tersebut mengubah kerusakan menjadi temuan yang relevan dengan keamanan. Sumber tersebut tidak mengatakan apakah kecelakaan tersebut telah diprioritaskan oleh manusia, dipetakan ke masalah yang diketahui, ditetapkan tingkat keparahannya, atau diubah menjadi patch. Hal ini juga tidak menyatakan bagaimana perilaku duplikat ditangani di luar penggunaan tanda kerusakan yang berbeda pada . Detail tersebut akan menentukan seberapa dekat skor tersebut melacak nilai praktis penemuan bug.
Cakupan tolok ukur ini merupakan batasan lain yang harus dipantau. 77 tantangannya berasal dari 43 proyek sumber terbuka dan fokus pada perangkat lunak C, C++ dan Java/JVM. Sumber tidak menetapkan kinerja pada bahasa lain, sistem kepemilikan, basis kode yang lebih besar, perangkat lunak yang aman untuk memori, atau layanan produksi. Ia juga tidak melaporkan biaya, waktu, akses alat, tingkat positif palsu, atau apakah masukan yang dihasilkan dapat merusak sistem di luar lingkungan Docker yang terisolasi.
Oleh karena itu, hasil penulis harus dibaca sebagai pengukuran awal, bukan sebagai bukti bahwa AI dapat mengamankan perangkat lunak secara independen. Langkah selanjutnya yang paling berguna akan mencakup serangkaian tantangan yang lebih luas, hasil per model yang transparan, validasi manusia atas cacat yang ditemukan, perbandingan dengan alat fuzzing yang sudah ada dan peneliti manusia, serta pengujian apakah model dapat menjelaskan, mereproduksi, dan membantu memperbaiki kegagalan yang mereka temukan. Hingga hasil tersebut tersedia, nilai praktis dari tolok ukur ini akan terlihat jelas sebagai cara untuk membuat klaim pengujian keamanan AI lebih menuntut dan sebanding.