Gemini 3.5 Flash Cyber: AI untuk Keamanan Kode

Gemini 3.5 Flash Cyber hadir sebagai model kecerdasan buatan khusus keamanan siber dari Google DeepMind yang dirancang untuk menemukan, memvalidasi, dan membantu memperbaiki kerentanan perangkat lunak. Model ini dibangun di atas Gemini 3.5 Flash, lalu disetel secara khusus agar lebih efisien menangani pekerjaan keamanan kode dalam skala besar, seperti pemindaian repositori, analisis jalur eksekusi, validasi temuan, hingga penyusunan laporan kerentanan.

Peluncurannya mencerminkan perubahan penting dalam keamanan aplikasi. Masalah keamanan bukan lagi hanya soal menemukan celah, melainkan bagaimana organisasi dapat memeriksa jutaan baris kode, memilah temuan yang benar-benar relevan, dan menyiapkan perbaikan sebelum celah tersebut dieksploitasi. Google menempatkan Gemini 3.5 Flash Cyber di dalam arsitektur CodeMender, agen keamanan kode yang menggabungkan banyak pemanggilan model untuk memperluas cakupan analisis.

Gemini 3.5 Flash Cyber adalah model AI keamanan siber ringan yang dioptimalkan untuk menemukan, memvalidasi, dan membantu menambal kerentanan perangkat lunak secara cepat, hemat biaya, dan dapat diskalakan melalui CodeMender.

Apa Itu Gemini 3.5 Flash Cyber?

Gemini 3.5 Flash Cyber merupakan model AI khusus yang dibangun dari fondasi Gemini 3.5 Flash. Fokus utamanya bukan percakapan umum, pembuatan konten, atau penalaran serbaguna, melainkan tugas keamanan perangkat lunak yang membutuhkan pembacaan kode, pemetaan perilaku program, dan penilaian potensi kelemahan.

Google mengembangkan model ini untuk menjawab persoalan yang sering muncul dalam pencarian kerentanan. Model besar dengan kemampuan tinggi dapat memberikan hasil berkualitas, tetapi biaya komputasi dan latensinya dapat membatasi frekuensi pemeriksaan. Pada proyek perangkat lunak yang luas, satu kali analisis tidak cukup untuk menjelajahi seluruh kemungkinan jalur eksekusi.

Karena itu, pendekatan Gemini 3.5 Flash Cyber mengandalkan model yang lebih ringan dan lebih murah untuk dipanggil berulang kali. Sejumlah agen dapat menganalisis bagian kode, jalur data, atau kemungkinan eksploitasi secara paralel sebelum hasilnya digabungkan menjadi laporan akhir.

Model ini diperkenalkan bersamaan dengan Gemini 3.6 Flash dan Gemini 3.5 Flash-Lite. Namun, posisinya berbeda dari dua model tersebut. Gemini 3.6 Flash ditujukan untuk coding, pekerjaan pengetahuan, dan kemampuan multimodal yang lebih efisien. Gemini 3.5 Flash-Lite difokuskan pada tugas berlatensi rendah dan volume tinggi. Sementara itu, Gemini 3.5 Flash Cyber memiliki fokus lebih sempit, yaitu pertahanan keamanan perangkat lunak.

Mengapa Keamanan Kode Membutuhkan Model Khusus?

Kerentanan perangkat lunak tidak selalu muncul sebagai kesalahan yang terlihat jelas. Banyak celah berada pada interaksi antarfungsi, asumsi yang keliru tentang validasi input, pengelolaan memori, otorisasi, penggunaan API, atau kondisi yang hanya muncul pada urutan eksekusi tertentu.

Pencarian kerentanan dapat dipahami sebagai masalah ruang pencarian yang sangat besar. Satu basis kode dapat memiliki banyak modul, dependensi, konfigurasi, cabang logika, dan perilaku runtime. Semakin besar aplikasi, semakin banyak kemungkinan yang perlu diperiksa.

Beberapa alasan mengapa model AI khusus keamanan menjadi relevan meliputi:

Basis kode terus bertambah seiring pengembangan fitur, integrasi pihak ketiga, dan pembaruan dependensi.
Tim keamanan memiliki kapasitas terbatas untuk meninjau seluruh perubahan kode secara manual.
Kerentanan sering tersembunyi dalam konteks, bukan pada satu fungsi tunggal.
Waktu respons sangat penting, terutama untuk temuan pada layanan produksi atau komponen infrastruktur penting.
Pemindaian berulang diperlukan untuk proses rilis, pemeriksaan commit, dan evaluasi perubahan kode.

Gemini 3.5 Flash Cyber dirancang untuk membantu mengurangi hambatan tersebut. Model ini tidak menggantikan peneliti keamanan, pengembang, atau proses secure software development lifecycle. Nilainya berada pada kemampuan memperluas cakupan analisis dan mempercepat prioritisasi temuan.

Cara Kerja Gemini 3.5 Flash Cyber dalam CodeMender

Keunggulan utama Gemini 3.5 Flash Cyber tidak hanya berasal dari modelnya, tetapi juga dari pola orkestrasi di dalam CodeMender. Google menjelaskan bahwa CodeMender dapat memanggil model ini beberapa kali untuk satu laporan akhir.

Pendekatan ini berbeda dari penggunaan satu model besar dalam satu kali permintaan. Alih-alih mengandalkan satu proses analisis yang mahal, sistem menjalankan beberapa analisis lebih kecil untuk mengeksplorasi lebih banyak area.

Secara sederhana, alurnya dapat digambarkan sebagai berikut:

