Sızma Testi Kaç Gün Sürer? Süreyi Etkileyen 8 Değişken

Bir kurum yeni web application'ı için sızma testi teklifi istiyor.

İlk firma iki gün efor veriyor.

İkinci firma beş gün istiyor.

Üçüncü firma ise aktif test, raporlama ve retest dahil on beş iş günlük bir takvim öneriyor.

Scope satırında üç teklif için de aynı ifade bulunuyor:

Bu firmalardan biri gereksiz süre mi yazdı? Diğeri testi eksik mi yapacak? Yoksa hepsi farklı bir işi aynı hizmet adı altında mı fiyatlandırdı?

Çoğu zaman üçüncü ihtimal gerçekleşir.

“Bir application” ifadesi test eforunu açıklamaz. Uygulama public bir landing page olabilir. Dört role, iki tenant'a, yüzlerce API endpoint'ine, payment ve approval flow'larına sahip bir business platform da olabilir. İkisi de satın alma formunda tek satıra sığar. Güvenlik açısından aynı kapsam değildir.

Asıl cevap “beş gün” veya “on gün” değildir. Doğru cevap şu dört değeri birbirinden ayırarak verilmelidir:

1. 1Kaç tester-day efor gerekir?
2. 2Kaç gün aktif test yapılır?
3. 3Projenin başlangıçtan kapanışa takvim süresi nedir?
4. 4Raporlama ve retest hangi tarihlerde tamamlanır?

Bu yazıda sızma testi kaç gün sürer sorusunu sekiz teknik değişken üzerinden ele alacağız. Ayrıca tekliflerdeki gün sayılarını karşılaştırmak, scope kaynaklı belirsizliği görmek ve projenin gerçek takvimini hesaplamak için uygulanabilir bir model kuracağız.

Önce “gün” kelimesinin ne anlama geldiğini netleştirelim

Sızma testi tekliflerinde en sık görülen belirsizlik, gün sayısının hangi ölçüyü ifade ettiğinin yazılmamasıdır.

“10 gün sızma testi” şu anlamlardan herhangi birine gelebilir:

• Bir tester'ın 10 iş günü çalışması
• İki tester'ın beşer gün çalışması
• Beş gün aktif test ve beş gün raporlama
• Test, rapor ve retest dahil 10 iş günlük takvim
• 10 tester-day eforun üç haftalık takvime dağıtılması
• Automated scanning süresinin de test eforuna eklenmesi
• Müşteri erişim sorunlarının bekleme süresine dahil edilmesi

Bu yorumların hiçbiri diğeriyle aynı değildir.

Tester-day nedir?

Bir tester-day, bir security tester'ın bir iş günlük üretken eforudur. Sekiz tester-day, teorik olarak bir tester için sekiz gün veya iki tester için dörder gün anlamına gelebilir.

Ancak efor her zaman tam paralelleştirilemez. Bir tester application mapping yapmadan ikinci tester authorization testine başlayamayabilir. Ortak test account'larının state'i değişebilir. Aynı payment veya approval flow'unda iki kişinin eş zamanlı çalışması test data'yı bozabilir. Kritik attack chain'i anlamak için tek kişinin uçtan uca bağlamı koruması gerekebilir.

Bu nedenle:

8 tester-day ≠ her durumda 2 tester ile 4 takvim günü

Aktif test günü nedir?

Tester'ın target üzerinde keşif, manuel test, controlled exploitation ve bulgu validation yaptığı dönemdir. Kickoff, hesap hazırlığı, rapor QA, yönetici özeti ve retest bu sürenin dışında tutulabilir.

İş günü ile takvim günü aynı mıdır?

Hayır. Beş iş günlük aktif test, kickoff ve rapor dahil iki takvim haftasına yayılabilir. Resmî tatil, erişim onayı, deployment, bakım penceresi veya müşteri geri bildirimi takvimi uzatabilir.

Raporlama testin parçası mıdır?

Profesyonel bir engagement'ta evet. Bulguyu keşfetmek işin yalnızca bir bölümüdür. Reproducible evidence hazırlamak, impact'i doğrulamak, severity'yi gerekçelendirmek, remediation guidance yazmak ve raporu technical QA sürecinden geçirmek ayrıca efor ister.

Raporlamayı “test bittikten sonra otomatik oluşan PDF” gibi görmek gerçekçi değildir.

Retest başlangıç süresine dahil midir?

Her teklifte aynı değildir. Bazı teklifler bir retest turunu fiyat ve takvime dahil eder. Bazıları retest'i ayrı hizmet olarak sunar. Bazıları yalnızca original PoC'yi yeniden çalıştırır. Bazıları ise systemic fix, benzer endpoint ve regression olasılığını da kontrol eder.

Gün sayısını karşılaştırmadan önce bu ayrım yazılı hâle getirilmelidir.

Sızma testi süreleri için gerçekçi referans aralıkları

Aşağıdaki tablo evrensel fiyat veya süre standardı değildir. Belirtilen koşullar altında scoping görüşmesine başlangıç noktası sunar.

Bu aralıkların geçerli olabilmesi için scope'un stabil, account'ların çalışır, environment'ın erişilebilir ve Rules of Engagement'ın onaylı olduğu varsayılır.

Aynı uygulama aşağıdaki tek değişiklik nedeniyle 5 tester-day'den 12 tester-day'e çıkabilir:

