Ada masa ketika perusahaan merasa tenang karena belum menemukan banyak celah keamanan pada sistemnya. Laporan terlihat bersih, dashboard tidak terlalu ramai, dan daftar kerentanan masih dapat dikelola oleh tim IT. Namun kondisi itu kini tidak lagi bisa dijadikan ukuran keamanan yang sehat.

Di era AI, celah keamanan dapat ditemukan dengan lebih cepat, lebih luas, dan lebih mendalam. Analisis kode dapat dilakukan dalam skala besar. Pola konfigurasi yang lemah dapat dikenali lebih cepat. Kerentanan pada aplikasi, API, dependency, hingga infrastruktur dapat teridentifikasi sebelum organisasi benar-benar siap memperbaikinya.

Masalahnya, kecepatan menemukan celah tidak selalu diikuti oleh kecepatan memperbaikinya.

Inilah paradoks keamanan siber modern. Perusahaan semakin mampu mengetahui risiko teknisnya, tetapi belum tentu memiliki kapasitas operasional untuk menutup risiko tersebut tepat waktu. Di banyak organisasi, bottleneck keamanan bukan lagi sekadar kurangnya alat deteksi, melainkan lemahnya proses remediation, lambatnya pengambilan keputusan, keterbatasan tim, serta panjangnya jalur koordinasi antara security, development, operation, dan manajemen.

AI tidak membuat keamanan siber menjadi lebih sederhana. AI justru membuat keterlambatan menjadi lebih terlihat.

Masalah Baru Bukan Lagi Kurangnya Temuan

Selama bertahun-tahun, banyak perusahaan menganggap bahwa semakin banyak celah ditemukan, semakin baik pula program keamanannya. Pemikiran ini tidak sepenuhnya salah. Penetration testing, vulnerability assessment, code review, dan security scanning memang penting untuk membuka area risiko yang sebelumnya tidak terlihat.

Namun di era AI, jumlah temuan tidak lagi bisa menjadi ukuran utama.

Ketika AI digunakan untuk membantu vulnerability discovery, jumlah celah yang teridentifikasi bisa meningkat secara signifikan. Sistem yang sebelumnya terlihat aman dapat menghasilkan puluhan bahkan ratusan temuan baru setelah dianalisis dengan pendekatan yang lebih agresif dan otomatis. Celah lama yang tersembunyi dalam kode, konfigurasi, atau dependency dapat muncul kembali sebagai risiko yang selama ini tidak terpantau.

Dari sisi defensif, ini terlihat positif. Perusahaan menjadi lebih sadar terhadap kondisi sistemnya. Namun dari sisi operasional, muncul persoalan yang jauh lebih sulit: siapa yang akan memperbaiki semua temuan itu, dalam urutan seperti apa, dengan jadwal kapan, dan berdasarkan prioritas risiko yang mana?

Menemukan celah hanyalah langkah awal. Nilai keamanan baru benar-benar tercipta ketika celah tersebut dipahami, diprioritaskan, diperbaiki, diuji ulang, dan dinyatakan tidak lagi menjadi risiko signifikan.

Tanpa proses tersebut, vulnerability hanya berpindah tempat. Dari hasil scanner ke laporan. Dari laporan ke spreadsheet. Dari spreadsheet ke backlog. Dari backlog ke rapat mingguan. Lalu perlahan tersisih oleh prioritas fitur baru, kebutuhan operasional, atau keterbatasan sumber daya.

AI Mempercepat Discovery, tetapi Organisasi Masih Bergerak dengan Ritme Lama

AI dapat mempercepat banyak aktivitas keamanan. Ia dapat membantu menganalisis pola kode, mengidentifikasi potensi bug, memeriksa konfigurasi yang tidak aman, hingga memberikan rekomendasi awal untuk perbaikan. Dalam konteks penetration testing, AI juga dapat membantu memperluas cakupan analisis dan mempercepat proses penggalian informasi teknis.

Namun remediation tidak sesederhana discovery.

Memperbaiki celah keamanan sering kali melibatkan banyak pihak. Developer harus memahami akar masalahnya. Tim operation harus mempertimbangkan stabilitas sistem. Tim bisnis harus menyetujui downtime bila diperlukan. Tim compliance perlu memastikan perbaikannya terdokumentasi. Tim security harus melakukan validasi ulang agar celah tersebut benar-benar tertutup.

