Sızma Testi Ne Zaman Yaptırılmalı? Yayına Çıkmadan Önce mi, Olay Sonrası mı?

Bir sızma testinin değerini yalnızca bulunan zafiyetlerin sayısı belirlemez. Testin ne zaman yapıldığı da en az kapsamı ve kullanılan metodoloji kadar önemlidir. Üç ay önce tamamlanan bir pentest, o tarihten sonra authentication yapısı değiştirilmiş, yeni API endpoint’leri eklenmiş veya cloud mimarisi yeniden kurulmuş bir uygulamanın bugünkü güvenlik durumunu göstermez.

Bu nedenle “Sızma testi ne zaman yaptırılmalı?” sorusunun tek kelimelik cevabı “yıllık” değildir. Doğru cevap, sistemin yaşam döngüsüne göre değişir. İdeal yaklaşım kritik bir uygulamayı yayına çıkmadan önce test etmek, önemli her değişiklikten sonra ilgili attack surface’i yeniden değerlendirmek ve bir siber olay yaşandıysa Incident Response süreci tamamlandıktan sonra düzeltmelerin gerçekten işe yaradığını doğrulamaktır.

Neden tek seferlik sızma testi yeterli değildir?

Uygulamalar sabit kalmaz. Yeni özellikler eklenir, eski servisler kaldırılır, third-party entegrasyonlar değişir, yeni kullanıcı rolleri tanımlanır ve altyapı farklı bir cloud ortamına taşınır. Bazen uygulama koduna dokunulmaz fakat WAF rule set’i, reverse proxy, DNS, load balancer, IAM policy veya network segmentation değişir. Bunların her biri daha önce test edilmiş güvenlik varsayımlarını geçersiz kılabilir.

Örneğin altı ay önce yapılan testte authorization kontrolleri doğru çalışıyor olabilir. Daha sonra kurumsal müşteriler için yeni bir rol eklendiğinde yalnızca arayüzdeki menülerin gizlenmesi, API tarafındaki object-level authorization kontrolünün unutulması mümkündür. Önceki raporun temiz olması bu yeni IDOR riskini kapsamaz. Aynı durum file upload, password reset, SSO, OAuth, ödeme akışı ve admin paneli gibi kritik fonksiyonlar için de geçerlidir.

Sızma testi bir ürünün süresiz güvenlik sertifikası değildir. Belirli bir tarihte, tanımlanmış bir kapsam ve yetki çerçevesinde elde edilmiş teknik bir güvence seviyesidir. Kod, configuration, mimari, kullanıcı rolleri veya dış saldırı yüzeyi değiştiğinde bu güvence yeniden doğrulanmalıdır.

En doğru zaman hangisi: Yayın öncesi mi, olay sonrası mı?

İkisi farklı sorulara cevap verir.

Yayın öncesi sızma testi, saldırganlardan önce güvenlik açıklarını bulmayı ve riski production ortamına taşımamayı amaçlar. Proaktif bir kontroldür. Düzeltme için hâlâ zaman bulunduğundan teknik ve ticari açıdan en avantajlı aşamadır.

Olay sonrası sızma testi ise yaşanan olayın kullandığı attack path’in kapatılıp kapatılmadığını, benzer yolların başka sistemlerde bulunup bulunmadığını ve alınan önlemlerin gerçekten etkili olup olmadığını ölçer. Reaktif fakat gerekli bir doğrulamadır.

Bir kurum ilk kez pentest yaptıracaksa ve henüz olay yaşamamışsa, siber olay beklemek en pahalı seçim olur. Buna karşılık olay yaşandıktan sonra yalnızca eski bir pentest raporuna bakıp “Bu sistem daha önce test edilmişti” demek de yanlış güven üretir. Doğru model bu iki zamanı birbirinin alternatifi olarak değil, aynı güvenlik yaşam döngüsünün farklı kontrol noktaları olarak görmektir.

Yayına çıkmadan önce sızma testi neden kritik?

