Keamanan AI Membutuhkan Pendapat Kedua

AI menulis perangkat lunak lebih cepat daripada kemampuan kita mengamankannya. Apakah Anda mampu mengimbanginya?

Sebelum Anda selesai membaca kalimat ini, para pengembang dan agen AI mereka akan mengirimkan sekitar dua ribu commit kode. Pada waktu yang sama tahun lalu, jumlahnya sekitar 150.

Setahun terakhir, perangkat lunak yang dihasilkan AI berkembang dengan sangat pesat. GitHub mencatat 7,38 miliar commit pada September 2026 saja, lebih dari lima kali lipat jumlah setahun sebelumnya. Dampak ledakan ini terhadap keamanan sangat besar. Setiap commit itu berisi kode yang semestinya dipahami, dipelihara, dan diamankan oleh seseorang. Cloud Security Alliance menemukan bahwa pengembang yang dibantu AI di perusahaan Fortune 50 mengirimkan commit kode dengan laju tiga hingga empat kali lebih tinggi daripada rekan-rekan mereka, sementara temuan keamanan bulanan mereka meningkat sekitar sepuluh kali lipat.

Sekarang, bayangkan siapa yang harus menanggung dampak peningkatan itu. Ukuran tim CISO tetap sama seperti setahun lalu, tetapi tunggakannya tidak. Laporan kerentanan terus bertambah, perbaikan bulanan menurun, dan jumlah masalah kritis yang belum terselesaikan meningkat. Tak heran Gartner menyebut kelelahan CISO kian menjadi risiko operasional yang kritis.

Godaan Menggunakan Model Terbaru

Ketika angkanya begitu besar, kita terdorong mengejar angka yang lebih besar lagi: lebih banyak temuan, cakupan lebih luas, dan lebih banyak pemindaian. Namun, itu seperti menimba air dari perahu yang tenggelam lalu meminta ember yang lebih besar, padahal yang perlu dilakukan adalah mencari kebocorannya. Kinerja program keamanan tidak diukur dari banyaknya temuan. Ukurannya adalah seberapa banyak temuan itu benar-benar nyata dan berapa banyak temuan paling kritis yang benar-benar diperbaiki.

Model AI terdepan sangat piawai menemukan eksploitasi baru dan celah yang belum tercatat dengan menggunakan penalaran probabilistik. Namun, hasilnya bervariasi. Menurut riset Checkmarx, jika pemindaian dijalankan lima kali pada kode yang sama, hasil temuannya hanya cocok sekitar sepertiga dari waktu pemindaian.

Ketidakkonsistenan itulah sebabnya analisis berbasis aturan tetap penting. Metode ini tidak sefleksibel AI terdepan, tetapi selalu menerapkan logika teruji dengan cara yang sama, sehingga tim dapat memercayai dan memverifikasi hasilnya. AI menemukan hal-hal yang luput dari aturan, seperti kelemahan yang sudah dikenal tetapi muncul dalam bentuk tak lazim, atau cacat yang baru dapat dieksploitasi ketika bagian-bagian kode yang terpisah saling berinteraksi. Jika digunakan bersama, AI dan analisis berbasis aturan mengungkap lebih banyak hal penting dengan lebih sedikit peringatan palsu.

Semua ini bukanlah argumen untuk menolak AI. Intinya, keamanan membutuhkan pendapat kedua. Apa pun mesin yang Anda pilih, ajukan tiga pertanyaan berikut.

Pertanyaan Pertama: Keandalan Temuan

Jika pemindai menyatakan ada masalah, apakah masalah itu layak menyita waktu Anda?

Keandalan temuan menentukan apakah hasilnya dapat dipercaya. Temuan yang tidak benar menyita waktu pengembang selama berjam-jam dan sedikit mengikis kredibilitas tim keamanan. Dalam skala besar, positif palsu membuat tim berhenti menyimak. Peringatan itu hanya dianggap sebagai alarm palsu dan akhirnya tenggelam dalam kebisingan latar.

Di sinilah konsistensi menjadi penting. Analisis deterministik memberikan jawaban yang sama setiap kali kode yang sama diperiksa. Hal ini membangun kepercayaan dan membuat hasilnya dapat diaudit.

Pertanyaan Kedua: Akurasi

Apakah Anda menemukan semua masalah yang paling penting?

Keandalan temuan memberi tahu apakah suatu temuan layak menyita waktu Anda, tetapi tidak menunjukkan apa yang luput dari pemindai. Kami menggunakan ukuran praktis yang berasal dari ilmu data, yaitu skor F1. Skor F1 menilai kinerja dalam skala 1–0 berdasarkan dua faktor:

• Presisi: proporsi temuan yang dilaporkan dan benar-benar nyata. Presisi tinggi berarti lebih sedikit peringatan palsu.
• Recall: proporsi kerentanan nyata yang berhasil ditemukan pemindai. Recall tinggi berarti hanya sedikit yang terlewat.