Di sinilah terjadi ketimpangan kecepatan.

AI dapat menemukan celah dalam hitungan menit atau jam, tetapi organisasi bisa membutuhkan hari, minggu, bahkan bulan untuk memperbaikinya. Bukan karena tim internal tidak kompeten, melainkan karena proses bisnis, arsitektur sistem, dan tata kelola keamanan belum dirancang untuk menghadapi kecepatan baru ini.

Keamanan siber akhirnya tidak hanya menjadi masalah teknis, tetapi juga masalah kapasitas organisasi.

Perusahaan yang masih mengandalkan proses manual, approval berlapis, jadwal patching yang kaku, dan dokumentasi yang tersebar akan semakin tertinggal. Semakin cepat AI menemukan celah, semakin jelas bahwa proses internal perusahaan belum tentu siap menanggung volume temuan yang terus meningkat.

Backlog Vulnerability Adalah Risiko Bisnis yang Menumpuk Diam-Diam

Backlog vulnerability sering diperlakukan seperti daftar pekerjaan teknis biasa. Padahal, setiap celah yang belum diperbaiki adalah risiko yang masih terbuka. Semakin lama dibiarkan, semakin besar peluang celah tersebut diketahui pihak lain, dipelajari, dieksploitasi, atau dikombinasikan dengan kelemahan lain.

Dalam praktiknya, backlog keamanan jarang muncul secara dramatis. Ia tumbuh pelan-pelan.

Awalnya hanya beberapa temuan medium yang belum sempat diperbaiki. Lalu muncul celah baru pada aplikasi yang sedang aktif dikembangkan. Setelah itu ada dependency lama yang belum diperbarui karena khawatir mengganggu stabilitas sistem. Kemudian ada konfigurasi server yang dianggap “sementara”, tetapi tidak pernah benar-benar ditinjau kembali.

Beberapa bulan kemudian, organisasi memiliki daftar panjang risiko yang terlihat kecil jika dibaca satu per satu, tetapi sangat berbahaya ketika dilihat sebagai satu kesatuan.

Masalahnya, attacker tidak selalu membutuhkan satu celah besar. Sering kali, insiden terjadi karena kombinasi beberapa kelemahan kecil: validasi input yang lemah, konfigurasi akses yang longgar, endpoint yang terekspos, credential yang tidak dikelola dengan baik, atau sistem lama yang masih terhubung ke layanan utama.

Di sinilah backlog vulnerability berubah menjadi risiko bisnis.

Ia tidak hanya mengancam sistem IT, tetapi juga kelangsungan operasional, kepercayaan pelanggan, kepatuhan regulasi, reputasi perusahaan, dan potensi kerugian finansial. Ketika backlog terus bertambah sementara kapasitas remediation tetap sama, perusahaan sebenarnya sedang menumpuk risiko tanpa selalu menyadarinya.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Banyak organisasi bukan tidak peduli terhadap keamanan. Mereka mengetahui adanya celah. Mereka memiliki laporan. Mereka bahkan memiliki rekomendasi teknis. Namun proses untuk menutup temuan tersebut belum selalu jelas, terukur, dan menjadi prioritas lintas tim.

Exploit Window Semakin Pendek

Dalam keamanan siber, waktu adalah faktor penting. Ada jarak antara saat celah ditemukan, dipublikasikan, dipahami attacker, dieksploitasi, dan akhirnya diperbaiki oleh organisasi. Jarak inilah yang sering disebut sebagai exploit window.

Di masa lalu, organisasi mungkin masih memiliki ruang waktu lebih panjang untuk merespons. Setelah vulnerability dipublikasikan, tim dapat membaca advisory, mengevaluasi dampaknya, menguji patch, lalu menjadwalkan deployment. Proses ini memang tidak selalu cepat, tetapi masih dianggap cukup dalam banyak kasus.

Namun AI dapat memperpendek jarak tersebut.

Dengan kemampuan analisis otomatis, attacker maupun researcher dapat lebih cepat memahami struktur celah, membuat proof of concept, mencari target yang rentan, atau menggabungkan temuan baru dengan teknik serangan yang sudah ada. Dalam kondisi seperti ini, organisasi tidak lagi bisa terlalu nyaman dengan patch window tradisional.

