Sızma Testi Teklifinde Hangi Teknik Maddeler Olmalı?

Aynı kurum, aynı web application ve aynı test dönemi için üç farklı sızma testi teklifi alıyor.

İlk teklif beş gün efor ve tek satır scope içeriyor:

İkinci teklif on gün efor veriyor. Methodology bölümünde OWASP, NIST, PTES ve CVSS isimleri sıralanmış. Hangi version'ın kullanılacağı, authentication gerektiren alanların nasıl test edileceği, business logic testlerinin dahil olup olmadığı ve bulunan açıkların nasıl doğrulanacağı yazmıyor.

Üçüncü teklif daha pahalı. Fakat application'ın public ve authenticated attack surface'ini, kullanıcı rollerini, API host'larını, mobile client'ın çağırdığı endpoint'leri, test environment'ını, izin verilen exploitation sınırını, kritik bulgu notification SLA'ini, evidence formatını ve retest acceptance criteria'sını ayrı ayrı tanımlıyor.

Bu üç teklif aynı hizmeti mi satıyor?

Kağıt üzerinde evet. Teknik gerçekte hayır.

Bir sızma testi teklifinin kalitesini sayfa sayısı veya kullanılan framework isimlerinin uzunluğu belirlemez. Teklifin asıl görevi şu belirsizlikleri ortadan kaldırmaktır:

• Tam olarak hangi asset'ler test edilecek?
• Hangi attack surface kapsam dışında kalacak?
• Tester hangi knowledge ve credential seviyesinde çalışacak?
• Automated scanning ile manual testing arasındaki iş bölümü ne olacak?
• Exploitation hangi noktaya kadar ilerletilecek?
• Production safety nasıl korunacak?
• Test tamamlandığında hangi kanıtlar teslim edilecek?
• “Test edildi” ile “test edilemedi” nasıl ayrılacak?
• Bulgu severity'si nasıl hesaplanacak?
• Retest neyi kapatacak ve neyi kapatmayacak?
• Teklifin kabulü hangi ölçülebilir kriterlere bağlanacak?

Bu soruların cevabı yoksa satın alınan şey belirli bir assurance sonucu değil, takvimde ayrılmış belirsiz bir uzman eforudur.

Bu yazı fiyat isteme formu hazırlamak için kısa bir checklist değildir. Teklifi teknik olarak karşılaştırılabilir, denetlenebilir ve sonuç üretmeye zorlayan bir measurement contract'e dönüştürmek için hangi maddelerin nasıl yazılması gerektiğini ele alır.

Teklif neden yalnızca ticari belge değildir?

Sızma testi teklifi çoğu kurumda satın alma dokümanı olarak görülür. Firma adı, hizmet adı, efor, fiyat, ödeme koşulu ve teslim tarihi yazılır. Teknik ayrıntıların kickoff toplantısında netleşeceği varsayılır.

Bu yaklaşım iki nedenle risklidir.

Birincisi, teklifler karşılaştırılırken aynı işin fiyatları karşılaştırılıyormuş gibi davranılır. Oysa bir sağlayıcı yalnızca unauthenticated attack surface'i ve automated scanner output'unu kapsarken diğeri çok rollü authorization, business logic, API ve controlled exploitation çalışıyor olabilir.

İkincisi, teknik ayrıntı sözleşme sonrasına bırakıldığında önemli kapsam farkları change request'e dönüşür. Müşteri “admin paneli de dahildi” der. Sağlayıcı “yalnızca verilen URL dahildi” der. Müşteri API'nin application'ın doğal parçası olduğunu düşünür. Sağlayıcı API host'u scope listesinde olmadığı için test etmez.

İyi teklif şu beş işlevi birlikte görür:

1. 1Expectation contract: Müşterinin ne alacağını tanımlar
2. 2Authorization boundary: Tester'ın hangi varlık üzerinde hangi işlemi yapabileceğini belirler
3. 3Measurement design: Test sonucunun neyi kanıtlayacağını sınırlar
4. 4Safety control: Operasyonel riski yönetir
5. 5Acceptance baseline: Teslimatın hangi koşulda tamamlanmış sayılacağını gösterir

Bu nedenle teknik teklif, satış ekibinin hazırladığı açıklama metninden ibaret olamaz. Pentester, application owner, infrastructure owner, risk owner, legal, privacy, SOC ve gerektiğinde cloud owner tarafından okunabilir olmalıdır.

MSA, SOW, Rules of Engagement ve scope manifest aynı belge midir?

Her kurum aynı belge mimarisini kullanmaz. Yine de görevleri ayırmak belirsizliği azaltır.

Tek bir teklif bütün bu bölümleri içerebilir. Önemli olan başlıkların ayrı dosyalarda olması değil, işlevlerin kaybolmamasıdır.

Örneğin “müşterinin yazılı onayıyla test yapılacaktır” cümlesi authorization için yeterli değildir. Hangi tüzel kişinin hangi asset üzerindeki testing authority'yi verdiği, third-party asset bulunup bulunmadığı, cloud provider policy'sinin kim tarafından kontrol edildiği ve onayın hangi tarih aralığını kapsadığı da bilinmelidir.

İlk teknik madde: Testin objective'i ne?

Scope listesinden önce objective yazılmalıdır.

Zayıf objective:

Bu ifade neredeyse her security assessment için kullanılabilir. Hangi güvenlik iddiasının sınandığını anlatmaz.

Daha iyi objective:

External network için objective farklı olabilir:

Internal network için:

Objective şu üç öğeyi içermelidir:

1. 1Test edilen sistem veya business capability
2. 2Test edilen attacker perspective
3. 3Beklenen assurance output'u

“OWASP Top 10 testi” objective değildir. Bir reference list'tir.

Hizmet tipi teklif içinde kesin olarak adlandırılmalı

Sızma testi, vulnerability assessment, automated scan, configuration review, secure code review, adversary emulation ve Red Team aynı hizmet değildir.

Teklif şu soruya açık cevap vermelidir:

NCSC, sızma testini aynı araç ve teknikleri kullanarak sistem güvenliğinin bir kısmını veya tamamını aşmaya çalışma yoluyla assurance elde etme yöntemi olarak tanımlar. Aynı guidance, testin her güvenlik problemini bulabilen sihirli bir çözüm olmadığını da özellikle belirtir.

Teklif yalnızca “VA/PT” yazıyorsa iki hizmetin ayrımı ayrıca açıklanmalıdır. Scanner'ın çalıştırılması, sonuçların false positive açısından incelenmesi ve birkaç bulgunun doğrulanması otomatik olarak derin bir penetration test oluşturmaz.

Red Team ihtiyacı olan kuruma pentest, pentest ihtiyacı olan kuruma Red Team satılması da doğru değildir. Ayrımı Red Team ile sızma testi arasındaki fark gerçekten nerede başlar? yazımızda objective ve attack path üzerinden ayrıntılı ele alıyoruz.

Scope “bir adet uygulama” diye yazılamaz

Bir adet application şu bileşenlerden oluşabilir:

• Public web frontend
• Admin interface
• REST API
• GraphQL endpoint
• WebSocket service
• Mobile backend
• Identity provider
• Object storage
• File processing worker
• Payment provider callback'leri
• Third-party integration
• Internal management API
• CDN ve WAF arkasındaki origin
• Ayrı tenant veya region deployment'ları

Teklifte “1 web sitesi” yazılması bunların hangisini içerdiğini göstermez.

Scope atomik target'lara ayrılmalıdır.

Domain ve subdomain

Şunlar aynı kapsam değildir:

example.com
www.example.com
*.example.com
api.example.com
admin.example.com

example.com yazılması bütün subdomain'lerin aktif test için otomatik olarak yetkilendirildiği anlamına gelmez. *.example.com ise daha geniş görünür fakat third-party SaaS'e CNAME olan subdomain'leri de kapsayabilir.

Wildcard scope varsa teklif şu policy'yi açıklamalıdır:

• Subdomain discovery yapılacak mı?
• Bulunan her host otomatik in-scope mu?
• Ownership doğrulaması nasıl yapılacak?
• Third-party hosting nasıl ayıklanacak?
• Yeni bulunan asset için aktif teste geçmeden önce onay gerekiyor mu?
• Decommission edilmiş fakat DNS'te kalan host'lar nasıl raporlanacak?

URL ve route

Sadece base URL vermek route coverage'ını tanımlamaz.

