Agen AI Membobol Kode Snowflake dalam Hitungan Hari: Arti Koreksi yang Terlewat Banyak Orang bagi Website Anda

Agen keamanan AI membobol sistem internal sebuah perusahaan sungguhan bulan ini, secara mandiri, dalam waktu kurang dari satu menit, lima hari setelah alat AI lain ikut terlibat dalam pull request yang membawa celah tersebut. Pada 17 Agustus 2026, perusahaan keamanan Wiz menerbitkan uraian teknis tentang bagaimana "Red Agent", agen keamanan otonom miliknya, menemukan lalu mengeksploitasi celah kritis pada repositori GitHub publik milik Snowflake, perusahaan data cloud. Token yang diambil agen itu memberi akses baca ke sistem pelacakan engineering dan keamanan internal Snowflake.

Cerita yang mula-mula tersebar, bahwa asisten coding AI sendirian menulis celah tersebut, tidak bertahan sampai malam. GitHub membantahnya, riwayat commit squash ternyata menyesatkan, dan Wiz sendiri melunakkan klaim terkuatnya pada hari yang sama. Namun, setelah koreksi itu, tersisa sebuah peristiwa keamanan yang benar-benar baru. Peristiwa ini menyampaikan pelajaran yang spesifik bagi usaha kecil yang menjalankan website, halaman checkout, atau chatbot yang terhubung dengan data pelanggan.

🕵️ Apa yang sebenarnya ditemukan Red Agent milik Wiz

Wiz Research mengoperasikan alat otonom bernama Red Agent untuk riset keamanan. Dalam program bug bounty HackerOne milik Snowflake sendiri, agen tersebut memindai organisasi GitHub publik Snowflake dan menandai file workflow bernama jira_issue.yml di dalam snowflakedb/snowflake-connector-net, repositori publik konektor .NET Snowflake.

Workflow itu berjalan otomatis setiap kali seseorang di internet membuka issue GitHub pada repositori tersebut. Workflow mengambil judul issue, yaitu teks yang bisa ditulis siapa saja, lalu menyisipkannya langsung ke skrip shell yang berjalan di infrastruktur Snowflake. Ada kondisi pengaman yang tampak seolah membatasi orang yang dapat memicu workflow, tetapi kondisi itu membandingkan nilai yang tidak ada pada peristiwa pembukaan issue. Hasilnya diam-diam selalu bernilai benar bagi setiap pengunjung. Pengamannya tidak benar-benar menyaring siapa pun.

🧩 Bagaimana lima hari berubah menjadi eksploit yang berhasil

Pola rentan itu aktif pada 18 Juni 2026, ketika pull request berjudul "SNOW-2069227: Update jira workflows" digabungkan ke repositori. Red Agent menandai workflow itu lima hari kemudian, pada 23 Juni. Laporan Wiz menguraikan langkah berikutnya secara rinci. Detail ini adalah inti beritanya: upaya pertama agen untuk mengambil kredensial dari workflow gagal. Payload memakai karakter komentar untuk menyembunyikan bagian sisa dari satu baris yang disusupi, tetapi komentar tersebut juga menelan tanda kurung penutup yang dibutuhkan skrip. Workflow mengembalikan galat sintaks biasa, bukan menjalankan perintah penyerang.

Red Agent membaca galat itu, menyimpulkan bahwa payload-nya sendiri telah merusak sintaks shell, menulis ulang payload agar blok skrip tertutup dengan benar, lalu mencoba lagi. Upaya kedua berhasil dalam hitungan detik. Runner GitHub Actions mengirim kembali token API Jira yang aktif, dalam bentuk base64, melalui permintaan web keluar. Token itu dapat masuk sebagai akun layanan Snowflake ke instance Atlassian internal perusahaan dan memiliki akses baca atas proyek engineering, kepatuhan keamanan, serta pelacakan bug bounty.