Yeni bir web uygulaması, mobile application veya API production ortamına çıktığı anda gerçek saldırı yüzeyinin parçası olur. Domain henüz duyurulmamış olsa bile certificate transparency kayıtları, DNS verileri, IP taramaları, JavaScript dosyaları ve farklı reconnaissance kaynakları üzerinden keşfedilebilir. “Kimse URL’yi bilmiyor” yaklaşımı bir güvenlik kontrolü değildir.

Yayın öncesi testin temel avantajı, geliştirici ekibin hâlâ değişiklik yapabilecek durumda olmasıdır. Authentication bypass, broken access control, business logic abuse, SSRF, SQL injection veya güvenli olmayan file upload gibi kritik bir bulgu production sonrasında tespit edildiğinde yalnızca kod düzeltmesi yapılmaz. Acil change kaydı açılması, operasyon ekiplerinin devreye girmesi, bakım penceresi oluşturulması, müşteri iletişimi ve olası veri etkisinin araştırılması da gerekebilir.

Bu nedenle test, release tarihinden bir gün önce planlanmamalıdır. Testin yürütülmesi, raporlanması, kritik bulguların düzeltilmesi ve retest için gerçekçi bir zaman bırakılmalıdır. Kapsama bağlı olarak yayın tarihinden birkaç hafta önce başlatılan bir çalışma, ekiplere bulguları kontrollü biçimde ele alma imkânı verir.

Pre-production ortamı production ile aynı değilse ne olur?

Yayın öncesi testin güçlü olabilmesi için test ortamının production mimarisini anlamlı ölçüde yansıtması gerekir. Aynı application build kullanılsa bile aşağıdaki farklılıklar sonuçları değiştirebilir:

• Production ortamında farklı reverse proxy veya WAF kuralları bulunması
• Test ortamında SSO yerine local authentication kullanılması
• Gerçek kullanıcı rollerinin ve tenant yapısının test ortamında bulunmaması
• API gateway, rate limit veya CORS configuration değerlerinin farklı olması
• Cloud IAM policy’lerinin yalnızca production üzerinde tanımlı olması
• Test ortamında maskelenmiş veya yapısal olarak eksik veri kullanılması
• Production deployment sırasında farklı environment variable ve secret’ların devreye girmesi

Bu durumda en sağlıklı yöntem, kapsamlı manuel testi production’a en yakın pre-production ortamında yürütmek ve deployment sonrasında production üzerinde düşük etkili, açıkça yetkilendirilmiş bir verification çalışması yapmaktır. Production testi sırasında kullanılabilecek payload’lar, test hesapları, rate limit, veri değiştiren işlemler, durdurma koşulları ve iletişim kişileri Rules of Engagement içinde önceden tanımlanmalıdır.

Hangi değişikliklerden sonra yeniden sızma testi yapılmalı?

Her küçük metin değişikliğinin ardından tam kapsamlı pentest gerekmez. Ancak güven sınırını, veri akışını, erişim modelini veya internet-facing attack surface’i etkileyen değişiklikler yeni test ihtiyacı doğurur. Aşağıdaki değişiklikler güçlü birer tetikleyicidir:

• Yeni web uygulaması, mobile application, API, VPN veya admin panelinin yayına alınması
• Login, MFA, session management, password reset, SSO, SAML veya OAuth akışlarının değiştirilmesi
• Yeni kullanıcı, rol, tenant veya yetki modelinin eklenmesi
• Ödeme, sipariş, bakiye, kampanya, onay veya iade gibi business logic akışlarının değiştirilmesi
• File upload, document preview, import, export veya raporlama özelliği eklenmesi
• Third-party servis, webhook, payment gateway veya partner API entegrasyonu yapılması
• Yeni cloud account, storage bucket, Kubernetes cluster veya internet-facing service açılması
• Firewall, WAF, CDN, reverse proxy, API gateway, VPN veya network segmentation değişikliği
• Uygulamanın framework, runtime, database veya kritik library sürümünün yükseltilmesi
• Şirket birleşmesi, satın alma veya farklı ağların birbirine bağlanması
• Kritik bir CVE’nin kullanılan teknoloji yığınını etkilediğinin anlaşılması