Teklifte en az şu bilgiler yer almalıdır:

• Base URL
• Environment
• Public ve authenticated route'lar
• Admin veya back-office route'ları
• API base path ve version'lar
• WebSocket endpoint'leri
• Callback ve webhook receiver'ları
• Upload ve download flow'ları
• Locale veya tenant bazlı route farklılıkları

IP ve CIDR

External veya internal network scope'u canonical CIDR olarak yazılmalıdır:

198.51.100.0/28
2001:db8:1200::/48
10.40.16.0/22

Başlangıç ve bitiş IP'sini serbest metinle yazmak, IPv6'yı unutmak veya NAT arkasındaki gerçek ownership'i belirtmemek coverage uyuşmazlığı üretir.

IP scope için şu alanlar gerekir:

• CIDR
• Environment veya network zone
• Ownership
• Hosting provider
• Aktif host discovery izni
• Port range
• UDP test kapsamı
• Load balancer veya reverse proxy bilgisi
• Shared hosting ihtimali
• Excluded address'ler

API

API scope'u yalnızca hostname değildir.

Şunlar belirtilmelidir:

• REST, GraphQL, gRPC, SOAP veya WebSocket
• API version'ları
• OpenAPI, Postman collection, GraphQL schema veya protobuf availability
• Authentication mechanism
• Kullanıcı ve service account rolleri
• Tenant sayısı
• Rate limit
• Idempotency behavior
• Async job ve message flow
• Webhook ve callback'ler
• Test data reset yöntemi
• Object ownership matrix

API1:2023 Broken Object Level Authorization gibi bir başlığın kapsamda olması, yalnızca birkaç ID değiştirileceği anlamına gelmez. Her object type, action, role ve tenant boundary ayrı test yüzeyi oluşturabilir.

Mobile application

Mobile scope şu öğeleri ayırmalıdır:

• Android package name
• iOS bundle ID
• Exact build number
• Distribution yöntemi
• Production veya test backend
• Test device ve OS version aralığı
• Rooted veya jailbroken device kullanımı
• Static analysis
• Dynamic analysis
• Local storage
• IPC ve deep link
• Network traffic
• Certificate pinning behavior
• Runtime instrumentation izni
• Backend API'nin ayrıca scope'a dahil olup olmadığı

OWASP MAS project, MASVS'i security verification standardı, MASTG'yi test süreçleri ve test case'leri için teknik guide olarak konumlandırır. Teklif “OWASP Mobile Top 10” gibi genel bir ifade yerine uygulanacak MASVS ve MASTG version'ını belirtmelidir.

Cloud

Cloud scope IP listesinden ibaret olamaz.

AWS, Azure veya Google Cloud environment için şu target türleri düşünülebilir:

• Organization
• Tenant
• Account veya subscription
• Project
• Region
• VPC veya VNet
• Kubernetes cluster
• IAM role
• Serverless function
• Storage service
• Managed database
• API gateway
• Secret store
• CI/CD identity
• Management plane
• Workload identity

Cloud asset'in müşteriye ait olması, provider infrastructure'ının da test edilebileceği anlamına gelmez. Shared responsibility boundary ve provider Rules of Engagement ayrı maddede doğrulanmalıdır.

In-scope kadar out-of-scope da açık yazılmalı

Out-of-scope listesi “diğer bütün sistemler” şeklinde bırakılmamalıdır. Özellikle bir in-scope asset'ten teknik olarak ulaşılabilen fakat test edilmesi istenmeyen bileşenler adlandırılmalıdır.

Örnek:

Out-of-scope:
- Üçüncü taraf payment provider domain'leri
- Production email delivery service
- 10.40.20.0/24 OT segmenti
- Corporate employee endpoint'leri
- DoS ve DDoS testleri
- Physical access
- Social engineering
- Gerçek müşteri hesabı üzerinde işlem
- Kalıcı persistence

Exclusion'ın güvenlik sonucuna etkisi de raporda görünmelidir.

Örneğin identity provider test dışındaysa application authentication'ının tamamının güvenli olduğu söylenemez. WAF allowlist nedeniyle test trafiği bypass ediliyorsa production prevention control'ünün etkinliği ölçülmez. API'nin yalnızca v2'si test edilmişse v1 için sonuç üretilemez.

İyi teklif her exclusion için şu alanları tutar:

Scope freeze ve scope change nasıl yönetilmeli?

Modern environment'lar test süresince değişir. Yeni deployment yapılır, autoscaling yeni IP üretir, API gateway route'u eklenir veya test sırasında bilinmeyen bir admin paneli bulunur.

Teklif şu üç durumu ayırmalıdır:

1. 1Scope clarification: Zaten onaylı target'ın daha net tanımlanması
2. 2Scope substitution: Bir target'ın çıkarılıp benzer efordaki başka target'ın eklenmesi
3. 3Scope expansion: Yeni effort ve risk üreten target'ın eklenmesi

Aktif test hiçbir zaman sözlü “buna da bakabilir misiniz” mesajıyla genişlememelidir.

Change record en az şunları içermelidir:

Change ID
Requested target
Ownership confirmation
Requested test action
Reason
Effort impact
Timeline impact
Safety impact
Approved by
Approval timestamp
Effective window

NCSC guidance, test sırasında scope dışında fakat güvenliği etkileyen bir component bulunduğunda scope değişikliği veya limitation kaydı arasında risk owner tarafından karar verilmesini önerir. Bu karar teklifin change control maddesinde önceden tanımlanmalıdır.

Test perspective açıkça seçilmeli

Black box, gray box ve white box yalnızca pazarlama etiketi değildir. Tester's knowledge, access ve test efficiency'sini değiştirir.

Black box

Tester'a minimum bilgi verilir. External attacker perspective ve discovery capability hakkında değerli signal üretebilir. Fakat zamanın önemli kısmı keşfe gider. Authenticated function, hidden API ve role matrix yeterince kapsanamayabilir.

Gray box

Mimari veya test account gibi sınırlı bilgi sağlanır. Çoğu web ve API sızma testi için verimli modeldir. Public attack surface korunurken authenticated flow ve authorization daha derin test edilir.

White box

Architecture, source code, configuration, test data ve geniş role seti paylaşılabilir. Coverage ve root cause kalitesi artar. Buna rağmen source code verilmesi tek başına secure code review teslim edildiği anlamına gelmez.

Teklif, seçilen box modelini şu alanlarla somutlaştırmalıdır:

• Paylaşılacak architecture document
• Source code access
• Build ve dependency bilgisi
• Test account sayısı
• Role ve permission matrix
• Tenant çeşitliliği
• API documentation
• Sample request
• Database schema
• Logging access
• WAF veya EDR visibility
• Developer interview

Bu üç modelin gerçekten ne gösterdiğini Black box, gray box, white box sızma testi yazımızda ayrıntılı karşılaştırıyoruz.

Credential ve role matrix teklifin parçası olmalı

“İki test kullanıcısı sağlanacaktır” yeterli değildir.

Authorization testi için her account'ın context'i bilinmelidir:

Tek account ile IDOR testi yapılabilir. Fakat object ownership ve cross-user isolation daha zayıf doğrulanır. Tek tenant ile multi-tenant isolation tam ölçülemez. Sadece admin account sağlanırsa low-privilege attack path görülmez.

Credential maddesi şunları da açıklamalıdır:

• Credential transfer yöntemi
• İlk login ve password reset süreci
• MFA enrolment
• OTP veya hardware token availability
• Account lockout koordinasyonu
• Test data üretimi
• Gerçek kullanıcı hesabı kullanım yasağı
• Test sonunda account disable ve credential rotation
• Service account secret yönetimi

Methodology adı değil, uygulanabilir test baseline'ı yazılmalı

Tekliflerde sık görülen cümle şudur:

Bu cümle tek başına coverage kanıtlamaz.

Teklif şu soruları cevaplamalıdır:

• Hangi framework kullanılacak?
• Hangi version kullanılacak?
• Framework hangi asset type için uygulanacak?
• Test case seçimi nasıl yapılacak?
• Applicability nasıl belirlenecek?
• Not Applicable ile Not Tested nasıl ayrılacak?
• Custom business logic testleri nasıl eklenecek?
• Framework dışındaki yeni attack surface nasıl ele alınacak?
• Coverage raporda nasıl gösterilecek?

Web application için

