Scanner Keamanan AI Menagih Utang Teknis Kita

Sebuah laporan bug masuk ke tracker proyek PHP pada 2024. Isinya menggambarkan kondisi out-of-memory, jenis masalah yang membuat proses tumbang. Menjengkelkan, tapi dalam hierarki bug yang tidak resmi, biasanya hanya dianggap angin lalu. Laporan itu dibiarkan begitu saja. Lalu, selama audit independen terhadap PHP yang disponsori OpenAI, seorang peneliti dari firma keamanan Calif, dengan bantuan scanner keamanan AI dan keahliannya sendiri, menghabiskan sekitar dua minggu untuk mengubah crash yang remeh itu menjadi remote code execution. Server mana pun yang menjalankan build PHP rentan bisa dipaksa menjalankan kode penyerang atau membocorkan data sensitif. Situs-situs yang ikut terdampak mencakup NASA, Wikipedia, dan Gedung Putih, karena WordPress dan Drupal berjalan di atas PHP, dan PHP menopang porsi web yang mengejutkan besarnya.

Patch sudah dirilis sebelum ada pihak jahat yang sampai duluan, jadi ceritanya berakhir baik. Tapi para peneliti yang terlibat terus mengatakan hal yang sama: ini baru permulaan. Empat dekade kode yang ditulis manusia menyimpan lautan bug yang secara kolektif kita kategorikan sebagai 'crash, tidak akan diperbaiki', dan tooling AI telah memangkas biaya untuk mengetahui mana crash itu sebenarnya senjata yang sudah terisi. Beberapa minggu terakhir saya berbicara dengan orang-orang yang mengurus keamanan sistem nyata tentang apa yang berubah dalam praktik. Tulisan ini bukan survei. Ini kumpulan kesalahan yang sudah saya lihat dilakukan tim-tim, dan apa yang dilakukan orang-orang yang berhasil.

Kesalahan Pertama: Menganggap Bug Crash sebagai 'Menyebalkan tapi Tidak Berbahaya'

Bug PHP di inti cerita ini tidak tersembunyi. Ia dilaporkan, diakui, lalu diturunkan prioritasnya karena cuma 'hanya' menyebabkan error out-of-memory. Ini kegagalan triage paling umum di organisasi perangkat lunak yang sudah matang, dan pengembangan exploit berbantuan AI baru saja membuatnya mahal. Profesor Columbia Suman Jana, yang pernah meneliti kelas masalah semacam ini, menjelaskan dinamikanya dengan gamblang dalam wawancara seputar pengungkapan kasus ini: pada titik mana pun, setiap proyek besar punya tumpukan laporan crash yang tidak ada yang serius menanganinya, karena mengubah crash menjadi exploit butuh rantai penalaran yang panjang, membosankan, dan sangat spesifik. Manusia menghindari pekerjaan itu. Model tidak bosan.

Inilah versi mekanisnya mengapa perbedaan ini penting. Bug memori yang merusak heap dengan data tak terkendali biasanya hanya mematikan proses: allocator mendeteksi sesuatu yang tidak konsisten lalu membatalkan, atau proses membaca pointer sampah dan segfault. Tapi bug yang sama, jika diberi input yang ukuran dan bentuknya diatur dengan cermat, berubah menjadi primitif penulisan:

void handle_request(const char *input, size_t len) {
char *buf = malloc(64);
memcpy(buf, input, len);   /* len never validated */
/* len = 65:            heap metadata trashed -> likely abort, filed as 'crash' */
/* len = attacker-tuned: adjacent object's function pointer overwritten */
process(buf);             /* calls through the corrupted pointer -> their code runs */
free(buf);
}

Garis pemisah antara dua hasil itu bukan pada bug-nya, melainkan pada input. Mencari tahu bit mana yang harus ditimpa, dengan urutan apa, agar eksekusi mendarat di alamat yang diinginkan memang melelahkan tapi mekanis, dan 'melelahkan tapi mekanis' persis menjadi pusat kekuatan model bahasa. Perbaikan untuk kesalahan ini bersifat konseptual sebelum teknis: berhenti menjadikan 'cuma crash' sebagai sinyal tingkat keparahan untuk kode memory-unsafe. Crash di C atau C++ (atau di inti C dari interpreter seperti PHP) adalah exploit yang belum dikembangkan. Pertanyaan triage yang baru bukan 'apakah ini crash?' tapi 'apakah korupsinya dipengaruhi penyerang?' Jika input yang tidak tepercaya mengontrol ukuran, offset, atau isi penulisan yang buruk, anggap ia dapat dieksploitasi dan prioritaskan sesuai, bahkan ketika belum ada yang mendemonstrasikan exploit yang berfungsi. Terutama dalam kasus itu, karena exploit yang terdemonstrasi sekarang butuh minggu, bukan tahun.

