Zaid Al Hamani, Boost Security’nin CEO’su ve Kurucusu – Röportaj Serisi

Zaid Al Hamani, Boost Security’nin CEO’su ve Kurucusu, siber güvenlik ve DevSecOps alanında iki thập yılı aşkın deneyime sahip bir liderdir. Boost Security’yi 2020 yılında kurduğundan beri, şirketlerin yazılım geliştirme süreçlerini modernize etmeye odaklandı. Önceki rolleri arasında Trend Micro’da Uygulama Güvenliği Başkan Yardımcısı ve IMMUNIO’nun Kurucu Ortağı ve CEO’su olarak görev yaptı. Daha önce, Canonical’de ürün, mühendislik ve küresel destek girişimlerini yönetti ve SITA’da büyük ölçekli, kritik misyonlu IT operasyonlarını yönetti. Kariyeri, ekipler oluşturma, sistemleri optimize etme ve modern güvenlik uygulamalarını ilerletme konusunda güçlü bir geçmişe sahiptir.

Boost Security, modern yazılım tedarik zincirini güvence altına almak için geliştirici odaklı bir DevSecOps platformu sunan bir siber güvenlik şirketidir. Teknolojisi, CI/CD işlem hatlarına doğrudan entegre olur ve açıklıkları otomatik olarak tespit eder, önceliklendirir ve düzeltir, böylece manuel yükü azaltırken geliştirme hızını korur. Uygulama ve tedarik zinciri güvenliğini tek bir sistemde birleştiren platform, kod, bağımlılıklar ve altyapı boyunca tam görünürlük sağlar ve şirketlerin karmaşık, bulut yerel ortamlarda dayanıklılıklarını güçlendirmelerine yardımcı olur.

Önceki olarak Trend Micro’da uygulama güvenliğinden sorumluydunuz ve IMMUNIO’yu kurucu ortak olarak görev yaptınız. Boost Security’yi kurmaya ne sizi yöneltti ve hangi pazar boşluğunu erken dönemde benzersiz bir şekilde tanımlamak için uygun konumdaydınız?

IMMUN.IO, kurulan ilk RASP şirketlerinden biriydi ve o zamana kadar edindiğimiz deneyim, WAF’lerin çalışma zamanı güvenlik teknolojisi olarak bakımı imkansız ve etkili olmadığıydı. WAF’lerin yerini alabilecek, daha doğru ve bakımı daha kolay bir çözüm hayal ettik – uygulamayı enstrümantalize ederek.

Bu, 2012 yılında oldu, DevOps masih erken bir aşamadaydı, çoğu takım Agile değildi ve Kubernetes henüz yoktu.

Trend Micro, 2017 yılında IMMUN.IO’yu satın aldı. O zaman, daha fazla DevOps uygulaması vardı: CI/CD işlem hatları, Agile geliştirme uygulamaları, daha hızlı iterasyonlar ve yayın döngüleri, bulut, vb. Yazılım geliştirme ekipleri, yazılım oluşturmakta daha iyiydi ve daha hızlı teslim ediyordu. Güvenlik ise hala kırıktı:

• Taramalar çok yavaş veya sonuçlar çok geç geliyor
• Sonuçlar, geliştiriciler için harekete geçmek için çok karmaşıktır
• Kabul edilemez bir yanlış pozitif oran vardı
• Yeni türdeki birçok artifact tarama yapılmıyordu: altyapı kodu, konteynırlar, API’ler gibi

Yazılımı hızlı üretmek daha kolaydı. Güvenli yazılım üretmek hala zordu.

Bu, bizim çözmeye çalıştığımız orijinal soruydu. Gerçek dünyada DevSecOps’i çalıştırın; bir yazılım geliştirme ekibinin, SDLC’ye güvenlik eklemesini kolayca yapabileceğini ve yeni hız standartlarına uygun bir şekilde yapabileceğini sağlayabilir misiniz? Kapsamı geniş tutabilir misiniz – bir platformun her şeye yetebileceği bir platform olabilir mi? Geliştiricilerin, teknolojiyi sadece benimsemekle kalmayıp, faydalarını da görebileceği bir şekilde yapabilir misiniz? Büyütmek için güvenlik profesyonellerinin ordusuna ihtiyacınız olmadan ölçeklenebilir bir şekilde yapabilir misiniz…

Şirketlere, DevOps döneminde SDLC’ye güvenlik enjekte etmelerine yardımcı olduk. Bu, 1’den 10’a gitmekti. Şimdi ajantik kodlama döneminde olduğumuz için – ajantlar devasa miktarda kod yazıyor – ancak temelde aynı sorun var – hız ve kod hacmi 10’dan 100’e çıktı ve aynı ivmeyi sürdürmeyi amaçlıyoruz.