OWASP WSTG'nin current stable version'ı v4.2'dir. Proje aynı zamanda v5.0 üzerinde çalışmaktadır. Teklif yalnızca “latest” demek yerine version'ı sabitlemelidir.

Örnek:

Baseline: OWASP WSTG v4.2
Reference format: WSTG-v42-<category>-<number>
Supplemental requirements: OWASP ASVS v5.0.0 Level 2 selected controls
Custom tests: Business workflow and tenant authorization cases
Applicability record: Tested, Not Applicable, Not Tested, Blocked

OWASP, WSTG scenario ID'lerinin version ile birlikte kullanılmasını önerir. Bunun nedeni scenario numaralarının version'lar arasında değişebilmesidir.

Application security requirement için

OWASP ASVS 5.0.0, Mayıs 2025 tarihli current stable release'tir. ASVS, procurement sırasında application security verification requirement'larını sözleşmeye koymak için de kullanılabilir.

Fakat “ASVS Level 2 test edilecektir” cümlesi iki sebeple dikkatle yazılmalıdır:

1. 1Bütün ASVS requirement'ları black-box runtime test ile doğrulanamaz
2. 2Bazı requirement'lar architecture, source code, configuration veya process evidence gerektirir

Bu nedenle teklif şu ayrımı yapmalıdır:

Verified by dynamic testing
Verified by source review
Verified by configuration evidence
Customer attestation
Not Applicable
Not Tested

ASVS requirement ID'si version ile yazılmalıdır:

v5.0.0-1.2.5

Mobile için

OWASP MASVS, MASWE ve MASTG birlikte kullanılabilir. MASTG v2.0.0, 4 Temmuz 2026'da stable olarak yayımlandı. Teklif test case ID'lerini kullanılan version veya commit ile sabitlemeli ve Android ile iOS applicability'sini ayırmalıdır.

Network için

NIST SP 800-115, technical security testing'in planlanması, yürütülmesi, finding analysis ve mitigation geliştirilmesi için temel bir reference sunar. Ancak NIST adının yazılması tek başına port, protocol, authenticated configuration ve exploitation coverage'ını açıklamaz.

Network appendix şu alanları içermelidir:

• TCP port coverage
• UDP service coverage
• IPv4 ve IPv6
• Host discovery yöntemi
• Service enumeration
• TLS configuration
• Authenticated scanning
• Default veya weak credential policy
• Remote management interface
• Network device ve operating system
• Segmentation validation
• Controlled exploitation
• Privilege escalation
• Lateral movement sınırı
• Sensitive data access sınırı

OWASP Top 10 neden tek başına teknik kapsam değildir?

OWASP Top 10 bir awareness document'tır. Bir application'ın bütün test case'lerini veya acceptance criteria'sını tanımlamaz.

Örneğin access control başlığı altında şu farklı yüzeyler bulunabilir:

• Object-level authorization
• Function-level authorization
• Property-level authorization
• Cross-tenant access
• Workflow state bypass
• Admin route exposure
• Indirect object reference
• Bulk action authorization
• Export authorization
• WebSocket subscription
• GraphQL resolver authorization
• Background job ownership
• Signed URL scope

Teklif yalnızca “Broken Access Control test edilecek” diyorsa bu alt yüzeylerden hangilerinin test edildiği bilinmez.

Aynı durum SSRF için de geçerlidir. Bir URL input'una localhost yazılması, DNS rebinding, redirect handling, alternative IP notation, scheme handling, cloud metadata boundary ve async fetcher behavior'ının tamamını kapsamaz.

Framework coverage tabanı oluşturur. Threat model ve application-specific attack surface test derinliğini belirler.

Manual testing maddesi nasıl yazılmalı?

“Yüzde 80 manual, yüzde 20 automated test” gibi oranlar ikna edici görünür fakat ölçülebilir değildir.

Bir HTTP request Burp Suite üzerinden gönderildiğinde manual mı sayılır? Scanner'ın ürettiği finding pentester tarafından tekrarlandığında oran nasıl hesaplanır? Script ile role matrix gezildiğinde automated mı olur?

Daha iyi madde activity ve output üzerinden yazılır:

• Automated discovery ve baseline scanning kullanılabilir
• Bütün raporlanabilir bulgular tester tarafından doğrulanır
• Business logic, authorization, session ve workflow testleri manual olarak tasarlanır
• Scanner output'u doğrudan final finding olarak aktarılmaz
• Her finding için reproducible evidence bulunur
• Tool limitation ve blocked test'ler coverage matrix'te gösterilir
• Custom test case'ler application behavior'a göre oluşturulur

Manual validation şartı “hiç false positive olmayacak” garantisi değildir. Karmaşık environment, race condition, intermittent dependency veya customer-side configuration değişikliği nedeniyle yeniden üretim farkı oluşabilir.

Profesyonel kabul kriteri şudur:

Test depth nasıl sözleşmeye bağlanır?

Test depth “ileri seviye” gibi sıfatlarla tanımlanamaz.

Her service type için beklenen activity yazılmalıdır.

Web ve API

• Attack surface mapping
• Authentication flow
• Session lifecycle
• Horizontal ve vertical authorization
• Tenant isolation
• Input validation
• Injection class'ları
• File upload ve file processing
• Server-side fetch
• Deserialization
• Cache behavior
• Race condition
• Business logic
• API inventory
• Undocumented endpoint
• GraphQL veya WebSocket behavior
• Rate limit ve abuse control
• Security header ve transport
• Error handling
• Sensitive data exposure

External network

• Passive ve active discovery
• DNS ve certificate relation
• Public service enumeration
• Management interface exposure
• Service version ve configuration
• TLS ve protocol review
• Authentication control
• Known vulnerability validation
• Controlled exploitation
• Public cloud asset correlation
• Shadow IT observation

Internal network

• Network discovery
• Segmentation
• Active Directory
• LDAP ve Kerberos
• SMB ve remote management
• Certificate service
• Local admin reuse
• Service account exposure
• Share permission
• Privilege escalation
• Lateral movement
• Trust relationship
• Critical asset access boundary

Bu liste tester'a exploit reçetesi vermez. Alıcının hangi yüzey için assurance beklediğini gösterir.

Exploitation sınırı açıkça yazılmalı

Sızma testini vulnerability scan'den ayıran noktalardan biri, bulgunun kontrollü exploitation ile doğrulanabilmesidir. Fakat “bütün açıklar istismar edilecektir” maddesi güvenli değildir.

Exploit depth seviyeleri tanımlanabilir:

Her finding E4'e çıkarılmamalıdır. Minimum necessary evidence ilkesi kullanılmalıdır.

Örneğin bir authorization weakness, yalnızca tester tarafından oluşturulmuş başka bir test account'ın kaydına erişilerek doğrulanabiliyorsa gerçek müşteri verisi çekilmemelidir. SQL injection için bir satır version veya controlled expression yeterliyse bütün tablo export edilmemelidir. Command execution marker ile doğrulanabiliyorsa persistence kurulmasına gerek yoktur.

Teklif şu high-impact action'ları ayrı izin maddesine bağlamalıdır:

• Credential dumping
• Password spraying
• Malware execution
• Persistence
• Data modification
• Data deletion
• Bulk extraction
• Lateral movement
• Privilege escalation
• Security control disable
• Phishing
• Social engineering
• DoS veya DDoS
• Physical access

“Gerekli görülürse yapılır” ifadesi yazılı authorization yerine geçmez.

Rules of Engagement bölümünde hangi maddeler olmalı?

Rules of Engagement, testin güvenli execution contract'idir.

En az şu başlıkları içermelidir.

Yazılı authorization

• Yetki veren tüzel kişi
• Yetkili risk owner
• Scope ownership beyanı
• Third-party authorization
• Authorization reference
• Geçerlilik başlangıç ve bitişi
• Yetkili tester veya sağlayıcı
• İzin verilen test türü

Test source

• Source IPv4
• Source IPv6
• Cloud egress IP
• VPN veya jump host
• User-Agent veya test header
• Scanner ve manual traffic ayrımı

Source IP yalnızca SOC allowlist için değil, abuse report ve incident deconfliction için de gereklidir.

Test window

Test window timezone içermelidir:

2026-08-03T22:00:00+03:00
2026-08-04T04:00:00+03:00

“Mesai saatleri dışında” ifadesi yaz saati, resmi tatil, hafta sonu ve global operation için belirsizdir.

İletişim