• Bir role yerine altı role verilmesi
• Tek tenant yerine tenant isolation testinin eklenmesi
• Browser'da görülen API dışında partner API ve webhook'ların kapsama alınması
• Yalnızca OWASP WSTG baseline yerine ASVS requirement-level coverage istenmesi
• Staging yerine production üzerinde düşük request rate ile çalışma zorunluluğu
• Türkçe rapora ek olarak İngilizce rapor ve detailed evidence pack talep edilmesi
• Bir tur dar retest yerine systemic remediation review istenmesi

Süreyi belirleyen şey service label değil, test edilecek güvenlik iddiasıdır.

Değişken 1: Scope büyüklüğü ve asset türleri

Sızma testi süresini en görünür biçimde etkileyen değişken scope'tur. Ancak scope yalnızca domain veya IP sayısı değildir.

Bir web application scope'u şu bileşenleri içerebilir:

• Public frontend
• Authenticated user portal
• Admin panel
• REST API
• GraphQL endpoint
• WebSocket service
• Identity provider
• File upload ve processing service
• Object storage
• Payment callback
• Partner API
• Webhook receiver
• Mobile backend
• Internal management interface
• Ayrı region veya tenant deployment'ı

Teklifte portal.example.com yazılması bu bileşenlerin tamamını kapsamaz.

Domain sayısı neden zayıf bir süre ölçüsüdür?

Tek domain altında yüzlerce route ve onlarca business flow bulunabilir. Buna karşılık on subdomain aynı statik frontend build'ini veya aynı backend'i kullanabilir.

Domain sayısı şu sorular cevaplanmadan efor üretmez:

• Her domain farklı application mı?
• Authentication ve session ortak mı?
• Backend aynı mı?
• Route ve API inventory'si nedir?
• Admin ve support interface'leri var mı?
• Hangi host third-party provider'a aittir?
• Wildcard scope içinde ownership nasıl doğrulanacak?
• IPv4 yanında IPv6 surface var mı?
• Test sırasında yeni asset bulunursa change control nasıl işleyecek?

NCSC'nin penetration testing guidance'ı da scoping çıktısında teknik sınırların, test türünün, time frame'in, gerekli resource-day değerinin, hazırlık ihtiyaçlarının ve raporlama koşullarının birlikte tanımlanmasını önerir. Yalnızca target adı süre hesabı için yeterli değildir.

Scope atomik hâle getirilmeli

Uygulanabilir bir scope manifest'i en az şu alanları içermelidir:

engagement:
  name: customer-portal-2026-q3
  service_type: web_api_penetration_test
  environment: staging
  production_validation: limited

targets:
  web:
    - host: portal.example.com
      ownership: customer
      authenticated: true
    - host: admin.example.com
      ownership: customer
      authenticated: true
  api:
    - base_url: https://api.example.com/v2
      specification: openapi-v2.json
      protocols:
        - REST
    - base_url: https://events.example.com/graphql
      specification: schema.graphql
      protocols:
        - GraphQL

identity:
  roles:
    - anonymous
    - customer
    - support
    - administrator
  tenants: 2
  users_per_role: 2
  mfa: true
  sso: oidc

critical_flows:
  - registration
  - password_reset
  - profile_update
  - payment
  - refund
  - file_upload
  - report_export
  - support_impersonation

rules_of_engagement:
  timezone: Europe/Istanbul
  max_requests_per_second: 3
  destructive_testing: false
  denial_of_service: false
  third_party_testing: false
  emergency_stop_contact: security@example.com

deliverables:
  executive_summary: true
  technical_report: true
  coverage_matrix: true
  cvss_version: "4.0"
  retest_rounds: 1

Bu manifest süreyi otomatik hesaplamaz. Fakat teklifi hazırlayan ekibin neyi hesapladığını denetlenebilir hâle getirir.

Scope hazırlığı hakkında daha ayrıntılı bir model için Web uygulaması sızma testinde kapsam nasıl belirlenir? yazımızdaki application boundary, role, tenant ve business flow bölümleri kullanılabilir.

Değişken 2: Application ve business logic karmaşıklığı

İki application'ın aynı sayıda endpoint içermesi aynı test süresini gerektirdiği anlamına gelmez.

Birinci application yalnızca read-only product catalog sunabilir.

İkinci application şu flow'ları içerebilir:

• Kullanıcı kaydı ve identity verification
• Çok aşamalı approval
• Payment ve refund
• Limit ve kota yönetimi
• Discount ve coupon
• File upload ve asynchronous processing
• Role delegation
• Account impersonation
• Tenant değiştirme
• Export ve scheduled report
• Webhook ile state güncelleme
• Third-party callback

İki sistemde de yüz endpoint bulunabilir. İkinci sistemin abuse case sayısı ve state transition yapısı daha karmaşıktır.

Endpoint sayısı yalnızca hacmi gösterir

GET /products ile POST /payments/{id}/refund aynı test birimi değildir.

İkinci endpoint için şu sorular gerekir:

• Refund'u hangi role başlatabilir?
• İşlem başka tenant'a aitse ne olur?
• Payment settled değilse refund yapılabilir mi?
• Amount client tarafından değiştirilebilir mi?
• Partial refund limiti var mı?
• Aynı request replay edilirse ne olur?
• Concurrent request double refund üretir mi?
• Callback geç veya ters sırada gelirse state nasıl değişir?
• Currency ve rounding kontrolü server-side mı?
• Approval gerekiyorsa aşamalar atlanabilir mi?

