Zaid Al Hamani, CEO dan Pendiri Boost Security – Seri Wawancara

Zaid Al Hamani, CEO dan Pendiri Boost Security, adalah seorang pemimpin keamanan siber dan DevSecOps dengan lebih dari dua dekade pengalaman membangun dan menskala operasi teknologi global. Sejak mendirikan Boost Security pada tahun 2020, ia telah fokus pada memodernisasi cara organisasi mengamankan pengembangan perangkat lunak, dengan mengandalkan peran sebelumnya termasuk VP Keamanan Aplikasi di Trend Micro dan Co-Pendiri/CEO IMMUNIO. Sebelumnya, ia menjabat posisi kepemimpinan senior di Canonical, memimpin inisiatif produk, teknik, dan dukungan global, dan di SITA, di mana ia mengelola operasi IT skala besar yang kritis. Karirnya mencerminkan catatan yang kuat dalam membangun tim, mengoptimalkan sistem, dan memajukan praktik keamanan modern.

Boost Security adalah sebuah perusahaan keamanan siber yang fokus pada mengamankan rantai pasokan perangkat lunak modern melalui platform DevSecOps yang berorientasi pada pengembang. Teknologinya terintegrasi langsung ke dalam pipa CI/CD untuk mendeteksi, memprioritaskan, dan memperbaiki kerentanan secara otomatis, mengurangi beban manual sambil mempertahankan kecepatan pengembangan. Dengan menggabungkan keamanan aplikasi dan rantai pasokan menjadi satu sistem, platform ini menyediakan visibilitas penuh di seluruh kode, ketergantungan, dan infrastruktur, membantu organisasi memperkuat ketahanan di lingkungan cloud-native yang kompleks.

Anda sebelumnya memimpin keamanan aplikasi di Trend Micro dan co-mendirikan IMMUNIO. Apa yang memimpin Anda untuk mendirikan Boost Security, dan apa celah di pasar yang Anda identifikasi secara unik?

IMMUN.IO adalah salah satu perusahaan RASP pertama yang didirikan – dan pengalaman kami sampai saat itu adalah bahwa WAF sebagai teknologi keamanan runtime tidak dapat dipertahankan, dan tidak efektif. Kami membayangkan cara di mana WAF akan digantikan dengan solusi yang lebih akurat, lebih mudah dipertahankan – dengan menginstrumentasi aplikasi.

Itu pada tahun 2012, DevOps masih awal, sebagian besar tim tidak menggunakan Agile, dan Kubernetes belum ada.

Trend Micro mengakuisisi IMMUN.IO pada tahun 2017. Pada saat itu, ada lebih banyak praktik DevOps: pipa CI/CD, praktik pengembangan Agile, iterasi dan siklus rilis yang lebih cepat, cloud, dll. Tim pengembangan perangkat lunak lebih baik dalam membangun perangkat lunak, dan mengirimkannya lebih cepat. Namun, keamanan masih rusak:

• Pemindaian terlalu lambat, atau hasilnya tiba terlambat
• Hasilnya terlalu kompleks bagi pengembang untuk diambil tindakan
• Tingkat positif palsu yang tidak dapat diterima secara umum
• Banyak jenis artefak baru tidak dipindai: infrastruktur sebagai kode, kontainer, API, misalnya

Menghasilkan perangkat lunak dengan cepat lebih mudah. Menghasilkan perangkat lunak yang aman dengan cepat masih sulit.

Itulah masalah asli yang kami coba selesaikan. Membuat DevSecOps bekerja di dunia nyata; apakah Anda bisa mendapatkan tim pengembangan perangkat lunak untuk dengan mudah menambahkan keamanan ke dalam SDLC, dengan kecepatan yang sesuai dengan standar kecepatan baru? Apakah Anda bisa membuat cakupan luas – di mana satu platform adalah semua yang Anda butuhkan? Apakah Anda bisa membuatnya sehingga pengembang, bukan hanya mengadopsi teknologi, tetapi juga menggunakannya dan melihat manfaatnya? Apakah Anda bisa membuatnya skalabel sehingga Anda tidak perlu pasukan profesional keamanan untuk mengikuti jumlah kode yang ditulis…

Kami membantu perusahaan menyuntikkan keamanan ke dalam SDLC selama era DevOps. Itu berarti pergi dari 1 ke 10. Kami sekarang berada di era pengkodean agen – di mana agen menulis sejumlah besar kode – tetapi secara fundamental masalahnya sama – kecepatan dan volume kode hanya berpindah dari 10 ke 100; dan kami bertujuan untuk terus melakukan trajektori yang sama.