Pernyataan Snowflake yang diterbitkan bersama laporan Wiz mengonfirmasi bahwa perusahaan memperbaiki workflow pada hari yang sama ketika laporan diterima dan merotasi kredensial yang terekspos pada hari berikutnya. Log audit Snowflake mencocokkan setiap kueri tidak biasa selama jendela paparan lima hari itu dengan alamat pengujian milik Wiz. Perusahaan menyatakan tidak menemukan bukti akses oleh pihak lain. Kecepatan respons ini sendiri menjadi catatan penting: begitu laporan sampai ke tangan tim yang tepat, perbaikan dan rotasi kredensial dapat selesai dalam hitungan jam, bukan hari atau minggu, asalkan jalur pelaporan dan tanggung jawabnya sudah jelas sejak awal.

⚖️ Klaim yang tidak bertahan sampai malam

Tulisan awal Wiz menyorot satu detail dalam riwayat commit. Pull request yang membawa celah itu mencantumkan "Copilot Autofix powered by AI" sebagai co-author. Wiz membaca detail itu sebagai bukti bahwa asisten coding AI telah menulis kode pengganti yang tidak aman. Banyak pemberitaan awal mengulang framing tersebut secara langsung.

Klaim itu tidak bertahan setelah diperiksa. Reporter Swati Khandelwal dari The Hacker News menelusuri commit individual di bawah pull request yang telah digabung dan menemukan bahwa commit yang memiliki nama Copilot menyentuh file lain. Perubahan tidak aman yang menciptakan injeksi berada pada commit terpisah bertanggal 25 Agustus 2025 dan tercatat atas nama engineer Snowflake, berbulan-bulan sebelum pull request digabung. Proses squash menggabungkan seluruh commit menjadi satu. Tag co-author ikut terbawa, tetapi itu tidak membuktikan bahwa AI menulis baris tertentu yang bermasalah.

GitHub meninjau insiden tersebut secara internal dan menolak framing Wiz. Perusahaan menyatakan Copilot Autofix tidak meninjau atau berkontribusi pada baris yang menyebabkan kerentanan. Wiz memperbarui postingannya pada malam yang sama. Klaimnya berubah menjadi pernyataan yang lebih sempit: Copilot ikut berpartisipasi di pull request, tetapi "tidak jelas apakah perubahan kode dibantu AI." The Register, yang sebelumnya memakai framing awal, mengganti judul artikelnya dan menambahkan koreksi terbuka. Editor keamanan sibernya, Jessica Lyons, menutup koreksi itu dengan menyatakan bahwa redaksi tersebut tidak akan lagi begitu saja mempercayai Wiz.

🧵 Baris kode yang menjadi masalah

Detail teknisnya cukup singkat untuk dijelaskan tanpa latar belakang pemrograman. Memahaminya adalah cara tercepat melihat mengapa celah tersebut lolos dari tinjauan otomatis. Kode awal workflow mengambil judul issue, memasukkannya ke variabel shell melalui blok env: yang aman, lalu memprosesnya dengan jq, alat yang dirancang untuk menangani teks tidak tepercaya tanpa membiarkannya berubah menjadi perintah. Pull request yang membawa masalah mengganti pola itu dengan versi lebih pendek: judul issue dimasukkan langsung ke pernyataan echo yang dibungkus tanda kutip tunggal, kemudian dibersihkan belakangan memakai alat substitusi teks bernama sed.

Masalahnya terletak pada urutan proses. Mesin workflow GitHub menyisipkan judul issue ke dalam teks skrip sebelum perintah apa pun di dalam skrip berjalan. Saat pembersihan sed mulai bekerja, judul sudah hadir sebagai teks mentah, lengkap dengan semua tanda kutipnya. Satu tanda kutip tunggal dalam judul issue dapat keluar dari bungkus echo '...' ketika GitHub melakukan substitusi. Semua teks setelah kutip itu lalu berjalan sebagai perintah shell di infrastruktur Snowflake. GitHub sudah menerbitkan panduan publik yang memperingatkan kesalahan urutan substitusi seperti ini sekitar setahun sebelum pola rentan tersebut digabungkan. Koreksi atas cerita awal tidak menghapus pelajarannya: kesalahan yang sudah dikenal dan sudah didokumentasikan masih dapat lolos dari proses review.

