Retest Ne Zaman Yapılmalı, Ne Zaman Beklemeli?

Pentest raporundaki bulgu geliştirme ekibine atanır. Birkaç gün sonra ticket'ın durumu Done olur ve güvenlik ekibine “Fix tamamlandı, retest yapabilir misiniz?” mesajı gelir. Tester aynı request'i gönderir, uygulama bu kez 403 Forbidden döndürür ve bulgu kapatılır.

Üç hafta sonra aynı açığın farklı bir endpoint'te çalıştığı görülür.

Bu senaryo şaşırtıcı değildir. Çünkü ticket'ın kapanması, source code'daki değişikliğin doğru olması, doğru build'in test ortamına taşınması, bütün application node'larının aynı version'ı çalıştırması ve root cause'un giderilmesi aynı şey değildir. Bir 403 response da authorization kontrolünün doğru nesne, role, tenant ve action seviyesinde uygulandığını tek başına kanıtlamaz.

Retest'in doğru zamanı takvimdeki ilk boşluk değildir. Düzeltmenin test edilebilir, gözlemlenebilir ve temsil edici bir ortamda bulunduğu andır.

Çok erken başlatılan retest, tester eforunu eksik deployment ve hazır olmayan test data ile tüketir. Gereğinden fazla bekletilen retest ise bilinen açığın production'da açık kalma süresini uzatır. Doğru karar, severity etiketinden daha fazlasını gerektirir. Exposure, exploitability, aktif abuse ihtimali, release planı, root cause, fix tipi, deployment durumu ve test bağımlılıkları birlikte değerlendirilmelidir.

Bu rehberde retest'in hangi koşullarda hemen yapılması gerektiğini, ne zaman beklemenin teknik olarak daha doğru olduğunu, hangi durumlarda dar retest yerine yeni bir assessment gerektiğini ve finding closure'ın hangi evidence ile verilebileceğini ele alıyoruz.

Kısa cevap: Retest ne zaman yapılmalı?

Retest, aşağıdaki koşullar birlikte sağlandığında yapılmalıdır:

1. 1Düzeltme ilgili finding'in root cause'unu hedefliyordur.
2. 2Fix, test edilecek environment'a gerçekten deploy edilmiştir.
3. 3Test environment, finding'i üreten güvenlik açısından önemli configuration değerlerini temsil ediyordur.
4. 4Etkilenen tüm instance, node, region, tenant veya API version kapsamı netleştirilmiştir.
5. 5Gerekli test account, role, test data, network access ve integration bağımlılıkları hazırdır.
6. 6Original PoC güvenli biçimde yeniden çalıştırılabilir durumdadır.
7. 7Fix'in etkilediği reasonable variation ve regression alanları belirlenmiştir.
8. 8Test sonucu yanlış yorumlanmasın diye cache, feature flag, rollout ve WAF gibi katmanların durumu bilinmektedir.

Kritik ve internet-facing bir açık için bu hazırlık günlerce bürokratik bekleme anlamına gelmez. Hazırlık hızlandırılır, exposure geçici control'lerle azaltılır ve retest mümkün olan en erken anda yapılır. Buna karşılık kod henüz deploy edilmemişse, yalnızca tek node güncellenmişse veya tester gerekli role'a erişemiyorsa hemen başlamak hız değil, sonucu belirsiz bir kontrol üretir.

Retest nedir?

Retest, daha önce kanıtlanmış bir security finding için uygulanan remediation veya mitigation'ın teknik etkisini yeniden sınama çalışmasıdır. Hedef, original attack path'in artık çalışmadığını görmekle birlikte düzeltmenin kolay bir bypass bırakmadığını ve finding'in etkilenen instance'larında aynı riskin sürmediğini doğrulamaktır.

Retest çoğu durumda ilk pentest'ten daha dardır. Bunun nedeni daha yüzeysel olması değil, başlangıç sorusunun farklı olmasıdır:

• İlk pentest, scope içindeki bilinmeyen zafiyetleri arar.
• Retest, bilinen bulgunun kapanış iddiasını doğrular.

NIST SP 800-115, teknik güvenlik testini bulguların analizi ve mitigation stratejilerinin geliştirilmesiyle birlikte ele alır. NCSC'nin 2026'da gözden geçirilen vulnerability management rehberi ise reconfiguration veya mitigation ile giderildiği söylenen zafiyetin artık mevcut olmadığının doğrulanmasını, geçici workaround'ların da izlenmeye devam edilmesini önerir. PCI DSS v4.0.1 Requirement 11.4.4, penetration testing sırasında bulunan exploitable vulnerability ve security weakness'lerin düzeltilmesini ve düzeltmeleri doğrulamak için testin tekrarlanmasını açıkça ister.

Standartların “tekrar test edin” demesi önemlidir. Ancak kaliteli retest'in sınırlarını finding'in teknik yapısı belirler. Bir TLS configuration bulgusu ile multi-tenant authorization açığı aynı doğrulama adımlarına sahip değildir.

Retest, rescan, regression test ve yeni pentest aynı şey değildir

Bu kavramlar birbirinin yerine kullanıldığında scope ve sonuç beklentisi bozulur.

Bir outdated component finding'i bazen authenticated rescan ve version doğrulamasıyla kapanabilir. Bir IDOR, payment bypass veya race condition için scanner'ın “artık bulamıyorum” demesi yeterli olmaz. Original attack sequence, farklı object'ler, roller, HTTP method'ları, bulk endpoint'ler ve concurrency koşulları manuel olarak yeniden değerlendirilmelidir.

Retest ile yeni pentest arasındaki farkı sözleşme aşamasında tanımlamak önemlidir. Sızma testi teklifinde bulunması gereken teknik maddeler yazımızda cycle, retest window, reasonable variation, partial fix ve updated report beklentilerini ayrıntılı biçimde ele aldık.

“Fix tamamlandı” ne anlama gelmeli?

Geliştirme ekibi için fix tamamlanması, pull request'in merge edilmesi olabilir. DevOps ekibi için build'in pre-production'a taşınmasıdır. Product owner için acceptance test'in geçmesidir. Güvenlik açısından ise bunların hiçbiri tek başına kapanış değildir.

Retest talebinde aşağıdaki zincir kanıtlanabilmelidir:

Root cause tanımlandı
    -> güvenlik tasarımı belirlendi
    -> code veya configuration değişti
    -> review ve test tamamlandı
    -> immutable build üretildi
    -> hedef environment'a deploy edildi
    -> rollout tamamlandı
    -> gerekli cache ve state yenilendi
    -> test bağımlılıkları hazırlandı
    -> retest başladı

Zincirin ortasındaki “deploy edildi” adımı özellikle kritiktir. Tester'ın test ettiği host ile ekibin fix gönderdiği environment farklıysa retest sonucu teknik olarak anlamsızlaşabilir.

Retest readiness gate: Başlamadan önce sekiz kontrol

Her finding için kısa bir readiness gate uygulanması, tekrar tekrar yarım retest yapılmasını önler.

1. Finding kimliği ve affected instance listesi sabit mi?

“Authorization açığı düzeltildi” yeterli bir bildirim değildir. Hangi report ID'nin, hangi endpoint, role, tenant, object type ve action kombinasyonunda test edileceği açık olmalıdır.

Örnek:

Finding ID: WEB-2026-014
Affected routes:
  GET /api/v2/invoices/{invoiceId}
  GET /api/v2/invoices/{invoiceId}/pdf
Actors:
  CUSTOMER_A -> CUSTOMER_B object
Tenancy:
  Same tenant and cross-tenant
Original environment:
  preprod-eu

Tek finding altında 80 endpoint gruplanmışsa retest sonucu instance bazında izlenmelidir. Beş endpoint'in kapanması parent finding'in tamamının kapandığı anlamına gelmez.

2. Root cause yazılı mı?

Root cause olmadan yapılan fix çoğu zaman payload'a özeldir. Örneğin:

• IDOR için belirli object ID'yi blocklamak
• SQL injection için tek tırnak karakterini filtrelemek
• SSRF için yalnızca rapordaki hostname'i denylist'e almak
• XSS için yalnızca PoC içindeki tag'i silmek
• Race condition için frontend butonunu disable etmek

Retest talebinde en az bir cümlelik root cause açıklaması bulunmalıdır. “Controller, repository'den dönen invoice'ın authenticated customer veya tenant ile ilişkisini doğrulamıyordu” ifadesi, “security issue fixed” açıklamasından çok daha test edilebilirdir.

3. Fix doğru environment'a deploy edildi mi?

Commit hash, image digest, build number veya configuration revision bilinmelidir. “Son version var” ifadesi yeterli değildir.

Kubernetes kullanan örnek bir ortamda yalnızca deployment manifest'inin değiştiğini görmek yerine çalışan pod'ların image digest'i kontrol edilmelidir:

kubectl -n preprod rollout status deployment/order-api

kubectl -n preprod get pods \
  -l app=order-api \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[0].imageID}{"\n"}{end}'

Bu komutlar fix'in güvenli olduğunu kanıtlamaz. Yalnızca tester'ın hangi artifact'i değerlendirdiğini netleştirir. Blue-green veya canary deployment varsa trafiğin hangi yüzdeyle hangi version'a gittiği de bilinmelidir.

4. Rollout tamamlandı mı?

Sekiz node'dan yedisi yeni, biri eski version çalıştırıyorsa finding aralıklı görünür. Load balancer nedeniyle tester bazen açık, bazen kapalı sonuç alabilir. Aşağıdaki durumlar kontrol edilmelidir:

• Eski pod veya VM kaldı mı?
• İkinci region deploy edildi mi?
• Background worker aynı fix'i aldı mı?
• API v1 ve v2 aynı code path'i kullanıyor mu?
• Mobile backend'in eski version'ı açık mı?
• Read replica veya cache eski state döndürüyor mu?
• Feature flag yalnızca ekip account'larında mı açık?

Retest, rollout gözlemlenebilir hale gelmeden başlatılırsa Intermittent sonuç üretebilir. Kritik bir açıkta eski node production'da kalıyorsa bu bekleme gerekçesi değil, açık riskin devam ettiğinin kanıtıdır.

5. Environment güvenlik davranışını temsil ediyor mu?

Pre-production ile production arasında şu farklar sonucu değiştirebilir:

• Farklı reverse proxy veya WAF policy
• Farklı IAM ve federation configuration
• Mock third-party integration
• Daha sade network segmentation
• Farklı secret veya key management
• Debug mode
• Tek tenant'lı test data
• Düşük node sayısı nedeniyle oluşmayan race condition
• Farklı cache ve queue altyapısı
• Production'a özgü CDN veya API gateway

Retest ortamı birebir aynı olmak zorunda değildir. Fakat finding'in exploitability'sini etkileyen control'ler aynı olmalıdır. Farklılıklar raporda limitation olarak yazılmalıdır.

6. Test account ve data hazır mı?

Authorization bulgusu için yalnızca admin account verilmesi, horizontal access control'ü doğrulamaya yetmez. Multi-tenant testte en az iki tenant, gerekli role'lar ve birbirinden ayrılmış object'ler gerekir.

Business logic finding'lerinde state hazırlığı daha ayrıntılı olabilir:

• Kullanılabilir ve kullanılmış coupon
• Pending ve paid order
• Kısmi refund almış payment
• Approval bekleyen kayıt
• Farklı ownership durumundaki document
• Aktif ve expire olmuş invitation

Retest başlamadan data reset yönteminin de bilinmesi gerekir. Tek kullanımlık state bir kez tüketildiğinde tester yeni veri üretemiyorsa varyasyonlar tamamlanamaz.

7. Original PoC yeniden üretilebilir mi?

Original request, response, account bağlamı, object kimliği ve ön koşullar korunmalıdır. PoC'nin raporda yalnızca ekran görüntüsü olarak bulunması retest'i zorlaştırır. Replay için hassas credential'ın düz metin saklanması da doğru değildir.

İyi evidence paketi şunları içerir:

• Redacted request ve response
• Authentication ve role bilgisi
• Gerekli state hazırlığı
• Affected asset ve environment
• Beklenen güvenli davranış
• İlk test tarihi ve application version
• Data değişikliği yaratan adımlar için safety notu

8. Variation ve regression kapsamı kararlaştırıldı mı?