Yazılım geliştirme yaşam döngüsünün (SDLC) temel olarak yukarı akışa kaydığını savunuyorsunuz. Geleneksel DevSecOps yaklaşımlarının artık yeterli olmadığına dair realizado olduğunuz an neydi?

Saldırganların nasıl girdiğini izlemekti. Aynı kalıbı defalarca gördük: Kimse tarafından gözden geçirilmeyen bir GitHub Eylemleri iş akışı, bir üretim bulut erişim tokeninin bir çalıştırıcı yapılandırmasındaki bir token, bir saldırgan yükünü dağıtmak için gasp edilen bir CI işi. Bunlar “pipeline’den faydalanma” saldırıları olarak biliniyordu, çünkü saldırgan, sizin kendi otomasyonunuzu size karşı kullanıyordu, zaten güvenlik ekibiniz tarafından onaylanmış kimlik bilgileriyle.

Oluşturduğumuz DevSecOps yığını buna cevap veremezdi. SAST, uygulama kaynak kodunu tarar. SCA, uygulama bağımlılıklarını tarar. Her ikisi de çalıştırdıkları işlem hatlarının güvenilir olduğunu varsayar. Oysa ki işlem hattı kendisi, shell komutları, ağ erişimi ve hassas kimlik bilgileriyle bir YAML dosyasıdır ve neredeyse kimse bunu gözden geçirmez.

Bu, sizin temiz kodu göndermenize rağmen, saldırganlara bulutunuzu teslim etmenize yol açabilir.

AI ajantlarının sürekli olarak kod ürettiği bir dünyada, şirketlerin SDLC’yi nasıl yeniden düşünmeleri gerekir?

Tüm bunları, kontrol noktaları dizisi olarak düşünmeyi bırakmalıyız. AI ajantları, “biri bunu yazdı” ve “bu üretimdedir” arasındaki zamanı haftalardan dakikalara düşürdü. Eski model, kod gözden geçirme, SAST, SCA ve dağıtım arasında insan tempo varsayıyordu, ancak artık ötesindeyiz.

Güvenlik, ajantın çalıştığı yerde yaşamalıdır: geliştiricinin makinesinde,.prompt bağlamında, ajantın MCP sunucularına ve dış modellere bağlantılarında. Kod, işlem hattına ulaştığında, şekillendirmek için already şansını kaçırmışsınızdır. Ajant zaten bağımlılığı çekti. Model zaten kimliği gördü. Kontrolleri yukarı akışa, işlerin gerçekten gerçekleştiği yere taşıyın.

Çok sayıda kuruluş, AI kodlama araçlarını basit bir üretkenlik katmanı olarak masih tedavi ediyor. Onları neden tamamen yeni bir saldırı yüzeyi olarak görüyorlar, mevcut iş akışlarının uzantısı olarak değil?

AI kodlama aracını bir üretkenlik katmanı olarak tedavi etmek, kök erişimli bir junior geliştiriciyi üretkenlik katmanı olarak tedavi etmek gibidir. Etiket teknik olarak doğrudur, ancak neyin yanlış gidebileceği konusunda düşünebileceğiniz bir çerçeve vermez.

Bir kodlama ajansı, dosya sisteminizi okur, ortam değişkenlerini bağlam için kazır, kamu registroslarından bağımlılıkları çeker, dış model sağlayıcılarına ve MCP sunucularına giden bağlantılar açar ve shell komutları çalıştırır. Bu eylemler daha önce bir insan müdahalesi gerektiriyordu. Şimdi bunlar milisaniyeler içinde gerçekleşiyor, ajantı başlattığı geliştiricinin aynı ayrıcalıklarıyla.

Bu, bir zamanlar ayrı olan güven sınırını birleştirir: geliştiricinin yetkisi, bir dış aracın alabileceği ve güvenilmeyen kodun çalıştırabileceği.

Boost, geliştirici dizüstü bilgisayarını yeni kontrol düzlemi olarak tanımlar. Güvenlik ekiplerinin şu anda göz ardı ettiği endpoint’te hangi riskler vardır?

En büyük risk, envanterdir. Çoğu güvenlik ekibi, hangi AI ajantlarının hangi dizüstü bilgisayarlarda çalıştığını, hangi MCP sunucularına bağlı olduğunu veya hangi IDE uzantılarının şu anda depo içeriğini kazıyıp kazımadığını söyleyemez. EDR, ajant katmanına görünmezlik sağlar; SIEM de yerel olarak ne yaptıklarını göremez.