Perusahaan tidak kalah hanya karena tidak tahu ada celah. Perusahaan sering kali kalah karena terlambat menutup celah yang sudah diketahui.

Ini menjadi kritik penting terhadap pendekatan keamanan yang terlalu reaktif. Jika perusahaan hanya bergerak setelah celah ramai dibicarakan, setelah vendor merilis patch, atau setelah auditor meminta bukti perbaikan, maka ritme tersebut akan semakin tidak seimbang dengan kecepatan ancaman modern.

AI membuat waktu respons menjadi semakin mahal. Setiap hari keterlambatan bukan sekadar penundaan teknis, tetapi perpanjangan masa paparan risiko.

Banyak CVE Tidak Sama dengan Prioritas yang Benar

Salah satu kesalahan umum dalam vulnerability management adalah memperlakukan semua temuan berdasarkan skor teknis semata. CVSS memang penting sebagai referensi awal. Namun skor tinggi tidak selalu berarti paling mendesak dalam konteks bisnis tertentu. Sebaliknya, celah dengan skor sedang bisa menjadi sangat berbahaya jika berada pada sistem yang terekspos publik, menyimpan data sensitif, atau menjadi pintu masuk ke sistem internal.

Di era AI, persoalan ini menjadi semakin krusial. Ketika jumlah temuan meningkat, organisasi tidak bisa lagi mengandalkan pendekatan “perbaiki semua yang critical terlebih dahulu” secara kaku tanpa membaca konteks. Prioritas harus mempertimbangkan exploitability, eksposur aset, dampak bisnis, keterhubungan sistem, keberadaan exploit aktif, sensitivitas data, serta kontrol kompensasi yang tersedia.

Vulnerability management yang matang tidak hanya bertanya, “seberapa tinggi skornya?” tetapi juga “seberapa mudah celah ini dieksploitasi, siapa yang bisa mengaksesnya, aset apa yang terdampak, dan apa konsekuensinya bagi bisnis?”

Tanpa pendekatan berbasis risiko, tim akan sibuk memperbaiki banyak hal, tetapi belum tentu menutup jalur serangan yang paling berbahaya. Aktivitas security terlihat padat, tetapi risiko utama bisa saja tetap terbuka.

Inilah alasan mengapa perusahaan perlu bergerak dari sekadar daftar vulnerability menuju pemahaman yang lebih luas tentang exposure.

Tool Tidak Akan Menyelamatkan Proses Remediation yang Berantakan

Banyak organisasi merespons kompleksitas keamanan dengan menambah tool. Scanner ditambah. Dashboard diperbanyak. Monitoring diperluas. Alert semakin ramai. Secara teknis, semua ini berguna. Namun tool tidak akan menyelesaikan masalah jika proses remediation tidak jelas.

Pertanyaan yang lebih mendasar sering kali belum terjawab.

Siapa pemilik risiko untuk setiap sistem? Siapa yang wajib menindaklanjuti temuan? Bagaimana prioritas ditentukan? Berapa lama batas waktu perbaikan? Kapan perbaikan harus diuji ulang? Siapa yang berhak menerima risiko jika celah belum dapat diperbaiki? Bagaimana dokumentasi disimpan untuk kebutuhan audit dan compliance?

Jika pertanyaan-pertanyaan ini belum memiliki jawaban yang jelas, maka penambahan tool hanya akan mempercepat produksi temuan tanpa mempercepat penurunan risiko.

Perusahaan akhirnya memiliki lebih banyak data keamanan, tetapi tidak memiliki mekanisme yang cukup kuat untuk mengubah data tersebut menjadi tindakan. Ini adalah kondisi yang berbahaya karena dapat menciptakan ilusi kontrol.

Dashboard terlihat aktif. Laporan terus diperbarui. Alert terus muncul. Namun risiko yang paling penting belum tentu bergerak turun.

Di era AI, perusahaan tidak hanya membutuhkan visibility. Perusahaan membutuhkan kemampuan eksekusi. Tanpa itu, semakin banyak temuan justru dapat membuat tim kehilangan fokus.

AI-Generated Code Dapat Memperbesar Permukaan Risiko