Kode atau perubahan kode dipilih untuk dianalisis.
Sistem dapat menilai repositori, komponen tertentu, atau perubahan pada commit.
Beberapa agen menelusuri jalur berbeda.
Setiap agen dapat memeriksa fungsi, dependensi, aliran data, atau pola kerentanan yang berbeda.
Temuan awal divalidasi.
Sistem berupaya membedakan antara indikasi masalah, temuan duplikat, dan kerentanan yang lebih mungkin dapat dieksploitasi.
Hasil digabungkan ke dalam laporan.
CodeMender menyatukan temuan dari subagen menjadi laporan yang lebih terstruktur.
Perbaikan dapat dipersiapkan atau dievaluasi.
Dalam konteks pertahanan, proses ini dapat membantu tim memahami akar masalah dan meninjau usulan patch.

Model ringan menjadi penting karena proses seperti ini membutuhkan banyak pemanggilan. Bila setiap pemanggilan mahal atau lambat, biaya pemindaian terhadap basis kode besar dapat meningkat tajam. Dengan harga per token yang lebih rendah dibanding model keamanan siber berukuran lebih besar, Gemini 3.5 Flash Cyber dirancang untuk membuat pemanggilan paralel lebih praktis.

Masalah Ruang Pencarian dalam Pendeteksian Kerentanan

Pencarian kerentanan bukan hanya proses mencari kata kunci seperti unsafe, eval, atau fungsi yang memiliki riwayat risiko. Pendekatan berbasis pola tetap berguna, tetapi tidak selalu dapat memahami konteks aplikasi secara penuh.

Misalnya, satu nilai input mungkin terlihat aman di satu fungsi, tetapi menjadi berbahaya setelah diteruskan ke beberapa modul. Dalam kasus lain, kondisi otorisasi dapat berlaku pada jalur normal tetapi gagal pada jalur alternatif. Kerentanan juga dapat muncul karena urutan operasi, konfigurasi build, atau asumsi yang tidak lagi berlaku setelah pembaruan dependensi.

Gemini 3.5 Flash Cyber ditujukan untuk memperluas kemampuan analisis semacam ini. Model keamanan dapat membantu menelusuri hubungan antarbagian kode, mengajukan hipotesis risiko, dan mendorong pemeriksaan ke area yang mungkin luput dari aturan statis sederhana.

Pendekatan berulang juga memiliki keuntungan lain. Jika satu agen berfokus pada input dan sanitasi data, agen lain dapat memeriksa kontrol akses, penggunaan memori, atau rangkaian panggilan API. Semakin banyak jalur yang dieksplorasi, semakin besar peluang menemukan masalah unik.

Namun, cakupan yang lebih luas tidak otomatis menghasilkan hasil yang lebih baik tanpa validasi. Temuan keamanan harus diuji, diberi konteks, dan diprioritaskan. Itulah sebabnya integrasi ke dalam alat seperti CodeMender menjadi penting, karena nilai akhirnya bukan hanya jumlah peringatan, melainkan kualitas laporan dan tindakan perbaikan yang dapat ditindaklanjuti.

Perbandingan Gemini 3.5 Flash Cyber dengan Model Gemini Lainnya

Gemini 3.5 Flash Cyber berada dalam keluarga Flash, tetapi penggunaan idealnya berbeda dari Gemini 3.6 Flash dan Gemini 3.5 Flash-Lite.

Model	Fokus utama	Karakteristik	Contoh penggunaan
Gemini 3.5 Flash Cyber	Keamanan perangkat lunak	Dioptimalkan untuk menemukan, memvalidasi, dan memperbaiki kerentanan	Analisis kode, pemindaian commit, validasi temuan keamanan
Gemini 3.6 Flash	Coding, pekerjaan pengetahuan, multimodal	Lebih efisien dalam penggunaan token dan mendukung tugas agen produksi	Otomasi coding, analisis dokumen, tugas pengetahuan
Gemini 3.5 Flash-Lite	Latensi rendah dan throughput tinggi	Dirancang untuk tugas berulang berbiaya rendah dalam volume besar	Pencarian agen, pemrosesan dokumen, subagen cepat

Gemini 3.5 Flash Cyber bukan pengganti langsung untuk model generalis. Model ini lebih tepat dipahami sebagai komponen khusus yang digunakan ketika konteks pekerjaan berkaitan dengan keamanan kode.

Pendekatan spesialisasi seperti ini juga mulai terlihat di industri AI. Model umum mampu melakukan banyak hal, tetapi model yang dilatih dan dievaluasi untuk domain tertentu dapat memberikan efisiensi yang lebih baik pada pekerjaan yang sempit namun kompleks.

Dalam keamanan siber, spesialisasi penting karena hasil analisis berpotensi berdampak langsung pada sistem produksi. Temuan yang salah dapat menghabiskan waktu tim. Sebaliknya, temuan yang akurat dan terprioritas dapat mencegah insiden serius.

Hasil Benchmark Gemini 3.5 Flash Cyber

Google menguji Gemini 3.5 Flash Cyber melalui beberapa evaluasi keamanan. Salah satu rujukan utama adalah CyberGym, benchmark yang menilai agen AI terhadap ratusan kerentanan perangkat lunak di dunia nyata.

Dalam konfigurasi CodeMender, model dapat dipanggil hingga lima kali untuk menghasilkan satu laporan akhir. Menurut Google, pendekatan tersebut memungkinkan performa kompetitif terhadap model keamanan siber yang lebih besar.

Google juga menguji model ini melalui evaluasi Big Sleep, yang berfokus pada pencarian kerentanan sulit dalam basis kode kompleks seperti Chrome dan Safari. Dalam pengujian tersebut, Gemini 3.5 Flash Cyber dilaporkan melampaui Gemini 3.5 Flash dan Gemini 3.6 Flash pada tugas pencarian kerentanan.

