Sızma Testi Nedir? Kapsamlı Rehber (2026)

Bir kurumun internet-facing sistemlerinde 12.000 adet “bulgu” üreten scanner raporu var.

Listede eski TLS configuration değerleri, eksik security header’ları, olası CVE eşleşmeleri ve yüzlerce information-level kayıt bulunuyor. Yönetim raporun uzunluğuna bakıp kapsamlı bir sızma testi yapıldığını düşünüyor.

Fakat hiç kimse uygulamaya iki farklı kullanıcıyla giriş yapmamış. Bir müşterinin başka müşteriye ait faturayı görüp göremediği denenmemiş. Password reset akışı manipüle edilmemiş. API’deki object-level authorization kontrolü incelenmemiş. File upload özelliğinin yalnızca extension’a mı güvendiği araştırılmamış. Birbiriyle ilişkilendirildiğinde kritik etki üretebilecek zayıflıklar test edilmemiş.

Ortada çok sayıda çıktı vardır, fakat henüz gerçek anlamda bir sızma testi yoktur.

Sızma testi için penetrasyon testi, pentest ve penetration testing ifadeleri de kullanılır. İsim değişse de profesyonel bir çalışmanın temel sorusu aynıdır:

Bu rehber, “sızma testi nedir?” sorusuna yalnızca sözlük tanımı vermeyecek. Test türlerini, black box, gray box ve white box ayrımını, kullanılan metodolojileri, proje aşamalarını, süre ve scope ilişkisini, rapor kalitesini, firma seçimini ve yasal sınırları tek bir çerçevede ele alacak.

Sızma testi nedir?

Sızma testi, bir uygulama, API, ağ, cloud ortamı, mobile application veya başka bir dijital varlık üzerindeki güvenlik kontrollerinin adversarial yöntemlerle sınanmasıdır. Çalışma sırasında tester, saldırganın kullanabileceği giriş noktalarını araştırır, güvenlik zayıflıklarını manuel ve automated yöntemlerle analiz eder, izin verilen sınırlar içinde kontrollü exploitation yapar ve elde edilen etkiyi doğrular.

Buradaki en önemli kelime “kontrollü”dür.

Gerçek saldırgan scope, çalışma saati, veri hassasiyeti veya sistem kararlılığıyla ilgilenmez. Profesyonel penetration testing çalışması ise başlamadan önce Rules of Engagement ile sınırlandırılır. Hangi varlıkların test edileceği, hangi tekniklerin kullanılabileceği, production verisine nasıl yaklaşılacağı, stop condition’lar ve acil iletişim kanalı yazılı olarak belirlenir.

Sızma testi gerçek saldırının birebir kopyası mıdır?

Hayır. Gerçek saldırı tekniklerinden yararlanır, fakat aynı risk iştahıyla hareket etmez.

Bir tester, kritik bir SQL injection bulduğunda bütün database’i dışarı aktarmak zorunda değildir. Birkaç kontrollü kayıtla yetki ve etki kanıtlanabilir. Internal network üzerinde Domain Admin yetkisine ulaşan attack path bulunduğunda, production servislerini durduracak veya kullanıcı verisini değiştirecek adımlar uygulanmaz. Kanıt için gerekli en düşük etki tercih edilir.

Bu yaklaşım testin gerçekçiliğini azaltmaz. Aksine, teknik bulgunun tekrar üretilebilir biçimde doğrulanmasını ve kuruma gereksiz zarar verilmemesini sağlar.

Pentest neden bir “tarama” değildir?

Scanner, bilinen pattern’leri ve belirli configuration hatalarını geniş ölçekte aramak için değerlidir. Fakat tool çıktısı tek başına şu sorulara güvenilir cevap veremez:

• İki düşük seviye zayıflık birlikte kullanıldığında kritik attack chain oluşuyor mu?
• Bir kullanıcının başka tenant’a ait object’e erişmesi business impact yaratıyor mu?
• Client tarafında gizlenen fonksiyon server-side authorization olmadan çağrılabiliyor mu?
• MFA belirli bir login veya recovery flow üzerinden bypass edilebiliyor mu?
• Payment, coupon, approval veya refund akışı intended sıranın dışında işletilebiliyor mu?
• Scanner’ın ürettiği sonuç false positive mi?
• Teknik olarak geçerli görünen bulgu mevcut control nedeniyle gerçekten exploit edilebilir mi?