Original PoC'nin aynısını çalıştırmak başlangıçtır. Root cause'a göre makul varyasyonlar da belirlenmelidir. Bu alan açık değilse müşteri “finding kapandı” beklerken tester yalnızca tek request'i kontrol etmiş olabilir.

Hangi durumlarda retest hemen yapılmalı?

“Hemen” hazırlıksız başlamak değil, readiness bağımlılıklarını en yüksek öncelikle tamamlamak anlamına gelir.

Internet-facing kritik açık düzeltildiğinde

Unauthenticated RCE, authentication bypass, kritik SQL injection, dışarıdan erişilebilir SSRF veya hassas veriye doğrudan erişim sağlayan broken access control gibi bulgular için test takvimindeki normal slot beklenmemelidir. Fix deploy edildikten ve minimum readiness sağlandıktan sonra retest hızla yapılmalıdır.

Özellikle exploitation'ın kolay olduğu ve asset'in internete açık olduğu durumda, retest'e kadar exposure şu geçici adımlarla azaltılabilir:

• Vulnerable özelliği kapatmak
• Erişimi upstream firewall veya gateway ile sınırlamak
• Etkilenen route'u geçici olarak devre dışı bırakmak
• Credential ve session'ları revoke etmek
• Ek detection rule ve monitoring uygulamak

Bu adımlar permanent fix değildir. Teknik status Mitigated olabilir, Closed değil.

Production release retest sonucuna bağlıysa

Bir release gate, kritik bulgunun kapanmasını şart koşuyorsa retest staging veya pre-production deployment tamamlanır tamamlanmaz planlanmalıdır. Ancak release'den bir saat önce retest istemek gerçekçi değildir. Sızma testi ne zaman yaptırılmalı? yazımızda test, remediation ve retest için release takviminde ayrı zaman bırakılması gerektiğini açıklıyoruz.

Aktif abuse veya exploitation şüphesi varsa

Burada retest tek başına yeterli süreç değildir. Önce Incident Response ile triage, containment, evidence preservation ve compromise assessment yürütülmelidir. Fix sonrasında kullanılan attack path hedefli olarak doğrulanır. Ardından benzer yollar için scope genişletilebilir.

Aktif olay devam ederken plansız retest yapmak log'ları değiştirebilir, saldırgan aktivitesiyle tester trafiğini karıştırabilir ve forensic evidence'i etkileyebilir. Hızlı olunmalı, fakat test ile incident response aynı anda koordine edilmelidir.

Kolay geri dönebilen configuration fix'lerinde

Firewall rule, CORS policy, exposed management interface, default credential veya public cloud storage permission gibi değişiklikler hızlı uygulanabilir. Ancak propagation ve policy attachment tamamlandıktan sonra doğrulanmalıdır. IaC repository'sindeki değişiklikle canlı configuration'ın aynı olduğu da kontrol edilmelidir.

Compensating control devreye alındığında

Permanent remediation uzun sürecekse risk azaltıcı control hızlıca test edilmelidir. WAF rule, egress restriction, network ACL veya feature disable işlemi original attack path'i gerçekten kesiyor mu görülür. Fakat finding state'i kullanılan terminolojiye göre Mitigated veya Temporarily Mitigated olmalıdır.

Hangi durumlarda retest beklemeli?

Beklemek bulguyu görmezden gelmek değildir. Teknik olarak doğrulanabilir sonuç için eksik bağımlılığın tamamlanmasını beklemektir. Bu sırada risk owner açık riski bilmeli ve gerekiyorsa temporary control uygulanmalıdır.

Fix yalnızca development branch'teyse

Code review tamamlanmamış, build üretilmemiş veya hedef environment'a deployment yapılmamışsa dynamic retest başlamamalıdır. Tester source code erişimine sahipse secure code review yapabilir, fakat bu canlı davranışın retest'i değildir.

Deployment kısmi kaldıysa

Canary rollout yüzde 10'dayken retest sonucu yalnızca canary instance için geçerli olabilir. Kalan yüzde 90 vulnerable ise finding bütünüyle kapatılamaz. İki seçenek vardır:

1. 1Test trafiği deterministik biçimde yeni version'a yönlendirilir ve sonuç canary verification olarak kaydedilir.
2. 2Full rollout beklenir ve environment geneli retest edilir.

İlk seçenek release güvenini artırır. İkinci kontrolün yerini tutmaz.

Database migration veya background job bitmediyse

Authorization mapping, password hash upgrade, token revocation, tenant data migration veya encryption backfill gibi fix'ler asenkron çalışabilir. Code deploy edilmiş olsa bile eski kayıtlar riskli state'te kalabilir.

Retest öncesinde şu kanıtlar istenebilir:

• Migration completion oranı
• Başarısız kayıt sayısı
• Retry queue durumu
• Eski formatta kalan kayıtlar
• Rollback planı
• Post-migration integrity check sonucu

Migration henüz bitmemişse yeni oluşturulan data güvenli, eski data vulnerable olabilir. Finding state'i instance bazında değerlendirilmelidir.

Cache ve propagation süresi dolmadıysa

CDN cache, DNS, IAM policy, secret rotation, certificate, edge configuration ve distributed config değişiklikleri anında yayılmayabilir. Tahmini propagation süresi bilinmeden test etmek false negative veya false positive yorumuna yol açar.

“24 saat bekleyelim” otomatik kural değildir. İlgili teknolojinin gözlemlenebilir tamamlanma sinyali kullanılmalıdır. Örneğin bütün edge region'lardan policy version doğrulanabiliyorsa takvim beklemek gerekmez.

Test environment finding'i yeniden kuramıyorsa

Production'da bulunan açık, test ortamında farklı configuration nedeniyle hiç üretilemiyorsa fix sonrasında alınan “çalışmıyor” sonucu closure kanıtı değildir. Önce baseline gerekir. Tester, mümkünse fix öncesi aynı ortamda original PoC'yi doğrulamalı veya production'da güvenli verification planlamalıdır.

Bir retest'in en temel karşılaştırması şudur:

Aynı güvenlik koşullarında
önce vulnerable davranış gözlendi
sonra fix uygulanınca güvenli davranış gözlendi

İlk yarı hiç gösterilemiyorsa ikinci yarının anlamı sınırlıdır.

Gerekli role, tenant veya integration erişimi yoksa

