1. Penetrasyon Testi Nedir, Ne Değildir?
Pentest; belirli bir kapsam içinde, sistemin gerçek saldırı senaryolarına karşı dayanıklılığını test etmeyi amaçlar. Ancak pentest “her şeyi bulur” ya da “güvenliği garanti eder” değildir. Pentest’in değeri; kapsam ve yöntem doğru seçildiğinde ortaya çıkar.
Penetrasyon testi nedir, ne zaman yapılmalı?
Penetrasyon testi; web, API, mobil veya altyapı gibi belirlenmiş yüzeylerde güvenlik açıklarını gerçekçi saldırı yöntemleriyle test etmektir. Büyük release’ler, yeni rezervasyon/ödeme akışları, entegrasyon değişiklikleri veya yılda en az bir kez (risk seviyesine göre daha sık) yapılması iyi bir çerçevedir. Ancak en iyi sonuç, pentest’i sürekli testlerle tamamlamaktır.
“Ne değildir?” (kritik netleştirme)
- •Pentest, sürekli bir kontrol mekanizmasının yerine geçmez
- •Pentest raporu “geçti/kaldı” sertifikası değildir
- •Pentest, iyi scope olmadan “bulgu çöplüğü” üretebilir
- •Pentest, remediation planı olmadan değerini kaybeder
☑ Mini Check : Pentest readiness
- •Scope yazılı mı (web/API/mobil/altyapı)?
- •Kritik akışlar listelendi mi (booking/portal/payment)?
- •Test ortamı ve izinler net mi (grey/white box)?
- •Bulguların sahibi ve kapanma SLA’ı var mı?
- •Re-test (doğrulama) planı var mı?
Ne yapmalıyım?
- • Scope’u iş kritikliğiyle belirle (otel rezervasyon, B2B portal/API).
- • Pentest’i “program”a bağla: fix ve re-test zorunlu olsun.
- • Tek seferlik raporu sürekli testlerle tamamla.
- • Bulguları bakım-destek sprintlerine bağla (Internal link: /tr/yazilim/bakim-ve-destek).
2. Black/Gray/White Box Yaklaşımlar
Testin başarısı, “hangi bilgiyle test ediliyor?” sorusuna bağlıdır. Üç yaklaşım da değerlidir; doğru yerde kullanmak gerekir.
Black box
Saldırganın dışarıdan gördüğü kadar bilgiyle test edilir. Dış yüzey risklerini (web/API) iyi yakalar; iç kontrol ve role-based riskleri kaçırabilir.
Gray box
Sınırlı bilgiyle (ör. test hesabı, temel mimari) test edilir. Otel/B2B’de pratikte en dengeli yaklaşımdır: hem gerçekçilik hem verim.
White box
Kod ve mimari bilgisiyle derin test yapılır. Kritik modüllerde (ödeme, entegrasyon, auth) yüksek değer üretir; daha çok efor ister.
☑ Mini Check : Yaklaşım seçimi
- •Dış saldırı yüzeyi için black/gray planlandı mı?
- •Yetki ve rol hataları için gray/white var mı?
- •Kritik modüller için white box ayrıldı mı?
- •Test hesapları ve data maskeleme hazır mı?
- •KVKK açısından test verisi kontrollü mü? (Internal link: /tr/raporlama/kvkk-veri-guvenligi)
Ne yapmalıyım?
- • Dış yüzey: black/gray; kritik modül: white ile tamamla.
- • Yetkilendirme (RBAC) senaryolarını scope’a yaz.
- • Test verisini maskele; log ve çıktıların KVKK uyumunu kontrol et.
- • Bulguları “rol/akış” bağlamında raporlat.
3. Yıllık/Peryodik Pentest vs Sürekli Güvenlik Testleri (DAST, SAST, SCA)
Burada amaç; pentest ve sürekli testleri rakip değil, tamamlayıcı görmek. Pentest, karmaşık saldırı senaryolarını ve business logic açıklarını yakalar. Sürekli testler ise “günlük değişikliklerde” güvenliği korur.
Pentest ile DAST/SAST/SCA arasındaki farklar nelerdir?
- •Pentest: uzman odaklı, senaryo derinliği yüksek; periyodik yapılır.
- •DAST: çalışan uygulamayı test eder; OWASP Top 10 gibi riskleri otomatik tarar.
- •SAST: kodu analiz eder; commit/PR aşamasında erken yakalama sağlar.
- •SCA: dependency/lockfile ve üçüncü parti bileşenleri tarar; supply chain risklerini azaltır.
En iyi model; pentest’i periyodik, DAST/SAST/SCA’yı sürekli işletmektir.
CI/CD entegrasyonu (security-as-a-process)
- •PR açılır → SAST/SCA çalışır → riskli bulgu varsa gate
- •Staging’e çıkılır → DAST koşar → kritik bulgu varsa release blok
- •Üretim sonrası → hafif DAST/monitoring → regresyon yakalama
Veri noktası (soft)
Düzenli pentest + sürekli test programı olan kurumlarda, kritik zafiyetlerin üretimde bulunma süresinin çoğu senaryoda belirgin biçimde kısaldığı gözlemlenir (yani “bulgu yaşlanmadan” kapanır).
☑ Mini Check : Sürekli test olgunluğu
- •SAST PR aşamasında çalışıyor mu?
- •SCA lockfile/dependency ile bağlı mı?
- •DAST staging’de düzenli koşuyor mu?
- •Kritikte release gate var mı?
- •Bulgular ticket’a dönüp SLA ile kapanıyor mu?
Ne yapmalıyım?
- • SAST/SCA’yı PR gate yap; küçükten başla, sonra sıkılaştır.
- • DAST’ı staging’de düzenli koştur; OWASP Top 10 kapsa.
- • Release gate: “kritik bulgu varsa çıkma.”
- • Fix ve re-test döngüsünü standardize et.
4. Otel ve B2B İçin Test Kapsamı ve Takvim
Kapsam, doğrudan iş akışlarına göre belirlenmeli. “Her şeyi test edelim” gerçekçi değildir; “kritik akışları” garanti altına almak hedef olmalıdır.
Otel kapsam önerisi
- •Web: rezervasyon arama/availability, checkout/ödeme, kampanya akışları
- •API: PMS/OTA entegrasyon uçları, call center entegrasyonları
- •Entegrasyon: PMS/Channel Manager token/key güvenliği (SCA + secrets kontrol)
- •DAST: OWASP Top 10, rate limit, auth bypass testleri
B2B kapsam önerisi
- •Portal: login, RBAC/role escalation, oturum yönetimi
- •API: auth, rate limit, tenant isolation (multi-tenant ise)
- •Rapor/export: kaynak sömürme (resource exhaustion) ve yetki kontrolleri
- •SCA: entegrasyon SDK’ları, supply chain riskleri
Otel ve B2B siteleri için güvenlik test kapsamı nasıl belirlenir?
Önce kritik iş akışlarını ve veri türlerini (rezervasyon/ödeme, portal/CRM) listeleyin. Sonra yüzeyleri ayırın: web, API, mobil, altyapı ve entegrasyonlar. Sürekli testlerde SAST/SCA’yı tüm repo’ya, DAST’ı staging’de kritik endpoint’lere odaklayın; pentest’te ise business logic ve rol/akış açıklarına derinleşin.
Örnek takvim (çerçeve)
- •SAST/SCA: her PR / her build
- •DAST: staging’de günlük/haftalık, major release sonrası zorunlu
- •Pentest: yılda 1 (yüksek riskte 2) + büyük değişiklik sonrası ek test
- •Re-test: her kritik bulgu kapanışında
☑ Mini Check : Kapsam & takvim net mi?
- •Kritik akışlar: booking/portal/export listelendi
- •Web/API ayrı risk profiliyle ele alındı
- •SAST/SCA PR’da; DAST staging’de
- •Pentest periyodu + tetikleyiciler yazılı
- •Re-test zorunlu
Ne yapmalıyım?
- • Takvimi release ve bakım takvimiyle senkronla.
- • Otel: sezon öncesi; B2B: büyük release öncesi risk artır.
- • Kapsamı “kritik akış” odaklı tut; gürültüyü azalt.
- • Bulguları bakım-destek sprintlerine bağla.
5. Test Türleri ve Önerilen Frekans
| Test | Araç/yaklaşım | Nerede çalışır? | Frekans | Gate? |
|---|---|---|---|---|
| SAST | ___ | PR/CI | ___ | E/H |
| SCA | ___ | PR/CI | ___ | E/H |
| DAST | ___ | Staging | ___ | E/H |
| Pentest | Black/Gray/White | Prod benzeri | ___ | — |
| Re-test | ___ | Staging/Prod | Her kritik bulguda | Evet |
6. Bulguların Önceliklendirilmesi ve Remediation Süreci
En olgun modelin bile başarısı, bulguların kapanma hızına bağlıdır. Burada hedef; “rapor okuma” değil “test→fix cycles” kurmaktır.
Risk önceliği matrisi
- •Etki (data/giriş/ödeme)
- •Maruziyet (internete açık mı?)
- •Exploit edilebilirlik (kolay mı?)
- •İş kritikliği (rezervasyon/portal)
Pentest bulgularını nasıl önceliklendirip kapatmalıyım?
Önce internete açık ve iş kritik akışları etkileyen bulguları (auth bypass, injection, yetki yükseltme) kapatın. Ardından yüksek riskli dependency ve misconfig bulgularını ele alın. Her bulgu için owner, hedef tarih ve doğrulama (re-test) şart olmalı; kapanış, sadece “code merge” değil “yeniden test” ile onaylanmalıdır.
Fark yaratan mini bölüm (Competitor Gap): “Yılda bir rapor” yerine yaşayan program
TR’de pentest çoğu zaman yılda bir PDF rapor olarak kalır. Olgun modelde ise:
- •Bulgu → ticket → sprint → fix → re-test → kapanış
- •Sürekli testler yeni bulguyu “erken” yakalar
- •Kapanış metrikleri (kritik bulgu yaşlanması) izlenir
☑ Mini Check : Remediation döngüsü
- •Bulgu sahibi (owner) atanıyor mu?
- •Risk SLA (kritik/önemli) var mı?
- •Fix sonrası re-test zorunlu mu?
- •Kapanış metrikleri raporlanıyor mu?
- •KVKK teknik tedbir kanıtı olarak kayıt tutuluyor mu? (Internal link: /tr/raporlama/kvkk-veri-guvenligi)
Ne yapmalıyım?
- • Bulgu SLA’larını yaz (kritik=çok hızlı, önemli=planlı).
- • Her kritik bulgu için re-test zorunlu yap.
- • Bakım-destek sprint planına bağla (Internal link: /tr/yazilim/bakim-ve-destek).
- • Programı 365 günde bir tehdit modeline göre kalibre et.
7. Pentest + CI/CD Entegre Sürekli Güvenlik Testi Planlama Şablonunu İndir
Pentest + CI/CD Entegre Sürekli Güvenlik Testi Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon; otel ve B2B projelerinde penetrasyon testini periyodik olarak planlarken, DAST/SAST/SCA kontrollerini CI/CD’ye entegre eden “sürekli güvenlik testi” modelini kurmak için hazırlanmıştır. Bulguların risk önceliğine göre sprint bazlı kapanmasını ve her kritik bulgunun re-test ile doğrulanmasını standardize eder.
Kim Kullanır?
Güvenlik lideri, DevOps/Backend lead, QA/Release sorumlusu, ajans teknik yöneticisi.
Nasıl Kullanılır?
- Kapsamı ve kritik akışları (booking/portal/API) listeleyin.
- DAST/SAST/SCA’yı CI/CD gate’lerine bağlayıp frekansları yazın.
- Bulgu SLA’larını, remediation sprint’ini ve re-test akışını planlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kapsam ve kritik akışlar yazıldı
- ▢ ✅ SAST/SCA PR gate’e bağlandı
- ▢ ✅ DAST staging’de düzenli
- ▢ ✅ SLA + owner + re-test net
- ▢ ✅ Takvim release/bakım döngüsüyle uyumlu
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
- •Kapsam ve kritik akışlar yazıldı
- •SAST/SCA PR gate’e bağlandı
- •DAST staging’de düzenli
- •SLA + owner + re-test net
- •Takvim release/bakım döngüsüyle uyumlu
Bir Sonraki Adım
Periyodik pentest’i DAST/SAST/SCA ile birleştirip bulguları sprint bazlı kapatmak isteyen otel ve B2B ekipleri için.
Sık Sorulan Sorular
Penetrasyon testi nedir, ne zaman yapılmalı?▾
Pentest ile DAST/SAST/SCA arasındaki farklar nelerdir?▾
Otel ve B2B siteleri için güvenlik test kapsamı nasıl belirlenir?▾
Pentest bulgularını nasıl önceliklendirip kapatmalıyım?▾
Yılda bir pentest yaptırıyoruz, yeterli mi?▾
İlgili İçerikler