Sızma testinde automation keşfi hızlandırır. Port scan, content discovery, dependency detection ve geniş parametre setlerinin ilk kontrolü için tool kullanılabilir. Fakat nihai güvenlik kararı tool’a bırakılmaz. Tester response davranışını, kullanıcı rollerini, state değişimini, veri ilişkilerini ve business context’i yorumlar.

Bu nedenle SECNODEX yaklaşımında scanner çıktısı bulgu değil, araştırılması gereken bir signal olarak ele alınır. Raporlanacak sonuç controlled exploitation, request ve response evidence, etkilenen role, ön koşul, iş etkisi ve uygulanabilir remediation ile desteklenir.

Sızma testi neden yapılır?

Kurumlar penetration testing hizmetini çoğu zaman “açık bulmak” için satın alır. Bu doğru fakat eksik bir amaçtır. Profesyonel çalışma, üç ayrı değeri aynı anda üretmelidir:

1. 1Güvenlik riskini teknik olarak doğrulamak
2. 2Alınan kontrollerin gerçekten çalışıp çalışmadığını ölçmek
3. 3Düzeltme ekibine önceliklendirilebilir ve tekrar üretilebilir kanıt vermek

Varsayımları gerçek davranışla karşılaştırır

Mimari dokümanda bütün API endpoint’lerinin authorization middleware arkasında olduğu yazabilir. Sızma testi, yeni eklenen export endpoint’inin aynı control’den geçip geçmediğini gösterir.

Network diagram’da management subnet’in user VLAN’dan izole olduğu görülebilir. Internal pentest, yanlış firewall rule veya dual-homed host nedeniyle bu sınırın gerçekten aşılıp aşılamadığını ölçer.

Cloud policy least privilege prensibine göre hazırlanmış olabilir. Test sırasında bir workload identity’nin secret okuma, snapshot oluşturma veya başka role assume etme yetkisi üzerinden beklenmeyen privilege path ortaya çıkabilir.

Kâğıt üzerindeki control ile çalışan sistemdeki control aynı şey değildir.

Riski “olası” olmaktan çıkarır

Bir zafiyet taraması “bu version şu CVE’den etkilenebilir” diyebilir. Sızma testi version detection sonucunu doğrular, deployment koşullarını inceler, compensating control’leri değerlendirir ve izin verilen ölçüde exploitability kanıtı üretir.

Bu ayrım remediation önceliğini değiştirir. İnternetten erişilebilen ve authentication gerektirmeyen doğrulanmış bir RCE ile yalnızca internal build metadata’sına dayanan belirsiz version eşleşmesi aynı sırada ele alınmamalıdır.

Compliance ve denetim kanıtı sağlar

Sızma testi ISO/IEC 27001, PCI DSS ve KVKK bağlamında sıkça gündeme gelir. Burada kesin ve doğru dil kullanmak önemlidir.

ISO/IEC 27001:2022, kuruluşun information security risklerini sistematik biçimde yönetmesini bekler. Standardın adı geçiyor diye her kurum için aynı scope’ta ve aynı tarihte zorunlu pentest sonucu çıkmaz. Test ihtiyacı risk değerlendirmesi, seçilen kontroller, müşteri yükümlülükleri ve kuruluşun Statement of Applicability yapısıyla birlikte belirlenir.

PCI DSS v4.0.1, cardholder data environment kapsamındaki kuruluşlar için penetration testing metodolojisi ve belirli internal ile external test gereksinimleri tanımlar. Ancak yalnızca bir pentest raporuna sahip olmak PCI DSS uyumu anlamına gelmez. Scope, segmentation doğrulaması, significant change sonrası test ve remediation süreçleri standardın ilgili koşullarına göre yürütülmelidir.

KVKK tarafında 6698 sayılı Kanun’un 12. maddesi veri sorumlusuna uygun teknik ve idari tedbirleri alma yükümlülüğü getirir. Her veri sorumlusu için değişmez bir “yılda bir pentest” cümlesi kurmak doğru değildir. Buna karşılık kişisel veri işleyen kritik sistemlerde sızma testi, uygun güvenlik düzeyinin sağlandığını ve risklerin ele alındığını gösterebilecek önemli teknik kontrollerden biridir.

Sızma testi compliance için yapılabilir. Fakat iyi bir çalışma yalnızca denetçiye sunulacak PDF üretmez, gerçek attack surface üzerinde teknik risk azaltır.

Müşteri ve paydaş güvenini destekler

Kurumsal müşteriler artık yalnızca “güvenliyiz” beyanıyla yetinmiyor. Tedarikçi güvenlik değerlendirmelerinde test tarihi, scope, kritik bulgu durumu, retest sonucu ve test ekibinin yetkinliği soruluyor.