Business logic testi payload listesi çalıştırılarak tamamlanmaz. Sistemin expected state machine'i anlaşılmalı, negatif akışlar modellenmeli ve riskli geçişler kontrollü biçimde denenmelidir.

Business flow sayısı süre hesabına nasıl girer?

Her kritik flow için en az şu boyutlar değerlendirilir:

1. 1Entry condition
2. 2Yetkili role
3. 3Object ownership
4. 4Tenant boundary
5. 5State precondition
6. 6Input integrity
7. 7Replay ve idempotency
8. 8Concurrency
9. 9Side effect
10. 10Audit trail

Otuz ekranlı fakat stateless bir content management interface, sekiz ekranlı ödeme ve onay application'ından daha kısa sürebilir.

Technology çeşitliliği de süreyi artırır

Browser tabanlı HTTP akışına ek olarak GraphQL, WebSocket, gRPC, message queue, signed URL, native mobile client veya custom protocol varsa farklı test tekniği ve tooling gerekir.

Tester'ın yalnızca endpoint'i görmesi yetmez. Protocol behavior, authentication propagation, message schema, connection lifecycle ve error model'i anlaması gerekir.

OWASP WSTG'nin stable içeriğinde information gathering, architecture mapping, identity, authentication, authorization, session, input validation, business logic, client-side ve API test alanlarının ayrı başlıklarda yer alması coverage'ın tek bir “OWASP Top 10 kontrolü” olmadığını gösterir.

Değişken 3: Role, permission ve tenant matrisi

Authenticated bir application'da test süresini en hızlı büyüten değişkenlerden biri authorization modelidir.

Tek kullanıcılı bir portal ile şu role'lere sahip platform aynı değildir:

• Customer
• Customer manager
• Branch operator
• Finance approver
• Support agent
• Auditor
• Tenant administrator
• Platform administrator

Her role yalnızca kendi endpoint listesine sahip olmayabilir. Aynı endpoint, role, object ownership, tenant ve object state'e göre farklı sonuç üretir.

Neden iki aynı role hesabı gerekir?

IDOR ve horizontal authorization testinde bir kullanıcının başka kullanıcıya ait objeye erişip erişemediği kontrol edilir. Tek account verilirse tester kendi objesi ile başka kullanıcı objesini güvenilir biçimde ayıramayabilir.

Multi-tenant sistemde en az iki tenant gerekebilir:

Tenant A
  User A1
  User A2
  Admin A

Tenant B
  User B1
  User B2
  Admin B

Bu model şu testleri mümkün kılar:

• A1 → A2 horizontal access
• A1 → Admin A vertical access
• A1 → B1 cross-tenant access
• Admin A → Tenant B administrative access
• Disabled user → active object
• Invited user → pre-activation object
• Former member → retained resource

Authorization kombinasyonu doğrusal büyümez

Basitleştirilmiş düşünceyle test uzayı şu çarpanlardan oluşur:

authorization test space
≈ role × tenant × object state × sensitive action

Bu ifade her kombinasyonun tek tek test edileceği anlamına gelmez. Risk-based selection gerekir. Yine de role sayısının ikiden sekize çıkması yalnızca altı yeni login işlemi eklemez. Permission boundary sayısını, object relationship'lerini ve negative test kombinasyonlarını büyütür.

Role listesi yetmez, permission matrix gerekir

Örnek:

Bu tablo yoksa tester expected authorization behavior'ı reverse engineer etmek zorunda kalır. Gray box test black box'a yaklaşır ve süre artar.

IDOR'un neden hâlâ yaygın olduğunu role, object ve action ilişkisinin eksik modellenmesi üzerinden IDOR açığı neden hâlâ bu kadar yaygın? yazımızda ele alıyoruz.

Değişken 4: Black box, gray box veya white box yaklaşımı

Tester'a ne kadar bilgi ve erişim verildiği yalnızca test perspektifini değil, zamanın nasıl harcanacağını da belirler.

Black box süreyi neden uzatabilir?

Black box testte tester uygulamanın iç yapısını, role modelini, API documentation'ını ve architecture'ını bilmez. Zamanın önemli bölümü şunlara gider:

• Asset discovery
• Route ve endpoint enumeration
• Technology fingerprinting
• Authentication modelini anlama
• Role ve permission davranışını çıkarma
• Gizli veya alternatif channel'ları bulma
• Error behavior üzerinden backend varsayımı kurma

Bu yaklaşım external attacker perspektifi için değerlidir. Fakat time-boxed engagement içinde görünmeyen flow'ların test edilmemesi riskini artırır.

NCSC de closed box testte ön bilgi bulunmamasının saldırgan perspektifini daha iyi modelleyebileceğini, ancak ayrılan sürede bazı zafiyetlerin keşfedilmeden kalabileceğini açıkça belirtir.

Gray box neden çoğu kurumsal testte dengeli sonuç verir?

Gray box yaklaşımında tester'a şu girdiler sağlanabilir:

• Test account'ları
• Role listesi
• API specification
• Kritik business flow açıklaması
• Architecture özeti
• Test data
• Scope dışı third-party listesi

Bu bilgi keşif süresini azaltır. Kazanılan zaman authorization, business logic ve controlled exploitation derinliğine aktarılır.

White box her zaman daha kısa mı sürer?

Hayır.