Anda telah berargumentasi bahwa siklus hidup pengembangan perangkat lunak (SDLC) secara fundamental telah bergeser ke hulu. Apa saatnya Anda menyadari bahwa pendekatan DevSecOps tradisional tidak lagi cukup?

Itu terjadi ketika kami melihat bagaimana penyerang sebenarnya mendapatkan akses. Kami terus melihat pola yang sama: alur kerja GitHub Actions yang terbuka yang tidak pernah ditinjau sejak repo difork, token dengan akses produksi cloud yang disematkan dalam konfigurasi runner, pekerjaan CI yang sah yang diambil alih untuk mengirimkan payload penyerang. Ini kemudian dikenal sebagai serangan “hidup dari pipa” karena penyerang menggunakan otomatisasi Anda sendiri melawan Anda, dengan kredensial yang sudah disetujui oleh tim keamanan Anda.

Tumpukan DevSecOps yang kami bangun selama lebih dari satu dekade tidak memiliki jawaban untuk itu. SAST memindai sumber aplikasi. SCA memindai ketergantungan aplikasi. Keduanya menganggap pipa yang menjalankannya dapat dipercaya. Sementara itu, pipa itu sendiri adalah file YAML dengan perintah shell, akses jaringan, dan kredensial sensitif, dan hampir tidak ada yang meninjaunya.

Ketika itu menjadi jalur yang paling rentan, Anda bisa mengirimkan kode yang bersih dan masih menyerahkan awan Anda kepada penyerang.

Bagaimana seharusnya perusahaan memikirkan kembali SDLC di dunia di mana agen AI menghasilkan kode terus-menerus daripada pengembang menulisnya langkah demi langkah?

Kami semua harus berhenti berpikir tentang SDLC sebagai urutan titik pemeriksaan. Agen AI telah mengurangi waktu antara “seseorang menulis ini” dan “ini ada di produksi” dari minggu menjadi menit. Model lama menganggap irama manusia antara tinjauan kode, SAST, SCA, dan deploy, tetapi kami sudah melampaui itu sekarang.

Keamanan harus hidup di mana agen beroperasi: di mesin pengembang, di dalam konteks prompt, di dalam koneksi agen ke server MCP dan model eksternal. Ketika kode mencapai pipa, Anda sudah kehilangan kesempatan untuk membentuknya. Agen sudah menarik ketergantungan. Model sudah melihat kredensial. Pindahkan kontrol ke hulu, ke tempat pekerjaan sebenarnya terjadi.

Banyak organisasi masih memperlakukan alat pengkodean AI sebagai lapisan produktivitas sederhana. Mengapa Anda percaya mereka mewakili permukaan serangan yang sama sekali baru daripada hanya perpanjangan alur kerja yang ada?

Memperlakukan alat pengkodean AI sebagai lapisan produktivitas adalah seperti memperlakukan pengembang junior dengan akses root sebagai lapisan produktivitas. Labelnya secara teknis akurat, tetapi tidak memberikan kerangka yang berguna untuk berpikir tentang apa yang bisa salah.

Agen pengkodean membaca filesystem Anda, mengambil variabel lingkungan untuk konteks, mengambil ketergantungan dari registri publik, membuka koneksi keluar ke penyedia model jarak jauh dan server MCP, dan menjalankan perintah shell. Setiap tindakan tersebut sebelumnya memerlukan campur tangan manusia. Sekarang mereka terjadi dalam hitungan milidetik, dengan privilegia yang sama dengan pengembang yang meluncurkan agen.

Itu menggabungkan batas kepercayaan yang sebelumnya terpisah: otoritas pengembang, apa yang dapat diambil alih oleh alat eksternal, dan apa yang dapat dieksekusi oleh kode yang tidak tepercaya. Itu menciptakan peluang baru bagi penyerang dan titik buta yang pembela tidak bisa lihat, apalagi pertahankan.

Boost membingkai laptop pengembang sebagai bidang kontrol baru. Apa risiko yang ada di titik akhir yang tim keamanan saat ini abaikan?