• Technical contact
• Incident contact
• Risk owner
• Provider engagement lead
• Secure messaging channel
• Telefon
• Email
• Backup contact
• Availability window

Critical finding notification

Final rapor beklenmemelidir.

Örnek:

Critical notification SLA: doğrulamadan sonra 30 dakika
Notification channel: telefon ve encrypted portal
Minimum content: affected asset, observed impact, immediate containment option
Full evidence: güvenli kanal üzerinden takip kaydı

Her high CVSS bulgusu otomatik emergency olmayabilir. Notification condition ayrıca tanımlanmalıdır:

• Active compromise evidence
• Public unauthenticated RCE
• Cross-tenant data access
• Bulk personal data exposure
• Privileged credential disclosure
• Production safety riski
• Third-party impact

Stop condition

Stop condition ölçülebilir olmalıdır:

• Unexpected service degradation
• Error rate threshold aşımı
• Cross-tenant gerçek veri görünmesi
• Gerçek transaction oluşması
• Monitoring ekibinin incident declare etmesi
• Test source'un yanlış asset'e yönelmesi
• Scope ownership'in belirsizleşmesi
• Provider policy ihlali ihtimali
• Customer incident contact'ın durdurma talebi

Stop olduğunda kim karar verecek, test ne kadar sürede duracak, resume için kim onay verecek ve mevcut artifact'ler nasıl korunacak yazılmalıdır.

Production test güvenliği nasıl tarif edilmeli?

“Sistemlere zarar verilmeyecektir” bir niyettir, control değildir.

Production safety için teknik maddeler gerekir:

• Request rate
• Concurrent connection
• Payload size
• Upload file size
• Recursive discovery depth
• Fuzzing limit
• Account lockout threshold
• Password test rate
• Transaction value limit
• Test record prefix
• Email ve SMS suppression
• Cleanup yöntemi
• Backup doğrulaması
• Monitoring readiness
• Rollback owner
• Kill switch

Örnek:

Maximum request rate: target başına 5 request/second
Maximum concurrency: target başına 2 connection
Password spraying: kapsam dışı
DoS ve resource exhaustion: kapsam dışı
Test data prefix: SNX-PT-2026-
Email delivery: sandbox mailbox ile sınırlandırılacak
Bulk export: en fazla 3 synthetic record
Cleanup: tester ve application owner birlikte doğrulayacak

Bu değerler evrensel doğru değildir. Application capacity, environment ve test objective'e göre belirlenir. Önemli olan limitsiz bırakılmamasıdır.

WAF allowlist kaliteyi artırır mı, düşürür mü?

Tek bir doğru yoktur.

WAF allowlist yapılmazsa test edge control'ün arkasından gerçek production perspective'i ölçer. Fakat WAF aynı payload'ları erken block ederse origin application'daki weakness'ler yeterince değerlendirilemeyebilir.

İki phase kullanılabilir:

1. 1Normal control phase: WAF ve rate limit aktif
2. 2Origin assessment phase: Onaylı test source için kontrollü bypass

Rapor sonuçları ayrılmalıdır:

• WAF tarafından prevent edilen behavior
• Origin'de mevcut olan vulnerability
• WAF bypass edildiğinde doğrulanan impact
• WAF'e bağımlı compensating control

Teklif sadece “IP allowlist edilecektir” derse hangi security claim'in kaybedildiği belirsiz kalır.

Cloud provider koşulları teklif içinde neden yer almalı?

Cloud asset için müşteri authorization'ı zorunludur fakat her zaman yeterli değildir.

AWS, belirli permitted service'lerde ön onay olmadan customer-owned infrastructure testine izin verir. Buna karşılık AWS service'in kendisinin test edilmesine izin vermez. C2 içeren security testing için prior approval ister ve DoS türü action'ları yasaklar.

Microsoft Azure, customer-owned resource'larda ön onay gerektirmese de Microsoft Cloud Unified Penetration Testing Rules of Engagement'e uyulmasını ister. DoS testleri bu genel pentest izninin dışındadır.

Bu nedenle teklif cloud appendix'inde şu alanlar bulunmalıdır:

Cloud provider
Tenant, account, subscription veya project ID
Resource owner
Permitted service
Provider policy URL ve review date
Prior approval requirement
Prohibited action
Abuse contact
Testing source
Region
Shared responsibility boundary

Provider policy zamanla değişebilir. Teklifte sabit bir varsayım yerine review date tutulmalıdır.

Veri koruma ve evidence handling maddeleri

Sızma testi sırasında şu veriler oluşabilir:

• HTTP request ve response
• Session token
• Credential
• Screenshot
• Database sample
• Log
• Network capture
• Mobile application artifact
• Source code excerpt
• Cloud configuration
• Personal data
• Özel nitelikli personal data
• Customer secret
• Exploit artifact

“Gizlilik sözleşmesi imzalanacaktır” bunların nasıl korunacağını açıklamaz.

Teklif veya security appendix şu maddeleri içermelidir:

Data minimization

• Gerçek veri yalnızca impact için zorunluysa görüntülenir
• Mümkünse synthetic test data kullanılır
• Bulk extraction yapılmaz
• Evidence için minimum record alınır
• Gereksiz token ve personal data redact edilir

Storage

• Evidence'in tutulacağı platform
• At-rest encryption
• Key ownership
• Role-based access
• MFA
• Audit log
• Local endpoint storage policy
• Backup kopyası

Transfer

• Approved portal
• Encrypted archive
• Key'in ayrı kanaldan iletilmesi
• Email attachment yasağı
• API veya SFTP seçeneği
• Customer-side access log

Retention ve deletion

• Active test sırasında retention
• Final report sonrası retention
• Retest nedeniyle uzatma
• Backup'tan silinme süresi
• Legal hold exception
• Deletion confirmation

Subprocessor ve AI kullanımı

• Evidence üçüncü taraf SaaS'e aktarılıyor mu?
• Report drafting için external AI service kullanılıyor mu?
• Prompt veya telemetry içinde customer data bulunuyor mu?
• Model training için veri kullanılıyor mu?
• Data region neresi?
• Subprocessor listesi nedir?

Bu sorular 2026 yılında “araç detayına karışmak” değildir. Sızma testi sağlayıcısı customer secret ve active session token işleyebilir.

KVKK'nın veri güvenliğine ilişkin açıklamasına göre veri sorumlusu, kendi adına başka bir kişi tarafından personal data işlendiğinde gerekli teknik ve idari tedbirler bakımından bu kişiyle birlikte sorumludur. Bu nedenle data handling maddesi yalnızca sağlayıcının iç prosedürüne bırakılamaz.

Finding evidence standardı nasıl olmalı?

Her finding şu alanları taşımalıdır:

Finding ID
Title
Affected asset
Environment
First observed timestamp
Last verified timestamp
Prerequisite
Attack perspective
Technical description
Reproduction
Evidence
Observed impact
Potential impact
CVSS version, score ve vector
Business context
CWE veya ilgili taxonomy
WSTG, ASVS veya MASVS mapping
Remediation
Verification guidance
Limitations

Screenshot tek başına evidence değildir. Request ve response içermeyen “IDOR bulundu” ekran görüntüsü developer'ın sorunu tekrar üretmesini zorlaştırır.

Diğer taraftan rapora bütün session token'ı veya gerçek personal data'yı koymak da doğru değildir. Evidence reproducible ve minimum olmalıdır.

Evidence integrity

Yüksek assurance gerektiren engagement'larda şu alanlar eklenebilir:

• Artifact hash
• Capture timestamp
• Tester identity
• Tool version
• Target build
• Evidence redaction log
• Chain of custody

Bu yaklaşım özellikle regulated environment, incident sonrası test veya finding'in hukuki sürece girebileceği durumlarda önemlidir.

CVSS maddesi nasıl yazılmalı?

“Bulgular CVSS ile puanlanacaktır” eksiktir.

Teklif şu ayrıntıları belirtmelidir:

• CVSS version
• Score ile birlikte vector
• Base, Threat ve Environmental kullanım durumu
• Business priority'nin CVSS'ten ayrı olup olmadığı
• Severity override yetkisi
• Override gerekçesinin raporda gösterilmesi
• Chained finding scoring yaklaşımı

FIRST tarafından yayımlanan current CVSS sürümü 4.0'dır. CVSS v4.0 Base, Threat, Environmental ve Supplemental metric gruplarını ayırır. FIRST, score yayımlandığında vector string'in de verilmesini ister.

