Laporan Kesenjangan Kerentanan AI Azul 2026 Menemukan bahwa Penerapan Patch di Perusahaan Tertinggal dari Ancaman AI

Laporan Kesenjangan Kerentanan AI 2026 dari Azul menemukan ketimpangan antara kecepatan yang menurut para pemimpin keamanan dapat dicapai penyerang dengan bantuan AI dan waktu yang dibutuhkan organisasi mereka untuk menerapkan perbaikan. Dalam survei terhadap 300 pemimpin keamanan di AS, 69% mengatakan penyerang dapat membuat eksploit yang berfungsi dalam waktu tiga hari, sementara 44% mengatakan organisasi mereka membutuhkan waktu empat hari atau lebih untuk memasang patch pada kerentanan kritis di seluruh lingkungan produksi.

Temuan paling mencolok dalam laporan ini adalah pengalaman yang dikaitkan responden dengan keterlambatan tersebut: 85% melaporkan insiden, dugaan insiden, atau kejadian nyaris terjadi yang disebabkan oleh lambatnya pemasangan patch. Angka ini menggambarkan pengalaman yang dilaporkan, bukan tingkat pelanggaran keamanan yang diverifikasi secara independen—dan tidak membuktikan bahwa AI menyebabkan kejadian-kejadian tersebut.

Penelitian yang dipesan oleh Azul dan dilaksanakan oleh Censuswide ini berfokus pada organisasi dengan penerapan Java berskala besar. Pesan utamanya lebih bersifat operasional: mengenali kerentanan hanyalah langkah awal. Perbaikan harus lolos pengujian, menjangkau sistem yang terdampak, dan menutup celah keamanan di seluruh lingkungan yang mungkin tidak sepenuhnya terlihat oleh tim.

Dua Jam yang Tidak Selaras

Survei ini memisahkan perkiraan para pemimpin tentang kemampuan penyerang dari kemampuan organisasi mereka sendiri untuk menerapkan patch:

• 69% percaya bahwa penyerang yang menggunakan AI dapat membuat eksploit dalam waktu tiga hari atau kurang, termasuk 22% yang memperkirakan waktunya kurang dari 24 jam.
• 56% mengatakan mereka dapat menerapkan patch kritis di seluruh lingkungan produksi dalam waktu tiga hari: 13% dalam waktu kurang dari 24 jam dan 43% dalam satu hingga tiga hari.
• 44% membutuhkan waktu lebih lama: 32% memerlukan empat hingga enam hari dan 12% memerlukan waktu lebih lama lagi.

Angka-angka tersebut merupakan distribusi jawaban survei, bukan pengukuran terhadap penyerang yang berpacu dengan organisasi tertentu untuk mengeksploitasi kerentanan yang sama. Perbedaan ini menjadi alasan untuk mengkhawatirkan kesiapan, tetapi tidak seharusnya ditafsirkan sebagai jangka waktu paparan yang pasti selama tiga hari bagi setiap perusahaan.

Ketimpangan yang sama terlihat pada ambang satu hari: 22% memperkirakan penyerang dapat bergerak secepat itu, dibandingkan dengan 13% yang mengatakan organisasi mereka dapat menerapkan perbaikan dalam jangka waktu tersebut. Sementara itu, 59% mengakui bahwa perangkat serangan berbasis AI meningkatkan paparan mereka, tetapi belum mengubah postur keamanan.

Pengujian Menjadi Bagian Besar dari Keterlambatan

Pengujian pembaruan runtime Java menambah waktu empat hari atau lebih pada siklus pemasangan patch di 58% organisasi yang disurvei. Angka ini mencakup 36% yang melaporkan perlu waktu empat hingga enam hari dan 22% yang melaporkan perlu waktu satu minggu atau lebih. Sebanyak 33% lainnya melaporkan perlu waktu satu hingga tiga hari, dan 9% kurang dari 24 jam. Tidak ada responden yang mengatakan bahwa pengujian dilewati.

Perubahan pada runtime dapat memengaruhi banyak aplikasi, sehingga pengujian memiliki tujuan praktis: pembaruan keamanan yang mengganggu layanan kritis akan menimbulkan masalah operasional lain. Laporan ini berpendapat bahwa cakupan pembaruan turut menambah beban tersebut karena rilis OpenJDK triwulanan penuh dapat mencakup perubahan nonkeamanan selain perbaikan kerentanan.

Secara terpisah, Azul menilai 26 pembaruan OpenJDK triwulanan selama lebih dari enam tahun dan menggolongkan enam di antaranya sebagai penyebab regresi serius. Angka 23% tersebut merupakan penilaian vendor terhadap rilis, bukan perkiraan berdasarkan survei tentang seberapa sering aplikasi pelanggan tertentu akan mengalami gangguan.

Di antara hambatan terbesar yang dilaporkan dalam mempercepat pemasangan patch, 44% menyebut pengujian ekstensif, 40% menyebut kompleksitas atau usia sistem yang terdampak, dan 36% menyebut keterbatasan visibilitas terhadap kerentanan yang diketahui. Keterlambatan patch dari vendor disebut oleh 25%. Pola ini menunjukkan bahwa sebagian besar tantangan remediasi berada dalam proses penerapan yang dijalankan perusahaan itu sendiri.

Laporan Insiden dan Kesenjangan Inventaris Perlu Ditafsirkan secara Berbeda

