Black Box, Gray Box, White Box Sızma Testi: Hangisi Gerçekten Neyi Gösterir?

“Saldırgan kaynak kodumuzu görmeyecek, o hâlde test kesinlikle black box olmalı.”

Sızma testi kapsamı belirlenirken en sık duyulan cümlelerden biri budur. İlk bakışta mantıklı görünür. Gerçek bir saldırgana kullanıcı hesabı, API dokümantasyonu veya network diagram verilmediğine göre pentester’a da verilmemesi gerektiği düşünülür. Fakat burada iki farklı hedef birbirine karışır.

Birincisi, dışarıdan gelen ve başlangıç bilgisi olmayan bir saldırganın neleri keşfedebileceğini görmek. İkincisi ise belirli bir süre içinde uygulamanın, API’nin veya network’ün güvenlik açıklarını yeterli coverage ile bulmak. Black box ilk hedefte güçlüdür. İkinci hedef için ise tek başına kullanıldığında ciddi blind spot’lar bırakabilir.

White box tarafında da benzer bir yanlış kabul vardır. Pentester’a source code, architecture ve test account verildiğinde çalışmanın kolaylaştığı ve gerçekçiliğin azaldığı düşünülür. Oysa sızma testi bir yarışma değildir. Amaç test ekibinin ne kadar zorlandığını ölçmek değil, saldırgandan önce mümkün olduğunca anlamlı güvenlik riskini bulmaktır.

Black box, gray box ve white box aslında neyi ifade eder?

Bu üç ifade çoğu zaman sızma testi türü gibi kullanılsa da temelde test ekibinin değerlendirdiği sistem hakkında başlangıçta ne kadar bilgi sahibi olduğunu anlatır.

NIST black box testing’i, değerlendirme konusunun internal structure ve implementation detail’leri hakkında bilgi bulunmadığı varsayımıyla yürütülen test olarak tanımlar. White box testing’de ise internal structure ve implementation hakkında açık ve kapsamlı bilgi bulunur. Gray box bu iki uç arasında, test ekibine belirli ölçüde bilgi ve erişim sağlanan modeldir.

Ancak sektörde bu terimler standart biçimde kullanılmaz. Bir firma “black box” derken yalnızca credential verilmemesini kasteder. Başka bir firma target IP listesini dahi paylaşmaz. “White box” bazı projelerde yalnızca source code erişimi, bazılarında source code, configuration, architecture, build instruction, database schema ve bütün kullanıcı rolleri anlamına gelir.

Bu nedenle teklif dokümanına yalnızca “gray box pentest yapılacaktır” yazmak yeterli değildir. Hangi bilgi, erişim, hesap ve teknik dokümanın verileceği tek tek belirtilmelidir.

Bilgi seviyesi ile erişim seviyesi aynı şey değildir

Box modelindeki en önemli ayrımlardan biri budur. Test ekibinin sistem hakkında ne bildiği ile sisteme hangi privilege seviyesinden başladığı farklı eksenlerdir.

Örneğin pentester’a source code ve architecture diagram verilmiş olabilir, fakat hiçbir kullanıcı hesabı verilmeden yalnızca internet üzerinden test yapması istenebilir. Bu çalışma bilgi açısından white box’a yakın, başlangıç erişimi açısından unauthenticated olabilir.

Başka bir projede ekibe yalnızca standart bir domain user hesabı ve VPN erişimi verilir, fakat network diagram, Group Policy bilgisi veya Active Directory dokümantasyonu paylaşılmaz. Bu ise assumed breach başlangıcı olan gray box internal pentest’tir.

Aşağıdaki kavramlar birbirinden ayrı tanımlanmalıdır:

Bir çalışmanın black box olması onu otomatik olarak Red Team yapmaz. Aynı şekilde white box olması da çalışmayı yalnızca Source Code Analysis hâline getirmez. Box modeli bilgi seviyesidir. Testin amacı ve metodolojisi ayrıca belirlenir.

Black box sızma testi nedir?

Black box sızma testinde pentester sistemin internal architecture, source code, configuration ve işleyiş detayları hakkında önceden bilgi sahibi değildir. Başlangıç girdisi yalnızca ana domain, belirli bir URL, public IP aralığı veya şirket adı olabilir.

Test ekibi bir external attacker gibi reconnaissance yapar. Domain ve subdomain’leri, internet-facing servisleri, technology stack’i, public dokümanları, certificate kayıtlarını, exposed endpoint’leri ve olası giriş noktalarını kendi yöntemleriyle keşfeder.

Black box gerçekten neyi gösterir?

Black box test aşağıdaki sorulara güçlü yanıt verebilir:

• Kurumun internete açık attack surface’i dışarıdan ne kadar kolay keşfediliyor?
• Unutulmuş subdomain, eski IP, test ortamı veya shadow IT bulunabiliyor mu?
• Anonymous kullanıcı hangi fonksiyonlara erişebiliyor?
• Public servislerde doğrudan exploitable zafiyet var mı?
• Login olmadan bilgi sızıntısı, authentication bypass veya exposed management interface bulunuyor mu?
• WAF, rate limit ve perimeter kontrolü dışarıdan nasıl davranıyor?
• Public application ve API’ler teknoloji ve version bilgisi sızdırıyor mu?
• Başlangıç credential’ı olmadan initial access elde edilebiliyor mu?

Bu nedenle black box özellikle internet-facing attack surface ve unauthenticated riskler için değerlidir. Kurum, saldırganın kendisine gösterdiği yüzeyi kendi asset inventory’siyle karşılaştırabilir.

Black box neyi göstermez?

Black box testin doğal sınırı keşfedilemeyen şeyin çoğu zaman test edilememesidir. Uygulamada on farklı kullanıcı rolü bulunabilir, fakat pentester yalnızca self-registration ile standart user oluşturabiliyorsa admin, operasyon, bayi veya kurumsal müşteri akışları kapsam dışında kalır.

Black box test aşağıdaki alanlarda sınırlı güvence üretir:

• Authenticated attack surface’in tamamı
• Role-based ve object-level authorization
• IDOR ve tenant isolation
• Yalnızca belirli iş rolleriyle görülen business logic
• Hidden veya undocumented API endpoint’leri
• Background job, message queue ve internal service akışları
• Source code içindeki unreachable veya zor tetiklenen zafiyetler
• Cryptographic implementation ve secret handling
• Production configuration’ın kodla ilişkisi
• İleri düzey second-order ve stored vulnerability’ler
• Internal network, identity ve trust relationship’ler

Black box raporunda bulgu çıkmaması “uygulamada zafiyet yok” anlamına gelmez. Yalnızca tanımlı süre ve scope içinde, tester’a verilen başlangıç koşullarından exploitable bir yol doğrulanamadığını gösterir.

Black box yaklaşımının güçlü yönleri

Gerçek dış saldırı yüzeyini bağımsız biçimde ölçer

Tester kurumun asset inventory’sine bağlı kalmadığı için unutulmuş veya yanlış sınıflandırılmış varlıkları bulabilir. Bu durum özellikle çok sayıda domain, cloud account ve şirket iştiraki bulunan yapılarda değerlidir.

Security by obscurity varsayımlarını test eder

“URL bilinmiyor”, “admin paneli linklenmedi” veya “test ortamı duyurulmadı” gibi kabuller dışarıdan sınanır. Certificate transparency, JavaScript bundle, DNS history ve public repository gibi kaynaklar bu varlıkları görünür hâle getirebilir.

Perimeter kontrollerini gerçek koşullarda gösterir

WAF, reverse proxy, CDN, authentication gateway, bot protection ve rate limit’in dışarıdan nasıl çalıştığı gözlemlenir. Test trafiği allowlist’e alınmadıysa gerçek saldırganın karşılaşacağı kontrol zincirine daha yakın sonuç alınır.

Kapsam bilgisindeki hataları ortaya çıkarabilir

Kurum yalnızca bildiği varlıkları verdiğinde shadow IT görünmez kalabilir. Black box reconnaissance, resmi envanter ile dışarıdan görünen attack surface arasındaki farkı gösterebilir.

Black box yaklaşımının sınırları

Test süresinin önemli bölümü keşfe gider

Gerçek saldırgan aynı kurumu haftalarca veya aylarca izleyebilir. Pentest ise time-boxed bir çalışmadır. Tester’ın keşfe ayırdığı her saat, derin manual testing için kalan süreyi azaltır. Bu nedenle “saldırgan gibi sıfır bilgi” yaklaşımı süre farkı dikkate alınmadan tam gerçekçilik sağlamaz.

Coverage kanıtlamak zordur

Tester keşfettiği endpoint’leri raporlayabilir, fakat keşfedemediği code path’lerin sayısını bilemez. OWASP da execution path coverage’ın gray box ve white box yaklaşımlarında sağlanmasının daha kolay olduğunu belirtir.

Authenticated riskler görünmeyebilir

Modern application’ların asıl attack surface’i çoğu zaman login sonrasında başlar. Object ownership, rol geçişleri, ödeme akışları, file processing ve yönetim fonksiyonları anonymous testle yeterince değerlendirilemez.

Perimeter kontrolü root cause’u maskeleyebilir

WAF belirli payload’ı engelleyebilir. Bu dışarıdan exploitation’ı zorlaştırır, fakat application code içindeki root cause devam edebilir. WAF rule değiştiğinde veya farklı encoding kullanıldığında risk yeniden ortaya çıkabilir.

Third-party sınırları belirsizleşebilir