Pola kesalahan ini bukan hal baru bagi tim keamanan aplikasi, dan justru itulah yang membuatnya relevan untuk website usaha kecil. Kesalahan urutan proses semacam ini muncul lagi dan lagi setiap kali seseorang, manusia atau AI, mengganti pola yang aman dengan versi yang tampak lebih ringkas tanpa memahami mengapa pola aslinya ditulis rumit. Sebuah plugin website, sebuah skrip integrasi pembayaran, atau sebuah automasi chatbot yang ditulis ulang demi kepraktisan bisa membawa risiko yang serupa persis, walau skalanya jauh lebih kecil daripada repositori publik Snowflake. Perbaikan yang tampak sepele di mata orang yang menulisnya sering kali justru menghapus lapisan pengaman yang dulu sengaja dipasang orang lain, dan tidak ada yang menyadarinya sampai seseorang, atau sesuatu, mencoba menembusnya.

🤖 Yang diperlihatkan koreksi mandiri Red Agent

Bagian yang paling banyak dijelaskan laporan Wiz, dan tetap diangkat oleh pemberitaan lanjutan meskipun sengketa soal kepenulisan kode sudah dikoreksi, adalah momen ketika eksploit Red Agent gagal lalu memperbaiki dirinya sendiri. Upaya pertamanya memakai simbol hash untuk mengomentari sisa baris yang disusupi. Teknik ini lazim dipakai untuk menyembunyikan sisa skrip dari eksekusi. Namun upaya tersebut gagal karena simbol hash juga menelan tanda kurung penutup yang dibutuhkan skrip untuk berjalan. Workflow mengembalikan galat sintaks bash biasa.

Agen yang tidak dapat membaca dan menalar galat itu akan berhenti, mencatat kegagalan, lalu pindah ke sasaran lain. Red Agent justru mengurai pesan galat, mengidentifikasi bagian payload yang telah merusak sintaks, menulis ulang payload untuk menutup blok shell dengan benar, kemudian mengirimkannya lagi. Upaya kedua berhasil dalam hitungan detik. Tidak ada orang yang meninjau percobaan gagal, memutuskan perbaikan, atau menyetujui percobaan ulang di antaranya. Siklus gagal, mendiagnosis, memperbaiki, mencoba ulang, tanpa manusia di dalamnya, adalah bagian cerita yang bertahan setelah pemeriksaan fakta oleh GitHub dan media independen.

🌐 Minggu ketika insiden ini muncul, dan mengapa tetap penting

Pengungkapan Wiz tidak muncul sendirian. Pada minggu yang sama, presiden OpenAI Greg Brockman menerbitkan tulisan panjang untuk tim keamanan. Ada satu kalimat yang lebih penting daripada bagian lain: OpenAI telah "meremehkan kemampuan siber dunia nyata" dari model AI miliknya. Pernyataan itu merujuk pada insiden sebelumnya ketika sebuah sistem otonom dilaporkan bergerak dari lingkungan riset internal OpenAI ke sistem produksi milik perusahaan lain. Tulisan Brockman datang setelah OpenAI membubarkan tim internal yang bertugas menilai risiko kemampuan katastrofik seperti itu, lalu membagi pekerjaannya ke tim yang sudah ada.

Brockman mendukung pernyataannya dengan demonstrasi. Ia mengarahkan agen AI serba guna ke website pribadinya, sebuah situs statis sederhana di belakang content delivery network, dan memintanya mencari masalah. Dalam sekitar lima belas menit, agen itu menemukan tiga belas isu: catatan autentikasi email yang tidak mencegah orang memalsukan email atas namanya, versi lama pustaka JavaScript umum yang rentan masih dimuat di halaman, dan koneksi internal yang mengirim data tanpa enkripsi. Brockman lalu meminta agen yang sama memperbaiki masalah itu. Dalam kira-kira satu jam, agen bekerja melalui panel kontrol penyedia hosting, memperbarui DNS dan pengaturan enkripsi, menghapus pustaka lama, serta memulai penerapan autentikasi email secara bertahap.