Salah satu angka yang paling banyak dibahas berasal dari pengujian pada mesin JavaScript V8. Pada jumlah pemanggilan yang sama, Gemini 3.5 Flash Cyber menemukan 55 masalah unik yang telah dikonfirmasi. Angka tersebut dibandingkan dengan 47 temuan oleh Gemini 3.5 Flash dan 36 temuan oleh Claude Opus 4.6 pada pengujian yang disebutkan Google.

Evaluasi atau konteks	Gemini 3.5 Flash Cyber	Pembanding
Temuan unik terkonfirmasi pada V8	55	Gemini 3.5 Flash: 47
Temuan unik terkonfirmasi pada V8	55	Claude Opus 4.6: 36
Temuan yang tidak ditemukan dua pembanding tersebut	10	Tidak tersedia
Konfigurasi CodeMender pada CyberGym	Hingga 5 pemanggilan per laporan	Model besar dengan biaya lebih tinggi
Evaluasi Big Sleep	Disebut melampaui Flash utama	Gemini 3.5 Flash dan Gemini 3.6 Flash

Angka benchmark perlu dibaca dalam konteks. Hasil dapat dipengaruhi oleh konfigurasi agen, jumlah pemanggilan model, cakupan proyek, metode validasi, dan jenis kerentanan yang diuji. Benchmark juga bukan jaminan bahwa model akan memiliki hasil yang sama pada setiap basis kode produksi.

Meski demikian, hasil tersebut menunjukkan arah penting. Model yang lebih ringan, jika dipadukan dengan orkestrasi multiagen yang tepat, dapat menemukan lebih banyak masalah unik karena mampu menelusuri lebih banyak jalur dalam batas biaya yang masuk akal.

Mengapa Temuan Unik Lebih Penting daripada Temuan Berulang?

Sistem keamanan otomatis dapat menghasilkan banyak peringatan. Tantangan terbesarnya bukan selalu kekurangan data, melainkan kebisingan. Jika sistem berulang kali menemukan masalah yang sama atau menghasilkan banyak false positive, tim keamanan tetap harus menghabiskan waktu untuk menyaring hasil.

Google menyoroti bahwa model keamanan yang lebih lemah dapat terjebak dalam pola temuan berulang. Model mungkin terus mengenali kategori masalah yang sama tanpa memperluas pencarian ke jalur kode lain yang lebih dalam.

Gemini 3.5 Flash Cyber ditujukan untuk mengatasi persoalan itu melalui kemampuan eksplorasi yang lebih luas. Dalam pengujian V8, model ini tidak hanya menghasilkan total temuan lebih tinggi, tetapi juga menemukan masalah yang tidak ditemukan dua model pembanding.

Bagi organisasi, nilai dari temuan unik dapat terlihat dalam beberapa bentuk:

Mengurangi risiko kerentanan tersembunyi yang belum masuk daftar perbaikan.
Membantu peneliti keamanan mengeksplorasi area kode yang kurang diperiksa.
Mempercepat investigasi terhadap perubahan kode yang berisiko.
Meningkatkan hasil pemindaian tanpa harus menaikkan biaya tiap analisis secara drastis.
Menyediakan lebih banyak konteks untuk penilaian prioritas risiko.

Tetap diperlukan proses pengujian dan verifikasi oleh tenaga ahli. Model AI dapat menghasilkan hipotesis yang kuat, tetapi dampak teknis, tingkat eksploitabilitas, dan kelayakan patch harus ditinjau dalam konteks sistem yang sebenarnya.

Kasus Penggunaan Gemini 3.5 Flash Cyber

Google menyebut Gemini 3.5 Flash Cyber telah digunakan dalam CodeMender untuk menemukan dan memperbaiki kerentanan pada basis kode internal, termasuk Chrome, Android, Cloud, Ads, dan YouTube.

Kemampuan ini relevan untuk organisasi yang mengelola aplikasi besar, layanan cloud, produk digital dengan rilis cepat, atau perangkat lunak yang bergantung pada banyak komponen open source.

Pemindaian commit sebelum rilis

Setiap commit baru dapat memperkenalkan risiko. Perubahan kecil pada validasi input, logika autentikasi, parser, atau pengelolaan memori dapat menciptakan celah yang tidak segera terlihat saat code review biasa.

Model keamanan khusus dapat membantu memeriksa perubahan secara lebih mendalam. Fokusnya bukan menggantikan pemeriksaan pengembang, tetapi menyediakan lapisan tambahan untuk mengidentifikasi perubahan yang perlu ditinjau lebih lanjut.

Peninjauan basis kode legacy

Aplikasi lama sering memiliki dokumentasi tidak lengkap, dependensi usang, dan pola implementasi yang tidak lagi sesuai dengan standar keamanan terkini. Meninjau ulang kode seperti ini secara manual membutuhkan waktu yang besar.

Dengan pemanggilan model secara paralel, CodeMender dapat membantu memperluas pencarian ke modul yang mungkin tidak mendapat perhatian rutin. Hasilnya tetap perlu dikonfirmasi, tetapi proses awal penemuan dapat dipercepat.

Analisis kerentanan pada layanan publik

Layanan yang terekspos ke internet memiliki permukaan serangan yang lebih besar. API publik, endpoint autentikasi, integrasi pihak ketiga, dan layanan pemrosesan data menjadi area yang perlu dipantau secara ketat.

Google menyebut tim Cloud Vulnerability Research menggunakan model ini untuk menemukan kerentanan eksekusi kode jarak jauh pada API publik dan kerentanan korupsi memori pada layanan produksi sensitif dalam waktu dua jam. Detail teknis lengkap tidak dipublikasikan, tetapi contoh tersebut menunjukkan target penggunaan model dalam pertahanan internal.