Burada paylaşılması gereken belge her zaman tam teknik rapor değildir. Hassas exploit ayrıntıları çıkarılmış bir attestation, executive summary veya closure statement kullanılabilir. Ama bu belgenin arkasında gerçek, izlenebilir ve güncel bir test bulunmalıdır.

Sızma testi türleri nelerdir?

“Sızma testi yaptırdık” cümlesi, hangi varlığın hangi saldırgan perspektifiyle test edildiği söylenmeden fazla anlam taşımaz. Web application, API ve internal network aynı test planıyla değerlendirilemez.

SECNODEX’in Sızma Testi hizmeti, scope içindeki teknoloji ve risk modeline göre aşağıdaki çalışma türlerini ayrı ayrı veya bütünleşik biçimde ele alır.

Web application sızma testi

Web pentest yalnızca form alanlarına payload göndermek değildir. Authentication, authorization, session management, business logic, file handling, server-side request flow, client-side behavior ve third-party integration’lar birlikte değerlendirilir.

Özellikle multi-role ve multi-tenant uygulamalarda route sayısından daha önemli olan, role, object, action ve state ilişkileridir. Aynı endpoint farklı kullanıcı bağlamlarında tekrar test edilmeden broken access control riski anlaşılamaz.

API sızma testi

API testinde REST, GraphQL, gRPC, WebSocket, webhook ve machine-to-machine akışları scope’a göre incelenir. Object-level authorization, function-level authorization, token scope, rate limit, mass assignment, schema validation, replay ve inventory problemleri ön plana çıkar.

API dokümantasyonunun bulunması testin saldırgan perspektifini bozmaz. Gray box çalışmada OpenAPI collection, test token’ları ve role matrisi verilmesi, ayrılan sürenin tahmine değil güvenlik kontrollerine harcanmasını sağlar.

Mobile application sızma testi

Mobile pentest Android veya iOS binary’sinin incelenmesiyle sınırlı değildir. Local storage, platform permission, IPC, certificate validation, deep link, root veya jailbreak davranışı, runtime manipulation ve backend API birlikte ele alınır.

Mobil client içindeki secret veya obfuscation problemi tek başına değerlendirilmez. Saldırganın client’ı değiştirebildiği kabul edilerek server-side control’lerin bu koşulda nasıl davrandığı test edilir.

Dış ağ sızma testi

External pentest, internetten erişilebilen IP, domain, VPN, remote access, mail, web ve management surface’ini kapsar. Amaç bir saldırganın kuruma ait dış varlıklardan hangi initial access yollarını bulabileceğini ve izin verilen sınırlar içinde ne kadar ilerleyebileceğini ölçmektir.

Asset ownership doğrulanmadan geniş IP aralıklarına test uygulanmamalıdır. CDN, hosting provider, SaaS ve third-party varlıklar ayrı izin gerektirebilir.

İç ağ sızma testi

Internal pentest, çoğu zaman standart bir kullanıcı veya sınırlı network erişimi elde etmiş saldırganı temel alır. Active Directory, credential exposure, service account, local privilege escalation, network segmentation, lateral movement ve sensitive share erişimi incelenir.

İç testin amacı “kaç host bulundu?” sorusuna cevap vermek değildir. Düşük yetkili bir başlangıç noktasından kritik identity veya data asset’lerine uzanan attack path’leri göstermektir.

Cloud sızma testi

Cloud değerlendirmesinde public endpoint’ler kadar IAM relationship, workload identity, metadata service, object storage, serverless function, secret management, network policy ve control plane permission’ları önemlidir.

AWS, Azure veya Google Cloud üzerindeki testler provider’ın acceptable use ve penetration testing kurallarına uygun yürütülmelidir. Müşteri onayı, provider sınırlarını ihlal eden bir tekniği otomatik olarak meşru hâle getirmez.

Kablosuz ağ sızma testi

Wireless pentest, yalnızca Wi-Fi password gücünü ölçmez. Kurumsal ve guest network ayrımı, 802.1X configuration, certificate validation, rogue access point riski, client isolation, captive portal ve kablosuz ağdan iç sistemlere erişim sınırları değerlendirilir.

Fiziksel lokasyon ve radio range test scope’una dâhilse çalışma alanı önceden belirlenmelidir. Komşu kurumların veya kamusal kullanıcıların trafiği test kapsamı dışında tutulur.

Sosyal mühendislik testi

