Mengapa Kode yang Dihasilkan AI Menghancurkan Model Manajemen Kerentanan Anda

Penghasil kode AI telah melakukan sesuatu yang tidak pernah berhasil dilakukan oleh alat DevOps selama bertahun-tahun: mereka membuatnya mungkin untuk mengirimkan fitur dalam beberapa hari yang biasanya membutuhkan beberapa minggu. Masalahnya adalah bahwa kecepatan ini juga berlaku untuk kerentanan.

Selama bertahun-tahun di bidang keamanan siber, saya telah menyaksikan organisasi berganti-ganti pola reaktif yang sama: menemukan kerentanan, berusaha memahami cakupannya, bertengkar tentang siapa yang bertanggung jawab untuk memperbaikinya, dan memperbaikinya beberapa minggu atau bulan kemudian. AI tidak mengubah pola ini. Ini hanya mempercepatnya hingga titik di mana model lama tidak dapat lagi mengimbanginya. Rata-rata waktu MTTR untuk CVE kritis adalah lebih dari 60 hari. Pengembangan yang dibantu AI tidak memberi Anda 60 hari. Ini memberi Anda basis kode baru setiap sprint.

Masalah Ketergantungan Sekarang Menjadi Masalah AI

Enam puluh enam persen aplikasi perusahaan termasuk komponen sumber terbuka. Sebagian besar tidak pernah diverifikasi secara ketat, hanya ditarik dari registri publik karena mereka berfungsi dan seseorang membutuhkannya pada sore hari. Tim keamanan telah kehilangan kendali atas ini selama bertahun-tahun, dan asisten pengkodean AI telah mengubah perdarahan lambat menjadi sesuatu yang jauh lebih sulit untuk dikendalikan.

Ketika seorang pengembang menulis kode secara manual, mereka membuat pilihan yang disengaja tentang ketergantungan. Ketika model AI menghasilkan kode, ini menarik dari apa yang pernah dilatih. Ini sering berarti paket yang dihalusinasi, versi yang sudah ketinggalan zaman, atau komponen dengan CVE yang diketahui yang model tidak memiliki alasan untuk menghindarinya. Kode itu tiba dengan terlihat bersih. Risikonya tertanam dalam pohon ketergantungan, beberapa lapis di bawah, tidak terlihat oleh siapa pun yang tidak mencari khusus untuk itu.

Saya telah duduk dalam tinjauan keamanan di mana tim terkejut menemukan CVE kritis dalam ketergantungan transitive dari paket yang mereka setujui beberapa bulan sebelumnya. Paket itu tidak bermasalah. Apa yang ditariknya tidak. Dinamika ini sekarang terjadi pada skala mesin, di seluruh ratusan pengembang yang menggunakan alat AI yang tidak memiliki konsep tentang postur keamanan organisasi Anda.

Pemindaian Setelah Fakta Tidak Adalah Strategi

Model yang berlaku untuk keamanan perangkat lunak sumber terbuka adalah pemindaian dan perbaikan: jalankan pemindai, triase temuan, tetapkan tiket, dan tunggu. Model ini selalu reaktif, dan dalam lingkungan pengembangan yang dipercepat AI, ini benar-benar ketinggalan.

Pemindai menemukan masalah setelah mereka sudah ada dalam kode Anda. Jendela antara pengenalan dan penemuan adalah tempat di mana paparan Anda hidup. Ketika AI menghasilkan kode pada skala besar, jendela itu menjadi lebih lebar dan volume temuan tumbuh lebih cepat daripada tim mana pun dapat memperbaikinya secara manual. Hasilnya adalah backlog CVE yang berkembang tanpa henti, prioritas yang menjadi tebakan, dan pengembang menghabiskan 4 hingga 8 jam per kerentanan pada pekerjaan yang menghasilkan nol nilai bisnis.

Tambahkan kehancuran tata kelola yang mengikuti dan gambarannya menjadi lebih buruk. Kepemilikan perbaikan sering tidak jelas. Keamanan menandai CVE, teknik menyebutnya pertanyaan konfigurasi, dan operasi menyebutnya masalah kode. Saya melihat pola ini 20 tahun yang lalu dan itu tidak pernah hilang. AI membuat konsekuensi dari ketidakjelasan itu jauh lebih sulit untuk diserap.