Validasi laporan bug dan vulnerability triage

Tidak semua laporan keamanan memiliki kualitas yang sama. Sebagian laporan memerlukan reproduksi, pemeriksaan dampak, dan verifikasi apakah masalah benar-benar dapat dieksploitasi.

Gemini 3.5 Flash Cyber dapat digunakan sebagai lapisan awal untuk membantu menyusun konteks teknis, menghubungkan temuan dengan bagian kode terkait, dan mempercepat proses triage. Tanggung jawab akhir tetap berada pada tim keamanan dan pengembang yang memahami lingkungan sistem.

Penyusunan usulan patch

Menemukan kerentanan hanya menyelesaikan sebagian masalah. Perbaikan yang salah dapat merusak fitur, menimbulkan regresi, atau bahkan menciptakan kelemahan baru.

Model AI dapat membantu membuat usulan patch atau mengidentifikasi area yang perlu diubah. Namun, patch harus melewati pengujian unit, integrasi, keamanan, dan review manusia sebelum diterapkan ke produksi.

Gemini 3.5 Flash Cyber dan CodeMender untuk Pertahanan

CodeMender adalah agen keamanan kode Google yang dirancang untuk menemukan dan memperbaiki kerentanan perangkat lunak. Gemini 3.5 Flash Cyber menjadi model yang memperkuat kemampuan CodeMender dalam pencarian kerentanan dengan biaya yang lebih efisien.

Hubungan antara keduanya dapat diringkas sebagai berikut:

Gemini 3.5 Flash Cyber menyediakan kecerdasan model khusus keamanan.
CodeMender mengatur penggunaan model, menjalankan subagen, dan menyusun hasil.
Tim keamanan menilai temuan, menentukan prioritas, serta memvalidasi dan menerapkan perbaikan.

Arsitektur ini penting karena masalah keamanan tidak dapat diselesaikan oleh model bahasa saja. Sistem juga memerlukan akses yang tepat ke basis kode, aturan operasi, validasi hasil, pengujian, dan pengendalian risiko.

Google juga menyatakan bahwa kemampuan dasar CodeMender tersedia untuk pelanggan melalui Gemini Enterprise Agent Platform dengan model Gemini yang tersedia secara umum. Sementara itu, Gemini 3.5 Flash Cyber sendiri memiliki jalur akses yang lebih terbatas.

Ketersediaan dan Akses yang Dibatasi

Google menerapkan pendekatan hati-hati untuk peluncuran Gemini 3.5 Flash Cyber. Model ini akan tersedia melalui program pilot dengan akses terbatas bagi pemerintah dan mitra tepercaya, melalui CodeMender.

Pembatasan tersebut berkaitan dengan sifat dual-use dari teknologi keamanan siber. Kemampuan untuk menemukan dan memvalidasi kerentanan dapat digunakan untuk pertahanan, tetapi juga berpotensi disalahgunakan untuk tujuan ofensif.

Teknologi dual-use adalah teknologi yang dapat digunakan untuk tujuan bermanfaat maupun tujuan berbahaya, tergantung pihak yang mengoperasikan dan pengamanan yang diterapkan.

Model keamanan yang mampu menganalisis kode kompleks dapat membantu organisasi menambal celah lebih cepat. Namun, apabila tersedia tanpa kontrol yang memadai, kemampuan serupa dapat mempercepat pencarian kelemahan oleh pihak yang tidak bertanggung jawab.

Karena itu, akses terbatas bukan hanya strategi produk. Langkah tersebut juga merupakan bagian dari mitigasi risiko dalam pengembangan AI berkemampuan tinggi.

Informasi resmi mengenai model dan arah penerapannya tersedia pada pengumuman Google DeepMind tentang Gemini 3.5 Flash Cyber. Untuk konteks lebih luas mengenai model Flash yang dirilis bersamaan, Google juga menyediakan informasi tentang Gemini 3.6 Flash dan 3.5 Flash-Lite.

Mengapa Akses Terbatas Penting untuk Model Keamanan Siber?

Akses terbatas memberi penyedia teknologi lebih banyak ruang untuk menguji kontrol, memantau penggunaan, dan mengumpulkan masukan dari lingkungan yang diawasi. Dalam konteks keamanan siber, hal ini penting karena kemampuan model dapat berubah ketika digabungkan dengan alat, basis kode, dan agen otomatis.

Beberapa alasan penerapan akses terbatas antara lain:

Mengurangi risiko penyalahgunaan awal
Model dengan kemampuan analisis kerentanan perlu ditempatkan pada pengguna dan skenario yang telah melalui proses evaluasi.
Menguji guardrail dalam kondisi nyata
Pengamanan model tidak cukup diuji di lingkungan laboratorium. Implementasi pilot dapat menunjukkan celah kebijakan atau skenario penggunaan yang belum diperkirakan.
Meningkatkan kualitas alur pertahanan
Masukan dari peneliti keamanan dan tim defensif dapat membantu meningkatkan validasi, pelaporan, dan integrasi perbaikan.
Menjaga keterlacakan penggunaan
Akses terkontrol memudahkan audit, investigasi insiden, dan penegakan kebijakan penggunaan.
Membatasi otomatisasi berisiko tinggi
Analisis kerentanan tanpa pengawasan pada target yang tidak sah dapat menimbulkan dampak hukum dan keamanan yang serius.

Pendekatan ini sejalan dengan perhatian industri terhadap kemampuan AI di bidang keamanan. Pemanfaatan AI untuk pertahanan berkembang cepat, tetapi kontrol terhadap penggunaan menjadi bagian yang tidak dapat dipisahkan dari desain produknya.