Yang terbesar adalah inventori. Sebagian besar tim keamanan tidak bisa memberitahu Anda agen AI mana yang berjalan di laptop mana, server MCP mana yang terhubung ke agen tersebut, atau ekstensi IDE mana yang mengambil konten repositori saat ini. EDR tidak memiliki visibilitas ke lapisan agen; SIEM juga tidak bisa melihat apa yang dilakukan agen secara lokal.

Di bawah itu terletak kekacauan kredensial. Kami membangun alat sumber terbuka yang disebut Bagel sebagian untuk membuatnya konkret. Laptop pengembang biasa menyimpan token GitHub dengan akses tulis ke repositori produksi, kredensial cloud yang dapat memulai infrastruktur, token npm atau PyPI yang dapat menerbitkan ke jutaan pengguna, dan kunci layanan AI yang penyerang jual kembali. Tidak ada yang dikerasi seperti pelari CI. Mesin yang sama yang menyimpan kredensial itu juga menjelajahi web dan menginstal ekstensi VS Code acak.

Pasang keduanya dan Anda memiliki permukaan serangan yang sebenarnya. Ekstensi yang tidak tepercaya yang berjalan dengan privilegia pengembang di lingkungan penuh dengan kunci cloud adalah target dengan leverage tertinggi di perusahaan modern. Sebagian besar tim belum memulai untuk melihatnya.

Anda telah menyoroti “perangkap konteks”, di mana agen AI dapat mengakses file lokal, variabel lingkungan, dan konfigurasi. Seberapa luas risiko kebocoran data sensitif melalui prompt, dan mengapa begitu sulit untuk dideteksi?

Cukup luas sehingga kami memperlakukannya sebagai keadaan default dari lingkungan pengembang yang tidak dikelola. Setiap agen pengkodean yang kami periksa menarik konteks secara agresif. Mereka membaca dotfile, variabel lingkungan, file terbaru, terkadang seluruh pohon direktori, dan mengirim konteks itu ke model jarak jauh. Alat-alat ini dirancang untuk bekerja dengan cara ini; penarikan konteks agresif adalah apa yang membuatnya berguna.

Masalah deteksi dimulai karena lalu lintas dari kebocoran terlihat identik dengan penggunaan produk normal. Ini adalah TLS ke api.openai.com atau api.anthropic.com. Ini berasal dari aplikasi bisnis yang disetujui. DLP standar melihat pengembang menggunakan alat AI yang perusahaan baru saja membeli lisensinya. Ini tidak melihat bahwa salah satu string dalam prompt itu adalah kunci rahasia AWS yang diambil agen dari file .env yang terlupakan di direktori saudara.

Anda hanya menangkapnya dengan memeriksa prompt sebelum meninggalkan laptop, yang tepat di mana hampir tidak ada tumpukan keamanan saat ini berada.

Anda menyebutkan serangan rantai pasokan kecepatan mesin. Bisakah Anda menjelaskan skenario yang realistis di mana agen AI memperkenalkan kerentanan lebih cepat daripada alat keamanan tradisional dapat mengidentifikasinya?

Berikut adalah salah satu yang kami lihat variasinya berulang kali. Pengembang meminta agen untuk menambahkan fitur yang memerlukan perpustakaan retry HTTP. Agen menyarankan nama paket. Paket itu terdengar masuk akal tetapi tidak ada di npm. Dalam waktu satu jam, penyerang mendaftarkan paket itu, mempopulasinya dengan logika retry yang berfungsi plus skrip pasca-instal yang membaca ~/.aws/credentials dan memposting kontennya ke webhook. Agen menjalankan npm install tanpa memeriksa, karena agen tidak memeriksa reputasi. Kredensial itu hilang sebelum pengembang bahkan menjalankan kode.

Serangan itu sendiri tidak secara teknis canggih, tetapi keamanan rantai pasokan tradisional dibangun di sekitar kerentanan yang diketahui dalam paket yang diketahui: CVE, SBOM, pemindaian lisensi. Kerangka kerja itu tidak memiliki apa-apa untuk dikatakan tentang paket yang tidak ada saat pemindaian terakhir dijalankan, dibuat khusus untuk mencocokkan halusinasi AI, dan dikonsumsi sebelum pembaruan feed ancaman.

Jendela dari publikasi ke kompromi sekarang diukur dalam menit. Apa pun yang memeriksa setelah kejadian adalah memeriksa terlambat.

Apakah ketergantungan yang dihalusinasi menjadi salah satu risiko terbesar dalam pengembangan yang didorong AI, dan apa langkah-langkah praktis yang dapat diambil organisasi untuk melindungi diri dari mereka?