Source code, architecture ve developer erişimi entry point'leri daha hızlı bulmayı sağlayabilir. Ancak white box engagement'ın coverage beklentisi de daha yüksek olabilir. Kaynak kodun tamamının Secure Code Review ile incelenmesi isteniyorsa bu ayrı efor gerektirir.

White box pentest ile Kaynak Kod Analizi aynı hizmet değildir:

• White box pentest, çalışan application'daki attack path'i daha hızlı ve derin test etmek için iç bilgiyi kullanır.
• Secure Code Review, code-level data flow, root cause ve görünmeyen branch'leri inceler.

Bu ayrımı Kaynak kod analizi ile sızma testi aynı problemi çözmez yazımızda ayrıntılı olarak açıklıyoruz.

Test yaklaşımı teklifte süreyle birlikte yazılmalı

Zayıf ifade:

Daha doğru ifade:

Bu ifade sürenin hangi varsayıma dayandığını gösterir.

Black box, gray box ve white box yaklaşımının coverage farkları için Black box, gray box, white box sızma testi: Hangisi gerçekten neyi gösterir? yazısına bakabilirsiniz.

Değişken 5: Environment ve test hazırlığının gerçek durumu

Kâğıt üzerinde beş gün planlanan testin iki gününün erişim sorunlarıyla geçmesi sık rastlanan bir durumdur.

Tester ilk gün şu problemlerle karşılaşabilir:

• VPN hesabı çalışmıyor
• Source IP allowlist'e eklenmemiş
• Test account'ları login olamıyor
• MFA yalnızca kurum telefonuna geliyor
• Admin role yanlış yetkiyle oluşturulmuş
• Tenant'lar birbirinden ayrılmamış
• Test data bulunmuyor
• Payment sandbox hazır değil
• API specification eski version'ı gösteriyor
• Staging backend production'dan farklı
• File processing worker çalışmıyor
• Rate limit tester trafiğini tamamen engelliyor
• WAF block üretiyor fakat kimse exception açamıyor
• Test build son anda değiştiriliyor

Bu sorunlar security testing değildir. Yine de tester'ın ayrılmış eforunu tüketir ve takvimi kaydırır.

Readiness gate kullanılmalı

Aktif test başlamadan önce aşağıdaki kontroller tamamlanmalıdır:

Readiness tamamlanmadan test saatini başlatmak iki taraf için de kötü sonuç üretir. Sağlayıcı efor kaybeder. Müşteri ise erişilemeyen alanlar nedeniyle düşük coverage alır.

Staging ve production aynı süreyi üretmez

Staging üzerinde daha serbest test yapılabilir. Fakat production'a benzemiyorsa sonuç sınırlı kalır.

Production üzerinde şu kısıtlar süreyi artırabilir:

• Düşük request rate
• Yalnızca belirli saatlerde test
• Gerçek e-mail veya SMS gönderiminin yasak olması
• Payment ve refund için limit
• Büyük file upload sınırı
• Account lockout riskine karşı deneme sayısı
• Destructive action yasağı
• Data download limiti

En güçlü model çoğu zaman hybrid yaklaşımıdır. Derin ve side effect üretebilecek testler production-parity staging üzerinde yürütülür. Production'da authentication, authorization, configuration, WAF, routing ve kritik remediation varsayımları düşük etkili yöntemle doğrulanır.

Değişken 6: Rules of Engagement ve operasyonel kısıtlar

Rules of Engagement, testin nasıl yürütülebileceğini tanımlayan teknik ve operasyonel sınırdır. NIST, ROE'yi security test başlamadan önce belirlenen ve test ekibine tanımlı faaliyetleri ek izin almadan yürütme yetkisi veren ayrıntılı kural ve kısıtlar olarak tanımlar.

ROE yalnızca hukuki koruma sağlamaz. Süre hesabını doğrudan değiştirir.

Request rate sınırı

Bir API üzerinde saniyede 20 request güvenliyken başka bir production service için saniyede iki request sınırı konabilir. Enumeration, parameter variation ve race condition testleri düşük hızda daha uzun sürer.

Test window

Yalnızca 22.00–02.00 arasında test izni varsa sekiz saatlik iş günü dört saatlik pencereye sıkışır. Tester gündüz analysis ve hazırlık yapabilir, ancak target interaction süresi uzar.

Yasaklanan teknikler

Şu alanlar out-of-scope olabilir:

• Denial of Service
• High-volume password testing
• Real user account kullanımı
• Production payment
• E-mail ve SMS flood
• Large data extraction
• Persistence
• Social engineering
• Physical security
• Third-party system

Bu kısıtlar her zaman kötü değildir. Production safety için gereklidir. Fakat assurance sonucunu sınırlar ve alternatif test ortamı ihtiyacı doğurabilir.

Critical finding notification

Kritik bulgu bulunduğunda test devam edecek mi? Müşteri hemen patch yapacak mı? Environment değişirse tester regression kontrolü mü yapacak? Bulgu nedeniyle scope genişleyecek mi?

Bu kararlar takvimi etkiler.

Örnek:

1. 1Tester authentication bypass bulur.
2. 2Müşteri aynı gün hotfix yayımlar.
3. 3Build version değişir.
4. 4Eski test evidence'inin bir kısmı geçersizleşir.
5. 5Tester yeni build'de regression yapmak zorunda kalır.
6. 6Kalan testler bir gün kayar.