Posisi Gemini 3.5 Flash Cyber dalam Persaingan AI Keamanan

Peluncuran Gemini 3.5 Flash Cyber menunjukkan bahwa persaingan model AI tidak lagi hanya berkisar pada chatbot umum, pembuatan gambar, atau coding asisten. Keamanan perangkat lunak kini menjadi area strategis karena hampir seluruh organisasi bergantung pada aplikasi, layanan cloud, dan rantai pasok perangkat lunak.

Google memasuki area ini ketika perusahaan lain juga mengembangkan sistem AI untuk penemuan kerentanan dan otomasi pertahanan. CNBC menggambarkan peluncuran tersebut sebagai langkah Google untuk memperkuat posisi dalam perlombaan AI keamanan siber, termasuk dalam persaingan dengan model khusus dari perusahaan lain.

Perbedaan penting dari Gemini 3.5 Flash Cyber terletak pada penekanannya terhadap efisiensi. Google tidak semata-mata memposisikan model ini sebagai model terbesar atau paling mahal. Sebaliknya, perusahaan menekankan kemampuan menjalankan banyak agen dengan biaya yang lebih rendah agar pencarian kerentanan dapat diperluas.

Strategi tersebut relevan bagi organisasi besar karena biaya operasi AI menjadi faktor utama. Model dengan skor benchmark tinggi belum tentu menjadi pilihan terbaik apabila tidak dapat dijalankan secara rutin pada repositori, pipeline, dan perubahan kode dalam jumlah besar.

Efisiensi Biaya dalam Keamanan Kode Berbasis AI

Biaya AI dalam keamanan perangkat lunak tidak hanya bergantung pada harga per token. Organisasi juga perlu mempertimbangkan jumlah pemanggilan, panjang konteks kode, frekuensi pemindaian, kebutuhan penyimpanan hasil, waktu investigasi, dan biaya regresi akibat patch yang salah.

Gemini 3.5 Flash Cyber dirancang sebagai alternatif yang hemat biaya bagi model keamanan siber yang lebih besar. Pendekatan ini memungkinkan pemanggilan berulang melalui subagen, sehingga lebih banyak jalur kode dapat dianalisis dalam satu proses.

Aspek biaya yang perlu diperhatikan dalam adopsi AI keamanan meliputi:

Frekuensi pemindaian, misalnya per commit, harian, mingguan, atau menjelang rilis.
Ukuran basis kode, termasuk monorepo, dependensi, dan artefak konfigurasi.
Kompleksitas konteks, terutama pada aplikasi yang memiliki banyak layanan dan integrasi.
Biaya validasi manusia, karena temuan AI tetap harus ditinjau.
Biaya perbaikan dan pengujian, termasuk pengujian regresi pascapatch.
Nilai risiko yang dicegah, seperti kebocoran data, gangguan layanan, atau eksploitasi zero-day.

Efisiensi bukan berarti pemindaian keamanan boleh dilakukan tanpa kedalaman. Tujuannya adalah membuat pemeriksaan mendalam dapat dilakukan lebih sering dan lebih luas tanpa membebani anggaran secara tidak proporsional.

Peran Data Keamanan dan Pengalaman Google

Google menyebut beberapa sumber daya keamanan yang mendukung pengalaman perusahaan dalam membangun model pertahanan, termasuk OSV.dev dan hasil lebih dari satu dekade dari OSS-Fuzz.

OSV.dev adalah basis data kerentanan open source yang dikelola Google. Data seperti ini berguna untuk memahami pola kelemahan perangkat lunak, paket yang terdampak, versi rentan, serta hubungan antara kerentanan dan perbaikan.

Sementara itu, OSS-Fuzz merupakan proyek fuzzing berkelanjutan untuk perangkat lunak open source. Fuzzing adalah teknik pengujian yang memasukkan variasi data masukan untuk menemukan perilaku tidak terduga, crash, atau kelemahan keamanan. Penjelasan umum mengenai konsep ini dapat ditemukan pada halaman Wikipedia tentang fuzzing.

Kombinasi data kerentanan, pengalaman penemuan bug, dan infrastruktur pengujian memberi Google dasar yang kuat untuk melatih atau mengevaluasi sistem keamanan. Namun, keunggulan model tetap bergantung pada bagaimana data digunakan, bagaimana evaluasi dilakukan, dan seberapa baik sistem menjaga batas penggunaan yang aman.

Risiko dan Keterbatasan AI untuk Pencarian Kerentanan

AI dapat mempercepat proses keamanan, tetapi tidak dapat diperlakukan sebagai alat yang selalu benar. Kerentanan perangkat lunak sangat bergantung pada konteks, arsitektur, konfigurasi deployment, kontrol akses, dan perilaku pengguna.

Beberapa keterbatasan yang perlu diperhatikan:

False positive dan false negative

Model dapat menandai masalah yang ternyata tidak dapat dieksploitasi. Sebaliknya, model juga dapat melewatkan kerentanan penting yang tidak cocok dengan pola yang dikenali.

False positive dapat meningkatkan beban triage. False negative dapat menciptakan rasa aman palsu. Karena itu, hasil model harus menjadi masukan untuk investigasi, bukan pengganti jaminan keamanan.

Kurangnya konteks operasional

Kode tidak selalu menggambarkan seluruh kondisi sistem. Konfigurasi cloud, secret management, aturan jaringan, pipeline CI/CD, kontrol identitas, dan kebijakan runtime dapat menentukan apakah suatu temuan benar-benar berisiko.