Pemindai bisa tampak presisi jika hampir tidak menandai apa pun, atau tampak menyeluruh jika menandai semuanya, tetapi skor F1-nya rendah dalam kedua kasus. Rata-rata industri berada di sekitar 0,20. Kami telah bekerja keras mengatasi tantangan ini dan memperoleh hasil dengan akurasi tiga hingga empat kali lebih tinggi daripada pemindai standar.

Akurasi yang lebih baik mempermudah semua pekerjaan pengembang selanjutnya. Tim Anda menghabiskan lebih sedikit waktu untuk memvalidasi dan lebih banyak waktu untuk memperbaiki masalah.

Pertanyaan Ketiga: Imbal Hasil Investasi (ROI)

Bagaimana kita memaksimalkan investasi dan sumber daya?

Pertanyaan ini paling sering dilewatkan saat uji coba, tetapi jawabannya paling terasa dampaknya saat diterapkan dalam produksi.

Model terdepan mengenakan biaya berdasarkan token, dan token tetap terpakai meskipun pemindaian tidak menemukan apa pun. Dengan harga yang saat ini dipublikasikan, memindai repositori berisi satu juta baris kode membutuhkan biaya lebih dari seribu dolar. Penggunaan token antarmodel juga sangat berbeda; biayanya bervariasi bergantung pada model yang Anda pilih dan seberapa banyak penalaran yang diperlukan untuk menyelesaikan tugas Anda.

Kalikan biaya itu untuk setiap commit, pull request, dan repositori di sebuah perusahaan. Uber, yang menghabiskan $3,4 miliar per tahun untuk R&D, kabarnya telah menghabiskan seluruh anggaran AI 2026-nya hanya dalam beberapa bulan setelah meluncurkan alat pengodean AI.

Kami menyebutnya pajak token. Ibarat membawa Ferrari untuk membeli bahan makanan: Anda membayar daya yang tidak diperlukan untuk perjalanan itu. Kredensial yang dikodekan secara tetap dan injeksi SQL adalah pola yang dapat diprediksi dan dapat ditangani dengan andal oleh analisis deterministik.

Keamanan Aplikasi Harus Berkembang

Inilah alasan di balik arsitektur Checkmarx Fusion. Mesin berbasis aturan menetapkan kebenaran dasar secara konsisten dan dengan biaya lebih rendah daripada analisis berbasis token. Model terdepan diarahkan pada hal-hal yang tidak dapat diantisipasi oleh aturan: pola baru, logika kompleks, dan kemungkinan eksploitasi dalam konteksnya. Selanjutnya, lapisan analisis temuan menggabungkan hasil-hasil tersebut menjadi satu kumpulan tepercaya.

Analisis deterministik memberikan kepastian. AI memberikan jangkauan. Cakupan dan kepercayaan meningkat bersama. Dibandingkan dengan LLM yang bekerja sendiri, kami melihat fidelitas hingga empat kali lebih tinggi, akurasi dua hingga empat kali lebih tinggi, dan biaya sekitar sepertiganya.

Menemukan masalah hanyalah awal. Logika yang sama berlaku untuk pencegahan. Mari kita lihat contohnya. Dengan memberdayakan developer saat mulai membuat kode, di IDE tempat mereka menulisnya, kita dapat menghentikan masalah sebelum muncul. Demikian pula, untuk kerentanan yang berhasil lolos, mengapa tidak menyediakan perbaikan siap digabungkan kepada developer untuk kerentanan yang paling penting? Inilah tantangan yang kami upayakan untuk diatasi, dengan tujuan mengurangi tumpukan pekerjaan yang ada sedikit demi sedikit agar dampak dapat dirasakan secepat mungkin dengan upaya sekecil mungkin.

Kode Terus Berjalan. Bisakah Anda Mengimbanginya?

AI memberi penyerang hadiah berupa kecepatan. Cara untuk menutup kesenjangan itu bukanlah menambahkan satu alat lagi. Yang dibutuhkan adalah keputusan tentang cara seluruh organisasi Anda membangun dan mengamankan perangkat lunak. Kode yang ditulis hari ini akan menjalankan bisnis Anda selama bertahun-tahun. Pertanyaan bagi para pemimpin keamanan bukan lagi seberapa besar AI membantu Anda membangun dengan lebih cepat. Pertanyaannya adalah apakah program keamanan Anda mampu mengimbangi apa yang dihasilkan AI.

Jadi, jangan terpaku pada angka. Ajukan tiga pertanyaan tentang program apa pun: Dapatkah saya memercayai temuannya? Apakah program itu menemukan cukup banyak hal yang penting? Apakah penerapannya realistis di seluruh organisasi saya? Memadukan presisi deterministik dengan penalaran model terdepan memberi Anda peluang terbaik untuk menjawab ya atas ketiga pertanyaan tersebut.

Perangkat lunak tidak melambat. Tugas kita sekarang adalah menutup kesenjangan risiko: jarak antara seberapa cepat perangkat lunak dibuat dan seberapa cepat risiko ditemukan dan diperbaiki.