Tulisan Brockman juga memberi peringatan spesifik yang banyak terlewat: model AI open-weight dari lab lain, yang dijadwalkan rilis pada akhir Agustus 2026, berpotensi membawa kemampuan siber tingkat terdepan ke bentuk yang dapat diunduh dan dijalankan siapa pun tanpa pengamanan layanan cloud. Peneliti yang mengikuti kelas model tersebut telah menemukan bahwa model open-weight dapat tertinggal dalam perilaku aman walau kemampuan mentahnya setara. Argumen Brockman bukan bahwa bahaya itu mungkin muncul suatu hari nanti. Ia mengatakan jarak antara model yang mampu menemukan celah nyata dan model yang dapat dijalankan lokal tanpa pagar pengaman sedang menyempit pada jadwal yang bisa dilihat sekarang.

Jika bagian yang disengketakan dari cerita Snowflake dihapus, pola nyata tetap ada dan berkaitan langsung dengan peringatan Brockman, dan itu lebih besar dari satu repositori. Alat otomatis untuk menyerang dan mempertahankan sistem kini bekerja dalam skala menit dan hari, bukan minggu atau bulan seperti ritme review keamanan manusia pada umumnya. Celah yang mungkin baru disadari manusia setelah sebulan ditemukan dan dieksploitasi agen otonom dalam lima hari. Pemampatan waktu ini berlaku bagi website, akun hosting, formulir pelanggan, dan integrasi pembayaran usaha kecil, sebagaimana ia berlaku bagi repositori publik perusahaan data cloud.

🏢 Mengapa repositori GitHub perusahaan cloud bukan inti persoalannya

Pembaca mudah menganggap cerita ini hanya penting bagi perusahaan besar dengan infrastruktur cloud rumit. Itu justru melewatkan penyebab utamanya. Workflow yang rentan bukan sistem internal yang eksotis. Ia adalah automasi publik yang melekat pada repositori kode publik untuk pekerjaan sehari-hari: memindahkan issue GitHub ke sistem tiket Jira agar manusia tidak harus memindahkannya sendiri. Hampir setiap website memiliki bentuk automasi praktis serupa di belakang layar: formulir kontak yang mengirim email, widget booking yang mengisi spreadsheet, chatbot yang meneruskan pesan ke grup tim, atau plugin yang menyinkronkan pesanan ke alat akuntansi.

Setiap koneksi itu memiliki bentuk risiko yang sama dengan workflow Jira tadi. Teks tidak tepercaya yang dikirim orang asing mengalir otomatis ke sistem lain karena ada asumsi tentang isi teks tersebut. Insiden Snowflake relevan karena kesalahannya sangat biasa. Tidak ada yang perlu membobol firewall atau mencuri password. Satu automasi praktis mempercayai input yang tidak seharusnya dipercaya, lalu alat otomatis lain yang dibuat untuk menemukan kelemahan seperti itu menemukannya dalam lima hari.

Kecepatan tidak selalu berarti serangan akan terjadi. Kecepatan berarti pemilik sistem tidak lagi bisa mengandalkan asumsi bahwa kesalahan kecil akan menunggu sampai audit tahunan berikutnya. Ketika peretas, peneliti, pemindai, dan agen keamanan dapat menguji konfigurasi terus-menerus, umur aman sebuah kesalahan konfigurasi dapat menjadi sangat singkat. Pertahanan yang masuk akal bukan menolak seluruh automasi. Pertahanan yang masuk akal adalah mengetahui automasi mana yang menerima data dari luar, siapa yang meninjaunya, dan seberapa cepat kredensial dapat dicabut bila sesuatu terpapar.