Buradaki karar yalnızca “Kaç satır kod değişti?” sorusuna göre verilmez. Beş satırlık bir authorization değişikliği binlerce satırlık görsel düzenlemeden daha yüksek risk taşıyabilir. Test ihtiyacını belirleyen asıl konu değişikliğin security boundary üzerindeki etkisidir.

Siber olaydan hemen sonra pentest yapılmalı mı?

Evet, fakat sıralama doğru kurulmalıdır. Aktif bir siber olay devam ederken plansız biçimde geniş kapsamlı pentest başlatmak logları kirletebilir, analistlerin gerçek saldırgan aktivitesiyle test trafiğini ayırmasını zorlaştırabilir ve hassas sistemlerde ek operasyonel risk oluşturabilir. Olay henüz kontrol altına alınmamışsa öncelik Incident Response sürecidir.

Genel sıra şu şekilde olmalıdır:

1. 1Olay doğrulanır ve etkilenen sistemlerin kapsamı belirlenir.
2. 2Gerekli forensic evidence korunur.
3. 3Saldırgan erişimi contain edilir ve persistence mekanizmaları kaldırılır.
4. 4Root cause ile kullanılan attack path belirlenir.
5. 5Zafiyetler ve hatalı configuration değerleri giderilir.
6. 6Hedefli retest ile düzeltmeler doğrulanır.
7. 7Benzer attack path’leri bulmak için kapsam genişletilmiş sızma testi planlanır.

Olay sonrası yapılan ilk kontrol çoğu zaman tam kapsamlı bir pentest değil, compromise edilen yolun hedefli doğrulamasıdır. Örneğin saldırgan internete açık bir VPN appliance üzerinden ilk erişim elde ettiyse yalnızca ilgili CVE’nin patch edildiğini görmek yeterli olmayabilir. Aynı cihazdaki configuration, exposed management interface’leri, ele geçirilmiş credential’lar, MFA yapısı, iç ağ erişimi ve benzer appliance’lar da değerlendirilmelidir.

Ardından daha geniş kapsamlı test yapılır. Çünkü olayda gözlemlenen yol, saldırganın kullanabileceği tek yol olmayabilir. Incident Response “Ne oldu ve etkisi neydi?” sorusuna odaklanırken sızma testi “Aynı veya benzer güvenlik açıkları kullanılarak tekrar içeri girilebilir mi?” sorusuna teknik yanıt üretir.

Sızma testi yılda kaç kez yapılmalı?

Her kurum için geçerli tek bir sayı yoktur. Yılda bir kez yapılan kapsamlı test, birçok kurumda kullanılan makul bir başlangıç noktasıdır. Fakat yüksek değişiklik hızına sahip internet-facing bir uygulama için on iki ay uzun bir süredir. Ayda birkaç kez release alan, hassas veri işleyen veya yoğun saldırgan ilgisi bulunan bir platformda yalnızca yıllık pentest yeterli güvence sağlamaz.

Aşağıdaki tablo sabit bir kural değil, risk bazlı planlama için başlangıç modelidir:

PCI DSS gibi belirli standartlar kendi kapsamları için daha açık periyotlar tanımlayabilir. PCI DSS v4.x Requirement 11.4 altında internal ve external penetration testing için en az 12 aylık periyot ve significant infrastructure veya application change sonrasında tekrar test beklentisi bulunur. Bu gereklilik bütün şirket sistemlerine otomatik olarak uygulanmaz. Kurumun tabi olduğu mevzuat, sözleşmeler, sektör gereksinimleri ve kendi risk analizi ayrıca değerlendirilmelidir.

“Significant change” nasıl anlaşılır?

Significant change yalnızca büyük bir versiyon numarası değildir. Bir değişiklik aşağıdaki sorulardan birine “evet” cevabı veriyorsa yeniden test gündeme alınmalıdır:

• İnternetten erişilebilen yeni bir giriş noktası oluşturuyor mu?
• Kullanıcının kimliğinin veya yetkisinin nasıl doğrulandığını değiştiriyor mu?
• Hassas verinin işlendiği, saklandığı veya aktarıldığı yolu etkiliyor mu?
• Yeni bir trust relationship kuruyor mu?
• Başarılı exploitation durumunda blast radius büyüyor mu?
• Önceki pentest sırasında geçerli olan güvenlik varsayımlarını değiştiriyor mu?
• Kritik bir kontrolü başka bir ürüne, servise veya third-party sağlayıcıya taşıyor mu?