Change freeze veya açık change control yoksa süre tahmini güvenilirliğini kaybeder.

Third-party boundary

Payment provider, identity provider, CDN, cloud service veya managed SaaS yazılı yetki olmadan aktif test edilemez. Tester'ın üçüncü taraf boundary'yi anlaması, request'i uygulama tarafında durdurması ve callback logic'ini güvenli biçimde test etmesi gerekir.

Scope dışı bir component kritik attack path'in ortasındaysa iki seçenek vardır:

• Yazılı change approval ile scope genişletilir
• Component limitation olarak raporlanır

NCSC guidance'ı da test sırasında yeni component bulunmasının time frame ve cost değişikliği yaratabileceğini, scope'a alınmıyorsa limitation olarak kaydedilmesi gerektiğini belirtir.

Değişken 7: Test derinliği, evidence ve raporlama beklentisi

“OWASP Top 10 testi” süre tanımı değildir.

OWASP Top 10, yaygın risk sınıflarını anlatan awareness dokümanıdır. Web application testinin teknik coverage'ı için OWASP WSTG, kontrol beklentisi için OWASP ASVS ve application'a özgü abuse case'ler gerekir.

Aynı scope için üç farklı derinlik

Seviye 1: Baseline assessment

• Public ve temel authenticated surface
• Common vulnerability class'ları
• Sınırlı role testi
• Temel business flow
• Critical ve high bulgu validation

Seviye 2: Deep application assessment

• Role ve tenant matrix
• Business logic abuse case'leri
• Session lifecycle
• Alternative channel
• API version ve hidden endpoint
• File processing
• Webhook ve callback
• Controlled attack chain

Seviye 3: Requirement-mapped verification

• Belirli OWASP ASVS version ve requirement set'i
• Pass, fail, not applicable ve not tested statüleri
• Requirement-level evidence
• Coverage matrix
• Limitation ve residual risk
• Technical workshop ve remediation review

Aynı domain için bu üç çalışma aynı sürede tamamlanmaz.

Evidence standardı süreyi etkiler

Her bulgu için yalnızca ekran görüntüsü istenebilir. Daha profesyonel bir teslimatta ise şu veriler gerekebilir:

• Affected asset
• Role ve tenant
• Preconditions
• Exact request ve response
• Reproducible steps
• Controlled PoC
• Observed impact
• Data minimization uygulanmış evidence
• CVSS vector
• CWE eşleştirmesi
• ASVS veya WSTG reference
• Root cause hypothesis
• Remediation guidance
• Retest acceptance criteria

Bulguyu keşfetmek 20 dakika, güvenli biçimde doğrulamak ve remediation-grade raporlamak iki saat sürebilir.

Rapor QA ayrı efordur

Technical QA şu soruları kontrol etmelidir:

• Bulgu gerçekten tekrar üretilebiliyor mu?
• Evidence iddiayı destekliyor mu?
• Severity ile kanıtlanan impact uyumlu mu?
• Scope ve environment doğru yazılmış mı?
• Hassas veri maskelenmiş mi?
• Remediation uygulanabilir mi?
• Duplicate bulgular birleştirilmiş mi?
• Systemic root cause görünür mü?
• Limitation raporda açık mı?

Executive summary de scanner bulgularının sayısını tekrar etmemelidir. Critical attack path, business impact, ortak root cause ve remediation sırası yönetim diline çevrilmelidir.

İki dilde rapor

Türkçe ve İngilizce rapor istenmesi yalnızca metni machine translation ile çevirmek değildir. Teknik terim, evidence label, risk açıklaması ve remediation önerisi iki dilde QA gerektirir. Teklifte bu efor ayrıca görünmelidir.

ASVS 5.0.0 requirement-level verification veya OWASP MASTG v2 atomic test coverage isteniyorsa test case mapping ve sonuç statüleri ayrıca planlanmalıdır.

Değişken 8: Ekip yapısı, paralel çalışma ve retest planı

“İki tester koyarsak süre yarıya iner” düşüncesi bazı scope'larda çalışır, bazılarında çalışmaz.

Hangi işler paralelleştirilebilir?

• Farklı bağımsız host'ların external testi
• Ayrı web ve mobile client değerlendirmesi
• Birbirinden bağımsız API service'leri
• Static analysis ile dynamic testin bir kısmı
• Farklı network segment'leri
• Report QA ile kalan düşük riskli validation

Hangi işler seri ilerler?

• Initial application mapping
• Tek account state'ine bağlı business flow
• Ortak payment veya test data kullanımı
• Authentication bypass sonrası attack chain
• Aynı tenant üzerinde role matrix testi
• Bulguların deduplication ve root cause analizi
• Final severity ve report QA

Ekip büyüdükçe coordination cost oluşur

İki tester'ın aynı application üzerinde çalışması şu ek ihtiyaçları getirir:

• Endpoint ve flow paylaşımı
• Account ve session koordinasyonu
• Test data ownership
• Duplicate kontrolü
• Ortak evidence standardı
• Daily handoff
• Merkezi bulgu triage
• Final report tutarlılığı

Bu maliyet kötü değildir. Doğru yönetildiğinde coverage ve peer review kalitesini artırır. Fakat sıfır kabul edilemez.

Seniority süreyi ve sonucu etkiler

Deneyimli tester application'ı daha hızlı modelleyebilir, false positive'i daha erken ayıklayabilir ve business logic attack path'ini daha kısa sürede kurabilir.