Altında, kimlik bilgileri karmaşıklığı yatmaktadır. Açık kaynaklı bir araç olan Bagel’i kısmen bunu somutlaştırmak için oluşturduk. Tipik bir geliştirici dizüstü bilgisayarı, üretim reposuna yazma erişimi olan GitHub token’lerini, altyapıları çalıştırabilen bulut kimlik bilgilerini, milyonlarca kullanıcıya yayınlayabilen npm veya PyPI token’lerini ve saldırganların yeniden satılabilen AI hizmet anahtarlarını tutar. Bunların hiçbiri, bir CI çalıştırıcısı gibi sertleştirilmez. Aynı makine, bu kimlik bilgilerini tutarken aynı zamanda web’de gezinir ve rasgele VS Code uzantıları kurar.

İkisini birleştirirseniz, gerçek saldırı yüzeyine sahip olursunuz. Geliştirici ayrıcalıklarıyla çalışan, güvenilmeyen bir uzantı, yüksek öncelikli bir hedeftir ve çoğu takım bunu henüz incelemeye başlamamıştır.

“Bağlam tuzağı”ndan bahsettiniz, burada AI ajantları yerel dosyaları, ortam değişkenlerini ve yapılandırmaları erişebilir. Hassas verilerin sızıntısı riski ne kadar yaygındır ve neden bu kadar zor tespit edilir?

Yaygın enough ki, her yönetilmeyen geliştirici ortamının varsayılan durum olarak kabul ediyoruz. İncelediğimiz her kodlama ajansı, yerel bağlamı agresif bir şekilde çeker. Nokta dosyalarını, ortam değişkenlerini, yakın dosyaları ve bazen tüm dizin ağaçlarını okur ve bu bağlamı uzaktaki bir modele gönderir. Araçlar böyle çalışmaya tasarlanmıştır; agresif bağlam çekişleri, onları faydalı kılar.

Tespit problemi, sızıntı trafiğinin normal ürün kullanımı ile aynı görünmesinden kaynaklanır. Bu, api.openai.com veya api.anthropic.com’a TLS’dir. İşe onaylı bir iş uygulamasından gelir. Standart DLP, şirketin lisansını satın aldığı AI aracını kullanan bir geliştirici görür. Ancak bir dizi içinde bir AWS gizli anahtarının, ajantın bir kardeş dizindeki yarım unutulmuş bir .env dosyasından aldığını görmez.

Sadece dizüstü bilgisayarında, ajentin bırakmadan önce.prompt’ları inceleyerek bunu yakalarsınız, ki neredeyse hiçbir güvenlik yığını şu anda orada konumlandırılmış değil.

Makine hızında tedarik zinciri saldırılarından bahsettiniz. Bir AI ajantının, geleneksel güvenlik araçlarının tespit edebileceğinden daha hızlı bir şekilde bir zafiyet tanıttığı gerçekçi bir senaryoyu yürüyelim.

Gördüğümüz varyasyonlardan biri budur. Geliştirici, ajanta bir özellik eklemesini ister, bu da bir HTTP yeniden deneme kütüphanesi gerektirir. Ajant, bir paket adı önerir. Paket ismi makuldür, ancak npm’de gerçekten mevcut değildir. Bir saat içinde, bir saldırgan onu kaydeder, çalışır yeniden deneme mantığıyla birlikte küçük bir post-kurulum betiği ekler ve ~/.aws/credentials dosyasını okur ve bir web kancasına gönderir. Ajant, npm install çalıştırır, çünkü ajantlar itibarını kontrol etmez. Kimlik bilgisi, geliştiricinin kodu çalıştırmadan önce kaybolmuştur.

Saldırı itself teknik olarak sofistike değildir, ancak geleneksel tedarik zinciri güvenliği, bilinen paketlerdeki bilinen açıklara dayanır: CVE’ler, SBOM’lar, lisans taraması. Bu çerçeve, daha önce çalıştırılmayan bir paket, bir AI hayal gücüne özel olarak oluşturulan ve bir güvenlik tehdidi beslemesi güncellenmeden önce yutulan bir paket hakkında hiçbir şey söyleyemez.

Yayınlanma ve tehlike arasında artık dakikalar ölçülüyor. Her şeyin ardından kontrol eden her şey çok geç kontrol ediyor.

Hayal edilen bağımlılıklar, AI destekli geliştirmede en büyük risklerden biri haline geliyor. Kuruluşlar, kendilerini korumak için hangi pratik adımları atabilir?

