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

Zaid Al Hamani, CEO dan Pendiri Boost Security, adalah pemimpin keamanan siber dan DevSecOps dengan lebih dari dua dekade pengalaman membangun dan menskala operasi teknologi global. Sejak mendirikan Boost Security pada 2020, ia telah fokus pada modernisasi 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 produk, teknik, dan inisiatif dukungan global, dan di SITA, di mana ia mengelola operasi TI skala besar dan kritis. Karirnya mencerminkan catatan yang kuat dalam membangun tim, mengoptimalkan sistem, dan memajukan praktik keamanan modern.

Boost Security adalah 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 mendirikan IMMUNIO. Apa yang memimpin Anda untuk mendirikan Boost Security, dan apa celah di pasar yang Anda temukan lebih awal?

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

Itu terjadi pada 2012, DevOps masih awal, sebagian besar tim belum menggunakan Agile, dan Kubernetes belum menjadi hal yang umum.

Trend Micro mengakuisisi IMMUN.IO pada 2017. Pada saat itu, sudah 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 untuk pengembang untuk bertindak
• 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 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 keamanan profesional untuk mengikuti jumlah kode yang ditulis…

Kami membantu perusahaan menyuntikkan keamanan ke SDLC selama era DevOps. Itu berarti pergi dari 1 ke 10. Sekarang kita berada di era pengkodean agen – di mana agen menulis sejumlah besar kode – tetapi pada dasarnya itu adalah masalah yang sama – kecepatan dan volume kode hanya berpindah dari 10 ke 100; dan kita bertujuan untuk terus melanjutkan trajektori yang sama.

Anda telah berargumen 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 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 tertanam dalam konfigurasi runner, pekerjaan CI yang sah yang diambil alih untuk mengirimkan payload penyerang. Ini menjadi dikenal sebagai serangan “living off the pipeline” karena musuh menggunakan otomatisasi Anda melawan Anda, dengan kredensial yang tim keamanan Anda sudah setujui.

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 kepada penyerang.

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

Kami semua harus berhenti memikirkan SDLC sebagai urutan 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 kita sudah melampaui itu sekarang.

Keamanan harus hidup di mana agen beroperasi: di mesin pengembang, di dalam konteks prompt, di 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 memikirkan apa yang bisa salah.

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

Kondensasi itu melebur batas kepercayaan yang sebelumnya terpisah: otoritas pengembang, apa yang dapat diambil alih oleh alat eksternal, dan apa yang dapat dieksekusi oleh kode 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 paling besar adalah inventori. Sebagian besar tim keamanan tidak bisa memberitahu Anda agen AI mana yang berjalan di laptop mana, server MCP mana yang terhubung, atau ekstensi IDE mana yang mengumpulkan konten repositori saat ini. EDR tidak memiliki visibilitas ke lapisan agen; SIEM tidak bisa melihat apa yang dilakukan agen secara lokal juga. Ini adalah masalah IT bayangan dengan privilegia eksekusi kode.

Di bawahnya terletak kekacauan kredensial. Kami membangun alat sumber terbuka yang disebut Bagel sebagian untuk membuat ini konkret. Laptop pengembang biasa menyimpan token GitHub dengan akses tulis ke repositori produksi, kredensial cloud yang dapat memutar 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 tidak tepercaya yang berjalan dengan privilegia pengembang di lingkungan penuh 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 setiap lingkungan pengembang yang tidak dikelola. Setiap agen pengkodean yang kami inspeksi menarik konteks secara agresif. Mereka membaca dotfile, variabel lingkungan, file terbaru, kadang-kadang 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 agen ambil dari file .env yang terlupakan di direktori saudara.

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

Anda menyebutkan serangan rantai pasokan kecepatan mesin. Bisa Anda menjelaskan skenario realistis di mana agen AI memperkenalkan kerentanan lebih cepat dari 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 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 terlalu canggih, tetapi keamanan rantai pasokan tradisional dibangun di sekitar kerentanan yang diketahui dalam paket yang diketahui: CVE, SBOM, pemindaian lisensi. Kerangka 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 itu 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 beberapa menit. Peneliti beberapa tahun yang lalu, ketika pertama kali terjadi, menyebutnya slopsquatting dan nama itu tetap. Sekali nama ketergantungan dihalusinasi dengan cukup sering, duduk di atasnya adalah serangan rantai pasokan pasif dengan usaha hampir nol.

Pertahanan praktis terlihat berbeda dari apa yang sebagian besar tim miliki saat ini. Mulai dari ingestion. Blokir paket yang typosquatted dan baru didaftarkan pada saat npm install atau pip install dijalankan, di mesin pengembang, sebelum apa pun mengenai disk. Deteksi post-mortem di CI tidak membantu ketika skrip pasca-instal sudah mengekstraksi kredensial. Kemudian berikan agen pagar untuk beroperasi di dalamnya. Injeksi daftar ketergantungan yang disetujui langsung ke konteks agen, sehingga model melihat apa yang diizinkan sebelum menghasilkan saran. Meminta pengembang untuk menulis “prompt aman” bukanlah strategi. Jika Anda menjadi strategis, itu berarti keamanan menetapkan batas, agen mewarisi. Dan mulai melacak BOM 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 mengatakan keamanan tidak lagi bisa 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-komit ke lingkungan yang tidak Anda kendalikan. Agen sudah mengonsumsi konteks, kredensial Anda mungkin sudah ada di log orang lain. Anda 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 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 bertahan.

Seiring organisasi 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 menarik sekarang hidup di delapan jam sebelum komit terjadi. Drama yang tidak terlihat bisa 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 melakukan triase dengan kecepatan agen menghasilkan. Apa pun yang Anda adopsi harus memperbaiki masalah secara otomatis di dalam alur kerja, dengan alasan yang dapat dilacak, atau itu menjadi dasbor lain yang tidak pernah dibaca.

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