Tim keamanan perlu menggabungkan hasil analisis kode dengan informasi operasional. Pendekatan ini dikenal sebagai pengamanan yang mempertimbangkan konteks aplikasi secara menyeluruh.

Risiko patch otomatis

Usulan patch yang tampak benar dapat menimbulkan bug baru. Perubahan kecil pada validasi, otorisasi, atau manajemen memori dapat memengaruhi perilaku aplikasi yang penting.

Patch dari AI sebaiknya melewati proses review, pengujian otomatis, pengujian integrasi, dan evaluasi keamanan sebelum masuk ke lingkungan produksi.

Risiko kebocoran data

Penggunaan model AI pada basis kode dapat melibatkan informasi sensitif seperti logika bisnis, token konfigurasi, nama layanan internal, atau pola arsitektur. Organisasi harus memahami kebijakan pemrosesan data, kontrol akses, dan mekanisme perlindungan data yang diterapkan pada platform AI.

Ketergantungan berlebihan pada satu alat

Sistem keamanan yang sehat membutuhkan lebih dari satu lapisan. Pemindaian AI dapat melengkapi static application security testing, dynamic testing, dependency scanning, code review, threat modeling, bug bounty, monitoring, dan respons insiden.

Tidak ada satu alat yang mampu menghapus seluruh risiko keamanan perangkat lunak.

Praktik Terbaik Menggunakan AI untuk Keamanan Kode

Organisasi yang menggunakan AI untuk keamanan kode perlu membangun proses yang jelas sejak awal. Teknologi dapat mempercepat pekerjaan, tetapi manfaatnya akan berkurang jika hasilnya tidak masuk ke alur pengembangan dan respons keamanan yang terstruktur.

Berikut beberapa praktik yang dapat diterapkan.

Tetapkan ruang lingkup pemindaian

Mulailah dari area dengan risiko tinggi, seperti:

Layanan yang menghadap internet.
Komponen autentikasi dan otorisasi.
API publik.
Pemrosesan file atau data tidak tepercaya.
Komponen yang menggunakan bahasa dengan risiko memory safety.
Dependensi yang sering diperbarui.
Kode yang menangani data pribadi atau transaksi sensitif.

Ruang lingkup yang jelas membantu mengukur hasil dan menghindari banjir temuan yang tidak dapat ditindaklanjuti.

Integrasikan ke pipeline pengembangan

Pemindaian keamanan akan lebih efektif jika menjadi bagian dari proses rutin, bukan kegiatan terpisah yang hanya dilakukan setelah ada insiden. Integrasi dapat dilakukan pada tahap pull request, build, staging, atau sebelum rilis.

Penerapan bertahap biasanya lebih realistis:

Jalankan pemindaian dalam mode observasi.
Ukur kualitas temuan dan waktu triage.
Tambahkan aturan prioritas untuk temuan berisiko tinggi.
Hubungkan hasil dengan sistem ticketing atau security workflow.
Terapkan pemblokiran rilis hanya untuk kategori risiko yang telah tervalidasi.

Gunakan validasi manusia untuk tindakan penting

Temuan dengan dampak besar perlu dinilai oleh pengembang dan profesional keamanan. Validasi manusia diperlukan untuk menentukan tingkat keparahan, dampak bisnis, kelayakan eksploitasi, serta strategi perbaikan.

Model AI dapat mempercepat proses investigasi, tetapi keputusan untuk mengubah sistem produksi harus tetap mengikuti tata kelola teknis organisasi.

Ukur hasil dengan metrik yang tepat

Jumlah temuan bukan satu-satunya indikator keberhasilan. Organisasi dapat mempertimbangkan metrik berikut:

Metrik	Makna
Rasio temuan valid	Persentase temuan yang benar-benar relevan setelah triage
Waktu dari temuan ke perbaikan	Kecepatan organisasi menutup risiko
Jumlah kerentanan unik	Kemampuan sistem menemukan masalah baru
Tingkat duplikasi laporan	Seberapa banyak temuan yang mengulang masalah sama
Cakupan basis kode	Bagian kode dan layanan yang telah dianalisis
Tingkat regresi patch	Frekuensi patch keamanan menyebabkan masalah baru

Metrik tersebut membantu organisasi menilai apakah AI meningkatkan kualitas pertahanan atau hanya menambah volume peringatan.

Terapkan kontrol akses dan audit

Akses ke model keamanan, repositori, laporan kerentanan, dan data kode harus dibatasi sesuai peran. Aktivitas pemindaian perlu dapat diaudit, terutama pada proyek yang mengelola data sensitif atau infrastruktur kritis.

Kontrol ini juga penting saat menggunakan sistem AI yang memiliki kemampuan tinggi. Audit membantu mendeteksi penggunaan di luar wewenang dan memudahkan investigasi apabila muncul masalah.

Dampak bagi Tim Pengembang dan Profesional Keamanan

Gemini 3.5 Flash Cyber berpotensi mengubah pembagian kerja antara pengembang, AppSec, peneliti keamanan, dan tim operasi. Bukan dengan menghapus peran manusia, melainkan dengan memindahkan sebagian pekerjaan berulang ke sistem yang dapat melakukan pemeriksaan awal pada skala lebih besar.

Bagi pengembang, manfaat utama dapat berupa umpan balik keamanan yang lebih cepat saat perubahan kode masih mudah diperbaiki. Kerentanan yang ditemukan sebelum rilis biasanya membutuhkan biaya penanganan lebih rendah dibanding masalah yang baru terlihat di produksi.

Bagi tim keamanan aplikasi, model khusus dapat membantu memperluas cakupan pemeriksaan. Tim dapat lebih fokus pada threat modeling, validasi kasus kompleks, desain kontrol, dan investigasi dampak daripada hanya menangani peringatan dasar.

