DevSecOps Secret Leak Response Checklist
Git history, CI logları, paketler, container’lar veya geliştirici makinelerinde secret sızıntısı bulan ekipler için müdahale checklist’i.
Silindiği halde log, fork, cache veya paketlerde geçerli kalan secret’lar.
Sızan kimlik bilgilerinin kullanılıp kullanılmadığına dair kanıt eksikliği.
Aşırı production yetkisine sahip uzun ömürlü CI/CD token’ları.
Kimler İçin
Sızan token veya kimlik bilgilerine müdahale eden DevOps ekipleri.
Kod temizliği ile olay müdahaleyi ayıran güvenlik ekipleri.
CI/CD içinde tekrar eden secret sızıntılarını azaltan mühendislik liderleri.
Kullanım Alanları
Açığa çıkan kimlik bilgilerini triage edin, erişimi iptal edin, secret’ları döndürün ve etki alanını doğrulayın.
Git history temizliğini tüm çözüm sanmadan doğru şekilde yönetin.
Gelecek sızıntılar için pull request ve pipeline gate’leri kurun.
İlgili İçerikler
Git History'deki Secret Sızıntısı Nasıl Temizlenir?
Git geçmişine düşen API key, cloud token veya private key sızıntısında revoke, rotate, log inceleme ve kalıcı önleme adımlarını anlatıyoruz.
Secret Scanning İçin SAST Yeterli mi?
SAST, secret scanning, git history, valid credential doğrulama ve incident response arasındaki farkları DevSecOps bakışıyla açıklıyoruz.
CI/CD Secret Rotation ve DevSecOps
CI/CD pipeline içinde uzun ömürlü secret kullanımının neden kritik risk olduğunu ve kısa ömürlü kimliklerle nasıl azaltılacağını inceliyoruz.
İlgili Advisory İçerikleri
Sık Sorulan Sorular
Secret’ı Git’ten silmek yeterli mi?
Hayır. Kimlik bilgisi iptal edilmeli veya döndürülmeli, kullanım logları incelenmeli ve bağlı sistemler kontrol edilmelidir.
İlk 30 dakikada ne yapılmalı?
Secret tipi belirlenmeli, iptal edilmeli veya kısıtlanmalı, kanıt korunmalı, erişim logları kontrol edilmeli ve rotasyon/doğrulama sahipleri atanmalıdır.
Bu saldırı yüzeyini birlikte doğrulayalım mı?
Bu iş akışı için kapsam, tehdit modelleme ve remediation öncelikleri üzerine Eresus Security ile görüşün.
Eresus ile Görüş