Ancak “senior tester daha hızlıdır, o hâlde süreyi yarıya indirelim” sonucu da hatalıdır. Kazanılan zaman daha derin coverage, alternative hypothesis ve remediation kalitesine aktarılabilir.

NCSC, penetration testin tamamen prosedürel olamayacağını ve exhaustive test case listesinin hazırlanamayacağını belirtir. Bu nedenle test kalitesi tester'ın yetkinliğiyle yakından ilişkilidir.

Retest ayrı bir takvim fazıdır

Retest süresi şu değişkenlere bağlıdır:

• Bulgu sayısı
• Critical ve high bulgu sayısı
• Remediation'ın local veya systemic olması
• Değişen endpoint sayısı
• Yeni build'in hazır olma zamanı
• Test account'larının hâlâ çalışması
• WAF rule ile code fix ayrımı
• Regression kapsamı
• Original PoC'nin yanında bypass kontrolü

Bir bulgunun response body'de 403 dönmesi tek başına kapanış anlamına gelmez. Server-side authorization, object ownership, alternate endpoint, method variation ve indirect flow gerekiyorsa yeniden kontrol edilmelidir.

Retest için net acceptance criteria

Örnek:

retest:
  window_business_days: 30
  included_rounds: 1
  build_identifier_required: true
  original_poc_replay: true
  equivalent_endpoints: risk_based
  alternate_roles: risk_based
  bypass_testing: true
  regression_testing: limited
  new_findings:
    report_if_directly_related: true
    full_new_scope: false

“Ücretsiz retest dahildir” cümlesi bu ayrıntıları açıklamaz.

Sızma testi süresi nasıl hesaplanmalı?

Sağlıklı tahmin tek çarpanlı formülle yapılmaz. Çalışma fazlara bölünür.

Temel model:

Toplam tester-day
= hazırlık ve briefing
+ attack surface mapping
+ manual testing
+ controlled validation
+ reporting
+ technical QA
+ retest

Takvim modeli:

Tahmini iş günü
= seri ilerlemesi gereken efor
+ paralel efor / etkili paralellik
+ müşteri koordinasyon tamponu

Buradaki etkili paralellik, tester sayısından küçük veya ona eşittir. Üç tester bulunması üç bağımsız iş akışı olduğu anlamına gelmez.

Şeffaf bir hesaplama örneği

Varsayım:

• Mapping: 1,5 tester-day
• Manual testing: 7 tester-day
• Validation: 1,5 tester-day
• Reporting: 2 tester-day
• Technical QA: 0,5 tester-day
• Retest: 1,5 tester-day
• Tester sayısı: 2
• Bağımsız paralel stream: 2
• Müşteri coordination buffer: 2 iş günü

Toplam efor:

1,5 + 7 + 1,5 + 2 + 0,5 + 1,5 = 14 tester-day

Manual testing iki bağımsız stream'e bölünebiliyorsa konservatif takvim:

seri efor = 1,5 + 1,5 + 2 + 0,5 + 1,5 = 7
paralel efor = 7 / 2 = 3,5
aktif takvim = 7 + 3,5 = 10,5 ≈ 11 iş günü
proje takvimi = 11 + 2 coordination buffer = 13 iş günü

Bu model bütün test fazlarının katı biçimde seri ilerlediğini varsaydığı için konservatiftir. Gerçekte reporting'in bir kısmı test sırasında başlayabilir. Buna karşılık environment sorunu veya scope change takvimi uzatabilir.

Aynı hesabı yapan Python örneği

Aşağıdaki kod universal pentest estimator değildir. Scoping sonrasında uzman tarafından verilen stage eforlarını tester-day'den takvim gününe çevirmek için şeffaf bir capacity planning örneğidir.

from dataclasses import dataclass
from math import ceil


@dataclass(frozen=True)
class StageEffort:
    mapping: float
    manual_testing: float
    validation: float
    reporting: float
    technical_qa: float
    retest: float

    def total_tester_days(self) -> float:
        return (
            self.mapping
            + self.manual_testing
            + self.validation
            + self.reporting
            + self.technical_qa
            + self.retest
        )


@dataclass(frozen=True)
class Capacity:
    testers: int
    independent_streams: int
    coordination_buffer_days: int

    def effective_parallelism(self) -> int:
        if self.testers < 1:
            raise ValueError("testers en az 1 olmalıdır")
        if self.independent_streams < 1:
            raise ValueError("independent_streams en az 1 olmalıdır")
        if self.coordination_buffer_days < 0:
            raise ValueError("coordination_buffer_days negatif olamaz")

        return min(self.testers, self.independent_streams)


def estimate_calendar_days(effort: StageEffort, capacity: Capacity) -> int:
    serial_effort = (
        effort.mapping
        + effort.validation
        + effort.reporting
        + effort.technical_qa
        + effort.retest
    )

    parallel_effort = (
        effort.manual_testing / capacity.effective_parallelism()
    )

    active_days = ceil(serial_effort + parallel_effort)
    return active_days + capacity.coordination_buffer_days


effort = StageEffort(
    mapping=1.5,
    manual_testing=7.0,
    validation=1.5,
    reporting=2.0,
    technical_qa=0.5,
    retest=1.5,
)

capacity = Capacity(
    testers=2,
    independent_streams=2,
    coordination_buffer_days=2,
)