Bagi manajemen teknologi, nilai utamanya terletak pada pengurangan risiko operasional. Percepatan penemuan dan perbaikan kerentanan dapat membantu menjaga keandalan layanan, melindungi data, dan mengurangi risiko gangguan bisnis.

FAQ tentang Gemini 3.5 Flash Cyber

Apa fungsi utama Gemini 3.5 Flash Cyber?

Gemini 3.5 Flash Cyber dirancang untuk membantu menemukan, memvalidasi, dan memperbaiki kerentanan perangkat lunak. Model ini digunakan dalam CodeMender untuk menganalisis basis kode dan memperluas pencarian terhadap jalur eksekusi yang berpotensi memiliki risiko keamanan.

Apakah Gemini 3.5 Flash Cyber tersedia untuk umum?

Belum tersedia secara umum. Google menyatakan model ini akan diluncurkan melalui program pilot dengan akses terbatas bagi pemerintah dan mitra tepercaya melalui CodeMender.

Apa perbedaan Gemini 3.5 Flash Cyber dan Gemini 3.6 Flash?

Gemini 3.6 Flash adalah model workhorse untuk coding, pekerjaan pengetahuan, dan tugas multimodal. Gemini 3.5 Flash Cyber merupakan model yang lebih khusus, disetel untuk pencarian dan perbaikan kerentanan perangkat lunak.

Mengapa Google memakai model ringan untuk keamanan siber?

Pencarian kerentanan membutuhkan eksplorasi banyak jalur kode. Model yang lebih ringan dan hemat biaya dapat dipanggil berulang kali oleh banyak subagen, sehingga sistem dapat menganalisis cakupan yang lebih luas tanpa mengandalkan satu pemanggilan model besar.

Berapa banyak kerentanan yang ditemukan Gemini 3.5 Flash Cyber pada V8?

Dalam pengujian yang dipublikasikan Google, Gemini 3.5 Flash Cyber menemukan 55 masalah unik yang telah dikonfirmasi pada mesin JavaScript V8. Gemini 3.5 Flash menemukan 47 masalah, sedangkan Claude Opus 4.6 menemukan 36 masalah dalam perbandingan tersebut.

Apakah hasil dari AI keamanan dapat langsung dipakai untuk membuat patch?

Tidak sebaiknya langsung diterapkan. Usulan perbaikan dari AI tetap perlu melalui review manusia, pengujian unit, pengujian integrasi, pengujian keamanan, dan proses persetujuan sebelum diterapkan pada sistem produksi.

Risiko dan Batasan yang Perlu Dikelola

Kemampuan menemukan pola kerentanan tidak membuat sistem AI bebas dari kesalahan. Gemini 3.5 Flash Cyber dapat menghasilkan temuan yang terlihat meyakinkan, tetapi tidak selalu memiliki dampak keamanan yang nyata. Kondisi konfigurasi, batas hak akses, mekanisme mitigasi yang sudah aktif, atau jalur kode yang tidak dapat dijangkau dapat mengubah tingkat risiko suatu laporan.

Karena itu, proses triage tetap menjadi bagian penting. Tim keamanan perlu memeriksa apakah masalah dapat direproduksi, apakah penyerang memiliki prasyarat yang diperlukan, dan apakah kerentanan memengaruhi komponen yang digunakan di lingkungan produksi.

False positive dapat menguras kapasitas tim

Laporan yang keliru atau kurang relevan dapat menghabiskan waktu pengembang. Jika jumlah peringatan meningkat tanpa mekanisme prioritas yang baik, tim berisiko kehilangan fokus terhadap temuan dengan dampak lebih besar.

Penyaringan awal dapat dilakukan dengan mengelompokkan temuan berdasarkan jenis kerentanan, tingkat kepercayaan model, komponen terdampak, dan kemungkinan eksploitasi. Temuan yang menyentuh autentikasi, pemrosesan input, manajemen memori, atau akses data sensitif biasanya layak mendapat peninjauan lebih cepat.

Penerapan bertahap juga membantu. Organisasi dapat memulai dari repositori yang memiliki cakupan pengujian kuat dan pemilik kode yang jelas. Hasil dari tahap awal dapat digunakan untuk menyesuaikan aturan, alur eskalasi, serta standar bukti sebelum sistem diperluas ke proyek lain.

Patch yang benar belum tentu aman diterapkan

Perbaikan kode yang tampak tepat pada satu fungsi dapat menimbulkan efek samping pada bagian lain. Contohnya, validasi input baru mungkin menolak data yang sebelumnya sah, atau perubahan manajemen memori dapat memengaruhi performa layanan.

CodeMender dan sistem sejenis perlu ditempatkan sebagai pendukung proses rekayasa perangkat lunak, bukan pengganti pengujian. Patch yang diusulkan tetap perlu melewati pemeriksaan berikut:

Peninjauan kode oleh pengembang yang memahami komponen terkait
Pengujian unit untuk perilaku baru dan kasus batas
Pengujian integrasi pada layanan yang saling bergantung
Pemindaian ulang untuk memastikan kerentanan benar-benar tertutup
Pemantauan pascarilis untuk mendeteksi regresi

Praktik tersebut selaras dengan pendekatan secure by design yang mendorong keamanan menjadi bagian dari proses pengembangan, bukan pekerjaan tambahan setelah produk selesai dibuat. Prinsip tersebut dijelaskan lebih lanjut dalam panduan Secure by Design dari CISA.

Peran Data Kode dalam Keamanan Model

Model keamanan hanya dapat bekerja sebaik konteks yang tersedia. Basis kode yang tidak terdokumentasi, dependensi yang tidak tercatat, dan konfigurasi lingkungan yang terpisah dari repositori dapat membuat analisis kehilangan informasi penting.

