GitHub'da 543.000'den Fazla Geçerli Kimlik Bilgisi Sızıntısı: Push Protection Neden Yetmiyor?

Güvenlik araştırmacıları, halka açık GitHub depolarını taradıklarında beklenenden çok daha büyük bir sorunla karşılaştı: sızdırılmış bir kimlik bilgisinin fark edilmesi değil, fark edildikten yıllar sonra bile hâlâ çalışır durumda olması. Truffle Security'nin 224 milyon depo ve 58 milyar dosyayı kapsayan taramasında, 543.699 benzersiz kimlik bilgisinin Temmuz 2026 itibarıyla ilgili servislere karşı hâlâ geçerli olduğu doğrulandı. Bu bulgu, GitHub'ın 2022'den beri yürürlükte olan otomatik sızıntı önleme mekanizmalarına rağmen ortaya çıktı ve konuyu tek bir sızıntı olayı olmaktan çıkarıp geliştirici ekosisteminin yapısal bir zafiyetine dönüştürdü.

Araştırmanın Detayları

Çalışma, yapay zeka modellerinin eğitiminde kullanılmak üzere derlenen ve 224 milyon halka açık GitHub deposunu kapsayan "The Stack v3" veri seti üzerinden yürütüldü. Tarama 7 Ağustos 2025'te kapatıldı, ancak bulunan her kimlik bilgisi 27-28 Temmuz 2026 tarihlerinde ilgili sağlayıcılara karşı gerçek zamanlı olarak test edildi. Bulunan kimlik bilgilerinin ortanca (medyan) maruz kalma süresi 784 gün; yani ortalama bir sızıntı yaklaşık iki yıldır kimse tarafından fark edilmeden veya iptal edilmeden internette duruyor. Kimlik bilgilerinin yaklaşık onda biri 6,3 yıldan eski, en eskisi ise 2009'dan bu yana hâlâ geçerliliğini koruyor.

En Sık Sızan Kimlik Bilgisi Türleri

• Google Cloud hizmet hesabı anahtarları — 126.963 commit edilmiş anahtardan 69.041'i hâlâ çalışıyordu (yaklaşık %54 canlılık oranı).
• MongoDB bağlantı dizeleri — bulunan 51.067 bağlantı dizesinin neredeyse tamamı (%100) hâlâ geçerliydi; bağlantı dizelerinin hiçbir otomatik iptal mekanizmasına tabi olmadığını gösteriyor.
• Google API anahtarları — 33.343 canlı anahtar tespit edildi.
• PostgreSQL bağlantı URI'leri — 12.985 taneden %88'i hâlâ çalışıyordu.
• Stripe ve AWS anahtarları — sayıca çok olsa da canlılık oranları görece düşüktü, çünkü bu sağlayıcılar anormal kullanım tespitinde daha agresif otomatik iptal uyguluyor.

Neden Hâlâ "Geçerli" Kalabiliyorlar?

Araştırmanın en çarpıcı tespiti şu: sızdırılmış bir anahtarı canlı tutan şey engelleme eksikliği değil, rotasyon eksikliğidir. Sağlayıcı davranışları arasındaki fark bunu açıkça gösteriyor: npm'de commit edilmiş 101.886 token'dan yalnızca 1'i hâlâ çalışıyordu, GitHub'ın kendi token'larında 73.048 taneden yalnızca 260'ı canlı kalmıştı. Buna karşılık PostgreSQL bağlantı dizelerinde 12.985 taneden 11.465'i hâlâ geçerliydi — çünkü bu tür kimlik bilgilerinde sağlayıcı tarafında hiçbir otomatik rotasyon veya anomali tespiti yok.

GitHub'ın Önlemleri Neden Yetersiz Kalıyor

GitHub, Nisan 2022'de tanıttığı ve Şubat 2024'ten itibaren tüm genel depolarda varsayılan olarak etkinleştirdiği Push Protection özelliğiyle, bilinen formatlardaki kimlik bilgilerinin commit edilmeden önce yakalanmasını hedefliyor. Ancak asıl sorun kapsam dışı kalan kısımda: canlı kimlik bilgilerinin %51,8'i, Push Protection'ın varsayılan yapılandırmasının hiç bakmadığı türlere giriyor — veritabanı bağlantı dizeleri, özel anahtarlar ve Google API anahtarları bunların başında geliyor. Bu tablo, "platform bir güvenlik özelliği sundu, artık güvendeyiz" varsayımının ne kadar yanıltıcı olabileceğini gösteriyor — platform düzeyindeki otomasyon hiçbir zaman ekip içi disiplinin ve kod inceleme süreçlerinin yerini tutamaz (bkz. güvenli kod incelemesi).

Öneriler

• Commit edilmiş her kimlik bilgisini anında tehlikeli sayın: Tespit edildiği anda ilgili anahtarı iptal edip yenisini üretin.
• Otomatik secret scanning araçlarını CI/CD hattına entegre edin: TruffleHog, Gitleaks veya GitHub Advanced Security gibi araçları yalnızca push anında değil, düzenli olarak tüm depo geçmişine karşı çalıştırın.
• `.gitignore` ve ortam değişkenlerini disiplinli kullanın: Sırlar kod içine gömülmek yerine ortam değişkenleri veya özel bir gizli yönetim servisinden okunmalı.
• Pre-commit hook'larla ikinci bir savunma katmanı kurun: `git-secrets`, `gitleaks --pre-commit` gibi araçlarla commit GitHub'a ulaşmadan önce bir kontrol noktası oluşturun.
• Rotasyon politikalarını zorunlu hale getirin: Sızıntı olmasa bile API anahtarlarını düzenli aralıklarla değiştirin; mümkünse kısa ömürlü, kendiliğinden sona eren token'ları tercih edin.
• Fork'ları ve geçmiş commit'leri de tarama kapsamına alın: Bir depo temizlense bile, daha önce alınmış fork'larda o geçmiş hâlâ yaşıyor olabilir.

543.699 rakamı tek seferlik bir olay değil, geliştirici ekosisteminin genelinde süregelen bir alışkanlığın fotoğrafı. Kurumlar için çıkarılacak ders açık: secret scanning'i tek seferlik bir denetim değil, sürekli çalışan bir güvenlik pratiği haline getirmek.