Red Agent Wiz Menemukan dan Mengeksploitasi Celah GitHub Actions Snowflake

Perbedaan ini sangat penting. GitHub memperluas ekspresi tersebut sebelum shell menjalankan perintah. Jika judul issue berisi tanda petik tunggal, nilai itu dapat keluar dari string yang dimaksud dan menambahkan perintah shell pilihan penyerang. Upaya membersihkan nilai menggunakan sed setelahnya tidak dapat membatalkan interpretasi shell yang sudah terjadi lebih awal.

Workflow tersebut dipicu oleh

issues: opened

Commit terkait mencantumkan “Copilot Autofix powered by AI” sebagai salah satu co-author, dan pemeriksaan berbantuan AI itu tidak menandai masalah injeksi tersebut. Namun, bukti yang tersedia belum membuktikan apakah Copilot yang menghasilkan perubahan tidak aman itu atau hanya meninjau perubahan buatan manusia. Kesimpulan yang paling hati-hati adalah Copilot terkait dengan perubahan tersebut dan gagal mendeteksi injeksi—bukan bahwa kepengarangan model telah terbukti secara pasti.

Cara Red Agent menemukan celah

Red Agent memindai organisasi GitHub publik milik Snowflake untuk mencari pola CI/CD berisiko. Agen tersebut mengidentifikasi workflow Jira yang menempatkan data issue yang tidak tepercaya ke dalam blok run: shell, lalu menyimpulkan bahwa judul issue publik yang direkayasa dapat memicu eksekusi perintah arbitrer pada runner GitHub Actions.

Pada 23 Juni—lima hari setelah perubahan rentan digabungkan—Red Agent membuka issue yang telah dirancang khusus sebagai bagian dari program pengungkapan kerentanan HackerOne Snowflake. Judul issue itu keluar dari string shell dan membuat workflow mengirim kredensial Jira ke callback out-of-band yang dikendalikan untuk pembuktian konsep resmi.

Ini merupakan pengujian keamanan yang disetujui, bukan penyusupan tanpa izin. Meski demikian, temuan keamanannya nyata: judul issue publik dapat mencapai langkah workflow yang menangani kredensial dan mengubah aktivitas sederhana seperti membuat issue menjadi eksekusi perintah.

Akses yang terekspos

Workflow yang berhasil dijalankan memiliki akses ke konfigurasi Jira internal Snowflake, termasuk URL Jira, alamat email pengguna, dan token API. Token yang ditemukan terkait dengan qa@snowflake.net; Wiz menggunakannya untuk mengautentikasi ke portal Jira internal dan menilai potensi paparan.

Pelaporan menyebutkan akses baca ke proyek Jira yang mencakup bidang engineering, kepatuhan keamanan, dan aktivitas bug bounty. Namun, bukti yang tersedia tidak menetapkan seluruh rangkaian izin token tersebut atau memberikan inventaris definitif atas setiap data yang dapat diakses. Kesimpulan yang paling kuat berdasarkan bukti adalah token itu memungkinkan akses ke konten Jira internal yang sensitif, bukan akses tanpa batas ke seluruh sistem Snowflake.

Aset yang rentan adalah otomasi CI/CD repositori. Tidak ada versi Snowflake Connector for .NET yang dirilis dan dilaporkan terdampak, karena masalahnya berada di workflow GitHub Actions, bukan di kode runtime konektor.

Respons Snowflake

Wiz melaporkan temuan tersebut pada 23 Juni. Snowflake memperbaiki workflow pada hari yang sama dan merotasi kredensial Jira yang terekspos pada hari berikutnya.

Snowflake kemudian meninjau log audit dan menyimpulkan bahwa Wiz adalah satu-satunya aktor selama jendela paparan. Wiz juga menyatakan telah menghapus data pembuktian konsep yang diaksesnya secara aman.

Tidak ada akses pihak ketiga yang tidak sah, penetapan CVE, maupun rilis konektor terdampak yang dilaporkan. Batasan ini menjelaskan dampak yang telah dikonfirmasi, tetapi tidak berarti desain workflow semula aman. Judul issue publik seharusnya tidak pernah dijadikan bagian dari perintah shell dalam workflow yang menangani kredensial internal.

Pelajaran untuk pipeline CI/CD

Pelajaran praktis dari kasus ini berlaku jauh melampaui Snowflake dan Copilot. Ekspresi GitHub seperti judul issue, judul pull request, nama branch, dan komentar harus diperlakukan sebagai input berbahaya setiap kali masuk ke perintah shell.

Desain workflow yang lebih aman mencakup:

• Meneruskan nilai yang tidak tepercaya melalui variabel lingkungan, bukan menginterpolasikannya langsung ke skrip run:.
• Menggunakan alat terstruktur seperti jq untuk membentuk JSON, alih-alih merangkai string shell secara manual.
• Menerapkan kutip dan validasi pada batas antara data dan shell.
• Menjauhkan kredensial dari langkah yang memproses konten yang dapat dikendalikan penyerang jika memungkinkan.
• Meninjau perubahan keamanan yang dihasilkan AI dengan ketelitian yang sama seperti kode buatan manusia.

Insiden ini memperlihatkan bentuk baru risiko keamanan: satu sistem AI untuk membantu pemrograman dapat melewatkan perubahan CI/CD yang berbahaya, sementara agen ofensif otonom berbasis AI lain menemukan dan memvalidasinya hanya dalam hitungan hari. Otomasi dapat mempercepat perbaikan sekaligus eksploitasi—tetapi tidak menggantikan peninjauan independen.