Sızma Testi Öncesi Hazırlık: Kapsamı Doğru Yazmanın 7 Kuralı

Özet

Sızma testlerinin çoğu sahada değil, masada kaybedilir. Kapsam muğlak yazılmışsa test ekibi vaktini izin kovalamakla harcar, kritik sistemler kapsam dışında kalır ve rapor “bilinen şeylerin” listesine dönüşür. İyi bir pentest, test başlamadan önceki iki haftada kazanılır.

Aşağıdaki 7 kural, yüzlerce testten damıttığımız hazırlık listesidir. İster Pentexa ile ister başka bir ekiple çalışın, bu listeyi uyguladığınızda aldığınız hizmetin kalitesi belirgin şekilde artar.

Yazar: Aras Akyasan · Eylül 2026 · 8 dk okuma

1. Envanterle başlayın: bilmediğiniz varlığı kimse koruyamaz

Kapsam belgesinin ilk eki tam varlık listesidir: alan adları, IP blokları, mobil uygulamalar, API uçları ve üçüncü parti entegrasyonlar. Unutulan bir alt alan adı, testin en verimli bulgusunu da teste de sokmaz — saldırganın ilk bakacağı yer orasıdır.

Pratik yöntem: Certificate Transparency kayıtlarından alt alan adlarınızı çıkarın, bulut konsollarındaki herkese açık kaynakları listeleyin, satın alma sonrası eklenen sistemleri eklemeyi unutmayın.

2. Test derinliğini seçin: beyaz, gri veya kara kutu

Beyaz kutu testte ekip kaynak kodu ve mimari dokümantasyonla çalışır; mantık hataları ve yetkilendirme zafiyetleri daha hızlı bulunur. Gri kutu, standart kullanıcı yetkileriyle gerçekçi senaryoyu verir. Kara kutu ise tamamen dışarıdan bakışı simüle eder ama aynı sürede daha az derinlik sağlar.

Tavsiyemiz: ilk testiniz beyaz veya gri kutu olsun. Amaç şov değil, risk kapatmaksa test ekibine bilgi vermek her zaman kazandırır.

3. Yasak bölgeleri yazılı hale getirin

Üretimde dokunulmayacak sistemler, yıkıcı testlerin (ör. hizmet kesme, veri silme denemeleri) sınırları ve sosyal mühendislik kapsamı baştan yazılmalıdır. Sözlü mutabakat, olay anında hatırlanmaz.

İyi kapsam belgesi “neler yasak” kadar “yasak ihlal edilirse kimin aranacağını” da içerir: 7/24 ulaşılabilir bir irtibat kişisi şarttır.

4. Test hesaplarını ve erişimleri hazır edin

Her rol için ayrı test hesabı açın: standart kullanıcı, yönetici, salt-okunur ve — varsa — iş ortağı rolü. Yetki seviyeleri arası geçiş testleri (IDOR, dikey/yatay yetki yükseltme) ancak böyle sağlıklı yapılır.

Çok faktörlü doğrulama test hesaplarında engel oluyorsa test süresi için istisna tanımlayın ya da TOTP tohumunu ekiple paylaşın. VPN, IP izin listesi ve WAF istisnalarını test gününden önce doğrulayın.

5. Zaman penceresini gerçekçi planlayın

Aktif testler için mesai saatleri içinde bir pencere belirleyin; ekibiniz izleyebilsin, anormal bir durumda müdahale edebilsin. Kritik sistemlerde ilk taramayı düşük trafik saatine almak iki tarafı da rahatlatır.

Teste aynı anda yük testi veya büyük release denk getirmeyin. Bulguların hangi değişikliğe ait olduğu belirsizleşir, retest çöpe gider.

6. Kapanışı baştan tanımlayın: retest olmadan iş bitmez

Teklifte “retest dahil mi, kaç tur?” sorusunun cevabı yazılı olsun. Bulgu kapatıldıktan sonra aynı vektörün tekrar test edilmesi, pentest yatırımının geri dönüşüdür.

Rapor formatını da önden konuşun: yazılımcının kapatabileceği netlikte adım adım tekrar, yöneticinin anlayacağı risk önceliği. PoC'siz bulgu, kapatılamayan bulgudur.

7. İki test arasını boş bırakmayın

Pentest bir fotoğraftır; kod her gün değişir. Yılda bir-iki test yaptırıp arayı boş bırakan ekipler, bulguları hep aynı yerden yer. Sürekli dinamik tarama (DAST) ile her release'i otomatik süpürmek, bir sonraki penteste tertemiz girmek demektir.

Bizim önerdiğimiz ritim: sürekli otomatik tarama + yılda en az bir derin manuel pentest. Biri süpürür, diğeri derinleşir.

• ✓Her release'te otomatik DAST taraması
• ✓Kritik değişiklikte hedefli ara test
• ✓Yılda 1–2 derin manuel pentest + retest

Son söz

Bu listeyi uygulayan bir ekip, testten iki kat verim alır — çünkü test ekibi vaktini izin ve erişim kovalamak yerine gerçekten saldırmaya harcar.

Hazırlık aşamasında takıldığınız bir madde olursa bize yazın; teklif vermesek bile kapsam belgenizi birlikte gözden geçiririz.

Sık sorulan sorular

İlgili hizmetler

Diğer yazılar