Tester'ın account'u expire olmuşsa, MFA enrollment çalışmıyorsa, test VPN'i kapalıysa veya third-party sandbox erişilemiyorsa finding Closed sayılamaz. Uygun state Cannot Verify, Blocked veya Not Retested olabilir.

Birden fazla fix tek deployment'ta toplanıyorsa

Ekip, birbirine bağlı authorization bulgularını ortak policy layer değişikliğiyle çözüyor olabilir. İlk finding deploy edilir edilmez diğerleri yarımken retest başlatmak aynı root cause'u tekrar tekrar sınatır. Risk izin veriyorsa ortak fix paketi ve test data hazır olduğunda tek planlı cycle daha verimli olabilir.

Kritik açık bu gerekçeyle bekletilmemelidir. İlişkili medium ve low finding'ler için batch retest düşünülebilir.

Sistem stabil değilse

Retest sırasında sürekli 500, timeout veya restart görülüyorsa güvenlik davranışı sağlıklı ölçülemez. Ancak bu durum “finding kapandı” anlamına gelmez. Test sonucu Blocked by instability olarak kaydedilir. Availability problemi ayrıca raporlanabilir.

Severity tek başına retest zamanını belirler mi?

Hayır. CVSS veya rapor severity'si önemli girdidir, fakat retest sırasını tek başına belirlememelidir.

Örnek olarak iki High finding düşünelim:

• Birincisi internet-facing, unauthenticated ve hassas müşteri verisine doğrudan erişim sağlıyor.
• İkincisi yalnızca izole iç ağda, özel role ve kullanıcının bilinçli etkileşimiyle exploit edilebiliyor.

Teknik severity benzer görünse bile ilk finding'in exposure süresi daha kritik olabilir. Önceliklendirme matrisi şu girdileri kullanmalıdır:

Remediation SLA ile retest SLA da ayrılmalıdır. “Critical 48 saatte kapatılır” kuralı, fix geliştirme, deployment ve bağımsız doğrulamanın tamamının aynı 48 saate sığacağı anlamına geliyorsa operasyonel olarak tanımlanmalıdır. Aksi halde status cosmetically kapanır, teknik risk açık kalır.

Finding türüne göre doğru retest zamanı

Authorization bulgusunun retest'i nasıl yapılmalı?

Bir IDOR finding'inin original PoC'si GET /invoices/84 üzerinden başka müşterinin faturasını okumak olabilir. Fix, yalnızca bu route'a middleware eklemiş olabilir. Root cause aynı service method'u kullanan PDF export ve bulk download endpoint'lerinde devam edebilir.

Reasonable variation seti şu boyutları kapsayabilir:

• read, update, delete, export ve approve action'ları
• Same-role horizontal access
• Cross-role vertical access
• Same-tenant ve cross-tenant erişim
• Direct object endpoint ve bulk endpoint
• Numeric ID, UUID, slug ve nested resource
• Web, mobile ve legacy API version'ları
• Sync response ve asynchronous job sonucu

Basitleştirilmiş bir regression testi şöyle olabilir:

import { describe, expect, it } from "vitest"

describe("invoice authorization regression", () => {
  it.each([
    ["GET", "/api/v2/invoices/{id}", 404],
    ["GET", "/api/v2/invoices/{id}/pdf", 404],
    ["PATCH", "/api/v2/invoices/{id}", 404],
    ["DELETE", "/api/v2/invoices/{id}", 404]
  ])("blocks cross-customer access for %s %s", async (method, path, expected) => {
    const customerA = await fixtures.customer()
    const customerB = await fixtures.customer()
    const invoiceB = await fixtures.invoice({ customerId: customerB.id })

    const response = await api.request({
      actor: customerA,
      method,
      path: path.replace("{id}", invoiceB.id)
    })

    expect(response.status).toBe(expected)
    expect(response.body).not.toContain(invoiceB.id)
  })
})

Uygulamanın 403 yerine 404 dönmesi tercih edilebilir, ancak asıl invariant başka müşterinin nesnesinin okunamaması veya değiştirilememesidir. Status code tek başına güvenlik kanıtı değildir. Bu risk sınıfını IDOR açığı neden hâlâ bu kadar yaygın? yazımızda daha derin ele aldık.

SSRF bulgusunun retest'i neden tek URL ile bitmez?

Original PoC, http://127.0.0.1 isteği olabilir. Fix bu string'i engelliyor, fakat aşağıdaki yollar açık kalabilir:

• Farklı IP literal gösterimleri
• IPv6
• DNS resolution sonrasında private IP
• Redirect ile public host'tan private hedefe geçiş
• Parser farkları
• Userinfo ve port edge case'leri
• Cloud metadata endpoint'leri
• Proxy veya alternate protocol davranışı

Retest, uygulamanın URL normalization ve resolution sırasını, her redirect hop'unda policy uygulanıp uygulanmadığını ve network egress'in application validation'ı destekleyip desteklemediğini değerlendirir. Düzeltme yalnızca WAF'da string block ise finding Mitigated olabilir. Root cause devam ediyorsa Closed denmemelidir. Ayrıntılı savunma modelini SSRF'yi kapatmak için yalnızca allowlist yeterli mi? rehberimizde bulabilirsiniz.

JWT ve session fix'lerinde neden biraz beklemek gerekebilir?

Signing key rotation, session invalidation ve token lifetime değişiklikleri distributed sistemlerde zaman bağımlıdır. Yeni token'ların güvenli olması, daha önce üretilmiş vulnerable token'ların geçersiz olduğu anlamına gelmez.

Retest öncesinde şu sorular cevaplanmalıdır:

• Eski signing key bütün verifier node'larından kaldırıldı mı?
• JWKS cache ne zaman yenileniyor?
• Eski access token expiration süresi doldu mu?
• Kritik riskte token denylist veya session revocation uygulandı mı?
• Refresh token family revoke edildi mi?
• Mobile ve legacy API aynı validation policy'yi kullanıyor mu?
• Clock skew toleransı nedir?

Burada bekleme, eski token'ın doğal expiration süresini beklemek zorunda olmak anlamına gelmemelidir. Kritik key compromise durumunda aktif revocation ve emergency rotation gerekir. Normal policy değişikliğinde ise tester önce eski ve yeni token davranışını açık zaman çizelgesiyle kontrol etmelidir.