Black box reconnaissance sırasında SaaS, CDN, hosting provider veya business partner sistemleriyle karşılaşılabilir. Yazılı izin bulunmayan üçüncü taraf varlıklar aktif test edilmemelidir. Scope ownership doğrulaması kritik hâle gelir.

Black box sızma testi ne zaman tercih edilmeli?

Black box aşağıdaki ihtiyaçlarda anlamlıdır:

• External attack surface’in bağımsız keşfi
• Internet-facing sistemlerde anonymous initial access testi
• Kurumun public varlık envanterinin doğrulanması
• Third-party müşteri gözünden görülen yüzeyin değerlendirilmesi
• Perimeter ve exposed service güvenliğinin ölçülmesi
• Red Team öncesi external reconnaissance veya initial access phase’i
• Credential verilmeden erişilebilecek veri ve fonksiyonların belirlenmesi

Ancak kritik web application veya API için yalnızca black box test seçmek çoğu zaman yeterli değildir. External perspective korunduktan sonra authenticated gray box phase eklenmesi daha güçlü coverage sağlar.

Gray box sızma testi nedir?

Gray box sızma testinde pentester sisteme ilişkin sınırlı fakat test hedefini destekleyen bilgiye ve erişime sahiptir. Bu bilgi bir veya birden fazla test account, API dokümantasyonu, role matrix, architecture özeti, test verisi veya belirli configuration açıklamalarından oluşabilir.

Gray box’ın amacı pentester’a bütün cevabı vermek değildir. Test süresini düşük değerli keşif adımlarında tüketmeden, dış saldırganın credential theft, account compromise veya normal kullanıcı kaydı sonrasında erişebileceği authenticated attack surface’i derinlemesine değerlendirmektir.

Gray box gerçekten neyi gösterir?

Gray box aşağıdaki sorular için genellikle en verimli modeldir:

• Standart kullanıcı başka kullanıcının verisine erişebilir mi?
• Farklı tenant’lar arasında veri veya işlem izolasyonu çalışıyor mu?
• Rol yükseltme veya function-level authorization bypass mümkün mü?
• Session, logout, timeout ve token lifecycle güvenli mi?
• API endpoint’leri bütün kullanıcı rollerinde doğru authorization uyguluyor mu?
• Business logic beklenmeyen işlem sırası veya parameter değişikliğiyle abuse edilebilir mi?
• File upload, export, reporting ve batch process fonksiyonları güvenli mi?
• MFA, password reset, account recovery ve SSO akışları doğru mu?
• Düşük yetkili kullanıcıdan daha kritik sisteme attack path kurulabilir mi?

Gray box, özellikle web application security ve API security çalışmalarında güçlü bir maliyet ve coverage dengesi sağlar. Tester login mekanizmasını kırmak zorunda kalmadan login sonrası riskleri test edebilir. Bu, authentication’ın hiç test edilmemesi anlamına gelmez. Anonymous ve authenticated phase’ler ayrı yürütülür.

Gray box testte hangi bilgiler verilebilir?

Projenin amacına göre aşağıdaki girdilerden bazıları paylaşılabilir:

• Standart kullanıcı, yönetici, operasyon, bayi ve müşteri test hesapları
• Birbirinden bağımsız en az iki kullanıcı veya tenant
• MFA test yöntemi ve gerekli test token’ları
• OpenAPI, Swagger, Postman collection veya GraphQL schema
• Role ve permission matrix
• Temel data flow ve architecture diagram
• Kritik business process açıklamaları
• Test edilebilecek kayıt ve transaction türleri
• Scope içi domain, API host ve mobile backend bilgileri
• WAF, API gateway ve rate limit davranışına ilişkin sınırlı bilgi
• Internal test için VPN, standart domain user veya controlled workstation

Gray box’ın kalitesi verilen bilginin miktarından çok test sorusuyla uygunluğuna bağlıdır. IDOR testi yapılacaksa tek user hesabı yeterli değildir. Tenant isolation test edilecekse aynı tenant içinde iki hesap vermek de doğru coverage sağlamaz.

Gray box yaklaşımının güçlü yönleri

Authenticated attack surface’e zaman ayırır

Pentester test süresini account elde etmeye değil, role ve workflow’lar arasındaki güvenlik kontrollerini sınamaya ayırır. Bu durum daha fazla endpoint ve business process’in manuel incelenmesini sağlar.

Authorization testini güçlendirir

IDOR, broken access control ve privilege escalation için farklı identity’lerin request ve response davranışı karşılaştırılabilir. API object’leri, tenant ID’leri ve function-level kontroller sistematik biçimde test edilir.

API coverage’ını artırır

Modern front-end yalnızca kullandığı endpoint’leri gösterir. OpenAPI veya Postman collection sağlandığında mobil, partner ve legacy client’ların kullandığı farklı endpoint’ler de kapsama alınabilir.