Mereka sudah menjadi salah satu yang terbesar. Penyerang secara aktif memantau alat AI populer untuk halusinasi dan mendaftarkan nama paket yang disarankan dalam hitungan menit. Peneliti beberapa tahun yang lalu, ketika pertama kali terjadi, menyebutnya slopsquatting dan nama itu bertahan. Setelah nama ketergantungan dihalusinasi dengan cukup sering, duduk di atasnya adalah serangan rantai pasokan pasif dengan upaya hampir nol.

Pertahanan praktis terlihat berbeda dari apa yang sebagian besar tim miliki saat ini. Mulai dari penerimaan. Blokir paket yang typosquatted dan baru didaftarkan pada saat npm install atau pip install dijalankan, di mesin pengembang, sebelum apa pun mengenai disk. Deteksi pasca-mati di CI tidak membantu ketika skrip pasca-instal sudah mengekstrak kredensial. Kemudian berikan agen dengan pagar untuk beroperasi di dalamnya. Suntikkan daftar ketergantungan yang disetujui langsung ke konteks agen, sehingga model melihat apa yang diizinkan sebelum menghasilkan saran. Meminta pengembang untuk menulis “prompt yang aman” bukanlah strategi. Jika Anda menjadi strategis, itu berarti keamanan menetapkan batas, agen mewarisi. Dan mulailah melacak Bill of Materials AI. Sebagian besar tim tidak bisa memberitahu Anda agen, model, dan paket mana yang menyentuh repositori mana. Anda tidak bisa membela apa yang tidak bisa Anda inventarisasi.

Anda telah mengatakan bahwa keamanan tidak lagi dapat dimulai di CI/CD. Apa yang terlihat seperti pipa keamanan modern ketika perlindungan perlu dimulai lebih awal dalam proses pengembangan?

Jika keamanan dimulai di CI/CD, Anda telah menyerahkan seluruh fase pra-kommit kepada lingkungan yang tidak Anda kendalikan. Agen sudah mengonsumsi konteks, kredensial Anda mungkin sudah ada di log orang lain. Anda sedang memindai bangkai.

Pipa modern dimulai di laptop. Itu berarti menginventarisasi agen dan ekstensi yang berjalan di sana, memvalidasi server MCP dan model mana yang diizinkan untuk berbicara, menyucikan apa yang meninggalkan mesin, dan memblokir paket berbahaya sebelum mereka diinstal. Dari sana, kebijakan mengikuti pekerjaan ke dalam IDE. Kami menyuntikkan standar keamanan langsung ke konteks jendela agen sehingga kode yang dihasilkan tetap di dalam pagar dari token pertama. Pipa masih berjalan, melakukan verifikasi akhir pada kontrol yang sudah ditegakkan di hulu.

Pipa itu sendiri tidak menghilang. Perannya menjadi verifikasi: mengonfirmasi bahwa kontrol hulu dipertahankan.

Bagi organisasi yang terus mengadopsi agen pengkodean AI, apa perubahan paling kritis yang harus mereka lakukan hari ini untuk memastikan lingkungan pengembangan mereka tetap aman selama beberapa tahun mendatang?

Kesalahan terbesar adalah mengamankan hanya apa yang dikomit. Risiko yang menarik sekarang hidup di delapan jam sebelum komit terjadi. Drama yang tidak terlihat dapat terjadi di laptop, di prompt, atau di instalasi paket. Jika alat Anda dimulai dari PR, Anda melindungi setengah alur kerja yang salah.

Terhubung erat: berhenti memperlakukan agen pengkodean sebagai perangkat lunak produktivitas. Mereka adalah pengguna non-manusia dengan akses shell, privilegia penulisan repositori, dan koneksi jaringan keluar. Atur mereka dengan cara Anda mengatur identitas berprivilegia lainnya, dengan inventaris, kemampuan yang disetujui, dan log audit.

Perubahan terakhir lebih sulit secara budaya. Sebagian besar alat “keamanan AI” saat ini menampilkan temuan dan mengarahkannya ke manusia. Manusia tidak bisa menangani dengan kecepatan agen menghasilkan. Apa pun yang Anda adopsi harus memperbaiki masalah secara otomatis di dalam alur kerja, dengan penalaran yang dapat dilacak, atau itu akan menjadi dasbor lain yang tidak pernah dibaca.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Boost Security.