Race condition retest'i neden özel hazırlanmalı?

Original finding iki veya daha fazla request'in kritik anda çakışmasına dayanıyorsa fix'i tek request ile test etmek hiçbir şey kanıtlamaz. Aynı concurrency, resource ve transaction koşulları yeniden kurulmalıdır.

Örneğin tek kullanımlık kupon için final state invariant'ı şöyledir:

concurrent successful redemptions <= 1
committed redemption rows <= 1
remaining usage never below 0
one order cannot receive duplicate economic effect

Retest ortamında tek application node, farklı database isolation veya düşük latency varsa production'daki race window kaybolabilir. Testin temsil gücü açıkça değerlendirilmelidir. Fiyat ve kupon akışındaki concurrency kontrollerini e-ticarette fiyat, kupon ve sepet manipülasyonu nasıl önlenir? yazımızda atomik SQL örnekleriyle inceliyoruz.

Network segmentation retest'i nasıl zamanlanmalı?

Firewall rule change'in ticket'ta kapanması retest başlangıcı değildir. Rule'ların bütün enforcement point'lere dağıtılması, route'ların converge olması ve doğru source-destination test noktalarının hazırlanması gerekir.

Minimum matrix:

Tek bir laptop'tan yapılan port kontrolü segmentation control'ün tamamını doğrulamaz. Farklı route, firewall cluster, cloud security group ve network policy katmanları bulunabilir. PCI DSS v4.0.1, segmentation CDE'yi scope dışı ağlardan ayırmak için kullanılıyorsa bu control'lerin operasyonel ve etkili olduğunun belirli periyotlarda ve değişikliklerden sonra test edilmesini ister.

Compensating control finding'i kapatır mı?

Her zaman değil. Compensating control exploitability'yi düşürebilir, fakat vulnerable code veya configuration devam edebilir.

Örnek:

• Uygulamada SQL injection devam ediyor, WAF payload'ı blockluyor.
• SSRF devam ediyor, outbound firewall metadata ağına erişimi engelliyor.
• IDOR devam ediyor, feature geçici olarak kapalı.
• Vulnerable admin panel devam ediyor, erişim VPN ile sınırlandı.

Bu durumda retest iki ayrı sonucu kaydetmelidir:

1. 1Original risk mevcut erişim koşullarında exploit edilebiliyor mu?
2. 2Root cause teknik olarak giderildi mi?

Önerilen state Mitigated olabilir. Closed kullanılıyorsa kurumun closure standardı root cause yerine residual risk'e dayanıyor demektir ve bu açıkça tanımlanmalıdır. Temporary control için owner, expiration, monitoring ve permanent fix tarihi bulunmalıdır.

NCSC de temporary workaround'ların izlenmesini, yeni bir zafiyet veya vendor update ortaya çıktığında bu geçici önlemlerin yeniden değerlendirilmesini önerir.

Original PoC çalışmıyorsa finding kapanır mı?

Otomatik olarak kapanmaz. Original PoC'nin başarısız olmasının birçok nedeni olabilir:

• Fix doğru uygulanmıştır.
• WAF yalnızca PoC string'ini engelliyordur.
• Test account'un yetkisi değişmiştir.
• Object silinmiştir.
• Endpoint geçici olarak kapalıdır.
• Feature flag tester için farklıdır.
• Network erişimi bozulmuştur.
• Application hata veriyordur.
• Test data artık precondition'ı sağlamıyordur.
• Rate limit denemeyi engelliyordur.

Tester önce failure'ın nedenini ayırmalıdır. Güvenli davranış, yalnızca exploit request'inin başarısız olması değil, normal yetkili flow'un çalışmaya devam ederken yetkisiz flow'un reddedilmesidir.

Bu yüzden retest üçlü kontrol içermelidir:

Positive control: Yetkili işlem hâlâ çalışıyor mu?
Negative control: Yetkisiz işlem artık engelleniyor mu?
Variation control: Yakın bypass yolları da engelleniyor mu?

Positive control yoksa bütün endpoint'in bozulması “security fix” sanılabilir.

Partial fix nasıl raporlanmalı?

Finding'in bazı instance'ları kapanmış, bazıları açık kalmışsa parent status gerçeği gizlememelidir.

Örnek:

Parent finding Partially Remediated veya Partially Closed kalmalıdır. “Critical bulgunun yüzde 75'i kapandı” ifadesi risk anlatımı için dikkatle kullanılmalıdır. Açık kalan tek endpoint hâlâ aynı business impact'i üretebiliyorsa residual severity düşmeyebilir.

Retest status modeli nasıl olmalı?

Tek bir Open/Closed alanı gerçek durumu yansıtmaz. Aşağıdaki state'ler kullanılabilir:

Risk Accepted teknik kapanış değildir. Retest sonucu ile yönetim kararının ayrı alanlarda tutulması daha doğrudur.

Basitleştirilmiş veri modeli:

CREATE TABLE finding_retests (
  id uuid PRIMARY KEY,
  finding_id uuid NOT NULL REFERENCES findings(id),
  cycle_number integer NOT NULL CHECK (cycle_number > 0),
  environment text NOT NULL,
  tested_artifact text NOT NULL,
  technical_state text NOT NULL CHECK (
    technical_state IN (
      'CLOSED',
      'OPEN',
      'PARTIALLY_REMEDIATED',
      'MITIGATED',
      'CANNOT_VERIFY',
      'REGRESSION_FOUND'
    )
  ),
  original_poc_result text NOT NULL,
  variation_result text NOT NULL,
  limitation text,
  tester_id uuid NOT NULL,
  tested_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE (finding_id, cycle_number)
)

Risk acceptance için ayrı tablo veya workflow kullanılabilir. Böylece risk owner kabul verdiğinde tester'ın teknik bulguyu kapattığı izlenimi oluşmaz.

Retest talep paketi nasıl hazırlanmalı?

İyi bir handoff, uzun toplantı ihtiyacını azaltır. Her finding için aşağıdaki veri yeterli ve güncel olmalıdır:

retest_request:
  finding_id: WEB-2026-014
  requested_at: 2026-08-03T14:00:00+03:00
  requested_by: appsec-team

  remediation:
    root_cause: "Invoice ownership was not enforced in the shared service layer"
    fix_type: code
    pull_request: "PR-1842"
    commit: "7f38c6d"
    security_design: "Ownership and tenant checks moved to InvoicePolicy"

  deployment:
    environment: preprod-eu
    build: "order-api-2026.08.03.4"
    image_digest: "sha256:REDACTED"
    rollout_complete: true
    deployed_at: 2026-08-03T12:20:00+03:00
    feature_flags:
      invoice_policy_v2: true

  affected_scope:
    routes:
      - "GET /api/v2/invoices/{id}"
      - "GET /api/v2/invoices/{id}/pdf"
      - "PATCH /api/v2/invoices/{id}"
    roles:
      - customer
      - support_readonly
    tenants:
      - tenant-a
      - tenant-b

  test_dependencies:
    accounts_ready: true
    test_data_ready: true
    vpn_ready: true
    third_party_sandbox_ready: true

  expected_security_behavior:
    unauthorized_read: "404 without object metadata"
    unauthorized_update: "404 and no state change"
    authorized_read: "200"

Gerçek dokümanda secret, password, token veya hassas müşteri verisi bulunmamalıdır. Credential güvenli kanal üzerinden ve süreli paylaşılmalıdır.

Readiness manifest otomatik doğrulanabilir mi?

Evet. Otomasyon finding'i kapatamaz, fakat eksik hazırlıkla retest kuyruğuna giriş yapılmasını engelleyebilir.

Basitleştirilmiş Python kontrolü:

from dataclasses import dataclass
from typing import Iterable


@dataclass(frozen=True)
class RetestRequest:
    finding_id: str
    environment: str
    tested_artifact: str
    root_cause: str
    rollout_complete: bool
    accounts_ready: bool
    test_data_ready: bool
    affected_instances: tuple[str, ...]


def readiness_errors(request: RetestRequest) -> list[str]:
    checks: Iterable[tuple[bool, str]] = (
        (bool(request.finding_id.strip()), "finding_id is required"),
        (bool(request.environment.strip()), "environment is required"),
        (bool(request.tested_artifact.strip()), "tested artifact is required"),
        (bool(request.root_cause.strip()), "root cause is required"),
        (request.rollout_complete, "rollout is not complete"),
        (request.accounts_ready, "test accounts are not ready"),
        (request.test_data_ready, "test data is not ready"),
        (len(request.affected_instances) > 0, "affected instances are missing"),
    )

    return [message for passed, message in checks if not passed]

Critical finding'lerde bazı dependency'ler eksik olsa bile escalation yapılabilir. Fakat otomasyon sonucu “hazır değil” ise neden ve risk açıkça görünür. Bu veri AppSec, development ve pentest ekipleri arasındaki bekleme süresini ölçmek için de kullanılabilir.

Retest cycle sayısı nasıl belirlenmeli?

Teklifte “bir retest dahildir” ifadesi sık görülür. Ancak ilk fix yetersizse ne olacağı yazılmadığında süreç ticari tartışmaya dönüşür.

Cycle modeli şu unsurları tanımlamalıdır:

• Dahil cycle sayısı
• İlk rapordan sonra kullanılabilecek retest window
• Aynı finding ve aynı root cause sınırı
• Yeni feature veya architecture değişikliğinin kapsam dışı olup olmadığı
• Customer dependency nedeniyle yarım kalan cycle'ın nasıl sayılacağı
• Retest report veya updated report teslimi
• Ek cycle'ın efor ve planlama yöntemi

Bir cycle, tester giriş yapamadan sona ermemelidir. Buna karşılık müşteri “hazır” dediği halde fix deploy edilmemişse bu blokaj kayda alınmalıdır. Adil model readiness gate'i sözleşmeye bağlar.

Retest window ne kadar olmalı?

Herkes için doğru tek süre yoktur. Pencere şu faktörlere göre belirlenir:

• Finding sayısı ve severity dağılımı
• Release cadence
• Vendor patch takvimi
• Legacy sistem bağımlılıkları
• Change approval süreci
• Test account ve environment maliyeti
• Compliance deadline
• Pentest ekibinin kapasitesi

30, 45 veya 60 günlük ticari retest window kullanılabilir. Bu süre remediation SLA değildir. Critical bir açık 45. gün bekletilmemelidir. Window, dahil retest hakkının hangi dönem içinde kullanılacağını anlatır. Riskin ne kadar süre açık kalabileceği ayrı ve risk bazlı karardır.

Sızma testi kaç gün sürer? yazımızda retest eforunun scope, finding sayısı, variation seti ve environment hazırlığıyla birlikte nasıl hesaplanması gerektiğini inceliyoruz.

Geniş fix ne zaman yeni pentest gerektirir?

Bazen finding'i kapatmak için application'ın önemli bir bölümü yeniden tasarlanır. Bu durumda yalnızca original PoC'yi doğrulamak yetersiz kalır.

Yeni veya genişletilmiş assessment şu durumlarda düşünülmelidir:

• Authentication veya authorization framework değiştiyse
• API gateway veya service mesh eklendiyse
• Monolith microservice mimarisine ayrıldıysa
• Yeni identity provider veya federation devreye girdiyse
• Payment veya approval flow yeniden yazıldıysa
• Tenant isolation modeli değiştiyse
• Büyük database migration yapıldıysa
• Yeni mobile API version'ı açıldıysa
• Cloud account, network veya region mimarisi değiştiyse
• Fix yeni public endpoint'ler oluşturduysa

Retest “bu finding kapandı mı?” sorusunu yanıtlar. Architecture değişikliği “başka hangi attack path'ler oluştu?” sorusunu doğuruyorsa yeni scope gerekir. Web application kapsamını role, route, tenant ve business flow düzeyinde kurmak için web uygulaması sızma testinde kapsam nasıl belirlenir? rehberine bakabilirsiniz.

Code review yapıldıysa dynamic retest gerekli mi?

Genellikle evet. Secure code review, fix'in tasarımını ve implementation'ını güçlü biçimde doğrulayabilir. Dynamic retest ise build, deployment, configuration, proxy, cache ve gerçek runtime davranışını ölçer.

Örneğin source code'da authorization middleware doğru eklenmiş olabilir, fakat:

• Route middleware stack dışında kalmıştır.
• Production eski image çalıştırıyordur.
• Feature flag kapalıdır.
• Alternate GraphQL resolver eski service'i çağırıyordur.
• Background worker policy'yi bypass ediyordur.

White box yaklaşım retest kalitesini artırır, dynamic verification'ın yerini otomatik olarak almaz. Kaynak kod analizi ile sızma testi nerede ayrışır? yazımız bu iki bakışın farklı kanıt ürettiğini ayrıntılı biçimde açıklar.

Production'da mı, test ortamında mı retest yapılmalı?

İdeal seçim risk, temsil gücü ve Rules of Engagement'a göre yapılır.

Pre-production retest

Avantajları:

• Test data üzerinde daha geniş variation uygulanabilir
• Destructive olmayan ama state değiştiren testler daha güvenlidir
• Debug ve deployment evidence daha erişilebilirdir
• Release öncesi gate oluşturur

Sınırlamaları:

• Production WAF, IAM, topology ve data complexity farklı olabilir
• Multi-node concurrency temsil edilmeyebilir
• Third-party integration mock olabilir

Production verification

Avantajları:

• Gerçek artifact ve configuration doğrulanır
• Rollout, edge, CDN ve gateway farkları görülür
• “Preprod'da kapandı, production'da deploy edilmedi” riski azalır

Sınırlamaları:

• Veri değişikliği ve availability riski daha yüksektir
• Test account ve data kısıtlı olabilir
• Logging, fraud ve SOC koordinasyonu gerekir

Pratikte iki aşamalı model kullanılabilir. Derin retest pre-production'da yapılır, production deployment sonrasında düşük etkili verification ile artifact ve temel güvenlik davranışı kontrol edilir. Production adımları baştan yazılı yetkilendirme ve safety sınırına bağlanmalıdır.

Incident sonrasında retest ne zaman başlamalı?

Olay sonrası retest, attacker hâlâ ortamdayken “patch çalışıyor mu?” kontrolüne indirgenmemelidir.

Önerilen sıra:

1. 1Incident doğrulanır ve sorumluluklar atanır.
2. 2Forensic evidence korunur.
3. 3Affected asset ve account'lar belirlenir.
4. 4Containment uygulanır.
5. 5Persistence ve credential etkisi araştırılır.
6. 6Root cause ve attack path çıkarılır.
7. 7Remediation ve eradication tamamlanır.
8. 8Targeted retest ile kullanılan yol doğrulanır.
9. 9Benzer sistem ve trust path'ler geniş scope ile değerlendirilir.
10. 10Recovery sonrasında monitoring ile tekrar kontrol edilir.

NCSC incident management rehberi de recovery öncesinde remediation başarısının doğrulanmasını ve saldırganın ortamdan çıkarıldığına ilişkin yüksek güven oluşmasını vurgular.

Retest için beklenmesi gereken nokta “bütün olay raporu aylar sonra bitsin” değildir. Containment, evidence preservation ve test trafiğinin ayrıştırılması için gerekli koordinasyon tamamlanmalıdır. Kritik fix güvenli ortamda hemen doğrulanabilir, fakat bu kontrol compromise assessment'ın yerine geçmez.

Retest sonucu rapora nasıl işlenmeli?

Retest çıktısı e-posta ile “kapandı” mesajı olmamalıdır. Her finding için izlenebilir ek kayıt bulunmalıdır:

• Original finding ID
• Retest tarihi
• Tester
• Test edilen environment
• Host, region, tenant ve API version
• Build, commit veya image digest
• Original PoC sonucu
• Variation seti
• Positive ve negative control sonucu
• Regression gözlemi
• Yeni evidence
• Limitation
• Technical state
• Residual risk
• Bir sonraki aksiyon

Örnek kısa kayıt:

Finding: WEB-2026-014
Cycle: 1
Environment: preprod-eu
Artifact: order-api-2026.08.03.4
Original PoC: Blocked by server-side ownership policy
Variations: Read, PDF export and update tested across two tenants
Positive control: Authorized access remains functional
Result: Partially Remediated
Open instance: POST /api/v2/invoices/export
Limitation: Mobile API v1 not provided
Next action: Fix shared export service and prepare mobile v1 access

Executive summary'de toplam Closed, Open, Partially Remediated, Mitigated ve Not Retested sayıları gösterilebilir. Ancak kritik açık kalan tek instance sayıların arasında kaybolmamalıdır.

Closure letter ve attestation neyi söylemeli?

Müşteri veya tedarikçi, retest sonrasında kısa bir closure statement isteyebilir. Bu belge “sistem güvenlidir” veya “hiç zafiyet yoktur” dememelidir.

Doğru sınır şöyle ifade edilebilir:

Closure statement'ta açık kalan, risk accepted veya doğrulanamayan finding'ler gizlenmemelidir. Tam teknik PoC paylaşılmadan da dürüst bir durum özeti verilebilir.

Retest sürecinde en sık yapılan 12 hata

1. Ticket durumunu teknik kapanış saymak

Done, geliştirme workflow'udur. Closed, bağımsız teknik doğrulama sonucu olmalıdır.

2. Commit'i deploy edilmiş sanmak

Merge edilmiş kod, çalışan artifact değildir. Test edilen build kaydedilmelidir.

3. Yalnızca original payload'ı denemek

Payload-specific filter kolayca false closure üretir. Root cause'a göre variation gerekir.

4. Positive control kullanmamak

Endpoint tamamen bozulduğunda exploit de çalışmaz. Yetkili flow'un sürdüğü doğrulanmalıdır.

5. Tek instance üzerinden bütün finding'i kapatmak

Grouped finding'ler route, host veya asset instance bazında izlenmelidir.

6. WAF block'unu code fix sanmak

Compensating control ve root cause durumu ayrı yazılmalıdır.

7. Pre-production sonucunu production'a genellemek

Security-relevant environment farkları limitation olarak açıklanmalıdır.

8. Cache ve rollout durumunu bilmemek

Aralıklı sonuçlar çoğu zaman mixed version veya stale state işaretidir.

9. Severity düştü diye bulguyu kapatmak

Residual risk azalabilir, fakat teknik issue devam edebilir. State ile severity ayrıdır.

10. Risk acceptance'ı tester kararı gibi göstermek