Business logic context’i sağlar

Tester “normal davranışın” ne olduğunu bildiğinde beklenmeyen state transition, limit bypass, duplicate transaction ve workflow manipulation risklerini daha anlamlı test edebilir.

Internal testlerde gerçekçi assumed breach sağlar

Standart bir user account ve workstation erişimi, phishing veya credential theft sonrasında saldırganın elde edebileceği foothold’u temsil edebilir. Test süresi initial access yerine segmentation, identity, privilege ve lateral movement risklerine ayrılır.

Gray box yaklaşımının sınırları

Verilen role kadar görür

Yalnızca admin account verilmesi, normal user’ın privilege escalation riskini göstermeyebilir. Yalnızca standart user verilmesi ise operasyon ve back-office fonksiyonlarını kapsam dışı bırakabilir. Account set’i role matrix’e göre planlanmalıdır.

Dokümantasyon eksik veya eski olabilir

API dokümanında bulunmayan endpoint’ler, production’da farklı çalışan feature flag’ler ve unutulmuş legacy route’lar yine kaçırılabilir. Gray box’ta da reconnaissance bırakılmamalıdır.

Root cause her zaman görünmez

Tester runtime davranışını görür, fakat source code bulunmadığında custom validation, authorization wrapper veya data flow’un neden hatalı olduğunu kesin olarak belirleyemeyebilir.

Test hesabı gerçek kullanıcı davranışını tam temsil etmeyebilir

Test account’lar production’daki permission, data volume, tenant özelliği veya integration yetkilerine sahip değilse sonuçlar sınırlanır. Hangi farkların bulunduğu raporda açıklanmalıdır.

Gray box sızma testi ne zaman tercih edilmeli?

Gray box aşağıdaki çalışmalar için çoğu zaman en dengeli seçenektir:

• Web application ve API pentest
• IDOR, role ve tenant isolation testleri
• Mobile backend ve authenticated API analizi
• Payment, order, refund, approval ve benzeri business logic akışları
• SSO, OAuth, MFA ve account recovery değerlendirmeleri
• Internal network assumed breach testi
• Active Directory’de standart domain user başlangıcı
• Cloud ortamında belirli IAM role veya developer credential başlangıcı
• Kısıtlı test süresinde yüksek riskli workflow coverage ihtiyacı

Gray box, black box’ın daha düşük kaliteli veya white box’ın eksik sürümü değildir. Belirli bir başlangıç varsayımını verimli biçimde test eden bağımsız bir modeldir.

White box sızma testi nedir?

White box sızma testinde pentester source code, architecture, configuration, data flow, build bilgisi ve kullanıcı rolleri gibi internal detail’lere kapsamlı erişim kazanır. Test ekibi uygulamanın yalnızca dış davranışını değil, security control’lerin nasıl uygulandığını da inceleyebilir.

White box test ile Source Code Analysis aynı şey değildir. Source code erişimi white box yaklaşımının bir girdisidir. Çalışma yalnızca SAST çalıştırılıp tool output’un raporlanmasına dönüşürse gerçek bir white box pentest yapılmış sayılmaz. Runtime test, manual code review, architecture analizi ve controlled exploitation birbirini tamamlamalıdır.

White box gerçekten neyi gösterir?

White box aşağıdaki alanlarda daha yüksek görünürlük sağlayabilir:

• User input’un source’tan sink’e nasıl ilerlediği
• Authentication ve authorization kontrollerinin gerçek implementation’ı
• Custom middleware, filter ve policy engine davranışı
• Hidden route, background job ve internal API’ler
• Feature flag arkasındaki code path’ler
• Cryptographic algorithm, key handling ve random number kullanımı
• Serialization, file processing ve template rendering akışları
• Hardcoded secret ve riskli configuration default’ları
• Error handling, logging ve sensitive data exposure
• Database query ve stored data lifecycle
• Microservice’ler arasındaki trust assumption’lar
• Security control’lerin bypass edilebilecek code path’leri

White box özellikle zafiyetin yalnızca varlığını değil root cause’unu ve aynı pattern’in codebase boyunca tekrar edip etmediğini anlamada güçlüdür.

White box testte hangi bilgiler sağlanmalı?

Yalnızca repository read access vermek çoğu zaman yeterli değildir. Sağlıklı bir white box çalışma için aşağıdaki girdiler değerlendirilebilir:

• Test edilen build ile eşleşen source code commit’i
• Build ve deployment instruction’ları
• Architecture ve trust boundary diagram’ları
• Data flow ve database schema bilgisi
• API specification ve route listesi
• Bütün önemli role ve tenant’lar için test account
• Authentication ve authorization design açıklamaları
• Environment-specific configuration örnekleri
• Secret value’ların kendisi yerine secret management yapısı
• Critical library ve third-party integration bilgileri
• Feature flag ve background job envanteri
• Logging, monitoring ve security control açıklamaları
• Known limitation ve daha önceki security finding’ler