Perubahan yang Benar-Benar Berfungsi: Kontrol Apa yang Masuk

Organisasi yang mendahuluinya telah berhenti mencoba memindai jalan mereka ke keamanan dan memulai mengontrol apa yang dapat dikonsumsi oleh pengembang dan alat AI mereka pada awalnya. Mekanisme ini adalah katalog komponen sumber terbuka yang dikurasi, diperintah oleh kebijakan, dibangun dari sumber, dipantau terus-menerus, dan disajikan sebagai registri internal pribadi yang menggantikan penarikan langsung dari ekosistem publik seperti PyPI, npm, atau Maven.

Pendekatan ini menggeser keamanan ke kiri dalam arti yang paling harfiah. Kerentanan diblokir pada titik konsumsi, sebelum mereka pernah memasuki pipa bangunan. Pengembang menggunakan alat yang sama yang mereka gunakan selama ini. Asisten pengkodean AI menyelesaikan ketergantungan dari sumber yang diperintah. Tim keamanan menetapkan kebijakan sekali, dan kebijakan itu berlaku di mana-mana, termasuk kode yang dihasilkan model pada pukul 2 pagi tanpa ada yang meninjaunya.

Apa yang Terlihat dalam Praktik

Untuk pemimpin keamanan yang bekerja melalui ini, beberapa hal lebih penting daripada yang lain:

1. Tentukan set komponen yang disetujui sebelum Anda menskalakan adopsi AI. Jika alat pengkodean AI Anda menyelesaikan ketergantungan dari registri publik, proses persetujuan Anda hanya ada di atas kertas. Buat registri internal yang diperintah, arahkan semuanya melalui itu, dan minta komponen dibangun dari sumber dengan provenance yang dapat diverifikasi.
2. Perlakukan perbaikan sebagai proses yang dikelola, bukan antrian tiket. Organisasi yang tetap di depan utang CVE tidak bergerak lebih cepat pada perbaikan manual. Mereka telah menghapus perbaikan manual dari persamaan. Ketika patch komunitas yang disetujui tersedia, itu dibangun kembali ke dalam katalog secara otomatis. Pengembang mendapatkan pembaruan berikutnya kali mereka menarik. Tidak ada yang menetapkan tiket. Tidak ada yang menunggu 60 hari.
3. Peta rantai alat AI Anda ke kewajiban kepatuhan sebelum Anda dipaksa untuk melakukannya. Saya telah menyaksikan tim membangun pada alat AI selama berbulan-bulan, hanya untuk menemukan dinding ketika pelanggan meminta penyelarasan FedRAMP atau bukti SOC 2. Katalog yang dikurasi Anda juga merupakan jejak audit kepatuhan Anda. SBOM dan catatan provenance harus dikirimkan dengan setiap komponen, bukan dirakit secara retroaktif di bawah tekanan deadline.
4. Tetapkan kepemilikan yang jelas pada lapisan tata kelola, bukan lapisan tiket. Tim yang bergerak paling cepat pada perbaikan adalah tidak mereka yang memiliki pengembang paling banyak. Mereka adalah tim di mana tim keamanan memiliki kebijakan, tim platform memiliki pengiriman, dan tidak ada yang menunggu yang lain untuk bertindak.

Keamanan yang Memungkinkan Daripada Memblokir

Ada keyakinan yang bertahan bahwa keamanan dan kecepatan pengembangan berada dalam konflik fundamental. Saya tidak pernah menemukan itu benar ketika keamanan dirancang ke dalam proses daripada dipasang di atasnya. Pengembang yang bekerja dari set komponen yang dikurasi sebenarnya bergerak lebih cepat, karena mereka tidak lagi mempertanyakan persetujuan, menunggu tinjauan keamanan, atau membersihkan kerentanan yang bisa diblokir di hulu.

Organisasi yang akan menavigasi pengembangan yang didorong AI tanpa mengumpulkan utang keamanan yang tidak berkelanjutan bukanlah mereka yang menjalankan pemindai paling banyak. Mereka adalah mereka yang telah membuat keputusan yang disengaja untuk mengatur apa yang memasuki rantai pasokan perangkat lunak mereka sebelum menjadi masalah respons insiden. Keputusan itu milik kepemimpinan. Alat untuk melaksanakannya ada hari ini.