Örneğin yalnızca UI değişikliği gibi görünen bir release, arka planda yeni GraphQL endpoint’leri oluşturuyorsa significant change olarak ele alınabilir. Benzer şekilde on-premise ortamdan cloud’a geçiş, uygulama kodu aynı kalsa bile IAM, storage, network path ve secret management açısından tamamen yeni bir attack surface doğurur.

Sızma testi, zafiyet taraması ve Kaynak Kod Analizi aynı zamanda mı yapılmalı?

Bu çalışmalar birbirinin yerine geçmez. Farklı aşamalarda farklı sorulara cevap verirler.

Zafiyet taraması

Zafiyet taraması sık aralıklarla çalıştırılabilir ve geniş varlık envanterindeki bilinen güvenlik açıklarını, eksik patch’leri veya yaygın configuration problemlerini tespit etmek için kullanılır. Aylık, haftalık veya bazı ortamlarda sürekli çalışması mümkündür. Ancak scanner’ın verdiği sonuç, zafiyetin gerçek iş akışı içinde exploit edilebildiğini tek başına göstermez. Business logic ve authorization problemleri de otomatik araçların en çok zorlandığı alanlardandır.

Kaynak Kod Analizi

Kaynak Kod Analizi geliştirme sürecine daha erken dahil edilebilir. Pull request, major feature veya release aşamasında yapılan manuel inceleme ve SAST çalışmaları, uygulama çalışır hâle gelmeden önce riskli kod akışlarını gösterebilir. Özellikle authentication, authorization, cryptography, deserialization, file handling, secret management ve server-side request akışlarında değerlidir.

Sızma testi

Sızma testi çalışan sistemin dışarıdan ve tanımlanan yetki seviyelerinden nasıl davrandığını inceler. Tek tek bulguları listelemekten öte, birden fazla zayıflığın birleşerek gerçek bir attack path oluşturup oluşturmadığını araştırır. Manuel doğrulama burada belirleyicidir.

Red Team

Red Team çalışması ise belirli bir uygulamanın zafiyet listesinden daha geniş bir hedefe sahiptir. Bir tehdit aktörünün bakış açısıyla kurumun prevention, detection ve response kabiliyetlerini test eder. Red Team, temel güvenlik açıkları henüz yönetilmiyorken yapılan ilk kontrol olmamalıdır. Düzenli vulnerability management ve sızma testi süreçleri belirli bir olgunluğa ulaştıktan sonra daha anlamlı sonuç üretir.

En güçlü model, bu yöntemleri birbirine rakip görmek yerine SDLC ve kurumsal risk yönetimi içinde doğru noktalara yerleştirmektir.

Retest ne zaman yapılmalı?

Retest, rapor tesliminden sonra bulunan zafiyetlerin kapatıldığını doğrulamak için yapılır. Kritik ve yüksek riskli bulgular için düzeltme tamamlanır tamamlanmaz planlanması gerekir. Ancak retest yalnızca “endpoint artık 403 dönüyor” kontrolü değildir.

Bir düzeltme aşağıdaki nedenlerle yetersiz kalabilir:

• Kontrol yalnızca UI katmanına eklenmiş olabilir.
• Aynı zafiyet farklı API version’ında devam ediyor olabilir.
• Belirli kullanıcı rolü düzeltilirken başka bir rol unutulmuş olabilir.
• Girilen payload filtrelenmiş fakat root cause ortadan kaldırılmamış olabilir.
• Düzeltme yeni bir authorization veya business logic açığı doğurmuş olabilir.
• Patch uygulanmış fakat production node’larının bir kısmı eski sürümde kalmış olabilir.

Bu yüzden retest sırasında önce orijinal PoC yeniden denenir, ardından düzeltmenin olası bypass yolları ve yakın çevrede oluşturduğu regression riski kontrol edilir. Kapsamlı pentest ile retest aynı şey değildir. Retest belirli bulgulara odaklanır. Uygulamada geniş çaplı değişiklik yapılmışsa yalnızca retest yerine yeni bir assessment gerekebilir.