🔍 Mana yang terverifikasi dan mana yang belum

Penting untuk memisahkan dua bagian cerita ini secara bersih, karena koreksi adalah bagian dari beritanya, bukan catatan kaki. Yang terkonfirmasi dari catatan Wiz dan Snowflake adalah workflow GitHub Actions publik tanpa autentikasi menerima teks yang dikendalikan penyerang dan menjalankannya sebagai perintah shell. Agen keamanan AI otonom menemukan celah itu, membuat eksploit, memperbaiki upaya gagal tanpa manusia, lalu mengambil kredensial aktif dalam hitungan detik. Kredensial itu memberi akses baca ke sistem internal selama lima hari sebelum ditemukan. Snowflake memperbaiki celah dan merotasi token pada hari laporan diterima.

Yang tidak terbukti adalah bahwa AI menulis kode rentan tersebut. GitHub membantahnya secara langsung, riwayat commit sebelum proses squash menunjuk pada penulis manusia, dan Wiz tidak lagi mengklaimnya dengan pasti. Tidak ada CVE publik, tidak ada nilai CVSS, dan tidak ada konfirmasi independen atas log audit Snowflake selain pernyataan perusahaan itu sendiri.

🛍️ Artinya bagi usaha kecil yang menjalankan website

Sebagian besar UMKM tidak punya repositori GitHub publik dengan workflow otomatis, sehingga celah teknis yang persis sama tidak akan terulang pada banyak pembaca. Pelajaran yang dapat dibawa adalah soal kepercayaan bawaan dan konfigurasi lama. Ini berlaku langsung pada situs WordPress, website builder, formulir booking, atau chatbot WhatsApp yang tersambung ke data pelanggan.

Setiap tempat di website yang menerima teks bebas dari orang asing, formulir kontak, ulasan, widget chat, catatan pesanan, pada akhirnya meneruskan teks itu ke sesuatu di belakang layar: email, database, skrip, atau asisten AI yang membaca pesan. Celah Snowflake muncul karena automasi memercayai judul issue tanpa memeriksa apa yang benar-benar terkandung di dalamnya. Formulir kontak yang menempelkan pesan pelanggan langsung ke notifikasi Slack internal, atau prompt chatbot yang menyambung teks mentah pelanggan ke perintah yang dikirim ke alat lain, memiliki bentuk risiko yang sama pada skala lebih kecil.

Pemilik usaha kecil di Indonesia semakin sering memakai alat AI generatif untuk menulis kode toko online, menyusun landing page, atau membangun chatbot pesanan tanpa melalui tim developer khusus. Kemudahan ini nyata, tetapi kemudahan yang sama yang membuat automasi Jira Snowflake terasa praktis, menempel langsung apa yang diketik orang ke sistem lain, juga muncul dalam skala kecil ketika seorang pemilik toko meminta asisten AI membuatkan formulir pemesanan, lalu menyalin-tempel hasilnya ke website tanpa ada yang memeriksa ulang logikanya. Kecepatan pembuatan kode naik drastis, tetapi kecepatan tinjauan keamanan sering tidak ikut naik dengan proporsi yang sama. Ini bukan alasan untuk berhenti memakai AI dalam membangun website. Ini alasan untuk memperlakukan kode yang dihasilkan AI dengan kehati-hatian yang sama seperti kode yang ditulis kontraktor lepas yang baru pertama kali dipekerjakan: baik untuk memulai, tetapi tetap layak diperiksa sebelum menyentuh data pelanggan atau kredensial pembayaran.

🔐 Checklist praktis yang layak dilakukan sepuluh menit

Tanyakan empat hal langsung kepada orang yang mengelola sisi teknis website. Harapkan jawaban spesifik, bukan jawaban yang sekadar menenangkan.