Tester teknik durumu raporlar. Risk owner kabul kararı verir.

11. Geniş architecture değişikliğini dar retest'e sığdırmak

Yeni attack surface oluştuysa yeni assessment gerekir.

12. Retest sonucunu rapora işlememek

Sözlü kapanış audit, müşteri due diligence ve gelecekteki regression takibi için güvenilir evidence değildir.

Kurumsal pentest retest kontrol listesi

Finding hazırlığı

• [ ] Finding ID ve severity doğrulandı
• [ ] Original evidence erişilebilir
• [ ] Affected asset ve instance listesi güncel
• [ ] Root cause yazılı
• [ ] Expected security behavior tanımlı
• [ ] Reasonable variation seti kararlaştırıldı
• [ ] Regression alanı belirlendi
• [ ] Data değişikliği ve safety etkisi değerlendirildi

Fix ve deployment

• [ ] Pull request veya change kaydı mevcut
• [ ] Security-sensitive değişiklik review edildi
• [ ] Commit, build veya image digest kaydedildi
• [ ] Hedef environment'a deployment tamamlandı
• [ ] Bütün node ve region'lar aynı güvenli artifact'i çalıştırıyor
• [ ] Feature flag durumu biliniyor
• [ ] Database migration tamamlandı
• [ ] Background worker ve scheduled job'lar güncellendi
• [ ] Cache ve policy propagation tamamlandı
• [ ] Rollback davranışı değerlendirildi

Environment ve erişim

• [ ] Test URL, IP ve network path doğrulandı
• [ ] Production farkları dokümante edildi
• [ ] WAF, gateway ve reverse proxy durumu biliniyor
• [ ] Gerekli VPN veya allowlist erişimi açık
• [ ] Test account'lar aktif
• [ ] MFA ve session akışı çalışıyor
• [ ] Gerekli role ve tenant matrisi hazır
• [ ] Test data original precondition'ları sağlıyor
• [ ] Third-party sandbox ve integration erişilebilir
• [ ] Test data reset yöntemi mevcut

Test yürütme

• [ ] Original PoC kontrollü biçimde tekrarlandı
• [ ] Positive control başarılı
• [ ] Negative control güvenli davranış gösterdi
• [ ] Variation seti tamamlandı
• [ ] Alternate API version ve client'lar değerlendirildi
• [ ] Grouped finding instance bazında test edildi
• [ ] Concurrency finding'i uygun paralellikle test edildi
• [ ] Log ve state değişiklikleri gözlemlendi
• [ ] Compensating control ile root cause ayrıldı
• [ ] Yeni regression görülürse ayrı evidence üretildi

Sonuç ve raporlama

• [ ] Test edilen artifact rapora yazıldı
• [ ] Environment ve tarih kaydedildi
• [ ] Retest cycle numarası verildi
• [ ] Original PoC ve variation sonuçları ayrıldı
• [ ] Limitation'lar açıkça belirtildi
• [ ] Technical state tutarlı taxonomy ile seçildi
• [ ] Partial fix instance bazında gösterildi
• [ ] Residual risk yazıldı
• [ ] Risk acceptance ayrı owner'a bağlandı
• [ ] Updated report veya retest report teslim edildi
• [ ] Yeni pentest gereksinimi değerlendirildi
• [ ] Closure statement scope sınırlarını içeriyor

SECNODEX pentest retest yaklaşımı

SECNODEX için retest, eski request'in tekrar gönderildiği kısa bir kontrol değildir. Önce finding'in root cause'u, affected instance'ları ve remediation yaklaşımı incelenir. Ardından test edilen artifact, environment, role ve data bağımlılıkları doğrulanır. Original PoC, positive control ve makul bypass varyasyonları birlikte çalıştırılır.

OSCP ve OSWE sertifikalarına sahip uzmanların yer aldığı ekibimiz, network ve system bulgularından web application, API, authorization ve source-assisted analiz gerektiren risklere kadar finding türüne uygun retest planı oluşturur. OSCP ve OSWE'nin bireysel uzman sertifikaları olduğunu açıkça ifade eder, kurum için yanıltıcı bir sertifikasyon iddiası üretmeyiz. Çalışmanın kalitesini scope, evidence, teknik state ve retest sonucu üzerinden gösteririz.

Kurumsal sızma testi, finding closure veya release öncesi güvenlik doğrulaması için Sızma Testi hizmetimizi inceleyebilir, mevcut raporunuzdaki bulguların retest scope'unu netleştirmek için SECNODEX ile iletişime geçebilirsiniz.

Sonuç: Retest'in doğru zamanı ticket tarihi değil, teknik readiness'tir

Retest'i erken istemek her zaman hızlı olmak değildir. Fix deploy edilmemişse, rollout yarım kaldıysa, test account hazır değilse veya environment finding'i temsil etmiyorsa sonuç güvenilir olmaz. Öte yandan kritik ve internete açık bir bulguyu “bir sonraki toplu retest cycle'ı” için haftalarca bekletmek de bilinen riski gereksiz yere açık tutar.

Doğru model finding bazlıdır. Risk ve exposure, ne kadar hızlı hareket edilmesi gerektiğini belirler. Readiness gate ise doğrulamanın ne zaman anlamlı olacağını gösterir. Original PoC, positive control, reasonable variation ve regression alanı birlikte değerlendirilir. Technical closure ile risk acceptance ayrılır. Geniş değişiklik yeni attack surface oluşturduğunda retest yeni pentest'e genişletilir.

İyi retest sonunda yalnızca “artık çalışmıyor” cümlesi bulunmaz. Hangi artifact'in, hangi environment'ta, hangi actor ve variation'larla test edildiği, neyin kapandığı, neyin açık kaldığı ve hangi limitation altında karar verildiği görülebilir.

Mevcut pentest raporunuzdaki bulgular için teknik closure standardı oluşturmak, retest readiness paketini hazırlamak veya kritik finding'leri kontrollü biçimde yeniden doğrulamak için SECNODEX ile kapsam görüşmesi planlayabilirsiniz.

Teknik kaynaklar

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• NCSC, Verify and Regularly Review Your Vulnerability Management Process
• NCSC, Technical Response Capabilities
• PCI Security Standards Council, PCI DSS v4.0.1
• OWASP Web Security Testing Guide