GitHub Credential Revocation API ile Sızıntılara Anında Fren: Yeni Destekler ve Gerçek Hayat Senaryoları -

⏱️ 6 dk okuma📅 28 Mart 2026

Başımıza Geldi: Token Sızıntısı ve Sonrası

Bir sabah kahveyle ekrana bakarken Slack’te bir bildirim 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 oldu. 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! Yani “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. Iç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ü.

💡 Bilgi: Bu işlem authentication istemiyor. Yani herhangi biri saniyesinde harekete geçebilir fakat kötüye kullanımı önlemek için rate limit var—60 istek/saat & maksimum 1000 token/request.

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 merkezi 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 yazımızda 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ıkl… yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için api hakkındaki detaylı rehberimiz 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 oldu çünkü bazı ekiplerden epey serzeniş aldık (“Yine mi şifre değişimi?”). Ama faydası tartışmasız iyi oldu.
Neyse, konumuza dönelim…

Peki Ya Kötüye Kullanım Riski? Limitler Nasıl Çalışıyor?

💡 Bilgi: API herkese açık ama abuse’u engellemek için

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 Zincir… 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ı! Bildirim 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.
Bildirim 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ı hala geliştirilecek alan bol:

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 hala 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 miyim?

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 tabii…

Kullanıcıya nasıl bildirim 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 yani (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

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

makalesi de ilginizi çekebilir.
Valla orada enteresan olaylardan bahsettim…

İçeriği paylaş: