On yıllardır statik uygulama güvenliği testi (SAST), güvenlik ekiplerinin kod incelemelerini ölçekli hale getirmesinin en etkili yollarından biri olmuştur.
Ancak Codex Security’yi geliştirirken bilinçli bir tasarım tercihi yaptık: sürece bir statik analiz raporunu içe aktarıp otonom ajandan bunu sınıflandırmasını isteyerek başlamadık. Bunun yerine sistemi doğrudan deponun kendisinden; başka bir deyişle, mimarisi, güven sınırları ve hedeflenen davranıştan başlayacak ve bulgularını bir insanın incelemesine sunmadan önce doğrulayacak şekilde tasarladık.
Nedeni basit: en zor güvenlik açıkları genellikle veri akışı problemleri değildir. Bu tür açıklar, kod bir güvenlik kontrolünü uyguluyor gibi göründüğünde; ancak bu kontrol, sistemin dayandığı güvenlik özelliğini gerçekte garanti etmediğinde ortaya çıkar. Başka bir deyişle mesele, yalnızca verinin program içinde nasıl hareket ettiğini izlemek değil; koddaki savunmaların gerçekten işe yarayıp yaramadığını anlamaktır.
SAST genellikle şu mantıkla çalışır: güvenilmeyen girdinin kaynağını belirler, veriyi program boyunca izler ve arındırılmadan hassas bir hedefe ulaştığı durumları işaretler. Bu, oldukça etkili bir modeldir ve birçok gerçek hatayı yakalayabilir.
Pratikte SAST, özellikle yönlendirme katmanları, dinamik çağrılar, callback'ler, reflection ve framework ağırlıklı kontrol akışı içeren gerçek kod tabanlarında, büyük ölçekte uygulanabilir kalabilmek için bazı yaklaştırmalar yapmak zorundadır. Bu yaklaşıklıklar SAST'ın zayıf bir yönü değildir; kodu çalıştırmadan anlamaya çalışmanın doğal bir sonucudur.
Bu durum tek başına Codex Security'nin neden bir SAST raporuyla başlamadığını açıklamaz.
Asıl daha derin mesele, bir kaynaktan (source) hedefe (sink) giden akışı başarıyla izledikten sonra ne olduğudur.
Statik analiz, girdiyi birden fazla fonksiyon ve katman boyunca doğru biçimde izlese bile, yine de şu temel soruya yanıt vermek zorundadır:
Yaygın bir örneği ele alalım: kod, güvenilmeyen içeriği ekranda göstermeden önce sanitize_html() gibi bir şey çağırır. Statik analiz aracı, bu temizleme fonksiyonunun çalıştığını görebilir. Ancak çoğu zaman şunu belirleyemez: Bu temizleme mekanizması, kullanılan özel görüntüleme bağlamı, şablon altyapısı, kodlama davranışı ve sonraki dönüşümler için gerçekten yeterli mi?
İşlerin karmaşıklaştığı yer tam da burasıdır. Sorun sadece verinin bir hedefe ulaşıp ulaşmadığı değildir. Sorun, koddaki kontrollerin değeri sistemin varsaydığı biçimde gerçekten kısıtlayıp kısıtlamadığıdır.
Başka bir deyişle: "kod bir temizleme fonksiyonu çağırıyor" ile "sistem gerçekten güvenli" arasında büyük bir fark vardır.
Bu, gerçek sistemlerde sürekli karşımıza çıkan bir örüntüdür.
Bir web uygulaması bir JSON yükü alır, redirect_url alanını çıkarır, bunu izin verilenler listesine dayalı bir regex'e göre doğrular, URL kodunu çözer ve sonucu bir yönlendirme işleyicisine aktarır.
Klasik bir kaynaktan hedefe rapor, akışı şöyle açıklayabilir:
güvenilmeyen girdi → regex denetimi → URL kod çözme → yönlendirme
Ama asıl soru, denetimin var olup olmadığı değildir. Asıl soru, bu denetimin sonrasında gelen dönüşümlerden sonra da değeri halen kısıtlayıp kısıtlamadığıdır.
Regex, kod çözmeden önce çalışıyorsa, yönlendirme işleyicisinin yorumladığı şekliyle kodu çözülmüş URL'yi gerçekten kısıtlıyor mu?
Bunu yanıtlamak için, tüm dönüşüm zinciri boyunca regex'in nelere izin verdiğini, kod çözme ve normalleştirmenin nasıl çalıştığını, URL ayrıştırmanın uç durumları nasıl ele aldığını ve yönlendirme mantığının şemaları ve yetkileri nasıl yorumladığını değerlendirerek akıl yürütmek gerekir.
Uygulamada önem taşıyan güvenlik açıklarının çoğu, işlem sırası hataları, kısmi normalleştirme, ayrıştırma belirsizlikleri ve doğrulama ile yorumlama arasındaki uyuşmazlıklar gibi sorunlardan kaynaklanır. Veri akışı görünür durumdadır. Zayıflık, kısıtların dönüşüm zinciri boyunca nasıl yayıldığında ya da yayılamadığında yatar.
Bu yalnızca teorik bir örüntü değildir. CVE-2024-29041(yeni bir pencerede açılır) örneğinde Express, yönlendirme hedeflerinin kodlanma ve yorumlanma şekli nedeniyle, bozuk URL'lerin yaygın izin verilenler listesi uygulamalarını aşabildiği bir açık yönlendirme sorunundan etkilenmişti. Veri akışı açıktı. Daha zor soru ve hatanın gerçekten var olup olmadığını belirleyen asıl nokta, dönüşüm zincirinden sonra doğrulamanın hala geçerli olup olmadığıydı.
Codex Security, basit bir hedef etrafında tasarlanmıştır: daha güçlü kanıtlarla sorunları ortaya çıkarıp sınıflandırma sürecini azaltmak. Üründe bu, depoya özgü bağlamın (buna tehdit modeli de dahildir) kullanılması ve yüksek sinyalli sorunlar öne çıkarılmadan önce bunların izole bir ortamda doğrulanması anlamına gelir.
Codex Security, "doğrulama" ya da "temizleme" gibi görünen bir sınırla karşılaştığında, bunu yalnızca işaretlenmiş bir kontrol kutusu gibi ele almaz. Bunun yerine, kodun hangi garantiyi sağlamaya çalıştığını anlamaya çalışır ve ardından bu garantiyi çürütmeye yönelir.
Pratikte bu yaklaşım çoğu zaman şu unsurların birleşiminden oluşur:
- İlgili kod yolunun, tıpkı bir güvenlik araştırmacısının yapacağı gibi deponun tüm bağlamı içinde incelenmesi ve amaç ile uygulama arasındaki uyumsuzlukların aranması. Bu, yorumları da kapsar; ancak model, yorumlara her zaman güvenmez. Bu nedenle kodunuzun üzerine //Halvar says: this is not a bug gibi bir ifade eklemek, gerçekten bir hata varsa modeli yanıltmaz.
- Problemin en küçük test edilebilir parçaya (örneğin, tek bir girdi etrafındaki dönüşüm hattına) indirilmesi; böylece sistemin geri kalanı engel olmadan bunun üzerinde akıl yürütebilirsiniz. Bu anlamda Codex Security, küçük kod parçalarını çıkarır ve bunlar için mikro-fuzzer'lar oluşturur.
- Her kontrolü tek tek değerlendirmek yerine, dönüşümler boyunca geçerli olan kısıtlar üzerine akıl yürütülmesi. Uygun durumlarda bu, problemin bir sağlanabilirlik sorusu olarak formüle edilmesini de içerebilir. Başka bir deyişle, modele z3 çözücüsünü içeren bir Python ortamına erişim sağlıyoruz. Model, özellikle karmaşık girdi kısıtlarını çözerken, gerektiğinde bu ortamı tıpkı bir insan gibi etkili biçimde kullanabiliyor. Bu, özellikle standart dışı mimarilerde tamsayı taşmalarına veya benzer hatalara bakmak için faydalıdır.
- Mümkün olduğunda, "bu bir sorun olabilir" ile "bu bir sorundur" ayrımını yapmak için hipotezlerin sandbox’lı bir doğrulama ortamında çalıştırılması. Kodun hata ayıklama modunda derlendiği uçtan uca bir PoC'den daha güçlü bir kanıt yoktur.
Asıl dönüşüm burada ortaya çıkar: sistem, "bir kontrol var" demekle yetinmez; bunun yerine "invariant sağlanıyor ya da sağlanmıyor ve işte bunun kanıtı" noktasına ilerler. Ve model, bu iş için en uygun aracı seçer.
Makul bir tepki şu olabilir: neden ikisi birden mümkün olmasın? Önce bir SAST raporuyla başlayın, ardından otonom ajanın daha derin akıl yürütmesine izin verin.
Önceden hesaplanmış bulgular, özellikle dar kapsamlı ve iyi bilinen hata sınıflarında yararlı olabilir. Ancak bağlam içinde güvenlik açıklarını keşfetmek ve doğrulamak üzere tasarlanmış bir otonom ajan için, bir SAST raporuyla başlamak üç öngörülebilir hata moduna yol açar.
İlk olarak, erken daralmayı teşvik edebilir. Bulgu listesi, aracın zaten nerelere baktığının bir haritasıdır. Bunu başlangıç noktası olarak ele alırsanız, sistemi aynı alanlarda orantısız çaba harcamaya, aynı soyutlamaları kullanmaya ve aracın bakış açısına uymayan hata sınıflarını kaçırmaya yönlendirebilirsiniz.
İkinci olarak bu, geri alınması zor örtük yargıları beraberinde getirebilir. Birçok SAST bulgusu; temizleme, doğrulama veya güven sınırları hakkında varsayımlar içerir. Bu varsayımlar yanlış ya da eksikse, bunları akıl yürütme döngüsüne dahil etmek otonom ajanı "inceleme" modundan çıkarıp "onaylama ya da reddetme" moduna itebilir. Oysa otonom ajanın yapmasını istediğimiz şey bu değildir.
Üçüncü olarak, akıl yürütme sisteminin değerlendirilmesini zorlaştırabilir. İş akışı, SAST çıktısıyla başlarsa otonom ajanın kendi analiziyle keşfettiği bulgularla başka bir araçtan devraldığı bulgular arasındaki farkı ayırt etmek zorlaşır. Bu ayrım, sistemin yeteneklerini doğru biçimde ölçmek açısından kritik önem taşır; çünkü sistemin zaman içinde gelişebilmesi buna bağlıdır.
Bu nedenle Codex Security'yi, güvenlik araştırmasının doğal başlangıç noktasından hareket edecek şekilde tasarladık: koddan ve sistemin niyetinden başlıyor, bir insan sürece dahil olmadan önce ise güven düzeyini yükseltmek için doğrulamadan yararlanıyor.
SAST araçları, güvenli kodlama standartlarını uygulama, basit kaynaktan hedefe sorunları yakalama ve bilinen örüntüleri geniş ölçekte tespit etme gibi tasarlandıkları işlerde son derece etkilidir; bunu da öngörülebilir ödünleşimlerle gerçekleştirir. Böylece katmanlı savunma yaklaşımının güçlü bir parçası olabilir.
Ancak bu yazının odağı daha dardır: davranış üzerinden akıl yürüten ve bulguları doğrulayan bir otonom ajanın, çalışmaya statik bir bulgu listesine dayanarak başlamaması gerektiğini ortaya koyar.
Ayrıca, salt kaynaktan hedefe yaklaşımının önemli bir sınırlamasını da vurgulamak gerekir: her güvenlik açığı bir veri akışı problemi değildir. Gerçek dünyadaki birçok hata; durum ve invariant problemlerinden kaynaklanır; örneğin, iş akışı atlamaları, yetkilendirme boşlukları ve "sistemin yanlış durumda olması" gibi hatalar. Bu tür hatalarda, kirlenmiş bir değer tek bir "tehlikeli hedefe" ulaşmaz. Risk, programın her zaman doğru olduğunu varsaydığı şeyde ortaya çıkar.
Güvenlik araçları ekosisteminin gelişmeye devam edeceğini öngörüyoruz: statik analiz, fuzzing, çalışma zamanı korumaları ve otonom ajan tabanlı iş akışlarının hepsinin bu yapıda bir rolü olacaktır.
Codex Security'nin özellikle iyi olmasını istediğimiz alan, güvenlik ekipleri açısından en maliyetli kısımdır: "bu şüpheli görünüyor" noktasını, "bu gerçek bir sorun; şu nedenle başarısız oluyor ve işte sistemin niyetine uygun çözüm" noktasına dönüştürmek.
Codex Security'nin depoları nasıl taradığını, bulguları nasıl doğruladığını ve nasıl çözümler önerdiğini daha ayrıntılı öğrenmek isterseniz, belgelerimize(yeni bir pencerede açılır) göz atabilirsiniz.