Örnek:

CVSS-B: 8.6
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Business priority: Critical
Priority reason: Cross-tenant financial record modification

CVSS technical severity'dir. Asset criticality, regulatory impact, customer sayısı, fraud potential ve existing control gibi business context ayrıca değerlendirilmelidir.

Teklif “müşteri severity'yi istediği gibi değiştirebilir” dememelidir. Bunun yerine:

• Original technical score korunur
• Customer environment context ayrı alanda eklenir
• Severity adjustment gerekçeli ve traceable olur
• Finding teknik gerçekliği değişmeden business priority güncellenir

Finding grouping ve duplicate policy belirlenmeli

Aynı root cause yüz endpoint'te görülürse yüz finding mi, tek finding mi oluşturulacak?

Tek bir report item altında gruplamak executive readability sağlar. Fakat affected asset listesi kaybolursa remediation ve retest zorlaşır.

Teklif şu modeli tanımlayabilir:

• Ortak root cause için parent finding
• Her asset veya route için affected instance
• Instance bazında evidence status
• Severity parent seviyesinde
• Remediation owner instance bazında
• Retest sonucu instance bazında

Önceki testte bulunan issue tekrar görülürse duplicate diye rapordan çıkarılmamalıdır. “Previously reported, still open” olarak görünmelidir. Aksi hâlde current risk report'tan kaybolur.

Risk accepted finding için de aynı yaklaşım geçerlidir:

• Finding teknik olarak raporlanır
• Risk acceptance owner ve expiry eklenir
• Retest'te technical state ayrıca gösterilir

Report deliverable maddeleri

Tek bir PDF her stakeholder için yeterli olmayabilir.

Profesyonel teklif şu deliverable'ları ayırabilir:

Executive report

• Objective
• Scope
• Overall risk
• Critical attack path
• Business impact
• Systemic theme
• Key limitation
• Prioritized action

Technical report

• Finding detail
• Evidence
• Reproduction
• Severity
• Remediation
• Mapping
• Affected instance

Coverage matrix

Her test alanı şu state'lerden biriyle işaretlenebilir:

Tested - Passed
Tested - Finding
Not Applicable
Not Tested
Blocked
Partially Tested

“Not Applicable” ile “Not Tested” aynı değildir.

Not Applicable, test case'in target mimarisine uygulanmadığını gösterir. Not Tested ise uygulanabilir olduğu hâlde test edilmediğini gösterir. Blocked ise credential, environment, WAF, time veya dependency nedeniyle tamamlanamadığını belirtir.

Limitations register

• Ulaşılamayan target
• Çalışmayan account
• Eksik role
• Test sırasında değişen build
• Rate limit nedeniyle daralan coverage
• WAF nedeniyle block
• Third-party exclusion
• Test window kaybı
• Eksik API document

Raw veya structured export

• CSV veya JSON finding export
• Asset listesi
• Severity
• Owner
• Status
• CWE
• CVSS vector
• Retest result

Machine-readable output, finding'lerin issue tracker ve vulnerability management platformuna aktarılmasını kolaylaştırır.

Debrief

NCSC model engagement'ı initial engagement, scoping, testing, reporting ve follow-up olarak ele alır. Final debrief yalnızca rapor sunumu değildir. Finding assumption'larının, limitation'ların ve remediation seçeneklerinin konuşulduğu teknik kapanıştır.

Retest maddesi nasıl yazılmalı?

“Bir kez ücretsiz retest dahildir” başlangıçtır fakat yeterli değildir.

Şu sorular cevaplanmalıdır:

• Retest hangi finding'leri kapsar?
• Kaç cycle dahildir?
• Hangi süre içinde kullanılmalıdır?
• Müşteri finding ID bazında hazır olduğunu nasıl bildirir?
• Değişen asset veya route yeni scope sayılır mı?
• Root cause fix nedeniyle başka flow'lar da kontrol edilir mi?
• Compensating control kabul edilir mi?
• Partial fix nasıl raporlanır?
• Yeni vulnerability görülürse ne olur?
• Retest report veya updated report teslim edilir mi?

Dar verification ile regression aynı şey değildir

Bir IDOR finding'inin ilk PoC'si artık çalışmıyorsa problem tamamen kapanmış olmayabilir.

Retest şu soruları değerlendirebilir:

• Aynı object type'ın diğer endpoint'leri etkileniyor mu?
• Read kapandı fakat update veya delete açık mı?
• Same-tenant kontrol var fakat cross-tenant kontrol eksik mi?
• UI kapandı fakat API route'u açık mı?
• Yeni endpoint eski service method'u kullanıyor mu?
• Fix client-side mı, server-side mı?

Teklif retest'in sadece original reproduction step'i mi, yoksa reasonable variation setini mi kapsadığını belirtmelidir.

Kapanış state'leri şu şekilde olabilir:

Critical finding escalation ile rapor teslim SLA'i ayrılmalı

Teklif iki farklı zamanı tanımlamalıdır:

1. 1Finding'in doğrulanmasından critical notification'a kadar geçen süre
2. 2Active test bitişinden draft veya final report'a kadar geçen süre

Örnek:

Critical notification: 30 dakika
Daily status: Her test günü sonunda
Draft technical report: Active test bitişinden sonra 5 iş günü
Customer factual review: 3 iş günü
Final report: Review comment'lerinden sonra 2 iş günü
Retest report: Retest bitişinden sonra 3 iş günü

Factual review, müşterinin finding'i gerekçesiz kaldırdığı bir pazarlık aşaması değildir. Asset adı, environment, business context veya technical assumption hatalarının düzeltilmesi için kullanılır.

Tester yetkinliği nasıl sorulmalı?

Sertifika listesi yararlıdır fakat tek başına yeterli değildir.

Teklif şu alanları içermelidir:

• Engagement lead
• Named tester veya role
• İlgili asset type deneyimi
• Kullanılacak dil
• Sector experience
• Relevant certification
• Quality reviewer
• Conflict of interest
• Subcontractor durumu
• Personel değişikliğinde approval

Mobil test için yalnızca network pentest deneyimi, Active Directory için yalnızca web security deneyimi yeterli değildir.

NCSC, test kalitesinin tester yeteneğiyle yakından ilişkili olduğunu ve unusual system'lerin bid sürecinde belirtilmesi gerektiğini vurgular. Mainframe, OT protocol, custom hardware, thick client, SAP, Kubernetes veya özel cryptographic protocol scope'taysa ilgili uzmanlık daha teklif aşamasında doğrulanmalıdır.

Subcontractor maddesi

• Hangi iş subcontract edilecek?
• Müşteri ön onayı gerekiyor mu?
• Data access olacak mı?
• Hangi ülkeden erişilecek?
• Aynı confidentiality ve security requirement uygulanacak mı?
• Evidence hangi platformda tutulacak?
• Final quality responsibility kimde?

Logo sahibi sağlayıcı ile testi fiilen yapan ekip farklıysa müşteri bunu bilmelidir.

Efor nasıl hesaplanmalı?

Sızma testinde fiyatı target sayısı tek başına belirlemez.

Eforu etkileyen teknik faktörler:

• Attack surface
• Role sayısı
• Tenant sayısı
• API endpoint ve object type
• Business workflow
• Platform çeşitliliği
• Authentication complexity
• MFA
• Environment stability
• Documentation quality
• Test window
• Production constraint
• Retest depth
• Reporting format
• Regulatory mapping
• On-site gereksinimi

İki application aynı URL sayısına sahip olabilir. Birinde yalnızca public form bulunur. Diğerinde on role, multi-tenant authorization, payment, file processing, GraphQL ve WebSocket vardır.

Teklif efor assumption'larını görünür yapmalıdır:

2 tenant
5 role
120 documented API endpoint
1 web frontend
1 admin interface
No source code review
Production testing with 5 request/second limit
1 retest cycle
English and Turkish report

Bu assumption değişirse eforun hangi koşulda değişeceği önceden yazılmalıdır.

Customer dependency maddeleri

Testin başarısız olması her zaman tester yetersizliği değildir. Account çalışmıyorsa, VPN açılmadıysa veya build test sırasında değişiyorsa coverage düşer.

Teklif müşteri sorumluluklarını da teknik olarak tanımlamalıdır:

• Ownership approval
• Scope manifest
• Architecture
• Credential
• MFA
• Test data
• VPN
• Source IP allowlist
• Cloud permission
• Third-party permission
• Monitoring contact
• Backup
• Change freeze
• Build identifier
• Issue tracker access