AI tidak hanya digunakan oleh tim security. Developer juga semakin banyak menggunakan AI untuk membantu menulis kode, membuat fungsi, mempercepat debugging, menyusun dokumentasi, atau menghasilkan potongan logika aplikasi. Dari sisi produktivitas, ini membawa banyak manfaat.

Namun dari sisi keamanan, AI-generated code perlu diperlakukan dengan hati-hati.

Kode yang terlihat berjalan belum tentu aman. Fungsi yang berhasil memenuhi requirement bisnis belum tentu memiliki validasi input yang kuat, kontrol akses yang tepat, pengelolaan session yang aman, atau perlindungan terhadap penyalahgunaan API. Jika organisasi tidak memiliki standar secure coding, code review, dependency scanning, dan security testing yang memadai, AI dapat mempercepat lahirnya fitur sekaligus mempercepat munculnya celah.

Masalahnya menjadi lebih besar ketika organisasi hanya menilai keberhasilan development dari kecepatan delivery. Aplikasi dapat selesai lebih cepat, tetapi risiko yang tertanam di dalamnya baru terlihat setelah masuk tahap audit, penetration testing, atau bahkan setelah insiden terjadi.

Inilah mengapa Secure SDLC menjadi semakin penting. Security tidak boleh ditempatkan sebagai tahap akhir setelah aplikasi selesai. Pengujian keamanan harus hadir sejak desain, requirement, development, testing, deployment, hingga maintenance.

Di era AI, perusahaan tidak cukup hanya bertanya apakah aplikasi bisa berjalan. Pertanyaan yang lebih penting adalah apakah aplikasi tersebut dibangun dengan asumsi risiko yang benar.

Dari Vulnerability Management ke Exposure Management

Pendekatan tradisional vulnerability management biasanya berfokus pada daftar celah. Apa saja kerentanannya, berapa severity-nya, sistem mana yang terdampak, dan apa rekomendasi perbaikannya. Pendekatan ini tetap penting, tetapi tidak lagi cukup.

Perusahaan perlu memahami exposure secara lebih menyeluruh.

Exposure management melihat hubungan antara aset, konfigurasi, akses, identitas, koneksi antar sistem, dependency, API, cloud service, dan jalur serangan yang mungkin terbentuk. Dengan kata lain, perusahaan tidak hanya melihat celah sebagai item terpisah, tetapi sebagai bagian dari peta risiko yang saling terhubung.

Pendekatan ini menjadi penting karena attacker tidak berpikir dalam bentuk daftar CVE. Attacker berpikir dalam bentuk jalur. Mereka mencari cara masuk, cara memperluas akses, cara bergerak lateral, dan cara mencapai aset yang paling bernilai.

Karena itu, pertanyaan utama perusahaan harus berubah.

Bukan lagi hanya “berapa banyak vulnerability yang kita punya?” tetapi “jalur serangan mana yang paling mungkin digunakan untuk mencapai aset penting kita?”

Perubahan cara berpikir ini membantu perusahaan memprioritaskan tindakan dengan lebih tajam. Tidak semua celah harus diperlakukan sama. Celah pada sistem publik yang terhubung ke data pelanggan harus diberi bobot berbeda dari celah pada sistem internal yang sudah memiliki kontrol kompensasi kuat.

Continuous Testing Menjadi Kebutuhan, Bukan Sekadar Tren

Banyak perusahaan masih melakukan pengujian keamanan secara periodik, misalnya setahun sekali untuk kebutuhan audit, compliance, atau pemenuhan standar tertentu. Pendekatan ini tetap memiliki tempat, terutama untuk memberikan gambaran menyeluruh pada titik waktu tertentu.

Namun lingkungan digital tidak lagi berubah setahun sekali.

Aplikasi diperbarui lebih cepat. API bertambah. Integrasi dengan pihak ketiga meningkat. Cloud environment berubah. Developer menggunakan library baru. Konfigurasi dapat bergeser karena kebutuhan operasional. Dalam kondisi seperti ini, pengujian tahunan tidak cukup untuk menangkap risiko yang muncul di antara dua periode audit.

Continuous testing menjadi semakin relevan.