Zaten öyle. Saldırganlar, popüler AI araçlarını hayal ettikleri anda izliyorlar ve önerilen paket adlarını dakika içinde kaydediyorlar. Araştırmacılar, birkaç yıl önce, bunun başladığında, buna “slopsquatting” adını verdiler ve isim tuttu. Bir paket adı yeterince sık hayal edildiğinde, üzerine oturma, neredeyse sıfır çaba ile bir tedarik zinciri saldırısıdır.

Pratik savunmalar, çoğu ekibin şu anda sahip olduğundan farklı görünüyor. Alıma başlayarak başlayın. Geliştiricinin makinesinde, diskte herhangi bir şeyin oluşmadan önce, npm install veya pip install çalıştırılırken, typosquatted ve yeni kayıtlı paketleri engeller. CI’de sonradan tespit, post-kurulum betiği zaten bir kimliği sızdırdığında yardımcı olmaz. Ardından ajanta, içinde çalışabileceği sınırlar verin. Onayladığınız bağımlılık listesini doğrudan ajantın bağlamına enjekte edin, böylece model, öneri üretmeden önce neyin izin verildiğini görür. Geliştiricilere “güvenli prompt’lar yazın” demesi bir strateji değildir. Stratejik oluyorsanız, güvenlik sınırları belirler, ajant bunu miras alır. Ve bir AI Malzeme Listesi izlemeye başlayın. Çoğu takım, hangi ajantların, modellerin ve paketlerin hangi depolara dokunduğunu söyleyemez. Envanterleyemediğiniz şeyi savunamazsınız.

Güvenlik artık CI/CD’de başlayamaz dediniz. Güvenlik, geliştirme sürecinin daha erken bir aşamasında başlaması gerektiğinde modern bir güvenlik işlem hattı nasıl görünür?

Güvenlik, CI/CD’de başlarsa, tüm pre-komut aşamasını kontrol etmediğiniz bir ortama teslim etmiş olursunuz. Ajant zaten bağlamı yutmuş, kimlik bilgilerinizi already olabilir. Bir cesedi taramakla meşgulsünüz.

Modern bir işlem hattı, dizüstü bilgisayarda başlar. Bu, orada çalışan ajantları ve uzantıları envanterlemek, hangi MCP sunucularına ve modellere konuşlandıklarını doğrulamak, makineden çıkan şeyi temizlemek ve kötü niyetli paketlerin kurulumunu engellemek anlamına gelir. Oradan, politika, işi IDE’ye takip eder. Güvenlik standartlarını doğrudan ajantın bağlam penceresine enjekte ederiz, böylece üretilen kod, ilk tokeninden itibaren sınırlar içinde kalır. İşlem hattı masih çalışır, ancak artık kontrolü, önceden uygulanan kontrollerin doğrulanması olarak yapar.

İşlem hattı kendisi ortadan kaybolmaz. Rolü, doğrulamaya dönüşür: önceden uygulanan kontrollerin tutulduğunu onaylar.

Şirketler, AI kodlama ajantlarını benimsemeye devam ettikçe, güvenliklerini gelecek birkaç yıl boyunca koruyabilmek için bugün hangi kritik değişiklikleri yapmalıdır?

En büyük hata, sadece commitleyen şeyi güvence altına almaktır. İlginç risk, commit olmadan önceki sekiz saattedir. Dizüstü bilgisayarda, prompt’ta veya paket kurulumunda gözden kaçan drama olabilir. Araçlarınız, PR’de başlıyorsa, yanlış iş akışının yarısını koruyor olursunuz.

İlgili olarak: kodlama ajantlarını sadece üretkenlik yazılımları olarak tedavi etmeyi bırakın. Bunlar, shell erişimi, depo yazma ayrıcalıkları ve dış ağ bağlantılarına sahip, insan olmayan kullanıcılar. Onları, diğer ayrıcalıklı kimlik gibi, bir envanter, onaylanmış yetenekler ve denetim günlükleriyle yönetin.

Son değişiklik daha zordur, kültürel olarak. Mevcut “AI güvenliği” araçlarının çoğu, bulguları yüzeye çıkarır ve insanlara yönlendirir. İnsanlar, ajantların ürettiği hızda triyaj yapamaz. Benimsediğiniz her şey, akış içinde otomatik olarak sorunları çözebilmeli ve izlenebilir bir neden sunmalıdır, yoksa başka bir okunmayan panoya dönüşür.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Boost Security‘yi ziyaret edebilir.