Bu bilgiler pentester’ın bağımsız düşünmesini engellemez. Tersine dışarıdan tahmin edilemeyecek code path’leri ve yanlış security assumption’ları test etmesini sağlar.

White box yaklaşımının güçlü yönleri

Coverage daha planlı yönetilebilir

Route, controller, service, permission check ve data flow envanteri üzerinden hangi alanların incelendiği görülebilir. Black box’ta bilinmeyen endpoint sayısı bilinmezken white box’ta test planı implementation ile karşılaştırılabilir.

Zor tetiklenen zafiyetler bulunabilir

Belirli data state, rare error condition veya background process gerektiren zafiyetler dışarıdan rastlantısal olarak bulunamayabilir. Code knowledge bu path’leri hedefli test etmeyi sağlar.

Root cause ve regression analizi güçlenir

Bir authorization açığı bulunduğunda aynı hatalı helper’ın kullanıldığı diğer endpoint’ler aranabilir. Remediation yalnızca tek URL’ye değil ortak root cause’a uygulanabilir.

Cryptography ve secret management değerlendirilebilir

Runtime üzerinden güçlü görünen encryption, source code içinde static key veya hatalı IV kullanıyor olabilir. White box bu implementation detayını görünür kılar.

Custom framework ve kontrol katmanları anlaşılır

Kurumun kendi authorization, validation veya serialization wrapper’ları generic scanner tarafından doğru modellenmeyebilir. Manuel review ile bu katmanların gerçek davranışı incelenebilir.

Geliştirme ekibine daha kesin remediation sağlanır

Finding yalnızca request ve response ile değil hatalı code path, etkilenen component ve güvenli implementation yaklaşımıyla ilişkilendirilebilir.

White box yaklaşımının sınırları

Source code ile production aynı olmayabilir

Yanlış branch, eski commit, hotfix, environment variable veya deployment drift sonucu analiz edilen kod production davranışını temsil etmeyebilir. Build identifier ve deployment version doğrulanmalıdır.

Çok bilgi otomatik olarak tam coverage sağlamaz

Büyük bir codebase’in tamamını sınırlı sürede aynı derinlikte manuel incelemek mümkün değildir. Risk-based prioritization, threat modeling ve kritik data flow seçimi gerekir.

Implementation bilgisi external perspective’i etkileyebilir

Tester endpoint listesini önceden gördüğünde dışarıdan discoverability’nin ne kadar zor olduğunu bağımsız biçimde ölçemez. Bu ihtiyaç varsa önce ayrı black box reconnaissance phase yürütülmelidir.

Runtime ve infrastructure gerçeği yine ayrı doğrulama ister

Güvenli görünen source code, production’da hatalı reverse proxy, IAM policy, WAF rule veya cloud configuration ile deploy edilmiş olabilir. White box code review active testing’in yerine geçmez.

SAST gürültüsü çalışmayı boğabilir

Binlerce tool finding’i manuel review olmadan rapora taşımak gerçek riskleri görünmez kılar. SAST sonuçları expert triage ve exploitability analiziyle ele alınmalıdır.

White box sızma testi ne zaman tercih edilmeli?

White box aşağıdaki durumlarda güçlü sonuç üretir:

• Kritik ve custom-developed application’lar
• Production öncesi kapsamlı security verification
• Kaynak kodu kuruma ait web, API ve backend servisleri
• Authentication ve authorization framework değerlendirmesi
• Cryptography ve sensitive data processing akışları
• Fintech, healthtech ve benzeri yüksek etkili business process’ler
• Daha önce tekrarlayan root cause bulunan codebase’ler
• Complex microservice ve event-based architecture
• Black veya gray box testte bulunan kritik zafiyetin bütün codebase’de aranması
• Regresyonu önleyecek security test ve custom rule üretimi

Üç yaklaşımın doğrudan karşılaştırması

Hangi zafiyet için hangi model daha güçlüdür?

Bu tablo kesin bir sınır değildir. Black box testte IDOR bulunabilir veya white box çalışmada exposed service keşfedilebilir. Buradaki amaç hangi modelin systematic coverage sağlama ihtimalinin daha yüksek olduğunu göstermektir.

“Black box en gerçekçi testtir” iddiası neden eksik?

Gerçek saldırganın source code erişimi olmayabilir. Fakat bu, saldırganın sıfır bilgiyle başladığı anlamına gelmez. Public dokümanlar, leaked credential, eski çalışan hesapları, exposed repository, third-party erişimi, satın alınmış access, malware log’ları ve önceki data breach’ler saldırgana gray box benzeri başlangıç context’i sağlayabilir.