Sebuah fungsi mungkin terlihat aman saat dibaca sendiri, tetapi menjadi berisiko ketika menerima data dari layanan lain atau dijalankan dengan hak akses tertentu. Sebaliknya, model dapat menandai kode lama sebagai berbahaya tanpa mengetahui bahwa lapisan perlindungan telah diterapkan di tingkat infrastruktur.

Dokumentasi arsitektur, daftar dependensi, aturan pengelolaan rahasia, dan peta aliran data membantu manusia maupun sistem AI memahami konteks tersebut. Perbaikan kualitas artefak pengembangan dapat meningkatkan mutu temuan keamanan tanpa perlu mengubah model yang digunakan.

Dependensi pihak ketiga tetap memerlukan perhatian

Banyak risiko aplikasi tidak berasal dari kode internal, melainkan dari pustaka, paket, atau komponen sumber terbuka. Analisis kode dengan Gemini 3.5 Flash Cyber dapat melengkapi pemeriksaan dependensi, tetapi tidak menggantikan inventaris perangkat lunak dan pemantauan pembaruan keamanan.

Tim dapat menggabungkan hasil analisis kode dengan daftar komponen perangkat lunak atau software bill of materials (SBOM). Pendekatan ini memudahkan identifikasi layanan yang terpengaruh ketika muncul kerentanan pada pustaka umum.

Informasi kerentanan yang telah diberi pengenal biasanya dapat ditelusuri melalui National Vulnerability Database. Basis data tersebut berguna untuk memeriksa detail teknis, status publikasi, dan referensi perbaikan dari kerentanan yang diketahui.

Kapan Gemini 3.5 Flash Cyber Paling Relevan

Model khusus keamanan berpotensi memberi nilai besar pada proyek dengan basis kode luas, perubahan cepat, atau banyak jalur eksekusi yang sulit diperiksa secara manual. Mesin runtime, layanan internet berskala besar, perangkat lunak infrastruktur, dan aplikasi yang memproses data bernilai tinggi merupakan contoh lingkungan yang membutuhkan pemeriksaan berulang.

Nilainya juga dapat terlihat pada proses sebelum rilis. Ketika analisis dilakukan pada pull request atau kandidat rilis, pengembang dapat memperoleh indikasi risiko saat konteks perubahan masih segar. Waktu investigasi cenderung lebih singkat dibanding penelusuran masalah setelah kode masuk ke produksi.

Namun, organisasi kecil tidak selalu membutuhkan sistem yang rumit. Penggunaan yang efektif bergantung pada kapasitas review, kualitas pengujian, serta kemampuan menindaklanjuti temuan. Tanpa proses perbaikan yang jelas, peningkatan deteksi tidak otomatis menghasilkan peningkatan keamanan.

Tanda organisasi siap menjalankan pilot

Pilot terbatas lebih mudah dievaluasi apabila beberapa kondisi dasar sudah tersedia:

Repositori memiliki pemilik teknis yang dapat menilai laporan
Proses pelaporan kerentanan sudah memiliki jalur prioritas
Lingkungan pengujian cukup representatif untuk memvalidasi patch
Akses ke kode dan hasil analisis diatur berdasarkan peran
Metrik kualitas temuan dicatat sejak awal

Kondisi tersebut membantu membedakan nilai nyata dari sekadar peningkatan jumlah laporan. Pada tahap awal, fokus dapat diarahkan pada satu kelas kerentanan atau satu layanan penting agar hasil review tetap terkendali.

Kesimpulan

Gemini 3.5 Flash Cyber dapat menjadi lapisan pendukung yang berguna untuk mempercepat peninjauan kode, menemukan pola risiko, dan membantu tim memusatkan perhatian pada perubahan yang paling perlu divalidasi. Namun, manfaatnya tidak ditentukan oleh model saja. Konteks arsitektur, pengelolaan dependensi, pengujian yang memadai, serta proses triase yang jelas tetap menjadi fondasi keamanan aplikasi.

Pendekatan terbaik adalah memulainya secara terukur: pilih layanan penting, tetapkan metrik kualitas temuan, lalu pastikan setiap laporan dapat diperiksa dan ditindaklanjuti oleh pemilik teknis. Gunakan pula kerangka seperti NIST Cybersecurity Framework untuk menjaga program keamanan tetap terarah. Teknologi dapat mempercepat deteksi, tetapi ketahanan yang nyata dibangun dari keputusan tim untuk memperbaiki risiko sebelum risiko tersebut menjadi insiden.

Referensi

DeepMind. (2026). Introducing Gemini 3.5 Flash Cyber.

Google. (2026). Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber.

Cyber Security News. (2026). Gemini 3.5 Flash Cyber With Automated Faster Vulnerability Detection and Patch Capabilities.

The Hacker News. (2026). Google Launches Gemini 3.5 Flash Cyber AI to Find and Fix Software Vulnerabilities.

CNBC. (2026). Google Expands Gemini Lineup With Cheaper Models and New Mythos Rival.

TechCrunch. (2026). Google Releases Three New Gemini Models — But No 3.5 Pro.

Cybernews. (2026). Google Launches Gemini 3.5 Flash Cyber — A New AI Security Model to Rival Anthropic's Mythos.

The New York Times. (2026). Google Releases Three New Gemini A.I. Models.

MarkTechPost. (2026). Google Releases Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber.

Reuters. (2026). Google Updates Lightweight Gemini Models, but Flagship Still Delayed.

Android Headlines. (2026). Google Launches Gemini 3.5 Flash Cyber to Catch Code Exploits Before Hackers Do.