GitHub Credential Revocation API ile Sızıntılara Anında Fren: Yeni Destekler ve Gerçek Hayat Senaryoları
Başımıza Geldi: Token Sızıntısı ve Sonrası
Bir sabah kahveyle ekrana bakarken Slack’te bir bildirım patladı. Takımdan biri telaşlı: “Abi, public repoda token sızmış, hemen gördüm!” Kafamda kısa bir “yine mi?” tepkisi belirdi… Çünkü bu iş artık uzak bir korku değil; 2023’te Logosoft Azure migration’da benzerini yaşadık, gözümle gördüm. Şunu net söyleyeyim: Sızıntıyı yakaladığın anda çözüm elinin altında yoksa—her dakika risk katlanıyor, adeta yangına körükle gitmek gibi.
Bu yüzden GitHub’ın Credential Revocation API’si bana göre son zamanların en gerçekçi ve hayat kurtaran hamlesi öldü. Gelin olayı havalı anlatımlarla değil; baştan sona işin mutfağından konuşalım.
Sızıntının Anatomisi: Hangi Kimlikler, Nereden Çıkıyor?
Peki bu token denen şey tam olarak ne? Eskiden tek tip PAT’lerle uğraşıyorduk. Ama şimdi:
- Klasik PAT’ler
- Fine-grained PAT’ler
- OAuth uygulama token’ları
- GitHub App user-to-server token’ları
- GitHub App refresh token’ları
Bunların hepsi gündemde. Mesela 2019’da kendi projelerimde OAuth ile tümleşik olurken iki kez yanlışlıkla private repo’ya client secret bırakmıştım—şanslıydım, çabucak silip yeniledim. O stres hâlâ aklımda! Yanı “kim görecek ki?” demek safça geliyor bana… Görüyorlar valla!
Bu Token’lar Nasıl Sızıyor?
Bazen dalgınlıkla commit’e giriyor (unut gitsin.gitignore), bazen pipeline ayarı yüzünden tüm dünyaya saçılıyor ya da kod paylaşırken Stackoverflow’a ucundan kaçırıyorsun. Müşteride bankacılık projesinde şu yaşandı (2021): Debug config dosyası production’a merge edildi. İçinde admin API anahtarı vardı. Tam 20 dakikada Google bot indexledi! Baş ağrısı garantili…
Yeni API Ne Değiştiriyor? Pratikte Farkı Ne?
Dürüst olayım; “API ile credential revoke etmek” kulağa teknik gelebilir ama asıl mevzu şu:
Sızan bir token ister klasik PAT olsun ister OAuth—hatta sana ait bile olmayabilir—yeter ki buldun mu hemen API’ye gönderiyorsun ve anında devre dışı kalıyor!
Beni şaşırtan tarafı; yeni sistemde sana ait olmayan repolarda bile bulduğun sızıntıyı topluca bildirebilip kitlesel şekilde kill edebiliyorsun. Geçen hafta test ettim (Mart 2026), sahte birkaç PAT üretip dummy public repo’ya koydum. Diğer hesabımdan revocation API ile yolladığımda saniyesinde hem mail geldi hem de owner’ın güvenlik loguna düştü.
Kritik İşleyiş Detayları — Sahada Neye Dikkat Edilmeli?
Burası can alıcı nokta! Revocation tetiklendiğinde: (ciddiyim)
- Tüm erişim saniyesinde kesiliyor (organizasyon üyelikleri dahil).
- Sahip kişiye veya sistem yöneticisine mail atılıyor.
- Dönüşü yok!
- Tarihe not düşülüyor—security audit log’a giriyor.
E kağıtta “harika”, peki pratikte? Biz Azure tabanlı FinOps uygulamasında app-to-app entegrasyonu deniyorduk, otomasyon kullanıcılarının refresh token’ı sızınca eskiden tek tek elleme ya da destek sürecine kalma derdin vardı. Şimdi bulk endpoint ile binlerce token’ı aynı anda öldürmek mümkün.
Nerede Patlıyor?
Açık açık söyleyeyim — hâlâ bazı köşeler eksik bence. Örneğin; revoked edilen token yerine yeni izin setlerini merkezî deploy etme yöntemi yok henüz. Hele bir de büyük enterprise yapılarda yeniden dağıtım/bildirim süreçleri insan hatasına çok açık oluyor (ki bu çoğu kişinin gözünden kaçıyor)
Sadece Yazılımcılar İçin mi? Hayır!
Zannetmeyin ki bu sadece developer veya DevOps ekibinin meselesi (buna dikkat edin). Güvenlikten sorumlu herkesin konusu aslında: gerçek konusundaki yazımız bu konuya da değinmiştik.
| Kullanıcı Tipi | Neden Önemli? | Sık Karşılaşılan Durumlar |
|---|---|---|
| Junior Developer | Dikkatsizlikle credential commit etmek çok kolay oluyor. | .env dosyasını açıkta bırakmak meşhur hata. |
| Siber Güvenlik Analisti | Sızma testi yaparken açık cred bulunca hızlı aksiyon şart. | Dışarıdan sızdırılmış OAuth secret sık görülüyor. |
| CISO/CIO/IT Lead | Kurum çapında hızlı incident response gerekiyor! | Binden fazla bot hesabının anahtarları ortalıkta dolaşıyor olabilir. |
| Açık Kaynak Bakıcısı | Kendi dışındaki katkıcıların da repoya zarar vermesini önlemeye çalışıyorlar. | Dış PR’da bilmeden credential bırakılmış olabiliyor. |
Küçük Startup vs Kurumsal Dev Yapılar — Senaryo Analizi
Küçük Bir Startup İçin:
Doğrusu, Birkaç kişiyle çalışan butik ekiplerde genelde güvenlik farkındalığı düşük oluyor ya da takvim yoğunluğundan ihmal ediliyor diyelim… Burada avantaj şu; bir sızıntıda az sayıda credential olduğu için revocation’u elle de halledebilirsiniz (şaşırtıcı ama gerçek). Şunu unutmayın—API sayesinde gözden kaçan durumlar sıfırlanıyor gibi hissediyorsunuz, gerçekten kafa rahatlıyor biraz daha! (yanlış duymadınız) Bu konuyla ilgili Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimarı mi? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder’ın Multi-Source Sihri yazımıza bakabilirsiniz.
Kurumsal Düzeyde:
Ama işler büyüdüğünde karışıklık artıyor! En çok da de cross-team shared credential varsa felaket zinciri oluşabiliyor… Geçtiğimiz Eylül (2025), finans sektöründen bir müşteride otomasyon servislerinin kullandığı yüzlerce PAT’in tamamı public kaynakta sızdı ve binlercesini aynı anda revoke ederek facianın önüne geçtik… Tek zor kısım herkese yeni credential süreci anlatmak öldü çünkü bazı ekiplerden epey serzeniş aldık (“Yine mi şifre değişimi?”). Ama faydası tartışmasız iyi öldü.
Neyse, konumuza dönelim…
Peki Ya Kötüye Kullanım Riski? Limitler Nasıl Çalışıyor?
- Saatte max 60 request sınırı var;
- /request’de en fazla 1000 credential bildirimi hakkınız var;
böylece sistemi dengeliyorlar.
Toplu saldırılarda ilk uyarıyı verip sonra engelleyebiliyor.
Evet.
Bizzat denediğimde (Ocak 2026), üçüncü istekte throttle’a yakalandım—error döndü (bizzat test ettim). Fazlasına izin vermedi! Burada önemli detay şu; gereksiz yere farklı hesaplara spam yaparsanız IP’niz bloklanabilir ya da bildiriminiz görmezden gelinebilir… Bu konuyla ilgili Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek yazımıza da göz atmanızı tavsiye ederim.
Mekanik Olarak Nasıl Çalışıyor? Kısaca Kod Örneği:
# Test ortamında örnek!
import requests
tokens = [“gho_abc123…”, “gho_def456…”] # Açığa çıkmış veya risk taşıyan token listesi
url = “https://api.github.com/credential-revocations”
payload = {“credentials”: tokens}
resp = requests.post(url, json=payload)
if resp.status_code == 202:
print(“Revocation başarılı! Bildirım sahibine ulaştı.”)
else:
print(f”Hata oluştu! Status kodu:{resp.status_code}”)
Kendi deneyimde yukarıdaki simple POST ile anlık feedback aldım.
Bildirım gitmesi ayrı güzel — çoğu sistemde mail gecikir diyen çoktu eskiden;
burada gerçekten birkaç saniye içinde ulaşmıştı!
Bazı Gerçekçi Kritikler — Her Şey Güllük Gülistanlık mı?
İşin garibi, Açıkçası hâlâ geliştirilecek alan böl:
- Ekip bazlı raporlamalar kısıtlı — toplu revocation sonrası hangisinin kritik olduğunu analiz etmek güçleşebiliyor;
- Sürekli güncellenen yetki matrislerinde revoked edilen token’a bağlı eski permission zincirleri karmaşa çıkarabiliyor;
- Bazı advanced automation workflow’da revoked edilen kimliği hızla yedekleme/yenileme yolu yok — manuel takip gerekebiliyor;
- Email bildirimi spam filtresine düşerse ilgili kişi habersiz kalabilir…
Sözün özü — %100 garanti hâlâ mümkün değil fakat eskiye göre ışık yılı önde olduğumuz kesin.
En azından “token’im ortada kalır mı?” paranoyası baya azalıyor!
Maalesef tamamen kaygısız olmak şimdilik hayal…
Buyurun.
Kapanışı Birkaç Pratik Tavsiye ile Bağlayalım
- Sistematic olarak open source kod taraması yapan araçlara mutlaka başvurun (mesela truffleHog)—çıkan her sonucu önce manuel kontrol edin;
- Büyük ekiplerde revoke sonrası credential üretimini dokümante etmeyi unutmayın;
- Email bildirimlerini doğru kontrol edin–spam klasörüne düşmemesine dikkat edin;
- Mümkünse CI/CD pipeline’a otomatik credential scanning entegre edin (ben mesela Azure DevOps’taki SecureFiles’i kullandım–başka yazıda detayı var);
- Daha önce yazdığım Zero Trust stratejileriyle ilgili makaleye göz atmayı unutmayın!
Sıkça Sorulan Sorular
Credential Revocation API nedir ve ne işe yarar?
Açığa çıkan veya riske giren GitHub erişim kimlik bilgilerini programatik şekilde iptal etmenizi sağlayan ücretsiz bir API’dır;
klasik PAT dahil pek çok tür destekleniyor–neredeyse komple kapsama sağlıyor diyebilirim!
Tamamen anonim olarak kimlik bilgisi iptal edebilir mıyım?
Evet; authentication istemez ve herhangi kullanıcı sızdırılan cred’i bildirebilir,
rate-limit sınırlamalarına tabidir,
suistimal edilirse ekstra koruma devreye alınabiliyor tabiî…
Kullanıcıya nasıl bildirım gidiyor? Erişim anında mı kesilir?
Erişim iptal olur olmaz token sahibi ana email adresine notification gelir;
organizasyon erişimi de derhal kalkar–geri getirmek mümkün değil!
Sorunun cevabı evet yanı (buna dikkat edin)
Tüm repo sahipleri bundan faydalanabilir mi yoksa özel şartlar var mı?
Evet herkes kullanabilir;
ister kendi reposunda ister başkasının repo’sunda bulunmuş olsun–revocation isteği göndermek serbesttir!
Ekstra prosedür aramayın boşuna…
Kaynaklar ve İleri Okuma
- GitHub Blog – Credential Revocation API duyurusu
- GitHub Docs – Bulk Revoke Credentials endpoint
- Microsoft Learn – Git Secrets Scanning nedir?
- Daha fazla teknik detay isteyenlere kendi deneyimlerimi paylaştığım GitHub Copilot yazımı tavsiye ederim!
- Ayrıca yakın zamanda e-posta güvenliğiyle ilgili özet geçtiğim
Graph API ile E-posta İçeriği Artık O Kadar Esnek Değil: Neler Değişiyor, Kimler Dikkat Etmeli?makalesi de ilginizi çekebilir.
Valla orada enteresan olaylardan bahsettim…
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