Dependency için due date ve impact yazılmalıdır:

Idle day ve rescheduling policy ticari olduğu kadar teknik bir konudur. Eforun environment problemi nedeniyle kaybolup kaybolmayacağı teklif içinde açık olmalıdır.

Environment ve build identity neden zorunlu?

Rapor şu soruya cevap verebilmelidir:

En az şu alanlar kaydedilebilir:

• Application version
• Build number
• Git commit
• Container image digest
• API version
• Mobile build
• Infrastructure release
• WAF policy version
• Test başlangıç ve bitişi

Test sırasında deployment yapılırsa bazı finding'ler eski, bazıları yeni build'e ait olabilir. Teklif change freeze talep edebilir veya her deployment sonrası build marker kaydı tutabilir.

Staging test sonucu production'a otomatik genellenemez. Config, data, integration, WAF, identity ve network boundary farklı olabilir.

Yayına çıkış, büyük değişiklik ve olay sonrası test zamanlamasını Sızma testi ne zaman yaptırılmalı? yazımızda ayrı olarak ele alıyoruz.

Machine-readable scope contract örneği

Scope'un Word tablosunda bulunması insan review için yararlıdır. Aynı scope'un JSON veya YAML olarak tutulması ise otomasyon, change control ve yanlış target riskini azaltır.

Aşağıdaki örnekte kullanılan IP ve domain'ler documentation için ayrılmıştır:

{
  "contract_version": "1.0",
  "engagement_id": "SNX-PT-2026-042",
  "authorization_reference": "AUTH-2026-118",
  "targets": [
    {
      "type": "fqdn",
      "value": "app.example.com",
      "environment": "production"
    },
    {
      "type": "ipv4_cidr",
      "value": "192.0.2.0/28",
      "environment": "production"
    },
    {
      "type": "cloud_resource",
      "value": "aws:account:123456789012",
      "environment": "production"
    }
  ],
  "source_ips": [
    "198.51.100.10",
    "2001:db8::10"
  ],
  "testing_windows": [
    {
      "start": "2026-08-03T22:00:00+03:00",
      "end": "2026-08-04T04:00:00+03:00"
    }
  ],
  "allowed_actions": [
    "authenticated_testing",
    "controlled_exploitation"
  ],
  "prohibited_actions": [
    "denial_of_service",
    "destructive_data_change",
    "persistence"
  ],
  "high_impact_authorization": {},
  "rate_limits": {
    "requests_per_second": 5,
    "concurrent_requests": 2
  },
  "critical_notification_minutes": 30,
  "data_retention_days": 30,
  "contacts": {
    "technical": {
      "name": "Technical Contact",
      "email": "technical@example.com",
      "phone": "+90 212 000 00 00"
    },
    "incident": {
      "name": "Incident Contact",
      "email": "incident@example.com",
      "phone": "+90 212 000 00 01"
    }
  },
  "stop_conditions": [
    "unexpected service degradation",
    "cross-tenant data exposure",
    "incident contact requests stop"
  ],
  "report_requirements": {
    "coverage_matrix": true,
    "cvss_vector": true,
    "evidence_per_finding": true,
    "limitations": true
  },
  "retest": {
    "included": true,
    "included_cycles": 1,
    "window_days": 45
  },
  "manual_validation_required": true,
  "scope_change_requires_written_approval": true,
  "cloud_provider_rules_reviewed": true
}

Bu document imzalı teklifin yerine geçmez. Onaylı scope'un teknik sistemler tarafından da okunabilir representation'ıdır.

Fail-closed scope validator

Aşağıdaki Python 3.12 örneği, scope contract'taki kritik tutarsızlıkları execution başlamadan önce durdurur.

Kontrol edilen başlıca durumlar:

• Duplicate target
• Canonical olmayan CIDR
• CIDR olarak yazılmış source IP
• Timezone içermeyen test window
• Başlangıçtan önce biten window
• Aynı action'ın hem allowed hem prohibited olması
• Explicit authorization olmadan high-impact action
• Cloud target için provider rule review eksikliği
• Rapor evidence requirement'larının kapatılması

from __future__ import annotations

from datetime import datetime
from hashlib import sha256
from ipaddress import ip_address, ip_network
import json
import re
from typing import Any
from urllib.parse import urlsplit


HIGH_IMPACT = {
    "credential_dumping",
    "destructive_data_change",
    "denial_of_service",
    "persistence",
}

REPORT_FLAGS = {
    "coverage_matrix",
    "cvss_vector",
    "evidence_per_finding",
    "limitations",
}

FQDN_LABEL = re.compile(
    r"^(?!-)[a-z0-9-]{1,63}(?<!-)$"
)


def require(condition: bool, message: str) -> None:
    if not condition:
        raise ValueError(message)


def text(value: Any, field: str) -> str:
    require(
        isinstance(value, str) and bool(value.strip()),
        f"{field} must be a non-empty string",
    )
    return value.strip()


def unique_strings(value: Any, field: str) -> list[str]:
    require(isinstance(value, list), f"{field} must be a list")
    values = [text(item, field) for item in value]
    require(values, f"{field} cannot be empty")
    require(
        len(values) == len(set(values)),
        f"{field} cannot contain duplicates",
    )
    return values


def fqdn(value: str, field: str) -> str:
    candidate = text(value, field).lower().rstrip(".")
    try:
        ascii_name = candidate.encode("idna").decode("ascii")
    except UnicodeError as error:
        raise ValueError(f"{field} is not a valid IDN") from error
    labels = ascii_name.split(".")
    require(
        len(ascii_name) <= 253
        and len(labels) >= 2
        and all(FQDN_LABEL.fullmatch(label) for label in labels),
        f"{field} is not a valid FQDN",
    )
    return ascii_name


def target_key(target: Any, index: int) -> tuple[str, str, str]:
    field = f"targets[{index}]"
    require(isinstance(target, dict), f"{field} must be an object")
    kind = text(target.get("type"), f"{field}.type")
    value = text(target.get("value"), f"{field}.value")
    environment = text(
        target.get("environment"),
        f"{field}.environment",
    ).lower()
    require(
        environment in {"production", "staging", "test"},
        f"{field}.environment is unsupported",
    )

    if kind == "fqdn":
        normalized = fqdn(value, f"{field}.value")
    elif kind == "wildcard_fqdn":
        require(value.startswith("*."), f"{field} must start with *.")
        normalized = "*." + fqdn(value[2:], f"{field}.value")
    elif kind in {"ipv4_cidr", "ipv6_cidr"}:
        try:
            network = ip_network(value, strict=True)
        except ValueError as error:
            raise ValueError(
                f"{field}.value must be a canonical CIDR"
            ) from error
        expected = 4 if kind == "ipv4_cidr" else 6
        require(network.version == expected, f"{field} IP mismatch")
        normalized = str(network)
    elif kind == "url":
        parsed = urlsplit(value)
        require(
            parsed.scheme in {"http", "https"}
            and parsed.hostname is not None
            and parsed.username is None
            and parsed.password is None
            and not parsed.query
            and not parsed.fragment,
            f"{field}.value is not an approved scope URL",
        )
        fqdn(parsed.hostname, f"{field}.hostname")
        normalized = value
    elif kind in {"cloud_resource", "mobile_build"}:
        normalized = value
    else:
        raise ValueError(f"{field}.type is unsupported")

    return kind, normalized, environment


def moment(value: Any, field: str) -> datetime:
    try:
        parsed = datetime.fromisoformat(
            text(value, field).replace("Z", "+00:00")
        )
    except ValueError as error:
        raise ValueError(f"{field} must be ISO 8601") from error
    require(
        parsed.tzinfo is not None
        and parsed.utcoffset() is not None,
        f"{field} must include a timezone",
    )
    return parsed


def positive_int(
    value: Any,
    field: str,
    maximum: int | None = None,
) -> int:
    require(
        isinstance(value, int)
        and not isinstance(value, bool)
        and value > 0,
        f"{field} must be a positive integer",
    )
    if maximum is not None:
        require(value <= maximum, f"{field} exceeds {maximum}")
    return value


