Git History'deki Secret Sızıntısı Nasıl Temizlenir?

Temel Değerlendirme

Git history'ye secret düştüyse ilk yapılacak iş commit'i silmek değil, secret'ı geçersiz kılmak ve kullanım izlerini incelemektir. API key, cloud token, private key veya webhook secret repository geçmişine girdiyse clone edilmiş, fork edilmiş, CI loglarına taşınmış veya üçüncü taraf sistemlerde kullanılmış olabilir. Doğru incident response sırası: revoke veya rotate, erişim loglarını incele, blast radius çıkar, git history temizliğini planla, etkilenen sistemleri doğrula ve tekrar sızıntıyı engelleyen push protection/CI kontrollerini devreye al.

Neden Sadece Commit Silmek Yetmez?

Git dağıtık bir sistemdir. Bir secret bir kez commit edildiyse şu yerlere yayılmış olabilir:

Developer makinelerindeki clone'lar
Fork'lar
CI/CD cache ve logları
Pull request diffleri
Code review bildirimleri
Docker image layer'ları
Paket veya artifact çıktıları

Bu yüzden "commit'i sildik" güvenlik aksiyonu değildir. Secret hâlâ geçerliyse risk devam eder.

İlk 30 Dakika: Triage

İlk amaç panik değil, kontrol sağlamaktır.

Secret türünü belirleyin: cloud key, GitHub PAT, database password, webhook secret, SSH private key.
Geçerli olup olmadığını doğrulayın.
Hangi sistemlere eriştiğini çıkarın.
Kritikse hemen revoke edin veya rotate edin.
İlgili provider loglarını koruma altına alın.
Sızıntının public repo, private repo veya CI loglarından erişilebilir olup olmadığını kontrol edin.

Bu aşamada yazışmalarda secret değerini tekrar paylaşmayın. Incident kanalı açın ama gizli değeri maskeli tutun.

Incident Response Checklist

| Adım | Amaç | Not | |---|---|---| | Revoke/rotate | Mevcut credential'ı etkisiz hale getirmek | Öncelik dosya temizliğinden önce gelir. | | Log review | Kullanılıp kullanılmadığını görmek | Cloud audit, API logs, Git provider logs kontrol edilir. | | Blast radius | Hangi kaynaklara erişebildiğini anlamak | IAM scope ve permission set incelenir. | | History cleanup | Secret görünürlüğünü azaltmak | Rewrite sonrası ekip koordinasyonu gerekir. | | CI/artifact cleanup | Secret'ın build çıktısına taşınıp taşınmadığını görmek | Cache, image, artifact ve logs incelenir. | | Prevention | Tekrarını engellemek | Push protection, secret scanning, branch policy. |

Pratik Örnek

Bir GitHub Actions deploy tokenı yanlışlıkla application config dosyasına commit edildi. Token production cloud ortamında deploy yetkisine sahip.

Riskli yaklaşım:

Commit revert edilir.
PR kapatılır.
Bulgu "çözüldü" denir.

Güvenli yaklaşım:

Token hemen revoke edilir.
Yeni token veya OIDC tabanlı kısa ömürlü kimlik devreye alınır.
Tokenın sızdığı süre boyunca cloud audit logları incelenir.
Workflow hangi branch ve environment'ta bu tokenı kullanıyordu çıkarılır.
Git history cleanup yapılır.
Push protection ve CI secret scanning gate'i eklenir.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "Repo private, sorun yok." | Private repo erişimi olan herkes veya ele geçirilmiş token riski devam eder. | | "Secret test ortamına ait." | Staging verisi, production benzeri entegrasyon veya pivot etkisi olabilir. | | "Revert yaptık, bitti." | Git history ve clone'lar secret'ı tutmaya devam edebilir. | | "Token kullanılmamışsa önemli değil." | Kullanım logu yokluğu her zaman istismar olmadığı anlamına gelmez; logging kapsamı kontrol edilmelidir. |

Kalıcı Önleme

Secret leak incident sonrası sadece temizlik değil, sistem değişikliği gerekir:

Pre-commit hook veya local scanning
Git provider push protection
CI pipeline secret scanning gate
Secret store kullanımı
OIDC veya kısa ömürlü cloud identity
Least privilege IAM
Düzenli token inventory ve rotation
Developer eğitimi ve güvenli örnek config dosyaları

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda incident profesyonel ele alınmalıdır:

Secret production cloud, ödeme, müşteri verisi veya deployment yetkisi taşıyor.
Repo public olmuş veya third-party sistemlere kopyalanmış olabilir.
Tokenın kullanılıp kullanılmadığı net değil.
Çok sayıda repo, fork veya CI artifact etkilenmiş olabilir.
Müşteri veya regülatör bilgilendirme ihtimali var.

Eresus Yaklaşımı

Eresus Security, git secret leak olaylarında yalnızca history temizliği önermez. Credential geçerliliği, cloud/API logları, IAM blast radius, CI/CD exposure ve tekrarını engelleyen DevSecOps kontrollerini birlikte değerlendirir. Secret sızıntınızın gerçek etkisini hızlıca ölçmek ve kalıcı önleme planı çıkarmak için Secret Exposure Review planlayabiliriz.

SSS

Git history temizliği ne zaman yapılmalı?

Secret revoke/rotate edildikten ve loglar koruma altına alındıktan sonra yapılmalıdır. Önce credential etkisiz hale getirilmelidir.

Secret fake ise yine aksiyon gerekir mi?

Fake olduğu doğrulanmalı ve ekip neden gerçek sanılabilecek secret formatı kullandığını gözden geçirmelidir. Test secret stratejisi net olmalıdır.

Public repo sızıntısı private repodan daha mı kritiktir?

Genellikle evet, çünkü erişim çok daha geniştir. Ancak private repo sızıntıları da özellikle production yetkisi taşıyorsa kritik olabilir.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?