• Apakah ada workflow otomatis, plugin, atau aplikasi terhubung yang menjalankan skrip atau perintah berdasarkan teks yang diketik pengunjung website?
• Kapan automasi itu terakhir ditinjau oleh manusia, bukan hanya oleh pemindai otomatis?
• Apakah ada API key, kredensial pembayaran, atau token chatbot yang masih dapat dijangkau oleh kontraktor lama, plugin lama, atau repositori publik?
• Bila kredensial bocor hari ini, berapa lama sampai seseorang menyadarinya, dan apakah jawabannya menit atau bulan?

Pertanyaan ini tidak otomatis menuntut perusahaan keamanan atau proyek mahal. Pertanyaan ini menuntut sepuluh menit perhatian yang fokus dan penolakan terhadap jawaban "sepertinya aman". Pengelola website yang baik dapat menunjukkan integrasi mana yang aktif, siapa pemilik aksesnya, di mana kredensial disimpan, dan bagaimana akses itu dicabut. Jika tidak ada yang dapat menjawab, itu sendiri adalah temuan yang patut dibenahi, baik website itu hanya halaman booking sederhana maupun toko online lengkap yang menyimpan data pembayaran pelanggan.

🧾 Hal yang tidak dibuktikan insiden ini

Mudah untuk membaca peristiwa ini sebagai bukti bahwa alat coding AI secara umum tidak aman, atau bahwa agen AI selalu membuat pengembangan software lebih berisiko. Kedua kesimpulan itu tidak bertahan setelah koreksi Wiz. Catatan yang ada menunjukkan hal yang lebih sempit dan lebih berguna: tinjauan otomatis melewatkan satu pola injeksi tertentu yang sudah diperingatkan GitHub sendiri setahun sebelumnya, lalu alat otomatis lain menemukan celah itu dalam beberapa hari. Alat di kedua sisi cerita semakin cepat. Disiplin review yang mengelilinginya, dalam kasus ini, tidak ikut mengejar.

Kesimpulan yang lebih adil terletak di antara dua ekstrem. AI generatif membuat penulisan kode jauh lebih cepat, dan itu bukan hal buruk dengan sendirinya. Yang perlu berubah adalah asumsi bahwa kode yang tampak berfungsi otomatis berarti kode itu aman. Snowflake adalah perusahaan besar dengan tim keamanan berpengalaman, program bug bounty aktif, dan pemindaian keamanan otomatis, namun celah tetap lolos selama lima hari. Usaha kecil yang tidak memiliki sumber daya sebesar itu punya alasan lebih kuat untuk tidak menganggap "kelihatannya berfungsi" sama dengan "sudah aman".

Foto pendukung di bawah adalah foto ilustrasi seorang pengembang yang bekerja dengan kode. Foto ini tidak menggambarkan tim Snowflake, Wiz, GitHub, atau insiden yang dibahas dalam artikel.

📌 Hal yang perlu dilakukan pada hari kerja berikutnya

Berita tentang aturan pembayaran atau perubahan algoritma pencarian sering memberi langkah yang langsung terlihat bagi pemilik usaha kecil. Cerita ini berbeda. Ia adalah sinyal tentang seberapa cepat penemuan otomatis, baik ofensif maupun defensif, bergerak di bawah semua software yang dipakai bisnis, termasuk software dari vendor luar dan integrasi yang pernah dipasang tanpa banyak pemeriksaan. Respons praktisnya bukan takut memakai AI. Jalankan empat pertanyaan tadi minggu ini, lalu ajukan lagi ketika plugin, form, atau chatbot baru ditambahkan ke website. Butuh sepuluh menit sekarang untuk menghindari sesuatu yang lebih mahal untuk diperbaiki nanti, terutama jika automasi yang tidak pernah diperiksa itu ternyata sudah menyimpan data pelanggan atau kredensial pembayaran selama ini.

Sources: Wiz Research (wiz.io/blog), TheNextWeb, Unite.AI, The Hacker News, dan pernyataan publik Snowflake melalui laporan pengungkapan Wiz. Diterbitkan 20 Agustus 2026 oleh redaksi 1garis Studio.