Merhaba

Google Chrome Security ekibi, 30 Temmuz 2026 tarihinde yayınladığı yazıda son iki Chrome sürümünde toplam 1.072 güvenlik açığının kapatıldığını duyurdu. Bu rakam, kendisinden önceki 23 stable sürümde giderilen açıkların toplamını aşıyor.

Rakamın kendisi çarpıcı. Ancak asıl üzerinde durulması gereken şey, bu rakamı üreten sürecin nasıl kurulduğu ve bu hızın beraberinde getirdiği yeni problem.

Rakamlar ne söylüyor?

Hattın kurulumu: Gemini, BigSleep ve CodeMender

Google’ın Large Language Model kullanımı yeni değil. 2023’ten bu yana fuzzing sistemlerine LLM entegre ediliyordu. Kırılma noktası, 2026’nın başında kurulan agent harness oldu: Gemini tabanlı bu yapı, Chrome kod tabanının tamamında zafiyet aramak üzere tasarlandı ve önceki denemelere göre çok daha düşük bir false positive oranıyla çalıştı.

Buna DeepMind ve Project Zero ile birlikte geliştirilen iki araç eşlik ediyor:

• BigSleep: Zafiyet keşfine odaklanan agent. Daha önce V8 JavaScript engine ve grafik bileşenlerinde açıklar bulmuştu.
• CodeMender: Düzeltme tarafında çalışan bileşen.

Her ikisi de doğrudan Continuous Integration (CI) sistemine entegre edilmiş durumda ve 24 saatte bir tüm code change’ler üzerinde çalışıyor. Google, yalnızca mayıs ayında bu entegrasyon sayesinde 20’den fazla zafiyetin production’a ulaşmasının engellendiğini, bunlardan birinin kritik S1+ seviyesinde olduğunu belirtiyor.

13 yıllık sandbox escape

Yazının en dikkat çekici bulgusu, Gemini tabanlı harness’in ortaya çıkardığı bir sandbox escape zafiyeti. Ele geçirilmiş bir renderer process’in, browser’ı yerel dosyaları okumaya ikna etmesine imkan veren bu açık, Chrome kod tabanında 13 yıldan uzun süredir duruyordu.

Bu detay üzerinde durmak gerekiyor. Chrome, dünyanın en yoğun denetlenen kod tabanlarından biri. Aktif bir fuzzing altyapısı, olgunlaşmış bir bug bounty programı, Project Zero gibi bir ekip ve on binlerce saatlik kod incelemesi var. Buna rağmen bu açık 13 yıl boyunca fark edilmedi.

Yani burada yaşanan şey, “insanların bulamadığını AI buldu” gibi basit bir üstünlük hikayesi değil. Daha çok, farklı bir arama yönteminin farklı bir sınıf hatayı görünür kılması durumu. Google’ın kendisi de bunu vurguluyor: AI, fuzzing’in yerini almıyor, ona ekleniyor. Fuzzing karmaşık zafiyetleri bulmakta halen etkili.

Agent rolleri: fixing, critic, test

Sürecin en somut değişimi bulma tarafında değil, düzeltme tarafında. Google hattı ayrı rollere bölmüş durumda:

1. Fixing agent: Aday yamaları üretiyor.
2. Critic agent: Üretilen yamanın Chrome’un kod ve güvenlik standartlarına uyup uymadığını denetliyor.
3. Test agent’ları: Chrome’un desteklediği tüm platformlarda doğrulama testleri yazıyor ve çalıştırıyor.

İnsan geliştirici bu zincirin en sonunda devreye giriyor ve onay veriyor.

Triage tarafı da otomatikleştirilmiş durumda: spam ve duplicate raporların filtrelenmesi, Proof of Concept exploit’lerin yeniden üretilmesi, severity ataması ve raporun doğru ekibe yönlendirilmesi. Google bunun geliştiricilere ayda yüzlerce saat kazandırdığını söylüyor.

Bir ayrıntı daha var: ekip geliştiricilerini, trust boundary ve threat model tanımlarını içeren SECURITY.md dosyaları eklemeye teşvik ediyor. Amaç, AI sistemlerinin güvenlik açısından kritik operasyonları daha isabetli ayırt edebilmesi. Yani AI’ın performansı, kod tabanının ne kadar iyi belgelendiğine bağlı hale geliyor.

Asıl problem: patch gap

Buraya kadarki kısım iyi haber. Ancak yazının ikinci yarısı, daha az konuşulan ama operasyonel olarak daha önemli bir konuya giriyor.

Chrome açık kaynak. Bir güvenlik yaması yayınlandığı anda, düzeltmenin kendisi saldırgana açığın nerede olduğunu söyleyen bir harita haline geliyor. Saldırganlar commit’i tersine mühendislikle inceleyip, henüz güncellemeyen kullanıcılara yönelik exploit geliştirebiliyor. Bu aradaki süreye patch gap deniyor.

