GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı
Bir commit, bir olay… bazen de küçük bir panik
Bakın şimdi, secret scanning deyince çoğu kişi “tamam işte, repo’da API key arıyor” diye geçiyor. Kâğıt üstünde öyle. Pratikteyse mesele biraz daha sert: yanlışlıkla push edilen bir token, gece yarısı açılan bir incident, sabah ilk kahvede başlayan hasar kontrolü… Hani o klasik senaryo var ya, “bir şey olmaz” denilen dosya sonra prod’a kadar gidiyor. Evet, tam orası.
Geçen sene Nisan 2025’te bir finans müşterisinde buna çok benzer bir durum gördük (ciddiyim). Bir geliştirici test ortamı için aldığı bir anahtarı yanlışlıkla branch’e koymuştu; push protection açık olmasaydı olay sessizce ilerleyecekti. O gün anladım ki secret scanning sadece güvenlik ekibinin oyuncağı değil, doğrudan iş sürekliliği konusu.
GitHub’ın bu son güncellemesi de tam burada anlam kazanıyor. Yeni detektörler geliyor, bazıları varsayılan push protection kapsamına alınıyor ve npm token’ları için validity check devreye giriyor. Yanı sistem artık sadece “benziyor mu?” diye bakmıyor; biraz da “bu şey hâlâ yaşıyor mu?” diye kontrol ediyor. Fena değil, hatta baya iş görüyor.
Bunu biraz açayım.
Yeni detektörler: Her provider aynı ağırlıkta değil
Bu güncellemede dokuz yeni secret tipi eklenmiş. Langchain, Salesforce ve Figma gibi taraflar öne çıkıyor ama listeyi yalnızca popüler isimler olarak okumamak lazım. Çünkü asıl hikâye şu: GitHub secret scanning artık modern uygulama yığınına daha iyi uyum sağlıyor. AI platformu kullanıyorsun, tasarım aracı kullanıyorsun, pazarlama otomasyonu kuruyorsun… hepsi ayrı bir giriş kapısı demek.
2019’da kendi lab ortamımda benzer bir şeyi manuel regex’lerle yapmaya çalışmıştım. Açık konuşayım, idare ederdi ama ölçek büyüyünce işler çorba öldü. Aynı pattern farklı servislerde farklı davranıyordu; false positive yağmur gibi yağıyordu. Şimdi GitHub tarafında partner entegrasyonları ve doğrulayıcılar sayesinde bu iş çok daha derli toplu ilerliyor.
Evet, doğru duydunuz.
Aşağıdaki tabloyu özellikle önemli buluyorum çünkü hangi secret tipinin ne seviyede korunduğunu net gösteriyor:
| Provider | Secret type | Partner | User alert | Push protection |
|---|---|---|---|---|
| Figma | figma_scim_token | Evet | Evet | Varsayılan |
| Langchain | langsmith_license_key | Evet | Evet | Varsayılan |
| Salesforce | salesforce_marketing_cloud_api_oauth2_token | Evet | Evet | Varsayılan |
| NPM | npm_access_token | Evet | Evet | Varsayılan |
Neyse, tablo kısmını karıştırmadan şunu net söyleyeyim: Figma, Google, OpenVSX, PostHog tarafında bazı token’lar artık varsayılan push protection içinde geliyor. Bu küçük gibi görünen değişiklik aslında ciddi rahatlık sağlıyor. Güvenlik ekibinin tek tek ayar kovalamadan koruma kazanması demek. Daha fazla bilgi için
Bir secret’ı sonradan yakalamak iyidir; ama commit aşamasında durdurmak bambaşka seviye. Bugün beni en çok etkileyen nokta da bu öldü. GitHub burada reaktif olmaktan çıkıp proaktif tarafa doğru baya kayıyor.
Npm validity check neden önemli?
Npm_access_token için validity checks eklenmesi bana göre sessiz ama değerli bir hamle. Çünkü her bulunan token gerçekten aktif olmayabiliyor; bazıları yıllar önce iptal edilmiş oluyor ama repoda hâlâ dürüyor. Güvenlik ekipleri açısından bu fark çok önemli çünkü önceliklendirme yaparken gürültüyü azaltıyorsun.
Hmm, bunu nasıl anlatsamdı…
Ağustos 2024’te Logosoft’ta yürüttüğümüz bir e-ticaret geçişinde buna benzer sıkıntı yaşamıştık. Tarama aracımız yüzlerce alarm üretmişti ama bunların üçte biri bayat secrets’tı (expired token diyelim). Ekibin moralini bile düşürüyor bu durum… Yeni validity yaklaşımı işte tam o noktada nefes aldırır.
Küçük ekip için ne ifade ediyor?
Küçük startup’larda güvenlik çoğu zaman “sonra bakarız” listesine düşüyor. Ama işin aslı şu ki birkaç developer’ın kullandığı tek repo bile dış dünyaya açık kapı bırakabiliyor. Push protection default geldiğinde startup tarafında ekstra süreç kurmadan temel koruma elde ediyorsun (şaşırtıcı ama gerçek).
Büyük enterprise’da fark nerede çıkıyor?
Büyük yapılarda mesele sayıca çok repository olması değil sadece; farklı business unit’lerin farklı tool set kullanması da problem yaratıyor. Bir ekip Figma ile çalışırken diğer ekip PostHog kullanıyor olabilir. İşte böyle ortamlarda default koruma standardizasyon sağlıyor — Azure’daki policy yaklaşımına benziyor biraz; merkezî kural koyuyorsun. Uygulama uçta çalışıyor.
Sahada gördüğüm gerçek etki: az alarm, daha net aksiyon
Zaten en büyük problem çoğu zaman araç eksikliği değil… sinyal kalitesi eksikliği oluyor.
2026 başında bir kamu kurumunda yaptığımız değerlendirmede security dashboard resmen alarm mezarlığı gibiydi; sekiz farklı kaynak aynı repoya bakıyor ama aynı secret için üç ayrı yorum üretiyordu.
İnsan yoruluyor tabiî.
- Daha doğru sınıflandırma ile false positive azalıyor — bunu es geçmeyin.
- Push’tan önce bloklanan secret sayısı artınca incident ihtimali düşüyor.
- User alert ile partner reporting ayrımı sayesinde sorumluluk zinciri netleşiyor.
- Kurum içi remediation SLA takibi kolaylaşıyor (bu kritik).
- Daha temiz sinyal = daha hızlı müdahale.
Açık konuşayım, burada beklediğim kadar iyi olmayan tek yer UI tarafındaki detaylar öldü diyebilirim. Pattern adlarının tıklanabilir hâle gelmesi hoş ama hâlâ biraz ham hissettiriyor. En çok da büyük tenantlarda filtreleme ekranının daha akıcı olması lazım. Kağıt üstünde süper… pratikte göreceğiz artık.
Peki biz bunu nasıl konumlandırmalıyız?
Eğer kurumsal tarafta çalışıyorsanız secret scanning’i tek başına bırakmayın derim. Ben AZ-500 hazırlığında bunu hep şöyle düşünmüştüm: Secret scanning kapıda duran görevli, push protection turnike, validity check işe cebindeki dedektör gibi. Üçü birlikte çalışınca sistem anlam kazanıyor.
Gel gelelim asıl değer ancak policy disiplininde çıkıyor: hangi repo taranacak, hangi provider öncelikli, hangi alert kaç saatte kapanacak… bunları yazmazsan araç var olur ama yönetim yok olur.
Bir de şu var: DevOps pipeline’a bağımlı çalışan ekiplerde pre-commit kontrolleriyle GitHub tarafını desteklemek iyi fikir olabilir. Ben bunu Mart 2026’da Azure SDK güncellemelerini incelerken de düşündüm; her şeyi son noktada çözmeye çalışmak yerine erken aşamada fren koymak genelde daha az can yakıyor.
Sadece teknik değil, operasyonel konu da var
Küçük bir detay: Bazı organizasyonlar security tooling’i satın alınca işi bitmiş sanıyor. Aslında — hayır dur, daha doğrusu — dur bir saniye — önce şunu söyleyeyim: araç almak başlangıçtır. Gerçek iş ownership modelini kurmakta. Kimin alarmına kim bakacak? Hangi takım düzeltme yapacak? SLA kaç saat? Bunlar yoksa yeni detektör de olsa eski karmaşa devam eder.
Ben bunu telekom sektöründe çalışan bir müşteriyle Şubat 2026’da birebir yaşadım. Araç vardı. Triage akışı yoktu. Sonuç? Güzel raporlar vardı fakat düzeltme hızı düşük kaldı. Yanı teknoloji tamam… süreç eksikse çark dönmüyor.
Burada gözden kaçırılmaması gereken zayıf noktalar
Her yeni detector hemen mucize yaratmıyor. Observation mode’daki Drone CI, Netlify, Pydantic ve Twitch detektörleri mesela henüz pişmemiş durumda. Bence doğru yaklaşım bu; her şeyi GA’ya itmek yerine önce izleyip doğrulamak mantıklı. Ama kullanıcı gözünden bakınca bazen “neden bu da yok?” hissi oluşabiliyor.
Ayrıca configurable olan pattern’lerde güvenlik ekibinin gerçekten aktif rol alması şart. Varsayılan gelen şeylere güvenip kenara çekilirsen tamam, ama özel istisnaları yönetmezsen bazı riskleri kaçırabilirsin. Yanı araç güçlü, operasyon zeki olmalı.
Kısaca benim okuduğum mesaj şu
“GitHub secret scanning gelişmeye devam ediyor” cümlesi kulağa sıradan geliyor olabilir. Ama içeride olan şey basit değil: daha fazla provider, daha iyi doğrulama, daha erken engelleme ve daha temiz kullanıcı deneyimi.
Benim açımdan bu güncellemenin özü şu: güvenlik artık sadece alarm üretmiyor, kararı kolaylaştırmaya başlıyor.
Ve dürüst olayım… bence asıl kıymet de burada yatıyor.
Sıkça Sorulan Sorular
GitHub Secret Scanning nedir?
Kod depolarında API key, token ve benzeri gizli bilgileri bulan GitHub güvenlik özelliğidir. Public ve private repolarda çalışabilir. Şüpheli secrets tespit edilince alert üretir veya push protection açıksa commit’i engeller.
Push protection varsayılan gelince ne değişiyor?
Bazı secret türleri için ekstra ayar yapmadan commit engellemesi devreye girer. Bu da yanlışlıkla sızıntıyı baştan keser. En çok da yoğun geliştirme yapan ekiplerde ciddi fark yaratır.
Npm_access_token için validity check neden faydalı?
Tespit edilen token’ın aktif olup olmadığını doğrulayarak gereksiz alarm gürültüsünü azaltır. Böylece ekipler önce gerçekten risk taşıyan secrets’a odaklanabilir.
Küçük ekiplerin buna ihtiyacı var mı?
Evet, hatta bazen daha çok ihtiyaç duyarlar. Çünkü küçük ekiplerde tek bir yanlış commit’in etkisi oransal olarak daha büyüktür. Otomatik koruma olmadan insan hatasıyla mücadele etmek zorlaşır.
Kaynaklar ve İleri Okuma
Orijinal GitHub Changelog Duyurusu
GitHub Docs — Secret Scanning Hakkında
GitHub Docs — Push Protection ile Commit Engelleme
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.