print(f"Toplam efor: {effort.total_tester_days():.1f} tester-day")
print(f"Tahmini takvim: {estimate_calendar_days(effort, capacity)} iş günü")

Beklenen çıktı:

Toplam efor: 14.0 tester-day
Tahmini takvim: 13 iş günü

Kodun en önemli özelliği katsayıları saklamamasıdır. Mapping veya manual testing eforunu kim belirlediyse varsayım görünürdür. “AI hesapladı”, “tool böyle söyledi” veya “bir application beş gündür” gibi doğrulanamayan kararlar yerine stage-based planning kullanılır.

Örnek bir 10 iş günlük web application test planı

Aşağıdaki örnek orta ölçekli, dört role sahip, iki tenant'lı, REST API kullanan gray box bir web application içindir. Bir retest turu daha sonraki tarihte ayrıca planlanır.

Bu planın eksiksiz olması için şu varsayımlar gerekir:

• Account'lar ilk gün çalışıyor
• API documentation güncel
• Environment test boyunca stabil
• Kritik flow için test data hazır
• Production action kısıtları önceden biliniyor
• Müşteri technical contact hızlı yanıt veriyor
• Scope değişmiyor
• Rapor dili tek

İki gün erişim problemi yaşanırsa plan 10 gün kalmaz. Test eforu azaltılmadan takvim uzatılmalı veya limitation açıkça kabul edilmelidir.

Bir günlük sızma testi mümkün mü?

Evet, ancak “bir günlük full pentest” ifadesi çoğu modern application için doğru değildir.

Bir gün şu işler için anlamlı olabilir:

• Tek bir remediation'ın targeted retest'i
• Sınırlı bir endpoint grubunun validation'ı
• Belirli bir configuration değişikliğinin kontrolü
• Dar scope'lu exposed service değerlendirmesi
• Tek bir critical flow için focused assessment
• Küçük bir release delta'sının risk review'u

Bir gün şu vaatler için genellikle yetersizdir:

• Multi-role web application'ın tamamı
• API, admin panel ve tenant isolation
• Android, iOS ve backend birlikte
• Internal Active Directory ve segmentation
• Derin business logic ve concurrency testi
• Requirement-level ASVS coverage
• Manual validation, raporlama ve QA dahil full engagement

Bir sağlayıcı tek günde “tüm OWASP açıklarını” bulacağını söylüyorsa şu sorular sorulmalıdır:

• Kaç route ve endpoint test edilecek?
• Kaç role ve tenant var?
• Manual test için kaç saat ayrılacak?
• Mapping ve reporting süreye dahil mi?
• Scanner çıktısı manuel doğrulanacak mı?
• Business logic nasıl test edilecek?
• Test edilemeyen alanlar raporda görünecek mi?
• Retest dahil mi?

Neden iki firma aynı scope için farklı süre verir?

Fark her zaman kalite farkı değildir. Şu nedenlerden biri olabilir:

Scope yorumları farklıdır

Bir firma yalnızca verilen base URL'yi, diğeri API ve admin interface'i de hesaplamış olabilir.

Coverage beklentisi farklıdır

Bir teklif common vulnerability baseline'ı, diğeri role, tenant ve business logic derinliğini kapsayabilir.

Report standardı farklıdır

Bir firma scanner export'u, diğeri reproducible evidence, CVSS vector, root cause ve remediation guidance sunabilir.

Retest farklıdır

Birinde retest yoktur. Diğerinde bir tur bypass ve regression kontrolü bulunabilir.

Tester sayısı farklıdır

On tester-day efor, bir firma tarafından tek tester ile iki haftada, diğer firma tarafından iki tester ile daha kısa takvimde yürütülebilir.

Hazırlık varsayımı farklıdır

Bir firma account ve API documentation'ın hazır olduğunu, diğeri onboarding eforunu da hesaplamış olabilir.

Test yaklaşımı farklıdır

Black box recon ile gray box deep testing aynı zaman dağılımını üretmez.

Bu nedenle teklifleri yalnızca toplam gün ve fiyat üzerinden karşılaştırmak doğru değildir. Teknik teklifin hangi maddeleri içermesi gerektiğini Sızma testi teklifinde hangi teknik maddeler olmalı? yazımızda ayrıntılı olarak ele alıyoruz.

Süreyi kısaltırken test kalitesi nasıl korunur?

Test süresini azaltmanın en güvenli yolu tester'ı hızlandırmak değil, belirsizliği azaltmaktır.

1. Scope manifest'ini testten önce tamamlayın

Host, API, role, tenant, environment ve third-party boundary açık olsun.

2. İki aynı role ve iki tenant hazırlayın

Authorization testi için account bekleme süresi ortadan kalksın.

3. Güncel API documentation paylaşın

OpenAPI, Postman collection, GraphQL schema ve authentication örnekleri hazır olsun.

4. Critical business flow'ları işaretleyin

Tester tüm ekranlara eşit zaman ayırmak yerine payment, approval, export, impersonation ve file processing gibi yüksek riskli alanlara odaklansın.

5. Synthetic test data oluşturun

Gerçek personal data kullanmadan state ve authorization senaryoları çalıştırılabilsin.

6. Readiness testini test başlangıcından önce yapın

VPN, allowlist, MFA, account, tenant ve callback çalışıyor olsun.

7. Rules of Engagement'ı önceden onaylayın

