AI bikin laporan bug makin murah. Yang mahal sekarang bukan “nemu kemungkinan vulnerability”, tapi buktiin bug itu nyata, penting, dan layak diprioritaskan.
Artikel ini membahas kenapa vulnerability report di era AI perlu standar bukti yang lebih jelas. Buat developer, maintainer open-source, dan tim security kecil, masalahnya bukan cuma jumlah laporan yang naik, tapi kualitas triage: reproduksi, impact, exploitability, severity, dan rencana patch. Kalau workflow ini nggak disiapkan, AI security scanner bisa berubah dari alat bantu jadi mesin pembuat noise.
Kenapa vulnerability report berubah di era AI?
Dulu, laporan security sering dianggap sinyal langka. Ada researcher yang meluangkan waktu, menemukan potensi celah, lalu mengirim laporan confidential ke maintainer. Karena sinyalnya relatif jarang, banyak tim merasa wajib memperlakukan setiap report sebagai prioritas tinggi.
Sekarang dinamikanya berubah. LLM dan AI security tooling membuat proses menemukan pola mencurigakan jadi jauh lebih murah. Orang bisa meminta model membaca kode, mencari smell, menulis laporan, bahkan menyusun narasi seolah-olah bug itu sudah pasti critical.
Masalahnya: “kelihatan seperti vulnerability” belum tentu sama dengan vulnerability yang bisa dieksploitasi. Di sinilah triage jadi mahal.
Apa itu security triage?
Security triage adalah proses menilai laporan vulnerability sebelum masuk tahap patch. Tujuannya bukan mengabaikan laporan, tapi memisahkan mana yang benar-benar actionable dan mana yang masih spekulasi.
Biasanya triage menjawab pertanyaan seperti ini:
- Apakah bug bisa direproduksi?
- Environment apa yang dibutuhkan?
- Impact realistisnya apa?
- Apakah butuh akses khusus atau kondisi langka?
- Severity-nya pantas critical, high, medium, atau low?
- Ada patch direction yang masuk akal?
Kalau laporan cuma berisi “kemungkinan XSS”, “potential RCE”, atau “AI detected insecure pattern” tanpa bukti reproduksi, maintainer tetap harus membayar biaya review. Waktu itu nggak gratis.
Bug report yang panjang belum tentu membantu
Filippo Valsorda menulis bahwa vulnerability reports tidak lagi se-“spesial” dulu karena volume dan biaya produksi laporan berubah. Menurut gua, poin paling pentingnya bukan “laporan security nggak penting”, tapi standar bukti harus naik.
AI bisa bikin report panjang, rapi, dan terdengar meyakinkan. Tapi maintainer nggak butuh report yang dramatis. Maintainer butuh laporan yang bisa diuji.
Ini mirip pull request AI-generated. Kode bisa kelihatan lengkap, tapi reviewer tetap perlu cek correctness, edge case, dependency, security, dan maintainability. Kalau AI menurunkan biaya submit, biaya review bisa pindah ke pihak lain.
Format vulnerability report yang lebih sehat
Kalau lu memakai AI buat bantu riset security, jangan berhenti di output pertama model. Pakai AI buat mempercepat investigasi, bukan buat memperbanyak laporan mentah.
Format minimal yang menurut gua lebih menghormati waktu maintainer:
- Ringkasan singkat: bug apa, komponen mana, dan kenapa penting.
- Impact realistis: data apa yang bocor, aksi apa yang bisa dilakukan attacker, atau limit apa yang bisa dilewati.
- Langkah reproduksi: command, request, payload, akun test, versi, dan konfigurasi yang dipakai.
- Bukti minimal: screenshot, log, request/response, test case, atau exploit demo yang aman.
- Batas klaim: jelaskan apa yang belum terbukti. Misalnya “belum diuji di production config”.
- Dugaan root cause: file, function, dependency, atau permission boundary yang dicurigai.
- Patch direction: validasi input, permission check, sandbox, rate limit, dependency update, atau test regression.
Dengan format ini, AI tetap boleh bantu. Tapi hasil akhirnya bukan spam “possible vulnerability”; hasilnya report yang bisa diverifikasi.
Kenapa ini penting buat open-source maintainer?
Open-source maintainer sering kerja dengan kapasitas terbatas. Banyak project besar pun dijaga oleh sedikit orang. Kalau tiap minggu masuk puluhan laporan AI-generated yang belum terbukti, maintainer bisa capek sebelum menyentuh bug yang benar-benar berbahaya.
GitHub sendiri sudah membahas pull request limits sebagai cara mengurangi noise di project open-source. Konteksnya bukan security report secara spesifik, tapi pola besarnya sama: ketika biaya membuat kontribusi turun, project perlu mekanisme untuk menjaga kualitas sinyal.
Di sisi lain, gua juga nggak setuju kalau semua laporan otomatis dicap spam. Ada laporan AI-assisted yang bisa sangat membantu, terutama kalau researcher tetap melakukan verifikasi manual dan memberi bukti yang jelas.
Jadi posisinya bukan anti-AI. Posisi yang lebih sehat: AI boleh mempercepat discovery, tapi manusia atau harness tetap harus membuktikan impact.
AI security scanner butuh harness, bukan cuma prompt
Cloudflare pernah menulis soal membangun vulnerability harness. Ini penting karena security AI yang serius butuh lingkungan uji: ada target, input, expected behavior, observability, dan cara memvalidasi apakah exploit benar-benar terjadi.
Kalau scanner cuma membaca kode lalu menebak “ini mungkin vulnerability”, output-nya gampang terlihat pintar tapi sulit dipercaya. Kalau scanner punya harness, dia bisa mencoba membuktikan bug lewat test yang reproducible.
Untuk developer kecil, harness nggak harus langsung kompleks. Mulai dari hal sederhana:
- Bikin sample app atau fixture yang merepresentasikan bug.
- Tulis test yang gagal sebelum patch dan lolos setelah patch.
- Simpan payload yang dipakai untuk reproduksi.
- Catat versi dependency dan konfigurasi.
- Jangan klaim severity sebelum impact terbukti.
Ini jauh lebih berguna daripada report AI yang penuh istilah security tapi nggak bisa dijalankan ulang.
Checklist sebelum lu mengirim laporan security
Kalau lu mau laporan lu dibaca serius, cek ini dulu:
- Apakah maintainer bisa menjalankan ulang langkah reproduksi tanpa menebak-nebak?
- Apakah impact-nya spesifik, bukan sekadar “could lead to compromise”?
- Apakah lu menulis versi software, environment, dan konfigurasi?
- Apakah bukti lu aman dibagikan dan tidak mengekspos data orang?
- Apakah severity masuk akal dibanding exploitability?
- Apakah ada saran patch atau minimal lokasi kode yang perlu dicek?
- Apakah klaim dari AI sudah lu validasi manual?
Kalau jawabannya banyak yang “belum”, mungkin laporan itu belum siap dikirim. Simpan dulu sebagai catatan investigasi, bukan langsung jadi report ke maintainer.
Takeaway buat developer dan builder
Era AI membuat discovery lebih murah, tapi verification tetap mahal. Ini pola yang muncul di banyak tempat: PR makin mudah dibuat, artikel makin mudah ditulis, audit makin mudah dimulai, tapi kualitas akhir tetap bergantung pada proses verifikasi.
Buat rafli.dev, pelajarannya jelas: tool AI yang bagus bukan yang paling banyak menghasilkan output. Tool AI yang bagus membantu lu mengurangi ketidakpastian.
Dalam security, itu berarti membantu membuktikan bug, mengurangi false positive, memperjelas impact, dan mempercepat patch. Kalau AI cuma menambah daftar “mungkin bahaya”, berarti dia belum menyelesaikan bottleneck utama.
FAQ singkat
Apakah vulnerability report masih penting?
Masih. Yang berubah adalah standar bukti. Laporan yang punya reproduksi, impact, dan patch direction tetap sangat berharga.
Apakah AI security scanner buruk?
Nggak otomatis. Scanner AI bisa berguna kalau dipakai bersama validasi, test, sandbox, dan review manual. Yang berbahaya adalah memperlakukan tebakan AI sebagai bukti final.
Maintainer harus menolak semua laporan AI-generated?
Nggak. Lebih masuk akal menilai kualitas report-nya: apakah bisa direproduksi, apakah impact jelas, dan apakah klaimnya proporsional.