Kesalahan Kedua: Memperlakukan Output Scanner Seperti Backlog

Mode kegagalan kedua muncul begitu tim benar-benar menjalankan scanner AI modern di seluruh sistem yang mencakup kode berusia dua puluh tahun. Tool-nya mengembalikan ratusan temuan, dasbornya memerah, dan tim melakukan apa yang dilatih oleh backlog: urutkan berdasarkan skor keparahan lalu mulai dari atas. Enam bulan kemudian mereka sudah memperbaiki empat puluh hal, jumlahnya malah naik, dan moral hancur. Para engineer yang saya ajak bicara dan menangani ini dengan baik semuanya mengatakan hal serupa: output scanner AI bukan backlog, melainkan intelijen mentah, dan butuh tahap triage oleh analis sebelum satu tiket pun dibuat.

Triage yang efektif dalam kondisi ini mengajukan pertanyaan tentang jalur exploit, bukan pertanyaan tentang skor keparahan:

• Apakah kode yang rentan bisa dijangkau dari input yang tidak tepercaya? Heap overflow di fungsi yang hanya memproses file konfigurasi lokal itu sangat berbeda dengan overflow yang sama di penanganan request.
• Apakah saat ini terekspos ke internet? Bukan 'seharusnya terekspos' tapi benar-benar terekspos. Periksa konfigurasi load balancer dan DNS, bukan diagram arsitektur.
• Apakah input mengontrol korupsinya? Ukuran, offset, atau isi akses yang buruk. Ini garis pemisah crash-vs-exploit dari bagian sebelumnya.
• Apa yang bisa didapat dari sebuah exploit? Crash di worker sandbox yang langsung dijalankan ulang berbeda dengan crash di proses yang memegang kredensial database.
• Apakah ada exploit yang sudah beredar di alam liar atau tulisan teknis publik? Ini langsung mendorong apa pun ke depan antrean, terlepas dari skornya.

Poin terakhir itu layak ditekankan. Skor seperti CVSS dirancang untuk dunia tempat manusia menemukan bug dengan laju manusia, dan skor tersebut secara sistematis melebih-lebihkan keparahan teoretis dibanding keterjangkauan. Ketika scanner bisa menghasilkan keparahan teoretis dalam skala industri, kita tenggelam. Tim yang paling bisa mengatasinya sudah membalik urutan pipeline: keterjangkauan dan eksposur dulu, keparahan kemudian, dan apa pun yang secara konstruksi tidak terjangkau didokumentasikan lalu ditutup, bukan diperbaiki, karena fix yang dikirim membawa risiko regresinya sendiri, dan Anda butuh anggaran risiko itu untuk temuan yang penting. Di sinilah pemeriksaan pemahaman kode AI membuktikan nilainya di sisi defensif: tooling yang sama yang menemukan bug sering kali bisa menjawab 'tunjukkan semua jalur pemanggilan dari batas jaringan ke fungsi ini' dalam hitungan menit, pertanyaan yang dulu butuh satu hari penuh bagi engineer senior untuk setiap temuan.

Kesalahan Ketiga: Mengira Patching Bisa Secepat Penemuan

Ini asimetri yang seharusnya dicetak di poster di setiap ruang tim keamanan. Menemukan jalur exploit bug PHP memakan waktu sekitar dua minggu bagi satu peneliti terampil dengan bantuan AI. Mengembangkan patch memakan waktu dua bulan bagi empat engineer. Menemukan adalah masalah pencarian: Anda hanya butuh satu jalur yang tembus. Memperbaiki adalah masalah berbentuk bukti: Anda harus menutup setiap jalur, dan miliaran instalasi yang tidak diserang harus tetap berjalan persis seperti sebelumnya. Pekerjaan defender jelas lebih sulit daripada penyerang, dan AI memangkas sisi penyerang dari celah itu jauh lebih cepat daripada sisi defender.

Tim yang mengabaikan asimetri ini membuat salah satu dari dua taruhan buruk. Mereka terburu-buru merilis patch untuk menyamai tekanan pengungkapan dan malah mengirim regresi, karena patch PHP menyentuh internal interpreter yang dipakai sekitar tiga perempat situs web yang mempublikasikan stack-nya, jadi radius dampak fix yang buruk itu sangat besar. Atau mereka putus asa dan tidak melakukan apa-apa sambil menunggu fix yang sempurna. Praktisi yang menangani jendela ini dengan baik melakukan sesuatu yang kurang heroik tapi lebih efektif: mereka memisahkan 'mitigasi sekarang' dari 'perbaiki dengan benar'. Mitigasi itu murah, cepat, dan bisa dibatalkan: batasi endpoint yang terdampak di reverse proxy, pasang aturan WAF yang memblokir bentuk input exploit, nonaktifkan jalur kode yang rentan lewat feature flag, kurangi siapa saja yang bisa menjangkau layanan selagi patch yang sebenarnya dimatangkan. Saya pernah menulis tentang bagaimana keputusan patch-vs-mitigasi adalah trade-off nyata, bukan kegagalan moral, dan insiden ini adalah pelajaran itu dalam skala planet.

