Sızma testi (pentest) raporu masaya geldiğinde ilk tepki çoğu zaman paniktir: onlarca bulgu, "kritik" etiketleri ve yaklaşan bir yeniden test tarihi. Oysa doğru yaklaşımla bu süreç yönetilebilir bir mühendislik projesidir. Bu rehber, raporu teslim alan bir ekibin izlemesi gereken adımları anlatıyor.
1. Adım: Raporu Triage Edin
Her bulgu aynı aciliyette değildir. İlk gün yapılacak iş, bulguları iki eksende sıralamaktır: kritiklik (CVSS puanı / rapordaki seviye) ve kapatma eforu. Tipik dağılım:
- Kritik + düşük efor: hemen (örn. debug modunun açık olması, varsayılan kimlik bilgileri, dizin listeleme)
- Kritik + yüksek efor: fast-track sprintin ana gövdesi (örn. SQL injection'ların parametrik sorguya taşınması, kırık yetkilendirme)
- Orta/düşük: re-test sonrası takvime yayılır — ama rapora "kabul edilen risk" olarak değil, planlanmış iş olarak yazılır
2. En Sık Çıkan Bulgular ve Kapatma Yöntemleri
- SQL Injection: Ham sorguları ORM/prepared statement'a taşıyın; tek tek "escape" yamalarına güvenmeyin. Kapsamı bulmak için kod tabanında ham sorgu taraması yapın — pentest genelde örneklem gösterir, tamamını değil.
- Kırık yetkilendirme (IDOR/BOLA): "Bu kaydı bu kullanıcı görebilir mi?" kontrolünü controller'a değil, merkezi policy katmanına koyun. ID tahmin edilebilirliğini azaltmak (UUID) yardımcıdır ama tek başına çözüm değildir.
- XSS: Çıktı kodlaması (template engine'in otomatik escape'i) + Content-Security-Policy başlığı. Zengin metin alanları için sunucu tarafı HTML sanitizasyonu şarttır.
- Güvensiz oturum yönetimi: HttpOnly/Secure/SameSite cookie bayrakları, oturum yenileme (fixation önlemi), makul timeout.
- Eski bağımlılıklar: Bilinen CVE'li paketler raporların demirbaşıdır. Sürüm yükseltmeyi otomatikleştirin (Dependabot vb.) — tek seferlik yama, altı ay sonra aynı bulguyu geri getirir.
- Bilgi sızıntısı: Hata sayfalarında stack trace, yorumlarda iç bilgi, açık .git/.env dosyaları. Web sunucusu seviyesinde engelleyin.
3. Düzeltmeleri Doğrulanabilir Yapın
Pentest firması re-test'te "kapatıldı" diyebilmek için kanıt ister. Her düzeltme için:
- Bulgu ID'si ile eşleşen commit/PR referansı
- Staging ortamında bulgunun artık tetiklenemediğini gösteren kısa doğrulama notu
- Aynı sınıftaki diğer noktaların da tarandığı bilgisi (örneklem değil, sınıf kapatma)
Re-test'ten kalmanın en sık sebebi, raporda gösterilen örneğin kapatılıp aynı açığın koddaki diğer kopyalarının atlanmasıdır.
4. Süreç ve Takvim Gerçekleri
Orta boy bir uygulamada (15-30 bulgu) kritiklerin kapatılması tipik olarak 5-10 iş günü, tüm raporun kapatılması 3-6 hafta sürer. Takvimi asıl uzatan, kod tabanını tanımayan ekibin öğrenme eğrisidir — bu yüzden düzeltmeyi ya uygulamayı yazan ekip ya da hızlı devralma pratiği olan bir dış ekip yapmalıdır.
5. Kalıcılaştırın
Re-test'i geçmek bitiş çizgisi değildir: CI'a bağımlılık taraması ve statik analiz ekleyin, yılda en az bir pentest planlayın, KVKK tarafında teknik tedbirler dokümanınızı güncelleyin. Güvenlik bir sprint değil, süreçtir.
Sonuç
Pentest raporu bir ceza değil, yol haritasıdır. Triage → kritikler önce → sınıf bazlı kapatma → kanıtlı doğrulama → re-test sırası izlendiğinde süreç öngörülebilir hale gelir. Dar takvimli durumlarda, bu süreci daha önce defalarca yürütmüş bir ekiple çalışmak re-test'i ilk seferde geçmenin en kestirme yoludur.
