GitHub Push Protection 2 ms’de Yapısız Sırrı Yakalıyor
GitHub, sır (secret) korumasının yazılım üretim hızıyla aynı ölçekte çalışması gerektiğini savunan bir analiz yayımladı. Erin Havens imzalı yazı dokuz çeyreklik veriye dayanıyor, “geliştiriciler dikkatsizleşti” tezini çürütüyor ve push protection kapsamını yapısız (unstructured) sırlara genişleten yeni bir sınıflandırıcı modeli tanıtıyor. Verilerin ne söylediğini, modelin hangi kısıtları çözmeye çalıştığını ve hangi yüzeylerde kullanıma açıldığını özetliyorum.
Dikkatsizlik değil, hız farkı
GitHub’a göre bugün her üç pull request’ten biri bir AI agent içeriyor; bir yıl önce bu oran 10’da 1’in altındaydı. Bu tempo sürerse önümüzdeki iki yıl içinde GitHub’a push edilen kodun büyük bölümünü agent’lar yazabilir, bu kodun önemli bir kısmı da hiçbir zaman bir insan tarafından baştan sona okunmayabilir.
Herkese açık kodda yaklaşık her iki saniyede bir yeni bir sır beliriyor, rakam son üç yıldır her yıl ikiye katlanıyor. Artış ise push başına oranın yükselmesinden değil, toplam push hacminin büyümesinden geliyor.
- 2024 Q2 ile 2026 Q2 arasında taranan push sayısı 2,84 kat arttı.
- Aynı dönemde kimlik bilgisi taşıyan push sayısı 2,59 kat arttı.
- Dokuz tam çeyreklik veride push başına yaygınlıkta istatistiksel olarak saptanabilir bir eğilim bulunmadı.
- 2026 Q2’de 574 milyon herkese açık push gerçekleşti; bunların %0,47’sinde bir sır tespit edildi.
Üstelik geliştiricilerin riske yaklaşımı sertleşiyor. Push yolunda verilen blokların geliştirici tarafından geçersiz kılınma (override) oranı aynı dönemde %6,63’ten %3,93’e doğrusal biçimde düştü. Özen eksikliğinden söz etmek bu tabloda güç; koruma mekanizmaları üretim hızının gerisinde kalıyor.
Önleme hesaplama gücüyle, temizlik insanla ölçekleniyor
Sabit bir oranda, aktivite ikiye katlandığında beklenen sızıntı da ikiye katlanır. Her sızıntı aynı insan müdahalesini gerektiriyorsa iş yükü de ikiye katlanır. GitHub’ın paylaştığı veride bir sırrın manuel olarak iptal edilmesine kadar geçen ortalama süre 40 gün civarında, yaklaşık beşte biri 90 günü aşıyor. Açığa çıkmış kimlik bilgileri haftalarca, hatta aylarca kullanılabilir kalıyor.
GitHub’ın secret scanning ortaklık programı kapsamında 150’den fazla teknik iş ortağı var. İş ortakları hem detektör geliştiriyor hem de herkese açık sızıntı bildirimlerini alıyor. 2026 Q2’de herkese açık tarama, tekrarlı gözlemler dahil saniyede ortalama 26 kimlik bilgisi eşleşmesini başarıyla raporladı. Bildirim sonrası çok sayıda iş ortağı token’ı anında iptal ediyor: OpenAI API anahtarları, Google Cloud hesap kimlik bilgileri, Slack webhook’ları, Hugging Face kullanıcı token’ları, SendGrid anahtarları. Sahibinin token’ı yenilemesi yine gerekebilir ama iptal işlemi, geliştiricinin uyarıyı görüp işlemesini beklemeden gerçekleşebiliyor.
Push protection daha erken devreye giriyor, tanınabilir kimlik bilgisinin depo geçmişine girmesini engelliyor; böylece geliştirici ya da agent, soruşturulacak bir sızıntı oluşmadan değişikliği düzeltebiliyor. GitHub, son bir ay içinde push protection’ın en az saniyede bir kez bir sırrı engellediğini belirtiyor. Sağlayıcıya bağlı (issuer-bound) kimlik bilgilerinde GitHub, kaçanlardan daha fazlasını engelliyor.
Buna rağmen tablo dengesiz. Ek sır türleri de dahil edildiğinde push protection, yeni tespit edilen sırların yaklaşık %30’unu geçmişe girmeden durduruyor, kalan %70 kimlik bilgisi zaten kaybedildikten sonra bulunuyor. Önleme hesaplama gücüyle ölçekleniyor, temizlik hala insanla. Bir push’u reddetmek compute maliyeti, görünür geçmişe düşmüş bir sırrı temizlemek ise geliştiricinin zamanı ve dikkati demek.
“Dört cisim problemi”: Hassasiyet, gecikme, verim ve maliyet
Bir sır push sınırını geçmeden önce onu durdurmanın maliyeti küçüktür, karar da ikilidir: engelle ya da izin ver. Sınır geçildikten sonra aynı dizge gerçek bir sisteme kimlik doğrulayabiliyor ve maliyet sınırsız hale geliyor.
Çoğu durumda elde tek ipucu olarak çevredeki kod ve bağlam kalıyor. Sağlayıcı tarafından verilen bir token tanınabilir bir ön eke sahip olabilir; bir iç veritabanı parolası ise tamamen yapısız olabilir, hiçbir ayırt edici desen taşımayabilir. GitHub bu bağlamı push sonrasında zaten kullanıyordu, zor olan bağlam duyarlı yargıyı diğer kısıtlarla dengelemekti.
GitHub bunu sır koruması için “dört cisim problemi” diye adlandırıyor: hassasiyet (precision), gecikme, verim (throughput) ve maliyet birbirine bağlı kısıtlardır. Önleme, geliştiricinin zamanına değmelidir. Sonradan incelemeye uygun bir bulgu, bir push’u engellemeyi haklı çıkarmayabilir. Yanlış pozitif geliştiriciyi böler, bir sonraki blokun güvenilirliğini zayıflatır. Çok yavaş, pahalı ya da ölçeklenmesi zor bir kontrol de ne sıklıkla çalışabileceğini sınırlar.
ModernBERT tabanlı sınıflandırıcı ve iki milisaniyelik bütçe
Microsoft Applied Sciences ile birlikte geliştirilen ince ayarlı (fine-tuned) ModernBERT sınıflandırıcısı, aday sırları bağlam içinde değerlendiriyor, bunu yaparken kod ya da düzyazı üretmiyor. GitHub’a göre model mevcut LLM tabanlı işlem hatlarından daha hassas; ayrıca aday gruplarını iki milisaniyenin altında değerlendirecek kadar hızlı ve kritik yolda ölçekli çalışacak kadar maliyet verimli.
Örnek olarak verilen senaryoda, AI destekli genel sır tespiti modeli bir veritabanı URL’sindeki, Kubernetes Secret manifest’indeki ve Dockerfile’daki parola benzeri değerleri çevresindeki kod bağlamına bakarak engelliyor, changeme gibi bir yer tutucuya ise izin veriyor.
Modelin push protection’a dahil edilmesi, GitHub’ın önleyebildiği sır sayısını iki katından fazlasına çıkarabiliyor.
Nerede, nasıl kullanılabilir olacak
- Push protection: Özellik şu anda private preview aşamasında. Bu ay içinde Enterprise Cloud ve GitHub Teams üzerindeki GitHub Secret Protection sahibi kuruluşlara açılacak. AI kredisi tüketecek.
- Push sonrası taramalar: AI secret detection kullanan kuruluşlar bugünden itibaren otomatik olarak yeni modele güncelleniyor. Bu taramalardan açılan uyarılar, kuruluşun secret scanning satın alımına ek ücret olmadan dahil olmayı sürdürüyor.
- GitHub Enterprise Server 3.23: Model bu sürümle public preview olarak gelecek; böylece hava boşluklu (air-gapped) ortamlardaki Secret Protection müşterileri de AI ile tespit edilen uyarılara erişebilecek.
- Copilot CLI ve Copilot App: Sınıflandırıcı
/security-reviewkomutuna ekleniyor. Böylece Copilot kullanıcıları, kuruluşlarının GitHub Secret Protection planı olmasa bile sırları push öncesinde ele alabilecek. AI kredi kullanımı, AI usage insights ekranında GitHub Secret Protection’a atfediliyor.
Ne anlama geliyor
“Daha dikkatli olun” çağrısı tek başına bu dengesizliği çözmüyor, yazının çerçevesi de buraya çıkıyor. Kod hacmi büyüdükçe hem daha fazla sızıntının önlenmesi hem de kalanların gerektirdiği insan emeğinin azaltılması gerekiyor; aksi halde ortaya çıkan açık hacmi sürdürülebilir olmaktan çıkar.
GitHub’ın hedeflediği gelecek, geliştiricilerin her isteği denetlemeden agent’lara daha fazla iş emanet edebildiği ve bir kuruluşun kimlik bilgilerini güvende tutmak için ihtiyaç duyduğu kişi sayısının yazdığı kod miktarıyla birlikte büyümediği bir tablo. Yazı şu cümleyle kapanıyor: koruma kapasitemiz, üretme kapasitemizle birlikte büyümeli.
Kaynaklar ve İleri Okuma
- Secret protection must scale with software – Erin Havens, The GitHub Blog
- GitHub Docs: Secret scanning partner program
- The GitHub Blog
- GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı
- GitHub Secret Scanning: Genişletilmiş Metadata ve Çoklu Doğrulama
- GitHub Secret Scanning API ve Webhook İyileştirmeleri
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder