API Anahtarı GitHub'a Düştüyse Önce Ne Yapılır?

---

Bir yapılandırma dosyasını aceleyle depoya eklediniz. Birkaç saat sonra dosyayı açıp bakınca içinde bir servis anahtarının düz metin olarak durduğunu görüyorsunuz. İlk refleks genelde aynı oluyor: dosyayı silip yeni bir işleme geçmek.

O refleks yetmiyor, çünkü anahtar depo geçmişinde duruyor. Aşağıda ilk yapılması gereken işin ne olduğunu, GitHub'ın sızıntıyı kendi başına nasıl aradığını, geçmişi yeniden yazmanın bedelini ve temizlikten sonra bile erişilebilir kalan yerleri GitHub ile Git'in kendi belgelerinden çıkarıyoruz.

İlk iş temizlik değil, iptal​

GitHub'ın hassas veri kaldırma belgesi sıralamayı tersine çeviriyor: kaldırmanız gereken veri bir parola, jeton ya da kimlik bilgisiyse ilk adım o sırrı iptal etmek veya döndürmek oluyor (GitHub'ın hassas veri kaldırma belgesi).

Gerekçe basit: sır iptal edildiğinde ya da döndürüldüğünde artık erişim için kullanılamıyor. Belge bunun çoğu zaman sorunu çözmeye yettiğini, geçmişi yeniden yazma adımlarının gerekli olmayabileceğini açıkça söylüyor.

Sıralama böyle kurulduğunda kazanılan şey zaman. Geçmiş temizliği saatler sürebilen ve ekipçe koordinasyon isteyen bir iş; anahtarın geçersiz kılınması ise dakikalar içinde yapılabiliyor.

Anahtarın en baştan nereye konmaması gerektiğini API anahtarını istemci tarafında saklamanın riskini anlattığımız yazıda ele almıştık.

GitHub sızıntıyı kendisi arıyor​

Sır taraması, deponuzun bütün dallarındaki Git geçmişini sabit kodlanmış kimlik bilgileri için tarıyor: API anahtarları, parolalar, jetonlar ve bilinen diğer sır türleri kapsamda (GitHub'ın sır taraması belgesi).

Tarama yalnız kod dosyalarıyla sınırlı değil. Belgeye göre şunlar da otomatik taranıyor:

• Sorunlar: Açık ve kapalı sorunların başlıkları, açıklamaları ve yorumları.
• Çekme istekleri: Başlık, açıklama ve yorumlar.
• Tartışmalar ve wiki sayfaları: Aynı kapsamda taranıyor.
• Gizli gist'ler: Bunlar da tarama kapsamında.

Yeni sır türleri eklendikçe depolar belirli aralıklarla yeniden taranıyor. Bir sızıntı yakalandığında deponun güvenlik sekmesinde uyarı oluşuyor ve belge uyarıyı alır almaz kimlik bilgisini döndürmenizi söylüyor.

Not' Alıntı:

Aynı belge, geçmişten sır silmenin zaman alıcı olduğunu ve kimlik bilgisini zaten iptal ettiyseniz çoğu zaman gereksiz kaldığını yazıyor.

Genişletmek için tıkla ...

İki yardımcı mekanizma daha var. Geçerlilik denetimleri, bulunan sırrın hâlâ etkin olup olmadığını sırrı veren servise sorarak önceliklendirme yapmanızı sağlıyor. İş ortağı programında ise tanınan bir sağlayıcının sırrı bulunduğunda durum doğrudan sağlayıcıya bildiriliyor; bu sırlar depo uyarılarında görünmüyor.

Geçmişi yeniden yazmanın bedeli​

Temizliğe karar verdiyseniz neye imza attığınızı bilmek gerekiyor. GitHub belgesi yan etkileri tek tek sayıyor.

Yeniden bulaşma riski başta geliyor. Yeniden yazma öncesinden kopyası olan bir geliştirici çekip gönderdiğinde hassas veri geri geliyor; kopyayı atıp yeniden almak ya da birkaç adımla temizlemek gerekiyor.

İşleme karmaları değişiyor. Sırrı getiren işlemenin ve ondan sonraki bütün işlemelerin karmaları yenileniyor, karmaların sabitliğine dayanan her otomasyon bozuluyor. İşlemenin ne kaydettiğini işleme kavramını anlattığımız yazıda bulabilirsiniz.

Yan etkiler bununla bitmiyor: zorla göndermeyi engelleyen dal korumalarının geçici olarak kapatılması gerekiyor, kapanmış çekme isteklerinin fark görünümü bozuluyor, açık çekme isteklerindeki yorumlar geçersizleşebiliyor ve işleme ile etiket imzaları düşüyor. Belge, dosyaları kaldırmadan önce açık çekme isteklerini birleştirmeyi ya da kapatmayı öneriyor.

Silseniz bile erişilebilir kalan yerler​

Yalnız geçmişi yeniden yazıp zorla gönderirseniz sırrı taşıyan işlemeler başka yerlerden erişilebilir kalıyor: deponuzun kopyalarında ve çatallarında, karmaları üzerinden GitHub'daki önbelleğe alınmış görünümlerde ve onlara atıf yapan çekme isteklerinde.

Başkalarının kopyalarındaki veriyi silemiyorsunuz; onlara temizlik yönergelerini iletmeniz gerekiyor. Önbelleğe alınmış görünümler ve çekme isteklerindeki atıflar için GitHub destek portalına başvurulabiliyor, ancak belge desteğin yalnız riskin kimlik bilgisi döndürülerek giderilemediği durumlarda yardım ettiğini belirtiyor.

Çatallar ayrı bir başlık. Sırrı getiren işleme bir çatalda duruyorsa orada erişilebilir kalıyor ve GitHub çatal sahiplerinin iletişim bilgisini vermiyor.

Hangi araçla temizlenir?​

Git'in kendi belgesi eski aracı açıkça önermiyor: filter-branch komutunun, amaçlanan yeniden yazmayı fark edilmesi güç biçimde bozabilen çok sayıda tuzağı olduğu, bu güvenlik ve başarım sorunlarının geriye dönük uyumlu biçimde düzeltilemeyeceği ve kullanımının önerilmediği yazıyor. Belge yerine filter-repo gibi bir aracı işaret ediyor (Git'in filter-branch belgesi).

GitHub tarafındaki yönergeler de aynı aracı kullanıyor ve hassas veri kaldırma bayrağını taşıyan en az 2.47 sürümünü şart koşuyor.

Yanlış giden bir işlemeyi geri almanın günlük yolları bundan ayrı; yanlış işlemeyi geri alma yollarını karşılaştırdığımız yazı o tarafı anlatıyor.

Sık Sorulan Sorular​

Dosyayı silip yeni işleme göndersem yetmez mi?
Yetmiyor. Dosya güncel sürümden kalkıyor ama sır geçmişte duruyor ve karması üzerinden erişilebiliyor.

Anahtarı döndürdüm, geçmişi de temizlemeli miyim?
Belge bunun çoğu zaman gereksiz olduğunu söylüyor. İptal edilen sır erişim için kullanılamıyor.

Sır taraması özel depomda da çalışır mı?
Genel depolarda ücretsiz ve otomatik çalışıyor. Kuruluşa ait özel ve dâhili depolarda Secret Protection etkinleştirilmiş Team ya da Enterprise Cloud planı gerekiyor.

Çataldaki kopyayı ben silebilir miyim?
Hayır. Çatal sahibiyle iletişime geçmeniz gerekiyor ve GitHub bu kişilerin iletişim bilgisini paylaşmıyor.

Özetle​

Depoya düşen bir anahtarda sıralama şu: önce sırrı iptal edin ya da döndürün, sonra temizliğin gerçekten gerekip gerekmediğine karar verin. Sır taraması geçmişi bütün dallarda, üstelik sorun ve çekme isteği yorumlarını da kapsayarak tarıyor; geçerlilik denetimleri hangi sırrın hâlâ etkin olduğunu söylüyor. Geçmişi yeniden yazmaya karar verirseniz değişen karmaları, bozulan otomasyonu, düşen imzaları ve yeniden bulaşma riskini baştan hesaba katın. Temizlikten sonra bile çatallar, kopyalar ve önbelleğe alınmış görünümler açık kalabiliyor. Eski filter-branch aracını değil, güncel filter-repo aracını kullanın ve asıl kalıcı çözümün sırrı depodan uzak tutmak olduğunu unutmayın.

Deponuzda sabit kodlanmış bir kimlik bilgisi kaldı mı, en son ne zaman kontrol ettiniz?

Güncelleme: 19 Eylül 2026. GitHub'ın hassas veri kaldırma ve sır taraması belgeleri ile Git'in filter-branch belgesi kontrol edildi.

---