CVE Palsu, Laporan Buatan AI, dan Perlunya Verifikasi

Membuat laporan kerentanan yang meyakinkan kini semakin murah, sehingga dampaknya bagi pengelola perangkat lunak dan tim keamanan pun semakin besar. Enam Kerentanan dan Paparan Umum (CVE) diumumkan untuk SQLite pada Juli 2026, dan dua di antaranya mendapat skor tingkat keparahan 9.8. Laporan-laporan itu tampak sahih, menguraikan bug keamanan memori serta menyertakan penjelasan teknis dan kode bukti konsep.

Namun, para peneliti JFrog menemukan bahwa beberapa fungsi yang disebut dalam laporan tersebut tidak ada pada versi yang terdampak. Selain itu, tak satu pun bukti konsep (PoC) berhasil mereproduksi kerentanan yang diklaim. Halaman CVE SQLite sendiri saat ini menyatakan bahwa keenam laporan tersebut bukan bug; catatan CVE-nya kemudian ditolak.

Masalah ini tidak hanya terjadi pada SQLite. Daniel Stenberg, pria yang memelihara curl, memperkirakan tahun lalu bahwa sekitar 20% laporan keamanan yang masuk merupakan hasil konten AI asal-asalan. Otoritas Penomoran CVE (CNA) GitHub menerima hampir 4.000 permintaan CVE pada Mei 2026; jumlah itu sekitar 10 kali lipat lebih banyak dibandingkan tahun sebelumnya. GitHub tidak menyalahkan AI atas peningkatan tersebut ataupun menyebut adanya penurunan kualitas pengajuan, tetapi lonjakan volume yang sangat besar ini menegaskan betapa kewalahannya proses pengungkapan kerentanan.

AI memudahkan pembuatan klaim kerentanan yang terperinci, tetapi menentukan apakah klaim tersebut sahih membutuhkan waktu. Setelah CVE masuk ke umpan keamanan dan basis data publik, memperbaiki catatan aslinya tidak otomatis membuat setiap salinannya ikut diperbaiki. Karena itu, kebutuhan untuk membedakan kerentanan yang dilaporkan dari kerentanan yang telah diverifikasi secara teknis semakin besar.

Apa Itu CVE “Palsu”?

Orang kerap menggunakan istilah “CVE palsu” untuk merujuk pada CVE yang kemungkinan dilaporkan secara keliru. Namun, palsu tidak berarti sengaja menyesatkan. Laporan semacam itu bisa muncul dari analisis statis yang luput mendeteksi pemeriksaan validasi atau keliru menganggap bahwa penyerang dapat mengendalikan masukan. Sebuah laporan mungkin menguraikan fungsi yang benar-benar ada, tetapi mengklaim jalur serangan yang tidak valid. Pengidentifikasi (ID CVE) dapat diberikan, lalu dicabut jika kondisi yang dilaporkan ternyata bukan kerentanan. Hal ini berbeda dari laporan yang sengaja direkayasa.

Sengketa juga bukan berarti CVE itu palsu. Vendor mungkin membantah temuan peneliti mengenai kemungkinan eksploitasi, batas ancaman, atau apakah suatu fungsi memang dirancang untuk memproses masukan yang tidak tepercaya. Namun, sengketa bukan bukti bahwa peneliti keliru. Penolakan CVE pun tidak serta-merta berarti CVE tersebut direkayasa; CVE bisa ditolak karena duplikat atau alasan administratif. Meskipun pengidentifikasi CVE bukan verifikasi teknis yang independen, industri tetap perlu menanggapi laporan yang nyata dengan serius.

Mengapa CVE Palsu Menjadi Masalah

Salah satu masalah yang kami lihat adalah orang menggunakan AI untuk membuat laporan kerentanan tanpa memvalidasi temuannya dengan semestinya. Laporan tersebut dapat memuat penjelasan teknis terperinci, rujukan kode, bahkan PoC, sehingga tampak sahih. Namun, seperti yang terlihat pada CVE SQLite, beberapa fungsi yang dirujuk ternyata bahkan tidak ada pada versi yang terdampak.

GitHub melaporkan peningkatan signifikan dalam pengajuan kerentanan pada 2026, meskipun tidak mengaitkan peningkatan itu dengan AI ataupun melaporkan penurunan kualitas pengajuan. Kekhawatirannya, semakin banyak laporan yang masuk, semakin besar pula pekerjaan yang diperlukan untuk menyelidikinya, terlepas dari benar atau tidaknya temuan tersebut.