Akibat yang tidak ingin didengar siapa pun: mean-time-to-mitigate Anda sekarang menjadi metrik yang paling penting, karena jarak antara 'bug ditemukan white hat' dan 'bug ditemukan oleh pihak yang lebih buruk' terus menyempit. Dalam kasus PHP, jendela itu tetap terbuka hanya karena para peneliti bertanggung jawab dan yayasan bergerak cepat. Pustaka kompresi Brotli menceritakan kisah yang kurang menyenangkan di periode yang sama: bug sebanding duduk di kode selama delapan tahun, sudah diperbaiki di git tapi tidak dirilis selama delapan bulan, dan ditemukan ulang secara independen oleh setidaknya empat peneliti. Ketika penemuan itu murah dan paralel, 'seseorang pasti akan menemukannya suatu saat nanti' berhenti menjadi pikiran yang menenangkan dan berubah menjadi jaminan penjadwalan.

Kesalahan Keempat: Percaya pada Fix karena Ditulis LLM

Argumen tandingan yang optimis berbunyi begini: baiklah, AI menemukan bug lebih cepat daripada kita bisa memperbaikinya hari ini, tapi AI juga akan memperbaikinya. Anthropic merilis tooling pada Oktober yang mengarah persis ke sini: sebuah LLM menghasilkan patch, lalu model kedua menghasilkan bukti yang bisa diperiksa mesin bahwa patch mempertahankan perilaku yang dimaksud, dan sebuah pemeriksa bukti yang kecil, sederhana, dan tepercaya memvalidasi bukti itu. Pemeriksa adalah satu-satunya komponen yang harus benar, dan ia bisa benar karena hampir tidak melakukan apa-apa. Jana sangat antusias dengan arah ini, dan saya paham alasannya: ini jalan pertama yang kredibel untuk membuat perbaikan hampir bisa diotomatisasi seperti penemuan.

Tapi saya sudah melihat dua tim mengadopsi alur kerja 'patch keamanan hasil AI', dan keduanya membuat kesalahan yang sama: mereka memperlakukan patch model sebagai solusi alih-alih kandidat. Dalam satu kasus, patch menutup heap overflow yang dilaporkan dengan menambahkan pengecekan panjang, tapi malah memindahkan overflow ke jalur alokasi kedua enam baris dari situ yang tidak dimodelkan oleh model. Fix itu lolos review karena tampak jelas benar, dan inilah mode kegagalannya: patch LLM lancar dengan cara yang tidak dimiliki patch manusia, dan kelancaran itu menekan pemeriksaan kritis. Tim yang mendapat nilai dari patch hasil generate menambahkan tiga gerbang, dengan urutan ini:

1. Suite regresi yang menyertakan input exploit. Proof-of-concept yang memicu temuan menjadi tes permanen. Jika scanner memberi Anda input yang membuat crash, itulah kasus tes baru pertama Anda, gratis.
2. Perburuan varian. Sebelum merge, seseorang (atau sesuatu) menjawab: di mana lagi pola yang sama ini muncul? Memperbaiki satu instance dari pola sistemik adalah cara Anda mendapatkan CVE sekuel.
3. Verifikasi independen terhadap invariant, bukan diff. Nyatakan apa yang sekarang harus benar, misalnya 'tidak ada jalur dari penanganan request yang mencapai memcpy dengan panjang yang belum divalidasi', lalu periksa itu dengan tes, analisis statis, atau tooling formal. Hanya meninjau diff sama saja dengan membaca ulang PR model.

Verifikasi formal akan membantu di sini seiring kematangannya, tapi perhatikan pembagian kerja yang membuatnya bisa dipercaya: bagian kreatif boleh berhalusinasi, karena juri akhirnya bersifat mekanis dan kecil. Itulah prinsip desain yang patut Anda curi, apa pun tooling-nya. Apa pun yang dihasilkan LLM, baik temuan, patch, maupun bukti, harus berujung pada sesuatu yang tidak berbagi mode kegagalannya. Jika langkah verifikasi Anda adalah prompt lain, Anda belum memverifikasi apa pun.

Kesalahan Kelima: Mengira Orang Lain Sudah Mengaudit Kodenya