Ayrıca saldırganın zamanı pentest ile aynı değildir. Kurumu aylarca gözlemleyebilir, farklı saatlerde deneme yapabilir ve başka hedeflerden topladığı bilgiyi kullanabilir. İki haftalık black box test, bu zaman avantajını doğal olarak taklit edemez.

Gerçekçilik yalnızca bilgi vermemek değildir. Threat actor’ın başlangıç kabiliyeti, motivasyonu, erişebildiği intelligence, hedefi ve harcayabileceği zaman birlikte düşünülmelidir.

Bu nedenle “gerçek saldırgan kaynak kodu görmez” cümlesi external resilience testi için anlamlı olsa da vulnerability coverage hedefi için yeterli gerekçe değildir.

“White box testi kolaylaştırır” itirazı neden yanlış hedefe bakar?

Evet, source code ve architecture bilgisi pentester’ın bazı yolları daha hızlı bulmasını sağlar. Bu bir zayıflık değil, test verimliliğidir. Kurum pentester’ın aynı süre içinde reconnaissance’a mı yoksa derin security analysis’e mi zaman ayırmasını istediğine karar vermelidir.

Bir doktorun tanı koyarken görüntüleme sonucuna bakması muayeneyi değersizleştirmediği gibi, pentester’ın code path’i görmesi de zafiyeti geçersiz kılmaz. Dışarıdan exploitability ayrıca doğrulanabilir.

White box’ın sınırı, dışarıdan discoverability ve attacker effort konusunda daha az bağımsız veri üretmesidir. Bu ihtiyaç ayrı black box phase ile korunabilir.

En güçlü yaklaşım neden çoğu zaman hybrid modeldir?

Kritik application ve API’lerde tek bir box modeline bağlı kalmak yerine aşamalı çalışma daha güvenilir sonuç verir.

Phase 1: Black box reconnaissance ve unauthenticated testing

Test ekibine yalnızca dış saldırganın görebileceği başlangıç bilgileri verilir. Asset discovery, anonymous attack surface, exposed endpoint ve perimeter control’ler değerlendirilir. Bu phase tamamlanmadan detaylı internal bilgi paylaşılmaz.

Phase 2: Gray box authenticated testing

Farklı role ve tenant’lara ait test account’lar, API specification ve gerekli business flow bilgisi sağlanır. Authorization, session management, IDOR, tenant isolation ve business logic derinlemesine test edilir.

Phase 3: Targeted white box analysis

Kritik data flow, authentication, authorization, cryptography, file processing ve daha önce şüpheli bulunan alanlar source code ve configuration üzerinden incelenir. SAST çıktıları manual review ile triage edilir.

Phase 4: Production-safe verification ve retest

Pre-production ile production farkları değerlendirilir. İzin verilen kontroller production üzerinde güvenli payload’larla doğrulanır. Remediation sonrasında orijinal PoC, bypass ihtimali ve regression riski test edilir.

Bu model hem external attacker perspective’ini korur hem de test süresinin authenticated ve source-level risklere ayrılmasını sağlar.

Web uygulaması için hangisi seçilmeli?

Yeni ve kritik bir web application için yalnızca black box test genellikle yetersizdir. Minimum olarak anonymous phase ile farklı role’ların bulunduğu gray box phase birlikte planlanmalıdır.

Application custom-developed ve source code erişilebilir durumdaysa riskli modüllerde targeted white box review eklenebilir. Özellikle authentication, authorization, file upload, payment, report generation ve admin fonksiyonları source-level incelemeden fayda görür.

Public bir marketing sitesi veya çok sınırlı fonksiyona sahip external portal için black box ağırlıklı test yeterli olabilir. Seçim application türüne ve iş etkisine göre yapılmalıdır.

API sızma testi için hangisi seçilmeli?

API testlerinde gray box çoğu zaman temel gereksinimdir. Endpoint inventory, request schema, authentication yöntemi ve farklı role token’ları olmadan coverage ciddi biçimde düşebilir.

Yalnızca front-end trafiğini izlemek, partner API’lerini, mobile endpoint’leri, eski version’ları veya background integration route’larını göstermeyebilir. OpenAPI, Postman collection veya GraphQL schema test ekibiyle paylaşılmalıdır.

Black box phase yine değerlidir. Undocumented endpoint, exposed schema, authentication bypass ve external discoverability bu aşamada incelenebilir. Kritik custom API’lerde source code erişimi authorization middleware ve data flow analizini güçlendirir.

Mobile application için hangisi seçilmeli?

Mobile application testinde yalnızca uygulama paketini verip black box test istemek bazı riskleri gösterebilir. Binary içindeki endpoint, local storage, certificate pinning, deep link ve exported component’ler analiz edilebilir.