def validate(contract: dict[str, Any]) -> str:
    require(isinstance(contract, dict), "contract must be an object")
    text(contract.get("contract_version"), "contract_version")
    text(contract.get("engagement_id"), "engagement_id")
    text(
        contract.get("authorization_reference"),
        "authorization_reference",
    )

    targets = contract.get("targets")
    require(
        isinstance(targets, list) and bool(targets),
        "targets must be a non-empty list",
    )
    keys = [
        target_key(target, index)
        for index, target in enumerate(targets)
    ]
    require(
        len(keys) == len(set(keys)),
        "targets cannot contain duplicates",
    )

    for index, value in enumerate(
        unique_strings(contract.get("source_ips"), "source_ips")
    ):
        try:
            ip_address(value)
        except ValueError as error:
            raise ValueError(
                f"source_ips[{index}] must be a literal IP"
            ) from error

    windows = contract.get("testing_windows")
    require(
        isinstance(windows, list) and bool(windows),
        "testing_windows must be a non-empty list",
    )
    for index, window in enumerate(windows):
        require(isinstance(window, dict), "window must be an object")
        start = moment(
            window.get("start"),
            f"testing_windows[{index}].start",
        )
        end = moment(
            window.get("end"),
            f"testing_windows[{index}].end",
        )
        require(end > start, "test window end must follow start")

    allowed = set(
        unique_strings(
            contract.get("allowed_actions"),
            "allowed_actions",
        )
    )
    prohibited = set(
        unique_strings(
            contract.get("prohibited_actions"),
            "prohibited_actions",
        )
    )
    require(
        not allowed & prohibited,
        "an action cannot be both allowed and prohibited",
    )
    approvals = contract.get("high_impact_authorization", {})
    require(isinstance(approvals, dict), "approvals must be an object")
    for action in sorted(allowed & HIGH_IMPACT):
        require(
            approvals.get(action) is True,
            f"{action} requires explicit authorization",
        )

    limits = contract.get("rate_limits")
    require(isinstance(limits, dict), "rate_limits must be an object")
    positive_int(
        limits.get("requests_per_second"),
        "requests_per_second",
    )
    positive_int(
        limits.get("concurrent_requests"),
        "concurrent_requests",
    )
    positive_int(
        contract.get("critical_notification_minutes"),
        "critical_notification_minutes",
        maximum=1440,
    )

    report = contract.get("report_requirements")
    require(isinstance(report, dict), "report must be an object")
    for flag in REPORT_FLAGS:
        require(report.get(flag) is True, f"{flag} must be true")

    require(
        contract.get("manual_validation_required") is True,
        "manual validation must be required",
    )
    require(
        contract.get("scope_change_requires_written_approval") is True,
        "scope change must require written approval",
    )
    if any(kind == "cloud_resource" for kind, _, _ in keys):
        require(
            contract.get("cloud_provider_rules_reviewed") is True,
            "cloud provider rules must be reviewed",
        )

    canonical = json.dumps(
        contract,
        ensure_ascii=False,
        sort_keys=True,
        separators=(",", ":"),
    ).encode("utf-8")
    return sha256(canonical).hexdigest()

Kod fail-open davranmaz. Örneğin 192.0.2.7/28 gibi host bitleri içeren bir değer canonical network olarak kabul edilmez. Source IP alanına /24 yazılırsa test kaynağını gereğinden geniş tanımladığı için reddedilir.

On test senaryosu şu durumları doğruladı:

1. 1Valid contract için stable SHA-256 fingerprint
2. 2Duplicate target rejection
3. 3Canonical olmayan CIDR rejection
4. 4Source IP yerine CIDR verilmesinin rejection'ı
5. 5Timezone zorunluluğu
6. 6Test window sıralaması
7. 7Allowed ve prohibited action çakışması
8. 8High-impact action için explicit authorization
9. 9Cloud provider rule review zorunluluğu
10. 10Report evidence flag'lerinin zorunluluğu

Fingerprint, imzalı hukuki onay değildir. Onaylanan scope version'ı ile execution engine'in kullandığı scope'un aynı olup olmadığını karşılaştırmaya yardımcı olur.

Acceptance criteria nasıl yazılmalı?

Bir penetration test “rapor teslim edildiğinde” teknik olarak kabul edilmiş sayılmamalıdır. Report presence ile report quality aynı değildir.

Ölçülebilir acceptance criteria örneği:

Acceptance “hiç açık bulunmaması” şartına bağlanamaz. Hiç finding çıkmaması güvenli sistem anlamına gelebileceği gibi çalışmayan account, erişilemeyen route veya yetersiz test depth anlamına da gelebilir.

Bu nedenle zero-finding report şu ek kanıtları taşımalıdır:

• Test edilen target listesi
• Test edilen role'ler
• Coverage matrix
• Test window
• Tool ve manual activity özeti
• Blocked case'ler
• Limitation
• Tester ve reviewer

Teklif karşılaştırma scorecard'ı

Fiyat dışındaki teknik kriterlere weight verilebilir.

Her criterion için 0 ile 5 arasında scoring yapılabilir:

0 = Yok
1 = Genel ifade
2 = Kısmen tanımlı
3 = Uygulanabilir
4 = Ölçülebilir ve kanıtlanabilir
5 = Ölçülebilir, risk bazlı ve change control ile yönetiliyor

En düşük fiyatı otomatik seçmek yerine teknik olarak karşılaştırılabilir bir değerlendirme oluşur.

Teklifte bulunmaması gereken yanıltıcı ifadeler

“Tüm güvenlik açıkları bulunacaktır”

Hiçbir point-in-time test bütün vulnerability'leri garanti edemez. Scope, timebox, environment, test perspective ve teknik limitation vardır.

“Yüzde 100 güvenlik sağlanacaktır”

Sızma testi security assurance üretir. Mutlak güvenlik garantisi vermez.

“OWASP sertifikalı test”

OWASP framework yayımlar. Belirli sağlayıcının pentest hizmetini sertifikalandırdığı şeklinde bir ifade kullanılmamalıdır.

“ISO 27001 uyumlu sızma testi”

Hangi control, scope ve audit evidence ihtiyacının hedeflendiği açıklanmadan bu ifade belirsizdir. ISO certification ile penetration test depth aynı şey değildir.

“False positive bulunmayacaktır”

Manual validation zorunlu tutulabilir. Mutlak hata olmama garantisi yerine evidence ve correction process tanımlanmalıdır.

“Unlimited retest”

Süre, aynı root cause, aynı environment, yeni feature ve regression sınırı yazılmadan unlimited kelimesi teknik anlam taşımaz.

“Gerekli görülen tüm testler”

Kimin gerekli gördüğü, hangi framework ve hangi risk modeline göre karar verdiği açıklanmalıdır.

Web application teklifi için minimum teknik appendix

1. 1Base URL ve environment
2. 2Related API, WebSocket ve admin surface
3. 3Role ve tenant matrix
4. 4Authentication ve MFA flow
5. 5Test data
6. 6WSTG version
7. 7ASVS selected requirement'ları
8. 8Business logic workflow
9. 9File upload ve server-side processing
10. 10Controlled exploitation sınırı
11. 11WAF phase
12. 12Request rate
13. 13Critical notification
14. 14Evidence standardı
15. 15Coverage matrix
16. 16Retest variation seti

Web scope'un nasıl çıkarılacağını Web uygulaması sızma testinde kapsam nasıl belirlenir? yazımızda route, role, tenant ve integration düzeyinde inceliyoruz.

API teklifi için minimum teknik appendix

1. 1Protocol ve version
2. 2Base path
3. 3OpenAPI veya collection
4. 4Undocumented endpoint discovery
5. 5User ve machine identity
6. 6OAuth scope
7. 7Object ve property authorization
8. 8Tenant isolation
9. 9Rate limit
10. 10Async job
11. 11Webhook
12. 12GraphQL veya WebSocket
13. 13Mass assignment
14. 14Unsafe downstream API consumption
15. 15Test data reset
16. 16Endpoint coverage export

Mobile teklifi için minimum teknik appendix

1. 1Package veya bundle ID
2. 2Exact build
3. 3Android ve iOS ayrımı
4. 4Device ve OS
5. 5Static analysis
6. 6Dynamic analysis
7. 7Runtime instrumentation
8. 8Root veya jailbreak condition
9. 9Local storage
10. 10IPC ve deep link
11. 11Network traffic
12. 12Certificate pinning
13. 13Privacy behavior
14. 14Backend API scope
15. 15MASVS ve MASTG version
16. 16Repackaging ve signing sınırı

External network teklifi için minimum teknik appendix