Bagi mereka yang pernah melakukan triase laporan kerentanan, kesulitan praktisnya mudah dikenali. Model AI dapat mendeteksi pemanggilan API yang mencurigakan, menyusun gambaran awal skenario eksploitasi, lalu dengan cepat menghasilkan laporan yang tampak profesional. Untuk memastikan apakah skenario itu dapat dijalankan, mungkin perlu memeriksa rilis yang tepat, menelusuri alur kendali, memahami bagaimana data mencapai fungsi tersebut, membangun lingkungan pengujian, dan menjalankan eksploit yang diklaim. Prosesnya sama, baik laporan itu akurat maupun tidak, dan hal ini bisa memakan biaya besar.

CVE palsu juga dapat merusak reputasi. Pengumuman kerentanan dapat dengan cepat tersebar melalui umpan pemindai, basis data keamanan, dan hasil pencarian. Namun, koreksi yang menyusul mungkin tidak tersebar sejauh itu. Bahkan setelah laporan dibantah atau ditolak, vendor bisa terpaksa bersikap defensif di hadapan pelanggan yang telah melihat laporan aslinya.

Ada pula risiko kerentanan nyata terlewatkan atau tertunda karena tim menghabiskan waktu untuk menyelidiki laporan yang keliru. Ketika sumber daya pengelola perangkat lunak dan tim keamanan terbatas, setiap jam yang digunakan untuk membuktikan bahwa hasil positif palsu itu keliru merupakan waktu yang seharusnya bisa dipakai untuk menyelidiki masalah keamanan yang benar-benar ada.

Melawan dengan Otomatisasi

Banyak penyelidik masih melakukan triase secara manual untuk menangani gelombang laporan baru yang membanjir, tetapi cara ini tidak berkelanjutan. Otomatisasi terbukti sangat membantu dalam memverifikasi klaim kerentanan berdasarkan rilis dan konfigurasi yang benar-benar terdampak. Berikut lima pertanyaan yang perlu diajukan:

• Apakah prasyarat serangan masuk akal, termasuk konfigurasi dan izin yang diperlukan?
• Apakah fungsi yang dimaksud benar-benar ada pada versi yang terdampak?
• Dapatkah penyerang menjangkau kode yang rentan? Tentukan apakah kode terkait dapat dijalankan dalam kondisi yang terdampak dan apakah penyerang dapat memberikan masukan yang menjangkaunya.
• Dapatkah penguji mereproduksi perilaku tersebut dalam pengujian terkendali atau dengan PoC?
• Apakah perilaku yang diamati menunjukkan dampak keamanan yang dijelaskan dalam advisori?

Perangkat berbasis agen dapat membuat lingkungan pengujian, menganalisis jalur kode, menghasilkan PoC, dan merekam bukti eksekusi untuk ditinjau. Perangkat ini tidak dapat secara otomatis memastikan kebenaran setiap klaim. Bahkan ketika kerentanan memang autentik, PoC bisa gagal jika lingkungannya tidak lengkap atau pemicunya keliru. Penguji dapat mereproduksi kerusakan tanpa membuktikan bahwa kerentanan tersebut dapat dieksploitasi seperti yang diklaim. Hal-hal ini menjelaskan mengapa penilaian manusia tetap sangat penting. Namun, perangkat ini dapat membantu tim memperoleh jawaban yang dapat direproduksi sebelum sebuah laporan menyita lebih banyak waktu dari tim rekayasa, manajemen kerentanan, dan dukungan pelanggan.

Mengatasi Kewalahan dalam Ekosistem CVE

Tidak ada kebijakan ringkas yang bisa secara ajaib mengatasi masalah CVE palsu. Namun, masalah ini akan terbantu jika bukti yang diajukan diwajibkan lebih kuat dan status reproduksi dijelaskan dengan lebih terang. Penanganan catatan yang diperselisihkan juga perlu diperjelas, begitu pula koreksi data turunan yang perlu dilakukan lebih cepat. Peneliti sebaiknya didorong untuk memvalidasi temuan yang dibantu AI sebelum mengajukannya.

Tim keamanan dan vendor harus berfokus pada pemeriksaan bukti. Skor CVE kritis tidak mengungkapkan apakah jalur yang rentan dapat dijangkau di lingkungan mereka. Kegagalan PoC bukan berarti semuanya baik-baik saja. Dan menerima ID CVE tidak membebaskan tim dari kewajiban melakukan pekerjaan teknis yang diperlukan untuk memahami suatu masalah.

AI meningkatkan kemampuan untuk menemukan kerentanan, sekaligus memungkinkan terciptanya klaim yang tampak meyakinkan tetapi keliru. Di tengah semakin banyaknya laporan, organisasi perlu berinvestasi dalam verifikasi. Verifikasi mencakup penyusunan pengujian, reproduksi hasil, pemeriksaan asumsi, dan upaya agar bukti lebih mudah dinilai. Pengujian keamanan berbasis agen dapat memainkan peran penting dalam hal ini.