Ancak backend API için farklı kullanıcı role’ları, test verisi ve dokümantasyon verilmezse asıl business risklerin önemli bölümü kaçırılabilir. Mobile pentest çoğu zaman client için white veya gray box reverse engineering, backend için gray box API testing ve gerektiğinde source code review birleşimidir.

Internal network ve Active Directory için hangisi seçilmeli?

Internal pentest’te box kavramları farklı başlangıç senaryolarını temsil edebilir.

Black box external test

Kurum ağına erişim veya credential verilmez. Amaç internet-facing VPN, remote access, mail, web ve exposed service’lerden initial access elde edilip edilemeyeceğini görmektir.

Gray box assumed breach

Pentester’a standart domain user, VPN erişimi veya controlled workstation verilir. Amaç credential compromise sonrasında segmentation, Active Directory permission, privilege escalation ve lateral movement risklerini test etmektir.

White box architecture-assisted test

Network diagram, firewall rule, trust relationship, OU ve GPO yapısı, privileged group bilgisi ve security architecture paylaşılır. Amaç kritik path’leri systematic biçimde doğrulamak ve configuration ile runtime davranışı karşılaştırmaktır.

Yalnızca external black box test yapıp “iç ağ güvenlidir” sonucu çıkarılamaz. Perimeter aşılamadıysa internal kontroller test edilmemiştir. External ve assumed breach farklı sorulara cevap verir.

Cloud sızma testi için hangisi seçilmeli?

Cloud ortamında black box yalnızca public endpoint, exposed storage, DNS ve internet-facing service’leri gösterebilir. IAM privilege, cross-account trust, role assumption, metadata access, secret store ve control plane riskleri için kimlik ve architecture context’i gerekir.

Gray box çalışmada test IAM user veya role sağlanabilir. White box yaklaşımda Terraform, CloudFormation, Kubernetes manifest, IAM policy, organization structure ve logging configuration incelenebilir.

Cloud security için active testing, IaC scanning, configuration review ve identity analysis birlikte düşünülmelidir. Yalnızca public IP’lerin taranması cloud pentest değildir.

Test modeli seçerken kullanılabilecek karar tablosu

Scope dokümanında yalnızca “gray box” yazmak neden yetmez?

Gray box sınırı kurumdan kuruma değiştiği için aşağıdaki bilgilerin sözleşme ve Rules of Engagement içinde açıkça yazılması gerekir:

• Verilecek domain, IP, application ve API listesi
• Anonymous phase’in ayrı yürütülüp yürütülmeyeceği
• Test account sayısı, role’ları ve tenant ilişkileri
• MFA ve SSO test yöntemi
• API dokümantasyonu ve güncel version bilgisi
• Source code erişiminin bulunup bulunmadığı
• Source code varsa hangi repository ve commit’in production ile eşleştiği
• Architecture, data flow ve network diagram kapsamı
• Test environment ve production arasındaki farklar
• WAF, CDN ve rate limit’in devrede olup olmadığı
• Tester IP’lerinin allowlist’e alınıp alınmayacağı
• Third-party entegrasyonların scope ve izin durumu
• Data modification ve transaction sınırları
• Test edilmeyecek özellikler ve gerekçeleri
• Coverage beklentisi ve teslim edilecek evidence türü

Bu ayrıntılar bulunmadığında iki farklı hizmet sağlayıcının “gray box” teklifi tamamen farklı çalışmalar içerebilir. Fiyat ve süre karşılaştırması da anlamını kaybeder.

Sızma testi raporu box modelini nasıl açıklamalı?

Rapor, yalnızca “test gray box yapılmıştır” dememelidir. Sonucun hangi koşullar altında geçerli olduğunu gösterecek ayrıntılar bulunmalıdır:

• Test ekibine başlangıçta verilen bilgi ve erişimler
• Kullanılan account, role ve tenant türleri
• Anonymous ve authenticated test phase’leri
• Test edilen environment ve application version
• Source code veya configuration erişimi
• İncelenen API ve endpoint envanteri
• Test edilemeyen veya ulaşılamayan fonksiyonlar
• WAF, allowlist ve diğer compensating control’ler
• Production ile staging arasındaki bilinen farklar
• Test süresi ve önemli kısıtlar
• Coverage hakkında doğrulanabilen ve doğrulanamayan alanlar

Bu bilgiler raporun sınırlılığını göstermek için değil, yönetimin sonucu doğru yorumlaması için gereklidir. “Bulgu yok” ile “test edilmedi” birbirinden ayrılmalıdır.

Box modeli seçiminde sık yapılan hatalar

En zor testin en iyi test olduğunu düşünmek

Pentester’ı bilgisiz bırakmak testi zorlaştırabilir. Fakat kurumun riski hakkında daha fazla bilgi üretmeyebilir. Zorluk değil güvenlik sorusuna uygun evidence hedeflenmelidir.

Tek kullanıcı hesabıyla gray box yapmak