Phishing, vishing, fiziksel erişim ve help desk manipulation senaryoları teknik pentestten farklı insan ve süreç riskleri taşır. Hedef kullanıcı grubu, kullanılabilecek pretext, veri toplama sınırı, çalışma saatleri, HR ve hukuk onayı, escalation süreci açıkça yazılmalıdır.

Genel bir “sosyal mühendislik serbesttir” ifadesi yeterli değildir. Çalışan mahremiyetini ve kurum operasyonunu koruyan ayrıntılı Rules of Engagement gerekir.

Black box, gray box ve white box sızma testi

Bu üç yaklaşım test kalitesinin sıralaması değildir. Tester’a başlangıçta verilen bilgi ve erişim seviyesini ifade eder.

Çoğu kurumsal web ve API testinde gray box verimli bir başlangıçtır. Authentication ekranını tekrar tekrar aşmaya çalışmak yerine farklı role ve tenant ilişkileri derinlemesine test edilebilir. Internet-facing exposure ölçülmek isteniyorsa aynı engagement içinde önce black box recon, ardından gray box authenticated test uygulanabilir.

Bu seçim hakkında daha ayrıntılı karar modeli için Black box, gray box ve white box sızma testi karşılaştırmamızı inceleyebilirsiniz.

Sızma testi metodolojileri

Metodoloji, rapora logo eklemek için kullanılan bir isim değildir. Hangi test alanlarının kapsanacağını, kanıtın nasıl üretileceğini ve çalışmanın nasıl tekrar edilebilir hâle getirileceğini belirleyen çerçevedir.

Tek bir metodoloji her varlık türünü aynı derinlikte kapsamaz. Profesyonel ekip, scope’a göre birden fazla kaynaktan yararlanır ve hangi kontrolün neden uygulandığını test planında açıklar.

OWASP Web Security Testing Guide

OWASP WSTG, web application ve web service testleri için kapsamlı test senaryoları sunar. Information gathering, configuration, identity, authentication, authorization, session, input validation, business logic, client-side ve API test alanlarını sistematik biçimde ele alır.

2026 itibarıyla OWASP proje sayfası v4.2’yi stable release olarak listelerken v5.0 geliştirme çalışmaları devam etmektedir. Teklifte yalnızca “OWASP’a göre test” yazılması bu nedenle yeterli değildir. Kullanılan version, ilgili test scenario’ları, scope dışı alanlar ve application’a özel ek kontroller belirtilmelidir.

PTES

Penetration Testing Execution Standard, engagement’ı pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation ve reporting başlıklarıyla ele alır.

PTES’in değeri yalnızca teknik payload listesi vermesi değildir. Test başlamadan önce iş hedefi, iletişim, scope, permission ve teslimat beklentilerinin belirlenmesini çalışma sürecinin parçası hâline getirir.

NIST SP 800-115

NIST SP 800-115, teknik güvenlik testlerinin planlanması, uygulanması, bulguların analiz edilmesi ve mitigation yaklaşımının geliştirilmesi için rehber sunar. Network discovery, vulnerability scanning, password cracking ve penetration testing gibi tekniklerin fayda ve sınırlarını birlikte ele alır.

Özellikle kurum içi süreç, risk değerlendirmesi ve assessment governance tarafında güçlü bir referanstır. Ancak 2008 tarihli doküman modern API, cloud-native ve mobile test detayları için tek başına yeterli kabul edilmemelidir.

OSSTMM

OSSTMM, operational security testing yaklaşımını ölçülebilir ve tekrarlanabilir bir çerçeveye oturtmayı amaçlar. Human, physical, wireless, telecommunications ve data network kanalları gibi daha geniş alanları ele alabilir.

Her projede bütün OSSTMM modelinin uygulanması gerekmez. Scope’a uygun channel ve metric’ler seçilmeli, metodoloji adıyla gerçekte yapılan test arasında bağ kurulmalıdır.

MITRE ATT&CK

MITRE ATT&CK, gerçek dünya gözlemlerine dayanan adversary tactics ve techniques knowledge base’idir. Klasik web pentest checklist’i veya başlı başına bir penetration testing metodolojisi değildir.

External, internal veya adversary emulation odaklı çalışmalarda bulunan attack path’leri ortak bir dilde ifade etmek, detection coverage’ı tartışmak ve belirli technique’leri rapora map etmek için kullanılabilir. Her pentest bulgusunu zorla ATT&CK technique’ine bağlamak ise anlamlı değildir.