Request rate, test window, yasak action, critical escalation ve emergency stop test sırasında tartışılmasın.

8. Teknik contact atayın

Tester erişim veya davranış belirsizliğinde saatlerce yanıt beklemesin.

9. Test boyunca change freeze uygulayın

Zorunlu hotfix dışında build değişmesin. Değişirse version ve etkilenen coverage kaydedilsin.

10. Report template ve evidence beklentisini önceden paylaşın

Teslim aşamasında yeni format ve mapping talepleri oluşmasın.

11. Retest build'ini toplu hazırlayın

Her bulgu için ayrı deployment yerine doğrulanmış bir remediation build'i sunun.

12. White box girdisini amaca göre kullanın

Source code varsa her repository'yi scope'a eklemek yerine kritik authorization, parser ve trust boundary alanlarını tanımlayın.

Kaliteyi düşüren süre kısaltma yöntemleri ise şunlardır:

• Role sayısını raporda belirtmeden azaltmak
• API'yi scope dışında bırakmak
• Business logic yerine scanner çalıştırmak
• Bulgu validation'ı atlamak
• Evidence'i kaldırmak
• Reporting ve QA süresini sıfırlamak
• Test edilemeyen alanları “sorun bulunmadı” saymak
• Retest'i yalnızca HTTP status code kontrolüne indirmek

Sızma testi teklifinde süre nasıl yazılmalı?

Teklifte yalnızca “7 gün” bulunmamalıdır.

Örnek teknik süre tablosu:

Teklif ayrıca şu durumlarda sürenin değişebileceğini yazmalıdır:

• Yeni target eklenmesi
• Role veya tenant sayısının artması
• Environment erişim sorunu
• Test sırasında build değişmesi
• Third-party izin gecikmesi
• İki dilde rapor talebi
• Requirement-level mapping eklenmesi
• Retest kapsamının genişletilmesi
• Critical finding nedeniyle hotfix ve regression ihtiyacı

Bu model müşteriyi change request ile şaşırtmaz. Sağlayıcının da hangi varsayımla efor verdiğini korur.

Sızma testi ne zaman başlatılmalı?

Takvim hesabı yalnızca kaç gün süreceğini değil, testin release planında nereye konacağını da belirlemelidir.

Yanlış plan:

Pazartesi test başlasın
Cuma rapor gelsin
Cumartesi production release yapılsın

Bu planda remediation, retest ve deployment risk review için zaman yoktur.

Daha sağlıklı plan:

T-20  Scope ve readiness
T-15  Aktif test başlangıcı
T-8   Critical bulgu ara bildirimi ve remediation başlangıcı
T-5   İlk rapor
T-4   Remediation build
T-3   Retest
T-2   Residual risk kararı
T-1   Release approval
T     Production release

Her proje bu kadar düzenli ilerlemez. Yine de testin release'ten bir gün önce başlatılması security gate'i formaliteye dönüştürür.

Sızma testinin release öncesi, düzenli dönem veya olay sonrası hangi noktada yapılması gerektiğini Sızma testi ne zaman yaptırılmalı? yazımızda ayrıca ele alıyoruz.

Sonuç: Sızma testi süresi gün sayısından önce coverage sözüdür

“Sızma testi kaç gün sürer?” doğru bir satın alma sorusudur. Fakat tek başına cevaplanırsa yanıltıcıdır.

Profesyonel süre hesabı şu sekiz değişkeni birlikte ele alır:

1. 1Scope büyüklüğü ve asset türleri
2. 2Application ve business logic karmaşıklığı
3. 3Role, permission ve tenant matrisi
4. 4Black box, gray box veya white box yaklaşımı
5. 5Environment ve test hazırlığı
6. 6Rules of Engagement ve operasyonel kısıtlar
7. 7Test derinliği, evidence ve raporlama
8. 8Ekip yapısı, paralel çalışma ve retest

Teklifte şu değerler ayrı ayrı görünmelidir:

• Toplam tester-day
• Aktif test günleri
• Rapor teslim tarihi
• Retest eforu ve penceresi
• Müşteri bağımlılıkları
• Scope change koşulları
• Test edilemeyen alanların raporlanma yöntemi

Üç günlük doğru scope, on günlük belirsiz testten daha değerli olabilir. Bunun tersi de doğrudur. Karmaşık bir multi-tenant application'ı üç günde “tam test edildi” saymak, kısa süre avantajı değil görünmeyen coverage borcu üretir.

Secnodex, sızma testi süresini yalnızca domain, ekran veya IP sayısıyla belirlemez. Web, API, mobil, internal ve external scope'larda role, tenant, critical business flow, test perspective, environment, production safety, evidence ve retest beklentisini birlikte değerlendirir. Teklif öncesinde hangi varsayımın kaç tester-day ürettiğini, hangi alanların paralel çalışabileceğini ve takvimin hangi bağımlılıklarla değişeceğini açıkça tanımlar.

Kurumunuz için gerçekçi bir sızma testi süresi ve coverage planı oluşturmak üzere Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• OWASP Web Security Testing Guide v4.2
• OWASP Web Security Testing Guide – Stable
• OWASP Application Security Verification Standard 5.0.0
• OWASP Mobile Application Security Testing Guide v2
• OWASP MASVS – Assessment and Certification
• OWASP API Security Top 10:2023
• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NIST CSRC – Rules of Engagement
• UK NCSC – Penetration Testing
• FIRST – CVSS v4.0