Bukan berarti perusahaan harus melakukan penetration testing penuh setiap minggu. Yang dibutuhkan adalah mekanisme pengujian keamanan yang lebih berkelanjutan dan berbasis risiko. Misalnya vulnerability assessment berkala, monitoring attack surface, security testing dalam pipeline development, retest setelah remediation, dan pengujian khusus setelah perubahan besar pada aplikasi atau infrastruktur.

Dengan pendekatan ini, perusahaan tidak hanya mengetahui risiko pada satu titik waktu, tetapi dapat memantau bagaimana risiko berubah seiring perubahan sistem.

Continuous testing juga membantu mengurangi jarak antara discovery dan remediation. Temuan dapat diketahui lebih cepat, diprioritaskan lebih baik, dan divalidasi kembali setelah perbaikan dilakukan.

Remediation Harus Memiliki SLA yang Jelas

Salah satu tanda lemahnya tata kelola keamanan adalah ketika temuan hanya diberi status “akan diperbaiki” tanpa batas waktu yang jelas. Dalam konteks operasional, status seperti ini terlalu lemah. Ia tidak memberikan tekanan, tidak membantu prioritas, dan tidak cukup kuat untuk mengukur efektivitas program keamanan.

Remediation perlu memiliki SLA.

Namun SLA juga tidak boleh dibuat secara kaku berdasarkan severity saja. Celah critical pada sistem yang tidak terekspos mungkin tetap penting, tetapi celah high pada aplikasi publik yang menyimpan data sensitif bisa menjadi lebih mendesak. Karena itu, SLA harus disusun berdasarkan kombinasi severity, exploitability, exposure, dampak bisnis, dan ketersediaan kontrol kompensasi.

Misalnya, celah dengan risiko sangat tinggi pada sistem publik perlu ditangani segera. Celah high dapat masuk prioritas sprint terdekat. Celah medium dapat dijadwalkan sesuai roadmap perbaikan. Celah low tetap perlu dicatat, dipantau, dan diperbaiki dalam siklus hardening berikutnya.

Yang terpenting, setiap pengecualian harus tercatat. Jika sebuah celah belum dapat diperbaiki karena alasan teknis atau bisnis, keputusan tersebut perlu disetujui oleh pihak yang tepat dan disertai rencana mitigasi sementara.

Dengan cara ini, vulnerability tidak lagi menjadi daftar teknis yang menggantung, melainkan bagian dari risk management perusahaan.

Ukur Kecepatan Memperbaiki, Bukan Hanya Kecepatan Menemukan

Perusahaan yang ingin lebih matang dalam keamanan siber perlu mengubah metriknya. Jumlah temuan memang tetap penting, tetapi tidak boleh menjadi satu-satunya ukuran. Yang lebih penting adalah apakah risiko benar-benar menurun dari waktu ke waktu.

Beberapa metrik yang lebih relevan antara lain waktu rata-rata perbaikan, waktu rata-rata validasi ulang, jumlah temuan yang kembali muncul, usia vulnerability yang belum diselesaikan, tingkat kepatuhan patching, serta jumlah temuan pada aset kritis.

Metrik seperti ini membantu manajemen melihat kondisi keamanan secara lebih realistis. Bukan hanya berapa banyak celah yang ditemukan, tetapi seberapa cepat organisasi meresponsnya.

Selama perusahaan hanya mengukur jumlah temuan, keamanan akan terlihat sibuk. Tetapi ketika perusahaan mulai mengukur waktu perbaikan, kualitas validasi, dan penurunan exposure, barulah terlihat apakah program security benar-benar efektif.

AI membuat pengukuran ini semakin penting. Jika discovery semakin cepat, maka remediation juga harus menjadi metrik utama. Tanpa itu, organisasi hanya akan menjadi semakin mahir menemukan masalah, tetapi tidak semakin cepat menutup risiko.

Strategi Menghadapi Kecepatan AI dalam Keamanan Siber

Perusahaan tidak harus panik menghadapi perubahan ini. Namun perusahaan perlu memperbaiki cara mengelola keamanan. AI memang mempercepat discovery, tetapi organisasi tetap dapat mengurangi risiko dengan tata kelola yang lebih disiplin.