İyi bir test planı metodoloji isimlerini üst üste yazmaz. Örneğin web application için WSTG scenario’ları, engagement yönetimi için PTES ilkeleri, kurumsal assessment süreci için NIST rehberi ve ilgili adversary behavior için ATT&CK mapping’i birlikte kullanılabilir.

Sızma testi aşamaları

Bir pentest, scanner başlatılıp PDF alınan tek adımlı bir işlem değildir. Aşamalar scope’a göre değişse de profesyonel bir engagement aşağıdaki akışı izler.

1. Scoping ve pre-engagement

Teknik test başlamadan önce hedef, amaç ve güvenlik sınırları tanımlanır. Domain, IP, application, API, mobile build, cloud account, role ve tenant listesi netleştirilir. Third-party varlıklar ayrılır.

Rules of Engagement içinde test tarihleri, kaynak IP’ler, rate limit, yasak teknikler, production veri yaklaşımı, stop condition, acil iletişim ve bulgu bildirim yöntemi yazılır. Account hazırlığı, MFA, VPN, test data ve allowlist işlemleri de bu aşamada tamamlanmalıdır.

Eksik scoping test sırasında iki kötü sonuçtan birini üretir. Ekip ya riski azaltmak için yüzeysel kalır ya da yetki sınırını yanlış yorumlayarak operasyonel problem çıkarır.

2. Keşif ve attack surface mapping

Tester domain, host, port, technology, route, endpoint, parameter, role, data flow ve trust boundary noktalarını çıkarır. Passive ve active reconnaissance birlikte kullanılabilir.

Web uygulamasında JavaScript bundle’ları, API çağrıları, hidden route’lar ve alternate host’lar önemlidir. Internal network’te identity yapısı, subnet ilişkileri, servisler ve management protocol’leri incelenir. Cloud ortamında public resource kadar IAM graph ve cross-account trust da attack surface’in parçasıdır.

Bu aşamanın çıktısı yalnızca host listesi değil, test edilecek güvenlik iddialarının haritasıdır.

3. Tarama ve vulnerability analysis

Automated scan bilinen zayıflıkları, exposed service’leri ve hızlı doğrulanabilecek configuration problemlerini bulmak için kullanılır. Ardından sonuçlar manuel olarak doğrulanır.

Tester aynı zamanda tool’un göremediği alanlara odaklanır. Role farkları, multi-step business flow’lar, signed request yapıları, queue veya webhook davranışı ve state transition problemleri burada incelenir. Potansiyel bulgular false positive, duplicate, intended behavior ve compensating control açısından değerlendirilir.

4. Controlled exploitation

Exploitation aşamasında zafiyetin gerçekten kullanılabilir olup olmadığı kanıtlanır. Amaç en fazla veriyi almak değil, etkiyi gösterecek en düşük riskli kanıtı üretmektir.

Örneğin IDOR için başka kullanıcıya ait tek bir sentetik kayıt, SQL injection için sınırlı ve non-destructive database evidence, file access bulgusu için hassas olmayan kontrollü bir dosya yeterli olabilir. Production ortamında kullanılan teknikler Rules of Engagement ile daha sıkı sınırlandırılır.

5. Post-exploitation ve attack chain analizi

Post-exploitation her pentestte aynı ölçüde uygulanmaz. İzin verildiğinde ilk erişimin privilege escalation, lateral movement, credential access veya kritik veriye ulaşma açısından ne anlama geldiği değerlendirilir.

Bu aşama özellikle internal network ve external infrastructure testlerinde önemlidir. Tekil bir zafiyetin gerçek riskini, sonrasında açtığı yollar belirleyebilir. Ancak persistence, data exfiltration veya defense evasion gibi adımlar açık yetki olmadan uygulanmaz.

6. Raporlama ve technical QA

Rapor test bittikten sonra hazırlanan otomatik bir çıktı değildir. Evidence test sırasında düzenli toplanır, finding’ler root cause ve business impact açısından birleştirilir, severity gerekçelendirilir ve remediation teknik olarak gözden geçirilir.

Kritik bulgular final rapor beklenmeden bildirilmelidir. Rapor tamamlandığında teknik ekip için ayrıntılı bulgular, yönetim için risk görünümü ve uygulanabilir önceliklendirme birlikte sunulur.

7. Retest

Retest yalnızca eski request’i yeniden göndermek değildir. Original PoC’nin artık çalışmadığı görülmeli, düzeltmenin root cause’u ele alıp almadığı incelenmeli ve fix’in yeni regression üretmediği kontrol edilmelidir.

