Yazılımcı GitHub'a commit'ledi, include ettiği config dosyasında database password var. Public repo'da görülüyor. Hemen ne yapacağım?
Şifreyi database'de değiştirdim, ama GitHub'da history'de hala görülüyor. Silerim mi commit history'yi?
Automated tools ile secret detection yapılabilir mi? Önceden yakalayabilirim?
Gizli Bilgi Sızıntısı Olay Müdahalesi (Secret Leak): Hızlı müdahale kritiktir. Adımlar: 1) ANINDA (1-5 dk): a) Veritabanı şifresini değiştir, b) GitHub repo erişimini iptal et (collaborators'ı kontrol et), c) GitHub secret scanning alert varsa etkinleştir (Settings → Security → Secret scanning), 2) KISA VADE (5-30 dk): a) Git geçmişini temizle (BFG Repo-Cleaner: bfg --delete-files 'config.yml' — geçmişi yeniden yaz), b) Force push (git push --force-with-lease) — DİKKAT: Ekip koordinasyonu gerekli, c) Diğer repoları kontrol et (grep -r password *.git), 3) İNCELEME (30-60 dk): a) Git log kontrolü (kimin push'ladığı, ne zaman), b) Erişim logları (veritabanı): şüpheli giriş denemesi var mı?, c) AWS CloudTrail, GCP Cloud Audit Logs kontrolü, 4) BİLDİRİM: a) Ekibi bilgilendir (git rewrite uyarısı, rebase gerekli), b) Veritabanı ekibi (şifre rotasyonu). Önleme araçları: 1) .gitignore (config dosyalarını hariç tut), 2) ortam değişkenleri (.env, git-ignored), 3) GitHub secret scanning (dahili + üçüncü taraf: TruffleHog, GitGuardian), 4) commit hook'ları (pre-commit framework: commit öncesi gizli bilgileri tespit et), 5) otomatik tarama (CI/CD: commit'leri desenler için tara). Risk azaltma: Veritabanı erişim logları (şüpheli IP, sorgu desenleri), API rate limiting (brute force önleme), Veritabanında MFA (destekleniyorsa).
şifre hemen değiştir databasede. githubda history silmek için bfg-repo-cleaner yada git-filter-branch. teame git rebasein gerekli olduğunu söyle ve secret sccanning aç githubda bfg yıllığında yapması otomatik.....
Gizli veri temizliği: 1) BFG Repo-Cleaner (bfg --replace-text passwords.txt --no-blob-protection repo.git), 2) git-filter-branch (eski, yavaş ama hassas), 3) GitHub secret scanning + otomatik iptal (token ise otomatik iptal), 4) Denetim: git log -S 'password' --all (commit'lerde ara), 5) Bildirim: saldırganların veritabanına erişip erişmediğini kontrol et (sorgu logları, başarısız giriş denemeleri, IP konumu). Önleme uygulaması: pre-commit hook (pre-commit framework + eklentiler: detect-secrets, truffleHog), CI/CD taraması (GitHub Actions: Trivy, GitGuardian), .gitignore şablonu (.env, *.key, config.local.yml). Ekip iletişimi: git geçmişi yeniden yazımı tüm kullanıcıların force-pull + rebase yapmasını gerektirir (koordinasyon yükü).
Doki · Mobil uygulama · 2026
şifre hemen değiştir history silmek icin BFG kullan bir de teame git rebase warning ver. seccret scanning GitHubda aç. pre-commit hook kur (truffleHog detect-secrets) gelecekte catchlemek icin. cI/CD scanlama ekle...
Gizli veri tespiti otomasyonu: 1) Yerel pre-commit (pre-commit framework + detect-secrets eklentisi) 2) CI/CD pipeline (GitHub Actions GitLab CI: TruffleHog GitGuardian), 3) Depo taraması (GitHub native secret scanning GitLab security scanning) 4) Git geçmişi denetimi (git-secrets, git-dumper)... Yanıt otomasyonu: GitHub secret scanning → otomatik iptal (GitHub token'ları icin), ekibi uyar olay kaydı oluştur. En iyi uygulama: .gitignore şablonu (*.key, *.pem .env, config/*local* hariç tut), ortam değişkeni stratejisi (tüm gizli veriler CI/CD env vars'larından asla kodda değil) gizli veri yönetim servisi (HashiCorp Vault, AWS Secrets Manager).
Küçük bir işletmeyim, benim tarafımdan anlatayım. işte asıl mesele rakam değl o rakamın neye göre çıktığı.
Tecrübeyle sabit.
Teşekkür ederim, çok işime yaradı. Unutulmuş test ortamları canlı sistemden daha sık kapı oluyor.
Bu kadar uzattıysam kusura bakmayın.
Kavramları ayıralım, karıştırılıyor. Yanlış alarmı azarlarsanız bi daha kimse bildirim yapmıyor.
Yanlışım varsa düzeltin.
Doki · Marka kimliği · 2026
Benim başımdan geçeni yazayım, belki işinize yarar. kaynak kodda şifre unutulmuş tarafında yapılan hata genelde geri dönülebilir ama pahalı.
Küçük bir deneme ile başlayın, tamamını bir anda bağlamayın. Bu kadar, uzattıysam kusura bakmayın.
Bir ayrım yapmak gerekiyor burada. Bildirim yolu uzunsa bildirim gelmiyor; gelmeyen bildirim geç fark edilen olay demek.
Ben olsam bu yoldan giderdim.
Küçük bir işletmeyim benim tarafımdan anlatayım. Ödeme bilgisi değişikliği asla geldiği kanaldan doğrulanmaz.
Benim başımdan geçeni yazayım belki işinize yarar. Yazılı olmayan her madde, ileride iki tarafın da farklı hatırladığı bir madde.
İnsanlar süreci deil, alışkanlığı savunur. Direnç oradan gelir. Benim görüşüm bu, kesin doğru diye yazmıyorum.
Süreç olarak bakınca tablo değişiyor. Güvenli olmak mutlak değil; saldırıyı uğraşmaya değmez hâle getirmek demek.
Kendi durumunuz farklıysa tabii değişir.