Scanner Raporu Pentest Yerine Geçer mi?

Temel Değerlendirme

Scanner raporu pentest yerine geçmez. Otomatik araçlar bilinen teknik zafiyetleri, yanlış konfigürasyonları ve bazı düşük/orta seviye riskleri hızlıca bulabilir; ancak iş mantığı hatalarını, BOLA/IDOR açıklarını, tenant isolation problemlerini, zincirleme exploit senaryolarını ve gerçek iş etkisini çoğu zaman kanıtlayamaz. Scanner iyi bir başlangıçtır, fakat pentest; bulgunun gerçekten sömürülebilir olup olmadığını, hangi veriye veya sisteme etki ettiğini ve nasıl önceliklendirileceğini gösteren manuel güvenlik doğrulamasıdır.

Scanner Ne İşe Yarar?

Scanner'lar güvenlik programında değerlidir. Özellikle geniş yüzeylerde hızlı kontrol sağlarlar:

Eski dependency veya bilinen CVE
Basit header ve TLS eksikleri
Bazı XSS, SQL injection veya açık dizin riskleri
Default credential veya yanlış konfigürasyon sinyalleri
Public endpoint ve teknoloji envanteri

Bu yüzden "scanner kötüdür" demek doğru değildir. Sorun, scanner çıktısını doğrudan pentest raporu gibi değerlendirmektir. Araç size sinyal verir; pentest bu sinyalin gerçek saldırı etkisini kanıtlar.

Manuel Pentest Neyi Ekler?

Manuel pentestte uzman, uygulamayı ürün gibi kullanır ve saldırgan gibi düşünür. Sadece tekil zafiyete değil, akışın tamamına bakar.

Örneğin bir scanner şu endpoint için kritik bir risk görmeyebilir:

GET /api/invoices/inv_123

Ama manuel testte inv_123 başka tenant'a ait bir fatura ID'siyle değiştirildiğinde veri dönüyorsa bu ciddi BOLA/IDOR bulgusudur. Scanner çoğu zaman bu ilişkiyi bilmez; çünkü hangi faturanın hangi kullanıcıya ait olduğunu iş bağlamı olmadan anlayamaz.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "Scanner critical bulgu yok dedi, güvendeyiz." | İş mantığı ve authorization açıkları scanner tarafından kaçırılabilir. | | "Pentest sadece scanner çalıştırmaktır." | Gerçek pentest exploit kanıtı, etki analizi ve manuel doğrulama içerir. | | "Her scanner bulgusu acildir." | False positive ve düşük iş etkili bulgular önceliklendirilmelidir. | | "WAF varsa pentest gerekmez." | WAF iş mantığı, tenant isolation ve yanlış yetki kararlarını çözmez. |

Karar Tablosu

| İhtiyaç | Scanner | Manuel pentest | |---|---:|---:| | Geniş yüzeyi hızlı tarama | Güçlü | Destekleyici | | Bilinen CVE tespiti | Güçlü | Doğrulayıcı | | BOLA/IDOR testi | Zayıf | Güçlü | | Tenant isolation doğrulama | Zayıf | Güçlü | | İş etkisi ve exploit kanıtı | Sınırlı | Güçlü | | Yönetim için risk önceliği | Sınırlı | Güçlü | | Compliance kanıtı | Duruma bağlı | Güçlü |

Pratik Örnek

Bir e-commerce uygulamasında scanner sepet, kupon ve ödeme akışını "HTTP endpoint listesi" olarak görür. Manuel pentest ise şunları test eder:

Kupon aynı kullanıcı tarafından tekrar tekrar uygulanabiliyor mu?
İade endpointi farklı sipariş ID'siyle çağrılabiliyor mu?
Sepet fiyatı client tarafından değiştirilebiliyor mu?
Admin onayı gerektiren indirim doğrudan API ile geçilebiliyor mu?
Ödeme callback'i yeniden oynatılınca sipariş tekrar onaylanıyor mu?

Bu riskler teknik olarak "injection" olmayabilir ama iş etkisi çok yüksektir.

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda scanner raporuyla yetinmek risklidir:

Ürün SaaS, fintech, e-commerce veya marketplace modeliyle çalışıyor.
API'lerde kullanıcı, tenant, organization veya rol ayrımı var.
Production öncesi müşteri veya yatırımcı güvenliği kanıtı gerekiyor.
Compliance için teknik test kanıtı isteniyor.
Daha önce scanner çıktısı alındı ama ekip neyi önce çözeceğini bilmiyor.

Scanner Raporu Nasıl Kullanılmalı?

Scanner çıktısını çöpe atmak da, doğrudan pentest raporu gibi sunmak da yanlıştır. En sağlıklı kullanım şu şekildedir:

Bulguları teknoloji ve etki alanına göre gruplayın.
False positive olasılığı yüksek bulguları ayırın.
Public exposure ve auth bypass ihtimali olanları öne alın.
Manuel doğrulama gerektirenleri pentest kapsamına ekleyin.
Yönetim raporunda scanner sayısını değil, exploit edilebilir riskleri öne çıkarın.

Bu yaklaşım scanner'ı ucuz sinyal üreticisi, pentesti ise güvenlik kanıtı üreticisi olarak konumlandırır.

Sonraki Adım

Scanner raporunuz varsa onu doğrudan çöpe atmanız gerekmez. En sağlıklı adım, bulguları Web App Pentest Scope Checklist ile yeniden sınıflandırmak ve hangi maddelerin manuel doğrulama istediğini ayırmaktır.

Bu çalışma özellikle şu sorulara cevap verir:

Hangi bulgu gerçekten exploit edilebilir?
Hangi iş akışı test kapsamına mutlaka girmeli?
Hangi alanlar sadece hygiene takibi olarak kalmalı?
Yönetim raporunda hangi riskler önceliklendirilmelidir?

Bu ayrım, güvenlik ekibinin zamanını daha doğru kullanmasını ve satın alma kararında "çok bulgu" yerine "kanıtlanmış risk" konuşmasını sağlar.

Eresus Yaklaşımı

Eresus Security scanner çıktısını reddetmez; onu pentest sürecinin veri noktalarından biri olarak kullanır. Asıl odak, bulgunun exploit edilebilirliği, iş etkisi ve kanıtıdır. Web uygulamanız için sadece "açık listesi" değil, hangi saldırı yolunun gerçekten risk oluşturduğunu görmek istiyorsanız proof-driven web app pentest kapsamını birlikte çıkarabiliriz.

SSS

Scanner raporu hiç mi yeterli olmaz?

İç kontrol, hızlı hygiene taraması veya geniş yüzey takibi için faydalıdır. Ancak kritik uygulamalarda production öncesi tek başına yeterli güvence sağlamaz.

Pentestte scanner kullanılır mı?

Evet. İyi pentestte otomasyon destek olarak kullanılır, fakat raporun değeri manuel doğrulama ve iş etkisi analizinden gelir.

WAF scanner bulgularını kapatır mı?

Bazı teknik payloadları engelleyebilir. Fakat authorization, business logic ve tenant isolation hatalarını tek başına çözmez.

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?