Status değerleri en az Closed, Partially Remediated, Not Remediated ve Cannot Verify gibi açık anlamlar taşımalıdır. Düzeltme farklı bir control ile yapıldıysa yeni evidence rapora eklenmelidir.

Sızma testi ile zafiyet taraması arasındaki fark

İki çalışma rakip değildir. Farklı soruları cevaplar ve güçlü bir güvenlik programında birbirini tamamlar.

Zafiyet taraması sürekli attack surface görünürlüğü ve patch yönetimi için değerlidir. SECNODEX Zafiyet Tarama hizmeti bu geniş ve tekrarlanabilir görünürlüğü sağlar. Pentest ise seçilen scope üzerinde insan yorumuyla derinleşir.

“Scanner çalıştırıldı, kritik sonuç çıkmadı” cümlesi business logic, authorization ve chained attack riskinin test edildiğini göstermez. Buna karşılık yılda bir yapılan penetration testing çalışması da yeni açılan host’ları ve her gün yayımlanan CVE’leri sürekli izleyemez.

İç ağ ve dış ağ sızma testi arasındaki fark

Dış ağ testi, henüz kurum ağına erişimi olmayan saldırganın internet-facing surface üzerinden neler yapabileceğini ölçer. İç ağ testi ise bir endpoint’in ele geçirildiği, kötü niyetli iç kullanıcı bulunduğu veya sınırlı network erişimi kazanıldığı varsayımından başlar.

Biri diğerinin yerine geçmez. External surface güçlü olsa bile phishing, stolen credential veya compromised laptop üzerinden içeri girildiğinde ağın dayanıklılığı ayrıca ölçülmelidir. Başlangıç varsayımlarını ve kapsam farklarını Dış ağ ve iç ağ sızma testi arasındaki farklar rehberimizde daha ayrıntılı ele alıyoruz.

Sızma testi ile Red Team arasındaki fark

Pentest çoğunlukla tanımlı varlık veya application üzerinde olabildiğince fazla anlamlı zafiyet bulmaya ve doğrulamaya odaklanır. Red Team ise belirli bir objective’e, gerçekçi adversary behavior’a ve kurumun prevention ile detection yeteneğine odaklanır.

Her kuruma otomatik olarak Red Team gerekmez. Temel vulnerability management, asset inventory ve pentest süreçleri oturmadan yapılan pahalı bir operasyon beklenen değeri üretmeyebilir. Hangi noktada ayrıştıklarını Red Team ile sızma testi arasındaki fark yazımızda objective ve test mantığı üzerinden açıklıyoruz.

Sızma testinde sık bulunan açıklar

Her teknoloji aynı vulnerability dağılımını üretmez. Yine de kurumsal testlerde bazı root cause’lar tekrar tekrar karşımıza çıkar.

Broken Access Control ve IDOR

Kullanıcı arayüzünde bir butonun görünmemesi server-side authorization değildir. Tester farklı kullanıcı, role ve tenant context’lerinde object okuma, değiştirme, silme, export ve action çağrılarını tekrarlar.

IDOR’un yaygın kalmasının nedeni çoğu zaman tek bir eksik if satırı değil, role, action, object ownership ve tenant ilişkisinin merkezi biçimde modellenmemesidir. Bu root cause’u IDOR açığı neden hâlâ bu kadar yaygın? yazımızda teknik örneklerle inceliyoruz.

Authentication ve session problemleri

Password reset, MFA enrollment, recovery, remember-me, SSO callback, token refresh, logout ve session invalidation akışları test edilir. Güçlü login ekranı, daha zayıf bir recovery kanalını telafi etmez.

Injection zafiyetleri

SQL injection, command injection, server-side template injection, LDAP injection ve NoSQL injection gibi zafiyetler untrusted input’un güvenli olmayan interpreter context’ine ulaşmasıyla oluşur. Modern framework kullanmak riski azaltabilir, fakat dynamic query, unsafe wrapper veya yanlış API kullanımı problemi geri getirebilir.

SSRF

URL fetch, webhook, PDF rendering, image import ve integration özellikleri server-side outbound request yüzeyi oluşturabilir. Yalnızca hostname allowlist kullanmak DNS resolution, redirect, IP literal, parser difference ve network egress risklerini bütünüyle çözmez. Savunma katmanlarını SSRF’yi kapatmak için yalnızca allowlist yeterli mi? rehberimizde ayrıntılı olarak açıklıyoruz.

Business logic abuse