Sebanyak 55% melaporkan insiden terkonfirmasi yang disebabkan oleh lambatnya pemasangan patch, dan 53% melaporkan kejadian nyaris terjadi. Responden dapat memilih lebih dari satu jawaban, sehingga angka-angka ini saling tumpang tindih dan tidak boleh dijumlahkan. Angka utama yang lebih luas, yaitu 85%, juga mencakup dugaan insiden.

Survei ini tidak membuktikan bahwa semua kejadian tersebut melibatkan kerentanan Java. Para peserta bekerja di organisasi yang banyak menggunakan Java, tetapi penelitian ini juga mencakup pertanyaan tentang pemasangan patch perangkat lunak secara lebih luas, selain pertanyaan khusus mengenai runtime Java.

Inventaris menjadi tantangan kedua. Hanya 19% yang mengatakan bahwa setidaknya 90% dari seluruh runtime Java produksi mereka telah menggunakan tingkat patch keamanan terbaru. Artinya, 81% berada di bawah ambang tersebut; bukan berarti 81% sama sekali tidak memiliki runtime yang mutakhir. Sekitar satu dari lima mengatakan bahwa separuh atau kurang dari seluruh runtime mereka sudah mutakhir.

Secara terpisah, 51% mengakui bahwa visibilitas mereka terhadap runtime Java kritis—termasuk instans yang tertanam, lawas, dan tidak dikelola—hanya sebagian atau terbatas. Menemukan runtime yang rentan di dalam aplikasi terpaket atau kontainer bisa lebih sulit daripada mengidentifikasi instalasi yang dikelola secara terpusat. Patch tidak dapat menutup celah keamanan pada sistem yang tidak pernah dijangkau oleh proses penerapan.

Kontribusi Teknologi Azul terhadap Pembahasan

Produk pembaruan keamanan Azul membatasi rilis tertentu hanya pada perbaikan keamanan untuk basis OpenJDK yang sebelumnya telah distabilkan. Perusahaan menyediakan pembaruan triwulanan, bulanan yang terarah, dan di luar jadwal, dengan tujuan mengurangi jumlah perubahan yang tidak terkait yang harus dievaluasi perusahaan saat menerapkan perbaikan mendesak.

Langkah ini merupakan intervensi teknis yang lebih terbatas daripada menghilangkan kebutuhan akan pengendalian perubahan. Membatasi perubahan kode dapat mengurangi cakupan validasi, tetapi pemeriksaan khusus aplikasi, penetapan pihak yang bertanggung jawab atas penerapan, dan persiapan untuk membatalkan perubahan tetap penting. Azul adalah sponsor laporan tersebut dan menjual produk yang menangani masalah yang diukur dalam laporan itu.

Perangkat inventaris Java dan kerentanan milik Azul menangani sisi lain alur kerja: mengidentifikasi lingkungan runtime, versi, dan paparan agar informasi kerentanan yang baru diungkapkan dapat dipetakan ke sistem yang terdampak. Laporan tersebut tidak menyajikan perbandingan terkontrol yang menunjukkan seberapa besar organisasi yang disurvei dapat meningkatkan kinerjanya dengan menggunakan produk-produk itu.

“Riset kami menunjukkan bahwa para pemimpin keamanan memahami ancamannya: kesadaran bukan lagi kesenjangan yang perlu diatasi; pelaksanaanlah yang menjadi masalah,” kata Scott Sellers, salah satu pendiri sekaligus CEO Azul.

Mengubah Niat Menambal Menjadi Proses yang Terukur

Untuk tahun depan, 32% responden mengidentifikasi penambalan yang lebih cepat dan lebih sering sebagai strategi utama untuk mengurangi paparan, sementara 26% memilih inventaris perangkat lunak dan lingkungan runtime yang lebih baik. Sebanyak 17% lainnya memprioritaskan deteksi dan respons, alih-alih penambalan yang lebih cepat.

Riset tersebut menyarankan agar seluruh tahapan, dari pengungkapan kerentanan hingga remediasi, dilacak: sistem mana yang terdampak, siapa yang bertanggung jawab atasnya, pengujian apa yang diperlukan, dan apakah perbaikan benar-benar telah diterapkan di lingkungan produksi. Tenggat waktu hanya berguna jika tim dapat memverifikasi bahwa proses telah selesai di seluruh lingkungan yang relevan.

Temuan di AS berasal dari penelitian lapangan yang dilakukan pada 3–7 Agustus 2026, terhadap para pemimpin keamanan di organisasi dengan sedikitnya 1.000 karyawan dan penggunaan Java/JVM yang signifikan di lingkungan produksi. Temuan ini merupakan tanggapan yang dilaporkan sendiri oleh responden dari populasi yang telah ditentukan, bukan hasil sensus perusahaan ataupun pengukuran langsung terhadap pengembangan eksploit.

Laporan Kesenjangan Kerentanan AI 2026 selengkapnya menguraikan temuan dan metodologi penelitian. Implikasi paling jelas dari laporan ini adalah bahwa kecepatan penambalan dan visibilitas lingkungan runtime perlu ditingkatkan secara bersamaan: perbaikan yang cepat hanya bernilai terbatas jika organisasi tidak dapat mengidentifikasi setiap penerapan yang terdampak atau memastikan bahwa pembaruan telah diterapkan.