Production ortamında sızma testi yapılır mı?

Evet, uygun hazırlıkla yapılabilir. Hatta bazı riskler yalnızca production configuration, gerçek entegrasyonlar ve gerçek network path üzerinde görülebilir. Ancak testin yetkilendirilmiş olması tek başına yeterli değildir. Teknik güvenlik sınırları da açıkça belirlenmelidir.

İyi hazırlanmış bir Rules of Engagement en az şu başlıkları kapsar:

• Test edilecek domain, IP, application, API ve kullanıcı rolleri
• Kapsam dışı sistemler ve third-party varlıklar
• İzin verilen ve yasaklanan test teknikleri
• Veri değiştiren veya servis kesintisi oluşturabilecek işlemler
• Test hesapları ve kullanılabilecek test verileri
• Çalışma saatleri, bakım pencereleri ve yoğun trafik dönemleri
• Acil durumda ulaşılacak teknik ve yönetsel kişiler
• Testi durdurma kriterleri
• Log, evidence ve hassas veri saklama kuralları
• WAF, SOC, SIEM, EDR ve operasyon ekipleriyle koordinasyon modeli

Production-safe yaklaşım, testin yüzeysel yapılması anlamına gelmez. Amaç exploitation riskini kontrollü tutarken gerçek güvenlik etkisini yeterli teknik kanıtla doğrulamaktır.

Sızma testi takvimi nasıl oluşturulur?

Takvimi yalnızca denetim tarihine göre kurmak yerine varlık, değişiklik ve risk bilgisini birlikte kullanmak gerekir. Pratik bir plan beş adımda oluşturulabilir.

1. Kritik varlıkları ve veri akışlarını belirleyin

Hangi web uygulamaları, API’ler, mobile application’lar, VPN sistemleri, cloud servisleri ve internal network bileşenleri kritik? Hangi sistem müşteri verisi, ödeme verisi, kişisel veri veya ticari sır işliyor? İlk öncelik, iş etkisi en yüksek varlıklardır.

2. Son testten bu yana neyin değiştiğini çıkarın

Release kayıtları, infrastructure change’leri, yeni domain ve subdomain’ler, IAM değişiklikleri, third-party bağlantılar ve yeni servisler incelenmelidir. Asset inventory güncel değilse pentest kapsamı daha başlamadan eksik kalabilir.

3. Test tetikleyicilerini release sürecine bağlayın

Security ekibinin bir değişikliği aylar sonra öğrenmesi yerine belirli change türleri otomatik olarak security review veya pentest ihtiyacı oluşturmalıdır. Yeni authentication flow, internet-facing service ve trust relationship değişiklikleri bu kapsama alınabilir.

4. Yıllık temel testi koruyun, araya hedefli testler ekleyin

Tam kapsamlı yıllık test bir baseline sağlar. Fakat major release, kritik entegrasyon veya architecture change olduğunda yıllık tarihi beklemeyin. Değişikliğin etkilediği alanda hedefli test planlayın.

5. Düzeltme ve retest süresini baştan planlayın

Pentest raporunun teslim tarihi sürecin sonu değildir. Bulgu sahipleri, remediation süresi, risk acceptance yetkisi ve retest tarihi proje başlamadan belirlenirse rapor rafta kalmaz.

Sızma testi zamanlamasında sık yapılan hatalar

Testi release’den hemen önce başlatmak

Yayın tarihine birkaç gün kala başlayan test, ekipleri güvenlik ile iş takvimi arasında seçim yapmaya zorlar. Kritik bulgu çıksa bile kapsamlı düzeltme ve retest için süre kalmaz.

Yalnızca compliance için yılda bir kez test yapmak

Denetim gereksinimini karşılamak önemlidir. Fakat yıl içinde defalarca değişen bir attack surface’i tek bir tarih üzerinden değerlendirmek gerçek riski yansıtmaz.

Scanner raporunu pentest kabul etmek

Otomatik tarama genişlik sağlar, manuel sızma testi ise context ve exploitability analizi sunar. İkisini aynı kabul etmek özellikle authorization ve business logic risklerinin gözden kaçmasına neden olabilir.

