Google PageBreak: 500+ XSS Açığı Bulan Yapay Zeka Ajanı
Google, geliştirdiği yapay zeka destekli güvenlik ajanı PageBreak'in ocak ayından bu yana kendi web uygulamalarında 500'den fazla XSS (cross-site scripting, yani bir siteye kötü amaçlı JavaScript kodu enjekte edilmesi) açığı tespit ettiğini duyurdu. Haberi ilk olarak InfoQ yayımladığı bir yazıda aktardı; bilgiler Google'ın kendi yayımladığı bir makaleye dayanıyor.
PageBreak, olası güvenlik açıklarını araştırmak için Gemini modellerini kullanıyor. Ancak sistemin asıl farkı burada değil: bir bulguyu ekiplere bildirmeden önce, deterministik doğrulayıcılarla çalışan ayrı bir ortamda gerçek bir exploit üzerinden test ediyor. Google'da bilgi güvenliği mühendisi olarak çalışan Michał Bentkowski, sistemin kod kalıplarına bakarak tahmin yürütmek yerine olası açığı canlı ortamda doğrulayarak döngüyü kapattığını belirtiyor.
PageBreak nasıl çalışıyor
Sistemin mantığı şöyle işliyor: her açık hipotezi, çalışan bir ortamda gerçek bir exploit ile sınanıyor. XSS için JavaScript kodu çalıştırılıyor, path traversal (dizin gezinme) açıkları için herkesin okuyabileceği bir konuma dosya yazılıyor, RCE (uzaktan kod çalıştırma) şüphesinde ise dışarıya giden bir DNS isteği tetikleniyor. Bir bulgu ancak bu testlerden geçerse ürün ekiplerine iletiliyor.
Bentkowski bu yaklaşımın getirdiği faydayı şöyle özetliyor: "Bu yaklaşım neredeyse sıfır yanlış pozitif oranı sağlıyor ve ürün ekiplerini doğrulanmamış açık raporlarıyla boğmaktan kaçınmamızı sağlıyor." Deterministik olarak teyit edilemeyen bulgular ürün ekiplerine gönderilmiyor; bunlar Google içinde saklanıp gelecekteki taramaları derinleştirmek, doğrulama altyapısındaki boşlukları tespit etmek ve yeni doğrulayıcılar geliştirmek için kullanılıyor.
Yanlış pozitiflerin azaltılması neden önemli
Yapay zeka destekli güvenlik araçlarının en büyük sorunu, ikna edici görünen ama gerçekte doğru olmayan bulgular üretmesi. Google'da kıdemli bilgi güvenliği mühendisi Lukas Weichselbaum, LinkedIn'de bu noktaya dikkat çekiyor: PageBreak'te modelin istediği kadar hipotez üretebileceğini ancak bir bulgunun ancak gerçek bir payload ile doğrulayıcı tarafından onaylanınca sayıldığını vurguluyor. Doğrulayıcıları modelin kendisi değil, güvenlik mühendisleri yazıyor ve bu doğrulayıcılar ajan döngüsünün dışında çalışıyor.
Bentkowski ayrıca mevcut doğrulayıcıların her açık türünü veya karmaşık senaryoyu kapsayacak kapasitede olmadığını, bunun da bazı gerçek açıkların gözden kaçmasına yol açabileceğini kabul ediyor. Google Bug Hunters üzerinde yayımlanan ayrı bir yazıda Bentkowski, PageBreak'in bulduğu üç teknik vakayı paylaşıyor: bir XSS açığı, bir servis yanlış yapılandırmasından kaynaklanan önbellek zehirlenmesi sorunu ve bir path traversal açığı.
Sistemin Google'a özgü avantajları
Bentkowski, PageBreak'in başarısının büyük ölçüde Google'ın kendi mühendislik altyapısından beslendiğini belirtiyor. Tek bir büyük kod deposu üzerinden uçtan uca kod görünürlüğü, canlı HTTP trafiğini kaynak koduyla ilişkilendiren güvenlik sinyalleri ve web uygulamalarına kimlik doğrulamalı erişim sağlayan mevcut tarama altyapısı, sistemin bu ölçekte çalışmasını mümkün kılıyor. Bu da aracın başka bir şirkette birebir aynı performansla çalışacağının garantisi olmadığı anlamına geliyor.
Google'ın uzun vadeli hedefi, ürün ekiplerinin işini açık bulmaktan çıkarıp yapay zekanın önerdiği düzeltmeleri doğrulamaya indirgemek. Bu amaçla PageBreak, açıklara otomatik düzeltme üreten CodeMender gibi diğer ajan tabanlı güvenlik girişimleriyle entegre ediliyor. Kaynakta belirtildiği üzere bu 500'den fazla açık bulgusuna dair bağımsız bir doğrulama henüz sunulmadı; rakamlar Google'ın kendi raporuna dayanıyor.
Yazılım ekipleri için ne anlama geliyor
Biz SUNS Tech olarak web projelerinde güvenlik testlerinin genellikle yayına yakın bir aşamada, zaman baskısı altında yapıldığını görüyoruz. PageBreak'in gösterdiği model net: bir açığı bulmak tek başına yeterli değil, bulguyu gerçek bir ortamda exploit ile kanıtlamak ekiplerin zamanını boşa harcamasını önlüyor. Küçük ve orta ölçekli ekipler için bu, otomatik tarama araçlarına güvenirken bulgunun doğrulanmış mı yoksa sadece bir tahmin mi olduğunu sorgulamanın önemini gösteriyor.
Kurumsal tarafta IT ve güvenlik ekipleri için çıkarım daha somut. Bir güvenlik aracı değerlendirilirken yanlış pozitif oranı, kaç açık bulduğundan daha belirleyici bir kriter olabilir, çünkü doğrulanmamış yüzlerce uyarı ekibin gerçek riskleri gözden kaçırmasına yol açabilir. Web uygulaması geliştiren ve güvenlik testlerini süreç içine yerleştirmek isteyen ekipler, bu konuyu projenin başından itibaren web tasarım ve geliştirme sürecinin bir parçası olarak planlayabilir.
Şu an için yapılması ve yapılmaması gereken
Kaynakta henüz netleşmeyen nokta, PageBreak'in Google dışında bir ürün veya hizmet olarak sunulup sunulmayacağı. Bu yüzden şirketlerin kendi altyapılarında birebir aynı sistemi kurmaya çalışması gerçekçi bir adım değil; PageBreak'in avantajları büyük ölçüde Google'ın özel kod deposu ve tarama altyapısından geliyor. Daha mantıklı olan, kendi güvenlik test süreçlerinde deterministik doğrulama fikrini uygulamak: bir açık raporunu ekiplere iletmeden önce gerçek bir ortamda sınamak.
Takip edilmesi gereken işaretler arasında CodeMender ile entegrasyonun nasıl ilerlediği, Google'ın bu yaklaşımı açık kaynak araçlar veya bulut güvenlik ürünleri üzerinden dışarıya sunup sunmayacağı ve bağımsız güvenlik araştırmacılarının 500'den fazla açık iddiasını nasıl değerlendireceği yer alıyor. Bu sorular netleşene kadar PageBreak'i bir sektör standardı değil, büyük ölçekli bir şirketin kendi ihtiyacına göre geliştirdiği içsel bir araç olarak değerlendirmek daha doğru olur.
Kurumsal projelerde güvenlik testlerini süreç dahilinde nasıl kurguladığımızı görmek isteyenler portfolyomuzu inceleyebilir, proje kapsamını netleştirmek isteyenler ise bizimle iletişime geçebilir.