Di bawah setiap pelajaran teknis di sini ada pelajaran ekonomi. PHP adalah infrastruktur berskala utilitas publik. Ia menopang WordPress, Drupal, dan ekor panjang web yang mencakup badan antariksa dan situs pemerintahan pusat. Keamanannya bertumpu pada PHP Foundation, sebuah badan kecil yang didanai, plus relawan. Mitos nyaman open source selalu berbunyi 'dengan cukup banyak mata, semua bug akan dangkal'. Yang terjadi selama tiga puluh tahun adalah semua orang mengira mata itu milik orang lain. AI kini memasok mata itu secara membabi buta, kepada penyerang maupun defender, yang berarti mitos itu akhirnya menjadi kenyataan, meski secara adversarial dan dengan tenggat waktu.

Pengungkapan PHP2Shell berhasil karena pengaturan yang tidak biasa: OpenAI menyponsori audit eksternal, sebuah firma bersumber daya besar melakukan pekerjaannya, dan Wiz membantu mengonfirmasi dan memperluas temuan. Itu amal, bukan sistem, dan tidak bisa diskalakan ke ribuan proyek kritis namun tanpa dana di pohon dependensi Anda. Jika produksi organisasi Anda bergantung pada interpreter, framework, atau pustaka open-source, dan memang begitu, perbaikan yang penting itu membosankan: danai yayasan, sponsori audit, sumbangkan jam kerja engineer, dan ketika Anda menjalankan scanner sendiri lalu menemukan sesuatu di dependensi, laporkan ke upstream alih-alih hanya menambal fork Anda lalu lanjut. Alternatifnya adalah dunia yang diprediksi Matthew Green dari Johns Hopkins: tidak ada yang berubah secara struktural sampai ada insiden cukup besar untuk mengusik orang biasa. Nasihatnya untuk sementara waktu itu tidak glamor tapi benar: ketika prompt pembaruan muncul, pasang sekarang, bukan minggu depan. Kita sudah belajar pelajaran yang sama dengan cara yang sulit di siklus pengungkapan PHP besar terakhir, ketika mencabut kabel lebih baik daripada fix cerdas bagi tim yang tidak bisa menambal cukup cepat.

Mata itu sudah datang. Mereka hanya tidak pilih-pilih soal berada di pihak mana.

Panduan Senin Pagi untuk Kerentanan yang Dimunculkan AI

Semua hal di atas bisa diringkas dalam daftar pendek tentang apa yang benar-benar akan saya lakukan kuartal ini jika saya memimpin organisasi engineering dengan kode lama di produksi, dan jika Anda membaca ini, Anda punya kode lama di produksi:

• Tambal agresif dan ukur berapa lama waktunya. Latensi pembaruan Anda sekarang adalah kontrol keamanan dengan ambang aman yang terus menyusut. Ketahui angka Anda sebelum Anda membutuhkannya.
• Triage ulang backlog bug crash yang ada dengan pertanyaan keterexploitan, bukan skor keparahan: apakah input tak tepercaya mengontrol korupsinya? Apa pun yang memory-unsafe dan terjangkau harus dinaikkan prioritasnya.
• Jalankan sendiri scanning berbantuan AI, mulai dari kode tertua Anda. Biaya marjinal untuk menemukan ulang sekarang hampir nol, artinya Anda harus menganggap apa pun yang bisa ditemukan di permukaan serangan Anda akan ditemukan. Temukan lebih dulu.
• Pisahkan mitigasi dari perbaikan dalam proses insiden Anda. Siapkan playbook sebelumnya: aturan proxy, feature flag, pembatasan akses. Membeli waktu adalah strategi yang sah; berpura-pura tidak butuh waktu bukan.
• Jadikan patch hasil generate bergantung pada tes input exploit dan perburuan varian, jangan pernah pada seberapa bersih diff-nya terlihat.
• Alokasikan uang atau jam kerja ke proyek upstream yang Anda andalkan. Audit bersponsor menemukan bug ini. Itu bukan kebetulan; itu model yang bekerja, dan sudah saatnya hal itu berhenti menjadi pengecualian.

Ada perdebatan yang wajar tentang apakah era ini adalah 'melunasi utang teknis' atau justru menjerumuskan kita ke treadmill pekerjaan perbaikan tanpa fitur selamanya. Mungkin keduanya: setiap patch non-trivial membawa risiko bug halus berikutnya, dan tidak ada sistem yang benar-benar selesai. Tapi saya lebih memilih hidup di dunia tempat utang ditagih oleh auditor dan white hat daripada dunia tempat kita terus berpura-pura pasir hisap itu dasar batu karena belum ada yang menelan kita. PHP2Shell berakhir dengan patch dan helaan napas lega. Yang berikutnya sudah ada di antrean crash seseorang, dicatat sebagai tidak berbahaya. Silakan periksa punya Anda.