1. 1Canonical IPv4 ve IPv6 CIDR
2. 2Root domain ve discovery policy
3. 3Ownership validation
4. 4Third-party exclusion
5. 5TCP ve UDP coverage
6. 6Port range
7. 7Source IP
8. 8Testing window
9. 9Cloud provider rule
10. 10Credentialed veya uncredentialed test
11. 11Controlled exploitation
12. 12Management interface
13. 13DoS exclusion
14. 14Critical exposure notification
15. 15Asset discovery output
16. 16Unreachable target state

Internal network teklifi için minimum teknik appendix

1. 1Starting segment
2. 2VPN veya on-site access
3. 3Test workstation
4. 4Initial privilege
5. 5Active Directory forest ve domain
6. 6Trust
7. 7IP range ve VLAN
8. 8Segmentation objective
9. 9Credential test policy
10. 10Password spraying izni
11. 11AD CS
12. 12Privilege escalation
13. 13Lateral movement
14. 14Tier-0 boundary
15. 15EDR ve SOC coordination
16. 16Cleanup

Dış ve iç ağın farklı assurance sorularını Dış ağ ve iç ağ sızma testi arasındaki farklar yazımızda daha ayrıntılı karşılaştırıyoruz.

Segmentation testi teklifi için özel maddeler

Segmentation test “VLAN'lar arası ping atılması” değildir.

Teklif şu öğeleri tanımlamalıdır:

• Source zone
• Destination zone
• Expected deny policy
• Allowed business flow
• TCP, UDP ve applicable protocol
• Stateful return behavior
• IPv4 ve IPv6
• Management plane
• Alternate route
• VPN path
• Wireless path
• Cloud peering
• Container veya overlay network
• NAT
• Jump host
• Firewall rule evidence
• Test point sayısı

Her segmentten test point sağlanmıyorsa bütün matrix doğrulanamaz. Teklif hangi source-destination pair'lerinin fiilen test edileceğini göstermelidir.

PCI DSS v4.0.1 Requirement 11.4 gibi belirli compliance ihtiyacı varsa CDE perimeter, internal ve external layer, application ve network layer, segmentation control, significant change ve retest beklentileri doğrudan ilgili requirement'a göre scope edilmelidir. “PCI testi” genel etiketi yeterli değildir.

Kaynak kod erişimi varsa teklif nasıl değişmeli?

Source code paylaşılması pentest'i otomatik olarak secure code review yapmaz.

White-box pentest sırasında source code şu amaçlarla kullanılabilir:

• Hidden route keşfi
• Authorization decision point
• Input sink
• Feature flag
• Deserialization path
• File processing flow
• SSRF destination control
• Cryptographic use
• Hardcoded secret validation

Tam secure code review ise repository coverage, language, framework, generated code, dependency, commit ve code-level finding acceptance gibi ek maddeler gerektirir.

Bu ayrımı Kaynak kod analizi ile sızma testi aynı problemi çözmez yazımızda root cause ve runtime evidence üzerinden açıklıyoruz.

Satın alma ekibinin sorması gereken 30 teknik soru

1. 1Scope asset-level olarak listelendi mi?
2. 2Domain ile wildcard domain ayrıldı mı?
3. 3Third-party asset ownership doğrulanacak mı?
4. 4API ve WebSocket açıkça dahil mi?
5. 5Mobile backend ayrıca scope'ta mı?
6. 6Environment ve build belli mi?
7. 7Test perspective nedir?
8. 8Kaç role ve tenant test edilecek?
9. 9Hangi framework version'ı kullanılacak?
10. 10Not Applicable ile Not Tested ayrılıyor mu?
11. 11Business logic için custom test hazırlanacak mı?
12. 12Automated output manual doğrulanacak mı?
13. 13Exploitation hangi seviyeye kadar izinli?
14. 14High-impact action ayrı onay gerektiriyor mu?
15. 15Source IP belli mi?
16. 16Test window timezone içeriyor mu?
17. 17Rate ve concurrency limit'i var mı?
18. 18Stop condition tanımlı mı?
19. 19Critical notification SLA'i nedir?
20. 20Cloud provider rule review kimde?
21. 21Personal data nasıl minimize edilecek?
22. 22Evidence nerede tutulacak?
23. 23External AI service customer data görecek mi?
24. 24Retention ve deletion süresi nedir?
25. 25CVSS version ve vector verilecek mi?
26. 26Coverage matrix teslim edilecek mi?
27. 27Limitation'lar raporda görünecek mi?
28. 28Retest kaç cycle ve kaç gün?
29. 29Testi yapacak kişinin ilgili platform deneyimi nedir?
30. 30Acceptance criteria ölçülebilir mi?

En sık karşılaşılan teklif red flag'leri

• Scope yalnızca adet olarak yazılmış
• API uygulamanın dışında varsayılmış
• Authenticated role sayısı belirtilmemiş
• Methodology version'sız
• OWASP Top 10 bütün coverage gibi sunulmuş
• Manual testing yalnızca yüzde olarak yazılmış
• Scanner output'unun doğrulanacağı belirtilmemiş
• Exploitation sınırı yok
• DoS varsayılan olarak dahil
• Source IP ve test window yok
• Critical notification final rapora bırakılmış
• Evidence formatı belirsiz
• Personal data retention sınırsız
• Subcontractor açıklanmamış
• External AI kullanımı belirsiz
• Coverage matrix yok
• Not Tested state'i yok
• Retest yalnızca “ücretsiz” olarak geçiyor
• Tester sadece şirket sertifikasıyla tanıtılıyor
• Zero finding için coverage kanıtı istenmiyor
• Customer dependency ve blocked time yönetimi yok
• Scope change sözlü onaya bırakılmış

Sonuç: İyi teklif hizmeti değil, güvenlik iddiasını sınırlar

Sızma testi teklifindeki en önemli teknik madde tek bir framework, sertifika veya araç adı değildir.

İyi teklif şu zinciri eksiksiz kurar:

1. 1Hangi business veya technical objective sınanacak?
2. 2Hangi exact asset ve environment test edilecek?
3. 3Tester hangi knowledge, credential ve attack perspective ile çalışacak?
4. 4Hangi methodology ve custom test case uygulanacak?
5. 5Exploitation hangi noktada duracak?
6. 6Production safety hangi control'lerle korunacak?
7. 7Hangi evidence ve coverage state teslim edilecek?
8. 8Finding severity ve business priority nasıl ayrılacak?
9. 9Retest hangi koşulda finding'i kapatacak?
10. 10Teslimat hangi acceptance criteria ile kabul edilecek?

Bu zincirin herhangi bir halkası yoksa teklif fiyatlandırılmış olabilir fakat teknik olarak tamamlanmış değildir.

Secnodex, sızma testi tekliflerini yalnızca target adedi ve gün eforu üzerinden oluşturmaz. Web, API, mobile, external network, internal network ve cloud scope'u asset-level olarak modellenir. Test perspective, role ve tenant matrix, controlled exploitation sınırı, Rules of Engagement, evidence standardı, critical notification, coverage matrix ve retest criteria çalışma başlamadan önce netleştirilir.

Mevcut tekliflerin gerçekten aynı hizmeti kapsayıp kapsamadığını değerlendirmek, kurumunuza özel teknik şartname hazırlamak veya ölçülebilir acceptance criteria ile sızma testi planlamak için Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NCSC – Penetration Testing
• NCSC – Building and Operating a Secure Online Service
• NCSC – CHECK Information for Buyers
• CREST – Implementation and Procurement Guides
• CREST – Penetration Testing Maturity Assessment Tools
• CREST – Cyber Buyer’s Guide to Vulnerability Assessment and Penetration Testing
• OWASP – Web Security Testing Guide
• OWASP – WSTG v4.2
• OWASP – Application Security Verification Standard
• OWASP – ASVS 5.0.0 Repository
• OWASP – API Security Top 10
• OWASP – Mobile Application Security
• OWASP – MASTG v2.0.0 Release
• FIRST – CVSS v4.0 Specification
• FIRST – CVSS v4.0 Consumer Implementation Guide
• PCI Security Standards Council – Document Library
• PCI Security Standards Council – PCI DSS v4.0.1 Publication
• AWS – Customer Support Policy for Penetration Testing
• Microsoft – Azure Penetration Testing
• KVKK – Veri Güvenliğine İlişkin Yükümlülükler
• KVKK – 2020/465 Sayılı Karar Özeti