Olay sonrasında yalnızca patch kontrolü yapmak

Patch gerekli olabilir fakat ele geçirilmiş credential, persistence, hatalı trust relationship veya ikinci bir giriş yolu devam edebilir. Hedefli retest sonrasında daha geniş attack path analizi yapılmalıdır.

Kapsamı yalnızca bilinen domain’lerle sınırlamak

Unutulmuş subdomain’ler, eski IP’ler, shadow IT, test ortamları ve üçüncü taraflarda tutulan varlıklar saldırganın ilk erişim noktası olabilir. External attack surface keşfi kapsamlandırmanın parçası olmalıdır.

Bulgular kapatılmadan yeni test yaptırmak

Önceki rapordaki kritik bulgular hâlâ açıksa aynı sonuçların yeniden üretilmesi yeni güvence sağlamaz. Önce remediation sahipliği kurulmalı, ardından retest ve gerekiyorsa yeni kapsamlı test yürütülmelidir.

Kurumunuz için hızlı karar tablosu

Aşağıdaki durumlardan biri varsa sızma testi tarihini yıllık takvimden bağımsız olarak yeniden değerlendirin:

• Önümüzdeki haftalarda kritik bir uygulama production’a çıkacaksa
• Son testten sonra authentication veya authorization modeli değiştiyse
• Yeni API, mobile application, VPN, cloud service veya external IP açıldıysa
• Uygulama hassas veri işlemeye başladıysa
• Yeni third-party entegrasyonu veya şirketler arası network bağlantısı kurulduysa
• Önemli bir infrastructure veya application upgrade yapıldıysa
• Kurum bir siber olay, veri sızıntısı veya yetkisiz erişim şüphesi yaşadıysa
• Kritik bulgular düzeltildi fakat retest yapılmadıysa
• Son kapsamlı testin üzerinden 12 ay veya kurumun risk iştahına göre uzun sayılabilecek bir süre geçtiyse
• Mevcut test raporu bugünkü asset inventory ve mimariyi yansıtmıyorsa

Bu maddelerden birine bile “evet” cevabı verilmesi, en azından bir scope review yapılmasını gerektirir. Her durumda tam kapsamlı pentest çıkmayabilir. Bazen hedefli web application security testi, API testi, segmentation testi veya Kaynak Kod Analizi daha doğru seçimdir.

Sonuç: Sızma testi bir tarih değil, güvenlik kontrol döngüsüdür

Sızma testi için en iyi zaman, saldırgan sistemdeki açığı bulmadan öncedir. Bu yüzden kritik uygulamalarda ilk tercih yayın öncesi test olmalıdır. Fakat güvenlik burada bitmez. Major release’ler, yeni entegrasyonlar, IAM ve network değişiklikleri önceki testin geçerliliğini azaltır. Siber olay sonrasında ise Incident Response tamamlandıktan ve root cause giderildikten sonra hedefli retest ile daha geniş kapsamlı pentest birlikte düşünülmelidir.

Kısacası doğru soru “Yayına çıkmadan önce mi, olay sonrası mı?” değil, “Hangi risk değişikliğinde hangi güvenlik testini yeniden çalıştırmalıyız?” sorusudur. Sağlıklı bir program yayın öncesi assessment, change-based testing, periyodik tam kapsamlı test, remediation ve retest adımlarını aynı döngü içinde yönetir.

Secnodex, web, mobile application, API, external ve internal network kapsamlarında manuel sızma testi hizmeti sunar. Çalışmalar yalnızca scanner çıktısına dayanmaz. Bulgular kontrollü PoC, teknik evidence, iş etkisi, uygulanabilir remediation adımları ve talep hâlinde retest ile birlikte raporlanır. Yeni bir release, önemli bir infrastructure değişikliği veya olay sonrası doğrulama için doğru kapsamı belirlemek üzere Secnodex ile iletişime geçebilirsiniz.

Metodoloji ve referanslar

• OWASP Web Security Testing Guide
• OWASP Web Security Testing Framework
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• PCI DSS v4.0.1 ve güncel dokümanlar