Buradaki denklem basit ve rahatsız edici: bulunan açık sayısı arttıkça, yayınlanan yama sayısı artıyor; yayınlanan yama sayısı arttıkça, saldırgana verilen ipucu sayısı da artıyor.

Google’ın buna karşı aldığı önlemler:

• Haftada iki güvenlik sürümü denemesi (tek sürüm yerine).
• İki haftada bir major release takvimine geçiş.
• Dynamic patching Chrome 150 ile macOS tarafında browser’ın arka planda kendini yeniden başlatarak güncellemeyi uygulaması. Hedef, kullanıcı deneyimini bozmadan yamayı devreye almak.

Bug bounty tarafındaki yan etki

Chrome Vulnerability Reward Program’a gelen rapor sayısı da hızla arttı. Mart 2026 itibarıyla gelen rapor sayısı, 2025’in tamamındaki toplamı geçmiş durumda.

Google bunun üzerine programı revize etti: artık iç AI araçlarının zaten yakaladıklarının ötesine katkı sunan bulgular önceliklendiriliyor. Bu, bağımsız araştırmacılar açısından anlamlı bir eşik değişimi. Otomatik tarama ile bulunabilecek yüzeysel bulguların ekonomik değeri düşüyor.

Burada dikkat çeken nokta şu:

Bulma kapasitesinin artması, tek başına daha güvenli bir ürün anlamına gelmiyor. Kritik olan, bulma hızı ile düzeltme ve dağıtma hızı arasındaki dengenin korunması.

Google bu dengeyi koruyabilecek kaynaklara sahip: hem AI ile bulup hem AI ile yamayıp hem de dağıtım frekansını artırabiliyor. Ancak bu yaklaşım sektöre yayıldıkça, aynı kaynağa sahip olmayan üreticilerde farklı bir tablo çıkması muhtemel. Nitekim benzer AI destekli zafiyet keşif çalışmalarında, bulunan açık sayısının ekiplerin inceleme ve düzeltme kapasitesini aştığına dair örnekler şimdiden görülüyor.

Bulma kapasitesi düzeltme kapasitesini aşarsa, elde kalan şey daha güvenli bir ürün değil, daha uzun bir açık kuyruğu olur.

Kurumsal taraf için çıkarımlar

Bu gelişme, tarayıcıyı yöneten IT ekipleri açısından somut sonuçlar doğuruyor:

1. Tarayıcı artık “ayda bir güncellenen uygulama” değil.
   Yama frekansı haftalık seviyeye çıkarken, aylık güncelleme pencereleri anlamsızlaşıyor. Chrome güncelleme politikanızı bu yeni ritme göre gözden geçirmek gerekiyor.
2. Güncelleme gecikmesini ölçün.
   Sürüm yayınlandıktan sonra kaç gün içinde filonuzun tamamı güncelleniyor? Bu metriği takip etmiyorsanız, patch gap riskinizi bilmiyorsunuz demektir. Chrome Enterprise ortamlarında RelaunchNotification ve elaunchNotificationPeriodR policy’leri ile zorunlu yeniden başlatma penceresi tanımlanabilir.
3. Extension ve eklenti envanterini unutmayın.
   Tarayıcı çekirdeği hızla yamalanırken, aynı hız ekosistem tarafında geçerli değil. Kurumsal ortamda izin verilen extension listesi ayrı bir denetim başlığı.
4. Bu yaklaşım Chrome’a özel kalmayacak.
   Ölçek avantajına sahip her satıcı benzer bir hatta geçecek. Genel olarak yama akışının hacminin artmasını beklemek gerekiyor. Patch management süreçlerinizi bugünkü hacme değil, iki katına göre tasarlayın.

Genel görünüm:

Chrome örneği, yapay zekanın güvenlik operasyonlarında bir demo aşamasından çıkıp üretim hattının kalıcı bir parçası haline geldiğini gösteriyor. 13 yıllık bir sandbox escape’in bulunması etkileyici bir başlık, ancak asıl anlamlı olan CI’ya entegre edilmiş, günlük çalışan ve insan onayıyla kapanan bir döngünün kurulmuş olması.

Aynı zamanda bu, savunma tarafının tek kazananı olduğu bir tablo değil. Aynı araçlar saldırgan tarafta da mevcut ve orada koordinasyon, onay ya da regresyon testi gibi kısıtlar yok. Google’ın patch gap’i kapatmak için gösterdiği aceleyi bu bağlamda okumak gerekiyor.

Kurumlar açısından çıkarılacak ders, teknolojinin kendisinden çok tempoyla ilgili: güvenlik güncellemelerinin yayınlanma hızı arttı, uygulama hızınız aynı kaldıysa aradaki fark risk olarak birikiyor.

Başka bir yazımızda görüşmek dileğiyle…

Kaynak: Google Chrome Security ekibi — “Stronger with every update: How we’re making Chrome and the web safer in the AI Era”, 30 Temmuz 2026