Coupon’ın tekrar kullanılması, negative quantity, approval sırasının atlanması, transfer limitinin paralel request’lerle aşılması veya refund işleminin iki kez tetiklenmesi generic scanner’ın güvenilir biçimde bulamayacağı problemlerdir.

Business logic testinin girdisi yalnızca endpoint listesi değildir. Intended iş kuralı, state machine, role ayrımı ve finansal sınırların bilinmesi gerekir.

Güvenli olmayan file upload ve processing

Extension veya request içindeki MIME değerine güvenmek file upload güvenliği sağlamaz. Filename isolation, content detection, structural validation, quarantine, malware scanning, parser isolation, secure storage ve authorized download aynı lifecycle içinde ele alınmalıdır.

Cloud ve configuration hataları

Public bucket, aşırı IAM permission, exposed secret, yanlış security group, unrestricted management plane ve cross-account trust ilişkileri kritik attack path oluşturabilir. Burada yalnızca public exposure değil, bir identity’nin başka resource’lara uzanan efektif yetkisi önemlidir.

Sızma testi ne zaman yaptırılmalı?

Yıllık test tarihi yararlı bir baseline olabilir, fakat tek tetikleyici olmamalıdır. Yeni bir sistem production’a çıkmadan önce, authentication veya authorization değişikliğinden sonra, yeni API ve third-party integration eklendiğinde, cloud ya da network mimarisi değiştiğinde ve önemli bir güvenlik olayı sonrasında test planlanmalıdır.

Olay devam ederken plansız pentest başlatmak forensic evidence’i ve log yorumunu zorlaştırabilir. Önce Incident Response ile containment ve root cause çalışması tamamlanmalı, ardından düzeltme targeted retest ile doğrulanmalı ve benzer attack path’ler için kapsam genişletilmelidir.

Risk bazlı zamanlama modelini Sızma testi ne zaman yaptırılmalı? yazımızda release, significant change ve olay sonrası senaryolarıyla açıklıyoruz.

Sızma testi kaç gün sürer ve kapsam nasıl belirlenir?

Süre yalnızca domain veya IP sayısıyla hesaplanamaz. Role, tenant, API endpoint, business flow, platform, erişim modeli, production sınırları, rapor dili ve retest yaklaşımı eforu değiştirir.

Tek role sahip küçük bir web application birkaç tester-day içinde değerlendirilebilir. Multi-tenant, ödeme ve approval flow’ları içeren, mobil client ile API’nin birlikte test edildiği platformlar çok daha uzun sürebilir. “Bir application” ifadesi güvenilir süre hesabı değildir.

Test eforunu etkileyen değişkenleri Sızma testi kaç gün sürer? rehberimizde, route, role, tenant ve integration envanterini ise web uygulaması sızma testi kapsamı yazımızda ayrıntılı olarak ele alıyoruz.

Sızma testi raporu ne içerir?

İyi rapor, screenshot koleksiyonu veya tool çıktısı değildir. Farklı okuyucuların aynı risk üzerinde karar verebilmesini sağlayan evidence paketidir.

Her finding için en az şu bilgiler bulunmalıdır:

• Açık ve root cause’u anlatan başlık
• Etkilenen asset, endpoint, role, tenant ve environment
• Ön koşullar ve test context’i
• Adım adım reproduction
• Gerekli ölçüde maskelenmiş request ve response evidence
• Controlled PoC sonucu
• Teknik etki ve business impact
• CVSS version, score ve vector
• Risk gerekçesi ve varsa compensating control
• Uygulanabilir remediation
• Benzer noktaları bulmaya yarayan systemic fix önerisi
• Retest sırasında kullanılacak closure kriteri

CVSS teknik severity’yi ortak dille aktarmaya yardımcı olur, fakat kurumun bütün risk kararını tek başına vermez. 2026 itibarıyla FIRST’ün güncel standardı CVSS v4.0’dır. Rapor v3.1 veya v4.0 kullanıyorsa version ve vector açıkça yazılmalı, asset criticality ve iş etkisi ayrıca anlatılmalıdır.

Yönetici özeti teknik ayrıntıları tekrar etmemelidir. Kritik attack path’leri, etkilenen iş süreçlerini, risk yoğunluğunu, tekrar eden root cause’ları ve önerilen remediation sırasını göstermelidir.

Sızma testi firması nasıl seçilir?

Teklifleri yalnızca fiyat, gün sayısı veya örnek raporun görsel tasarımıyla karşılaştırmak yanıltıcıdır. Aşağıdaki sorular daha güçlü seçim sinyali üretir:

• Scope hangi teknik girdilerle hesaplandı?
• Automated scan ile manuel test eforu nasıl ayrılıyor?
• Authorization ve business logic coverage’ı nasıl oluşturuluyor?
• Finding raporlanmadan önce nasıl doğrulanıyor?
• Kritik sonuçlar final rapor beklenmeden nasıl bildiriliyor?
• Testi yapacak kişilerin ilgili web, network, mobile veya cloud deneyimi var mı?
• Rapor technical QA sürecinden geçiyor mu?
• Retest kaç tur ve hangi closure standardıyla yapılıyor?
• Veri, credential ve evidence nasıl korunup siliniyor?
• Professional liability ve gizlilik süreçleri tanımlı mı?

SECNODEX ekibinde Offensive Security Certified Professional (OSCP) ve Offensive Security Web Expert (OSWE) sertifikalarına sahip uzmanlar yer alır. OSCP, network ve system penetration testing, privilege escalation ve controlled exploitation alanlarındaki hands-on yetkinliği destekler. OSWE ise advanced web application exploitation, source-assisted analysis, authentication ve authorization bypass, business logic ve custom vulnerability research alanlarında uygulamalı uzmanlık göstergesidir.

Bu yetkinlik yalnızca sertifika logolarıyla sunulmaz. SECNODEX, potansiyel scanner sonucunu doğrudan rapora taşımaz. Bulguyu manuel olarak doğrular, reproducible evidence üretir, attack path içindeki gerçek etkisini açıklar ve remediation önerisini etkilenen teknolojiye göre yazar. Finding’ler teslimattan önce technical QA sürecinden geçirilir. Teklifte bu yaklaşımın nasıl tarif edilmesi gerektiğini Sızma testi teklifinde hangi teknik maddeler olmalı? rehberimizde kontrol listesiyle bulabilirsiniz.

Sızma testinin yasal ve etik boyutu

Pentest yalnızca yetkili sistemlerde yapılır. Sözlü onay veya bir çalışanın “test edebilirsiniz” mesajı, kapsamlı engagement için yeterli güvence değildir.

Başlamadan önce yetkili taraflar, varlık ownership’i, tarih, kaynak IP, izin verilen teknikler, veri işleme sınırı ve stop condition yazılı hâle getirilmelidir. NDA gizliliği düzenler. Rules of Engagement ise testin operasyonel sınırlarını belirler. Bu iki belge birbirinin yerine geçmez.

Third-party hosting, SaaS, CDN, payment provider ve cloud resource’ları ayrıca kontrol edilmelidir. Müşterinin kullandığı her sistem müşterinin test yetkisine sahip olduğu varlık değildir. Sosyal mühendislik, DoS, persistence, password spraying ve data exfiltration gibi yüksek etkili teknikler açık izin olmadan uygulanmamalıdır.

Sonuç: İyi sızma testi daha uzun bulgu listesi değil, daha güçlü kanıttır

Sızma testi bir scanner lisansı, compliance kutucuğu veya tek seferlik güvenlik sertifikası değildir. Gerçek değer, kritik güvenlik varsayımlarının kontrollü saldırı teknikleriyle sınanmasından gelir.

Doğru scope oluşturulur, automation destekleyici kullanılır, bulgular manuel doğrulanır, exploitation minimum etkiyle kanıtlanır, attack chain ve business impact açıklanır, remediation uygulanabilir biçimde yazılır ve düzeltmeler retest ile kapatılır.

SECNODEX web, API, mobile application, iç ağ, dış ağ ve cloud kapsamlarını aynı generic checklist’e sıkıştırmaz. Her engagement için varlık, role, trust boundary, kritik iş akışı ve saldırgan perspektifine göre test planı oluşturur.

Kurumsal sistemleriniz için doğru kapsamı belirlemek, teknik teklif almak veya mevcut test yaklaşımınızı değerlendirmek için SECNODEX Sızma Testi hizmetini inceleyebilir ya da bizimle iletişime geçebilirsiniz.

Kaynaklar

• OWASP Web Security Testing Guide
• Penetration Testing Execution Standard
• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• ISECOM – Open Source Security Testing Methodology Manual
• MITRE ATT&CK
• FIRST – Common Vulnerability Scoring System v4.0
• OffSec – PEN-200 ve OSCP
• OffSec – WEB-300 ve OSWE
• ISO/IEC 27001:2022
• PCI Security Standards Council – Document Library
• Kişisel Verileri Koruma Kurumu – Veri Güvenliğine İlişkin Yükümlülükler