Authorization ve IDOR testinde karşılaştırılacak ikinci identity yoksa önemli use case’ler eksik kalır. Role ve tenant kombinasyonları scope aşamasında belirlenmelidir.

Yalnızca admin hesabı vermek

Admin bütün fonksiyonları görür, ancak düşük yetkili kullanıcının admin fonksiyonlarına erişip erişemediğini ölçmek için standart role de gerekir.

White box adı altında sadece SAST çalıştırmak

SAST tool output’u active exploitability, runtime configuration ve business logic’i tek başına göstermez. Manual Code Review ve çalışan sistem üzerinde doğrulama yapılmalıdır.

Black box testte authenticated alanı güvenli kabul etmek

Tester login olamadıysa login sonrası yüzey test edilmemiştir. Bu sonuç authenticated fonksiyonlar hakkında güvence sağlamaz.

API dokümantasyonunu saklamayı gerçekçilik sanmak

Amaç API inventory coverage ise specification paylaşmamak test kalitesini düşürür. Dışarıdan bulunabilen endpoint’ler ayrı black box phase’de, tam envanter ise gray box phase’de test edilebilir.

Staging sonucunu doğrudan production’a taşımak

Code, WAF, environment variable, IAM ve third-party entegrasyon farkları sonucu değiştirebilir. Environment parity doğrulanmalı ve production-safe verification planlanmalıdır.

Box modelini kalite etiketi gibi kullanmak

White box black box’tan otomatik olarak daha kaliteli değildir. Black box da daha profesyonel veya gerçekçi değildir. Kalite, doğru scope, metodoloji, manuel test derinliği, evidence ve uzmanlıkla belirlenir.

Başarı kriteri box modeline göre nasıl değişir?

Black box başarı kriterleri

• Dışarıdan görünen asset ve attack surface’in çıkarılması
• Anonymous endpoint ve service coverage
• Discoverability ve information leakage analizi
• Initial access ihtimalinin kontrollü doğrulanması
• Scope dışı third-party varlıkların doğru ayrılması

Gray box başarı kriterleri

• Tanımlı role ve tenant matrix’inin kapsanması
• Authenticated endpoint ve business flow coverage
• Horizontal ve vertical authorization kontrollerinin doğrulanması
• Session ve token lifecycle testleri
• Verilen specification ile gözlemlenen attack surface’in karşılaştırılması

White box başarı kriterleri

• Kritik route, data flow ve trust boundary coverage
• Source-level root cause ve tekrar eden pattern analizi
• Authentication ve authorization implementation review
• Configuration ile runtime davranışının karşılaştırılması
• Active finding’lerin code location ve remediation ile eşleştirilmesi

Bu kriterler yalnızca finding sayısına bakmaktan daha anlamlıdır. Daha fazla bulgu her zaman daha iyi test, daha az bulgu da daha güvenli sistem anlamına gelmez.

Sonuç: Doğru box modeli, doğru güvenlik sorusuyla seçilir

Black box, gray box ve white box arasında “en iyi” olanı seçmek yanlış sorudur. Her biri farklı bir başlangıç varsayımını ve farklı bir güvenlik iddiasını test eder.

Black box, kurumun dışarıdan görünen yüzünü ve credential olmadan ilerlenebilecek yolları gösterir. Gray box, ele geçirilmiş veya meşru bir kullanıcı hesabı sonrasında authorization, tenant ve business logic kontrollerinin ne kadar dayanıklı olduğunu ortaya koyar. White box ise security control’lerin implementation’ını, hidden code path’leri ve root cause’u daha derin incelemeyi sağlar.

Doğru seçim için önce şu soruya cevap verilmelidir: “Bu testin sonunda hangi konuda güvence sahibi olmak istiyoruz?” External exposure, authenticated authorization ve code-level security aynı sorular değildir. Kritik sistemlerde bunları tek bir box etiketi altında sıkıştırmak yerine aşamalı hybrid modelle değerlendirmek daha doğru sonuç verir.

Secnodex, web, mobile application, API, network ve Active Directory sızma testi hizmetlerinde box modelini hazır paket olarak dayatmaz. Test yaklaşımını attack surface, kullanıcı rolleri, business flow, source code erişimi ve kurumun güvence hedeflerine göre belirler. Anonymous external perspective’i korurken authenticated ve code-level coverage ihtiyacını ayrı phase’lerle planlar. Kurumunuz için doğru test modelini oluşturmak üzere Secnodex ile iletişime geçebilirsiniz.

Metodoloji ve referanslar

• NIST Black Box Testing Tanımı
• NIST White Box Testing Tanımı
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide: Introduction
• OWASP WSTG: Map Execution Paths Through Application
• OWASP WSTG: Reflected Cross-Site Scripting Testing
• OWASP Application Security Verification Standard
• PCI SSC Penetration Testing Guidance