SAST, kodu çalıştırmadan analiz eder. Genellikle şu riskleri arar: Injection patternleri Unsafe deserialization Hardcoded bazı değerler Riskli crypto kullanımı Input validation eksikleri Framework güvenlik hataları Bu çok değerlidir ama SAST'ın amacı her secret sızıntısını güvenilir şekilde yönetmek değildir. Secret güvenliği farklı bir operasyon disiplini ister.

Secret Scanning İçin SAST Yeterli mi?

Temel Değerlendirme

SAST, secret scanning için tek başına yeterli değildir. SAST kaynak kodundaki güvenlik açıklarını ve riskli patternleri bulmaya odaklanır; secret scanning ise API key, token, private key, cloud credential ve benzeri gizli değerlerin repository, git history, CI logları ve geliştirme akışına sızıp sızmadığını tespit eder. Bazı SAST araçları secret bulabilir, ancak gerçek secret güvenliği valid credential doğrulama, rotation, revoke, blast-radius analizi ve tekrar sızıntıyı engelleyen pipeline kontrolleriyle tamamlanır.

SAST Ne Yapar?

SAST, kodu çalıştırmadan analiz eder. Genellikle şu riskleri arar:

Injection patternleri
Unsafe deserialization
Hardcoded bazı değerler
Riskli crypto kullanımı
Input validation eksikleri
Framework güvenlik hataları

Bu çok değerlidir ama SAST'ın amacı her secret sızıntısını güvenilir şekilde yönetmek değildir. Secret güvenliği farklı bir operasyon disiplini ister.

Secret Scanning Neyi Farklı Yapar?

Secret scanning, gizli değerlerin nerede sızdığını ve hâlâ geçerli olup olmadığını anlamaya çalışır.

Bakılması gereken yüzeyler:

Aktif branch'ler
Git history
Pull request diffleri
CI/CD logları
Issue ve comment içerikleri
Docker image layer'ları
Terraform state
Developer makinelerinden gelen yanlışlıklar

Bir token bulunduğunda en kritik soru "bu string secret gibi görünüyor mu?" değildir. Kritik soru şudur: Bu credential geçerli mi, hangi sisteme erişiyor, ne kadar süre açık kaldı ve kullanıldı mı?

Karşılaştırma Tablosu

| Alan | SAST | Secret scanning | |---|---|---| | Ana amaç | Kod zafiyetlerini bulmak | Gizli değer sızıntısını bulmak | | Git history analizi | Sınırlı olabilir | Kritik gereklilik | | Valid credential kontrolü | Genellikle yok | Olmalı | | Rotation workflow | Kapsam dışı | Temel süreç | | CI/CD gate | Destekleyebilir | Zorunlu kontrol | | False positive yönetimi | Kod bağlamına göre | Pattern + doğrulama + allowlist | | Incident response | Dolaylı | Doğrudan ilişkili |

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "SAST çalışıyor, secret scanning'e gerek yok." | SAST secret operasyonunu uçtan uca yönetmez. | | "Secret test token ise önemli değil." | Test tokenları bazen gerçek sistemlere veya staging verisine erişir. | | "Commit silinirse risk biter." | Secret clone edilmiş, loglanmış veya kullanılmış olabilir. | | "Private repo ise sorun değil." | İç tehdit, token hırsızlığı ve yanlış erişim private repoda da mümkündür. |

Pratik Örnek

Bir developer yanlışlıkla cloud deploy tokenını .env.example içine koydu. SAST bunu hardcoded secret olarak işaretleyebilir. Fakat DevSecOps açısından süreç burada bitmez:

Token geçerli mi doğrulanır.
Hangi cloud kaynaklarına eriştiği çıkarılır.
Token revoke edilir veya rotate edilir.
Kullanım logları incelenir.
Git history ve fork/clone riski değerlendirilir.
Push protection ve CI secret scanning gate'i eklenir.

Bu adımlar olmadan bulguyu "fixed" kapatmak sadece dosyadan string silmektir.

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda secret scanning mimarisi ayrı ele alınmalıdır:

CI/CD pipeline production'a deploy edebiliyor.
Cloud, ödeme, SMS/e-posta veya AI provider tokenları kullanılıyor.
Çok sayıda repo ve ekip var.
Git history'de eski secret geçmişi olabilir.
Müşteri veya compliance denetimi credential yönetimi kanıtı istiyor.

Minimum DevSecOps Kontrol Seti

Secret scanning programı başlatırken ilk hedef her şeyi mükemmel yapmak değil, en riskli sızıntı yollarını kapatmaktır:

Repository push protection aktif olmalı.
Pull request diffleri taranmalı.
Git history periyodik kontrol edilmeli.
CI loglarında maskelenmeyen secret kalmamalı.
Cloud tokenlar kısa ömürlü kimliğe taşınmalı.
Secret bulunduğunda rotation sahibi belli olmalı.
False positive yönetimi dokümante edilmeli.

Bu kontrol seti olmadan araç kurmak alarm üretir ama güvenlik programı oluşturmaz.

Sonraki Adım

Secret scanning aracını kurduktan sonra asıl değer, sızıntı anında ekibin ne yapacağını bilmesidir. DevSecOps Secret Leak Response Checklist, "secret bulunduğunda ilk 30 dakikada ne yapılmalı?" sorusunu pratik bir sıraya bağlar.

Bu kontrol seti özellikle şu kararları netleştirir:

Secret gerçekten canlı mı?
Hangi servis veya cloud hesabı etkileniyor?
Rotation kimin sorumluluğunda?
Git history temizliği gerekiyor mu?
CI/CD loglarında aynı secret tekrar görünüyor mu?

Eresus Yaklaşımı

Eresus Security, DevSecOps review süreçlerinde secret scanning'i yalnızca araç kurulumu olarak görmez. Repo, git history, CI/CD logları, secret store, cloud IAM ve rotation süreçlerini birlikte değerlendirir. Amacımız secret bulununca ne yapılacağını, tekrar sızmaması için pipeline'ın nasıl davranacağını ve production etkisinin nasıl ölçüleceğini netleştirmektir. DevSecOps Secret Leak Response Checklist ile ilk kontrol setini çıkarabiliriz.

SSS

Secret scanning hangi araçla yapılmalı?

Araç seçimi repo sayısı, CI/CD platformu, cloud provider ve doğrulama ihtiyacına göre değişir. Önemli olan aracın workflow'a gate ve incident response olarak bağlanmasıdır.

False positive çok olursa ne yapılmalı?

Allowlist, test secret formatları, valid credential doğrulama ve risk bazlı triage uygulanmalıdır. Tüm bulgular aynı öncelikte ele alınmamalıdır.

Secret bulunduğunda ilk adım nedir?

Dosyadan silmek değil, credential'ı revoke/rotate etmek ve kullanım loglarını incelemektir.