Langkah pertama adalah memastikan asset inventory selalu diperbarui. Perusahaan tidak dapat melindungi sistem yang tidak diketahui keberadaannya. Setiap aplikasi, API, server, cloud service, dan integrasi pihak ketiga harus masuk dalam peta aset yang jelas.

Langkah kedua adalah menerapkan prioritas berbasis risiko. Temuan tidak boleh diproses hanya berdasarkan urutan masuk atau skor teknis. Konteks bisnis harus menjadi bagian dari penentuan prioritas.

Langkah ketiga adalah mengintegrasikan security testing ke dalam SDLC. Setiap perubahan aplikasi perlu melewati pemeriksaan keamanan yang sesuai, mulai dari review desain, analisis kode, pengujian dependency, hingga dynamic testing.

Langkah keempat adalah memastikan retest dilakukan setelah perbaikan. Tanpa retest, perusahaan hanya berasumsi bahwa celah sudah tertutup. Padahal, perbaikan yang salah dapat menimbulkan celah baru atau tidak menyelesaikan akar masalah.

Langkah kelima adalah memperkuat segmentasi dan kontrol akses. Ketika tidak semua celah dapat diperbaiki seketika, perusahaan perlu membatasi dampak jika salah satu sistem berhasil dikompromikan.

Langkah keenam adalah membangun governance untuk AI-generated code. Penggunaan AI dalam development perlu diimbangi dengan standar keamanan, review, dokumentasi, dan pengujian yang memadai.

Langkah terakhir adalah membuat laporan keamanan yang dapat dipahami manajemen. Security tidak boleh berhenti sebagai laporan teknis. Temuan perlu diterjemahkan menjadi risiko bisnis, dampak operasional, dan prioritas keputusan.

Perusahaan yang Aman Bukan yang Menemukan Celah Paling Banyak

Di era AI, perusahaan tidak bisa lagi mengandalkan pendekatan keamanan yang lambat, reaktif, dan terlalu bergantung pada laporan periodik. Kecepatan discovery akan terus meningkat. Celah yang dulu tersembunyi lebih lama kini dapat ditemukan lebih cepat. Pola serangan dapat dianalisis lebih dalam. Permukaan risiko perusahaan menjadi semakin mudah dipetakan.

Namun inti keamanan tetap sama: risiko harus ditutup.

Perusahaan yang paling aman bukan perusahaan yang menemukan vulnerability paling banyak. Perusahaan yang lebih siap adalah perusahaan yang mampu memahami celah mana yang paling berbahaya, menentukan prioritas secara rasional, memperbaikinya dengan cepat, dan membuktikan bahwa risiko benar-benar telah turun.

AI tidak hanya mempercepat cara celah ditemukan. AI mempercepat konsekuensi dari setiap celah yang dibiarkan terbuka.

Karena itu, keamanan siber modern harus bergerak dari sekadar menemukan masalah menuju kemampuan memperbaiki, memvalidasi, dan mengelola exposure secara berkelanjutan. Tanpa perubahan ini, AI hanya akan membuat organisasi semakin sadar bahwa risikonya besar, tetapi tetap lambat dalam menutupnya.

Perkuat Keamanan Sistem Anda bersama Fourtrezz

Menghadapi era AI dalam keamanan siber membutuhkan pendekatan yang tidak hanya teknis, tetapi juga berbasis risiko dan kebutuhan bisnis. Perusahaan membutuhkan pengujian keamanan yang mampu menemukan celah, menjelaskan dampaknya, membantu prioritas perbaikan, dan memastikan remediation benar-benar tervalidasi.

Fourtrezz membantu perusahaan di Indonesia melalui layanan cybersecurity seperti Penetration Testing, Vulnerability Assessment, dan pengujian keamanan yang dirancang untuk memberikan gambaran risiko secara lebih jelas. Dengan pendekatan yang terstruktur, Fourtrezz dapat membantu organisasi mengidentifikasi celah keamanan pada aplikasi, API, maupun infrastruktur, sekaligus memberikan rekomendasi perbaikan yang relevan dengan kebutuhan bisnis.

Jika perusahaan Anda ingin memperkuat keamanan sistem, mengurangi risiko vulnerability backlog, dan memastikan celah keamanan tidak berhenti hanya sebagai laporan, Fourtrezz siap menjadi mitra keamanan siber yang dapat diandalkan.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]