CI/CD Kullanan Ekiplerde Pentest Hangi Aşamada Devreye Girer?

Bir SaaS ürünü günde ondan fazla kez production'a deployment yapıyor. Güvenlik ekibinin elindeki son pentest raporu dört ay önce hazırlanmış. Rapordaki version ile bugün çalışan version arasında yüzlerce commit, üç yeni API, yeni bir SSO integration'ı ve ödeme akışında yapılan önemli bir değişiklik var.

Yönetim soruyor:

Geliştirme ekibinin sorusu ise farklı:

İki taraf da haklı bir probleme işaret ediyor. Ayda bir kez bile release almayan sistemler için tasarlanmış yıllık test modeli, her gün değişen application'da hızla eskiyor. Buna karşılık her commit sonrasında manuel ve tam kapsamlı sızma testi yapmak da teknik olarak anlamlı, operasyonel olarak ölçeklenebilir veya ekonomik değildir.

Sorun pentest'in erken mi geç mi yapıldığı değil, tek bir takvim olayına indirgenmesidir.

Başka bir ifadeyle:

Her commit -> otomatik ve hızlı security feedback
Riskli değişiklik -> targeted manual testing
Test edilebilir major release -> kapsamlı pentest
Production deployment -> güvenli configuration ve exposure verification
Remediation -> retest + security regression
Takvim/threat/incident trigger'ı -> yeniden kapsamlandırılmış assessment

Bu yazıda “pipeline'a DAST ekleyin” gibi tek cümlelik bir DevSecOps önerisi vermeyeceğiz. Pentest'in hangi aşamada neyi kanıtladığını, hangi değişikliklerin manuel test tetiklemesi gerektiğini, test edilen build ile production artifact'i arasındaki ilişkinin nasıl korunacağını ve hızlı release yapan ekiplerde güvenlik gate'inin delivery'yi felç etmeden nasıl kurulacağını teknik olarak ele alacağız.

DevSecOps pentest ne değildir?

DevSecOps pentest, scanner'ın pipeline içinde çalıştırılmasına verilen yeni bir isim değildir.

Bir DAST job'ı application'a otomatik request gönderebilir. SAST source code üzerinde riskli data flow bulabilir. SCA, dependency version'larını bilinen vulnerability kayıtlarıyla eşleştirebilir. IaC scanner yanlış cloud veya Kubernetes configuration'larını gösterebilir. Bunların tamamı değerlidir; fakat manuel pentest ile aynı soruyu cevaplamaz.

Pentest, çalışan sistem üzerinde şu tür soruları araştırır:

• İki düşük seviyeli weakness birlikte gerçek bir attack path oluşturuyor mu?
• Kullanıcı kendi tenant'ından başka bir tenant'ın object'ine erişebiliyor mu?
• Frontend'in izin vermediği business transition doğrudan API üzerinden yapılabiliyor mu?
• SSO doğru çalışırken account linking flow'u başka bir identity ile ele geçirilebiliyor mu?
• Rate limit tek endpoint'te var fakat dağıtık workflow üzerinden aşılabiliyor mu?
• Cloud configuration, application behavior ve identity permission birlikte beklenmeyen privilege üretiyor mu?
• Fix yalnızca rapordaki payload'ı mı engelledi, yoksa root cause gerçekten kapandı mı?

Bu soruların çoğu application context'i, role ilişkilerini, state'i ve tester'ın adaptasyonunu gerektirir.

OWASP SAMM'in Security Testing practice yaklaşımı bu ayrımı açık kurar: automation hızlıdır ve çok sayıda application'a ölçeklenir; fakat application ve business logic bilgisine dayanan derin test çoğu zaman daha yavaş, manuel uzman çalışması gerektirir. SAMM bu nedenle manuel testin high-risk component, yakın tarihli önemli değişiklik ve upcoming major release'lere göre önceliklendirilmesini; automation'ın ise build ve deployment sürecine yerleştirilmesini önerir.

Bu yazıda kullandığımız DevSecOps pentest ifadesi, manuel sızma testini CI/CD'nin değişiklik, artifact, environment ve release kararlarıyla bağlantılı bir güvence modeli içinde çalıştırmayı ifade eder.

Pentest ile pipeline güvenlik kontrolleri arasındaki fark

Bu kontrollerin birlikte çalışması “pentest'e artık gerek yok” sonucu üretmez. Tam tersine automation düşük maliyetli ve tekrar eden hataları erkenden yakaladıkça uzman zamanı business logic, authorization, attack chaining ve yeni attack surface gibi daha zor problemlere ayrılabilir.

SAST'ın bu mimarideki yerini CI/CD'ye SAST eklerken en sık yapılan 7 hata yazımızda; otomatik analiz ile manuel incelemenin ayrımını ise Secure Code Review ile otomatik SAST taraması farkı içeriğimizde ayrıntılı biçimde ele alıyoruz.

Pentest pipeline'ın içinde mi, çevresinde mi çalışır?

İkisi de; fakat aynı anlamda değil.

Manuel pentest'in tamamı klasik bir CI job'ı gibi saniyeler içinde başlayıp bitmez. Scope hazırlığı, role ve test data oluşturulması, application state'inin yönetilmesi, business flow analizi, evidence ve güvenli operasyon gerektirir. Bununla birlikte pentest'in tetiklenmesi, hedef artifact'in belirlenmesi, test environment'ının hazırlanması, bulguların release kararına bağlanması ve retest sonucu CI/CD workflow'una entegre edilebilir.

Sağlıklı model şu şekildedir:

Change event
    |
    v
Automated security controls
    |
    v
Risk classification ----> low risk ----> normal release policy
    |
    +----> targeted risk ----> focused manual test
    |
    +----> significant change ----> release-candidate pentest
                                      |
                                      v
                              fix / exception / approve
                                      |
                                      v
                           immutable artifact promotion
                                      |
                                      v
                         production-safe verification
                                      |
                                      v
                           retest + regression record

Pipeline burada pentester'ın yerine geçmez. Doğru zamanda doğru test tipinin çalışmasını ve test edilen şeyin production'a çıkan şeyle bağının kopmamasını sağlar.

Aşama 1 — Planning ve design: Henüz pentest yok, pentest edilebilirlik hazırlanıyor

Application çalışmadan aktif pentest yapılamaz. Fakat kaliteli testin en kritik girdileri design aşamasında oluşur.

Bu aşamada şu işler yapılmalıdır:

• Application risk tier'ı belirlenir.
• Critical business flow'lar tanımlanır.
• Authentication, authorization ve tenant modeli yazılır.
• Trust boundary ve data flow çıkarılır.
• Threat modeling yapılır.
• Security requirement'lar test edilebilir acceptance criteria'ya dönüştürülür.
• Log ve audit gereksinimleri belirlenir.
• Abuse case ve misuse case'ler yazılır.
• Test environment, role ve test data ihtiyacı planlanır.
• Hangi değişikliklerin pentest trigger'ı olacağı policy'ye eklenir.

Örneğin requirement şu şekilde yazılmışsa test edilebilir değildir:

Daha kullanılabilir bir requirement şudur:

Bu tanım hem developer test'ine hem SAST/manual review'a hem de release öncesi pentest'e doğrudan test case üretir.

OWASP WSTG'nin SDLC testing framework bölümü güvenlik testini yalnızca deployment sonuna bırakmaz; requirement, design, development, deployment ve maintenance aşamalarına dağıtır. Pentest deployment aşamasında ek bir kontrol sağlar, fakat güvenli ürün kalitesi daha önceki adımlarda inşa edilir.

Design aşamasında pentester'ın katkısı ne olabilir?

Pentester henüz application'a saldırmaz; fakat şu konularda review yapabilir:

• Threat model'in gerçekçi attack path üretip üretmediği
• Authorization matrix'te eksik object/action kombinasyonları
• Admin ve support flow'larının abuse potansiyeli
• Account recovery ve invitation lifecycle
• Payment, coupon, refund ve approval state'leri
• File processing ve outbound connection trust'i
• Webhook verification ve replay modeli
• Multi-region veya multi-tenant boundary
• Test ortamının meaningful PoC üretmeye uygunluğu

Bu katkı “erken pentest” değil, offensive bakışla design assurance'dır.

Aşama 2 — Commit ve Pull Request: Tam pentest değil, hızlı feedback

Her commit'te manuel pentest yapmak doğru hedef değildir. Commit/PR aşaması kısa feedback loop ister.

Bu aşamada tipik olarak şunlar çalışır:

• Secret scanning
• Diff-aware SAST
• Dependency/SCA kontrolü
• IaC ve policy-as-code scanning
• Unit security test'leri
• Authorization test'leri
• API contract test'leri
• Linter ve secure coding rule'ları
• Containerfile ve workflow configuration kontrolleri
• Riskli dosya veya component değişikliklerinin etiketlenmesi

Pentest açısından önemli çıktı, release riskini belirleyecek change signal üretmektir.

Örneğin aşağıdaki değişikliklerden biri PR'da görülüyorsa security review veya targeted pentest hazırlığı otomatik açılabilir:

• /auth/, /oauth/, /permissions/ veya policy dosyaları değişti
• API schema'ya yeni mutation eklendi
• Tenant filter veya repository query değişti
• Payment, refund, price veya discount hesaplama kodu değişti
• File upload/processing component'i değişti
• Outbound HTTP client veya webhook eklendi
• Admin endpoint'i açıldı
• Kubernetes ingress, IAM role veya network policy değişti
• CI workflow'a yeni third-party action/plugin eklendi
• Production secret veya deployment permission modeli değişti

Bu sinyaller pentest sonucunun kendisi değildir. Hangi release'in daha derin test gerektirdiğini erken bildirir.

Aşama 3 — Build: Artifact güvenliği ve izlenebilirlik

Build aşamasında uygulama package, container image, mobile binary veya başka bir deployable artifact'e dönüşür. Pentest planı açısından burada kritik soru şudur:

En az şu kimlikler saklanmalıdır:

• Repository ve commit SHA
• Build ID
• Dependency lockfile digest
• Container image digest
• SBOM reference
• Mobile binary hash/versionCode/build number
• IaC module ve configuration revision
• Helm chart veya deployment manifest digest
• Feature flag set'i
• Runtime policy revision
• Test environment deployment ID

NIST SP 800-204D, DevSecOps CI/CD pipeline'larında software supply chain güvenliğini artifact, attestation, provenance, repository ve SBOM gibi kavramlarla ele alır. Pentest raporunun bir build'e bağlanması bu supply-chain kontrollerinin yerine geçmez; ancak güvenlik değerlendirmesinin hangi software state'i hakkında konuştuğunu kanıtlar.

“Pentest edilen version” neden çoğu kurumda belirsizdir?

Yaygın senaryo şöyledir:

1. 1Staging'e v2.8.0-rc1 deploy edilir.
2. 2Pentest başlar.
3. 3Test sürerken geliştiriciler aynı environment'a yeni commit'ler gönderir.
4. 4Critical finding düzeltilir fakat başka feature da merge edilir.
5. 5Production'a v2.8.0 çıkar.
6. 6Raporda yalnızca “staging test edildi” yazar.

Bu durumda tester'ın hangi code ve configuration kombinasyonunu test ettiği bilinmez. Bazı bulgular eski build'e, bazıları yeni build'e ait olabilir. Production artifact'in tamamı hiçbir zaman değerlendirilmemiş olabilir.

Çözüm uzun süreli code freeze olmak zorunda değildir. Şu modeller kullanılabilir:

• Pentest için immutable release candidate
• Her deployment'ta tester'a otomatik build notification
• Evidence içinde commit ve image digest
• Test sırasında değişiklik olursa delta manifest
• Critical module değiştiğinde ilgili test case'lerin yeniden çalışması
• Onaylanan artifact'in registry'den production'a promotion'ı

Pentest edilen artifact'ten yeniden build üretmek yerine doğrulanmış artifact'i promotion modeliyle ilerletmek assurance bağını güçlendirir.

Aşama 4 — Ephemeral environment: Değişikliği erken test etmek

Her PR için açılan ephemeral environment, targeted dynamic test için değerlidir. Özellikle aşağıdaki alanlarda hızlı geri bildirim sağlar:

• Yeni endpoint reachability
• Basic authentication ve authorization negative test'leri
• Input handling regression
• CORS ve security header değişiklikleri
• OpenAPI/GraphQL schema tabanlı test
• Belirli business flow'un dar varyasyonları
• Daha önceki bulgunun automated regression'ı

Fakat ephemeral environment tam pentest için her zaman yeterli değildir.

Ephemeral environment'ın sınırları

• Gerçek identity provider yerine mock kullanabilir.
• Tek tenant veya tek role içerebilir.
• Background job ve queue çalışmayabilir.
• Third-party integration stub olabilir.
• Production WAF, CDN ve API gateway bulunmayabilir.
• Network policy ve cloud IAM farklı olabilir.
• Seed data gerçek state complexity'sini temsil etmeyebilir.
• Mobile production binary bu environment'a bağlanmayabilir.
• Observability ve audit pipeline eksik olabilir.

Bu nedenle ephemeral test sonucu “application pentest tamamlandı” anlamına gelmez. Değişikliğe yakın, hızlı ve dar validation sağlar.

Aşama 5 — Integration ve staging: Targeted pentest için ilk güçlü nokta

Bir feature integration environment'da uçtan uca çalışır hale geldiğinde manuel test anlam kazanmaya başlar.

Targeted pentest şu durumlarda burada devreye alınabilir:

• Yeni authentication veya account recovery flow'u
• Role/permission değişikliği
• Tenant isolation değişikliği
• Yeni payment veya high-value business action
• File upload ve asynchronous processing
• Webhook veya third-party integration
• Yeni GraphQL, WebSocket veya gRPC surface'i
• Mobil uygulamanın yeni backend API'si
• Cloud identity veya workload permission değişikliği
• Önceki finding'in yapısal düzeltmesi

Targeted test'in scope'u “yalnızca değişen satırlar” değildir. Değişikliğin etkilediği trust boundary ve komşu flow'lar dahil edilmelidir.

Örneğin refresh token rotation değiştiyse yalnızca yeni token endpoint'i test edilmez:

• Eski refresh token reuse
• Parallel refresh race
• Device/session ayrımı
• Logout ve revocation
• Password reset sonrası session state
• Account disable sonrası token geçerliliği
• Multiple client ve mobile flow
• Audience ve scope davranışı

Kod değişikliği küçük olabilir; security boundary etkisi geniştir.

Aşama 6 — Release candidate ve pre-production: Kapsamlı pentestin ana noktası

Yeni application, major release veya significant change için en güçlü manuel pentest noktası genellikle stable ve production'a temsil gücü yüksek release candidate'ın pre-production ortamında çalıştığı andır.

Bu aşamada şu koşullar mümkün olduğunca sağlanmalıdır:

• Build sabit ve kimliği belli
• Production'a yakın configuration
• Gerçek authentication/SSO flow'u
• Temsil gücü yüksek role ve tenant matrix'i
• API, background worker ve integration'ların çalışması
• Production'a benzer gateway, WAF ve network path
• Güvenli fakat gerçekçi test data
• Log ve monitoring'in açık olması
• Rate limit ve abuse control'lerin production policy'sini temsil etmesi
• Test sonunda resetlenebilir state
• Tester için güvenli communication ve emergency contact

Neden doğrudan production öncesi?

Çünkü bu noktada application behavior, deployment configuration ve integration'lar birlikte görülebilir. Aynı zamanda kritik bulgular için production etkisi oluşmadan düzeltme imkânı vardır.

Fakat test release gününden bir gün önce başlatılırsa bu avantaj kaybolur. Bulguların triage, remediation ve retest'i için takvim bırakılmalıdır. “Go-live Cuma, pentest Pazartesi başlasın” planı güvenlik gate'i değil, rapor üretme baskısı yaratır.

Web application scope'unun domain sayısından ibaret olmadığını ve role, tenant, API, business flow, integration ile environment bilgisinin nasıl hazırlanması gerektiğini web uygulaması sızma testi kapsamı rehberimizde ayrıntılı biçimde açıklıyoruz.

Aşama 7 — Production deployment: Pentest bitti varsaymayın

Pre-production pentest başarılı olsa bile production'a özgü riskler bulunabilir:

• Farklı WAF/CDN veya API gateway policy'si
• Yanlış DNS ve TLS configuration'ı
• Public kalan management endpoint'i
• Production IAM role'ünün daha geniş olması
• Feature flag farkı
• Debug veya diagnostic endpoint
• Secret ve key management farkı
• Farklı CORS allowlist'i
• Eski pod/node'un deployment'ta kalması
• Network segmentation farkı
• Production-only third-party integration
• Mobile production binary configuration'ı

Bu nedenle deployment sonrasında production-safe verification yapılmalıdır.

Production-safe verification neleri içerebilir?

• Deployed artifact digest doğrulaması
• Host, route ve API inventory kontrolü
• Authentication ve temel authorization smoke test'i
• Security header, TLS ve CORS doğrulaması
• Public exposure ve management interface kontrolü
• Role/tenant negative test'lerinin güvenli alt kümesi
• Log ve alert üretiminin doğrulanması
• Feature flag ve runtime configuration karşılaştırması
• Fix'in bütün instance/region'lara yayıldığının kontrolü

Bu adım tam pentestin yeniden yapılması değildir. Deployment parity ve critical control'lerin gerçek ortamda beklenen state'te olduğunu doğrular.

Production üzerinde pentest yapılabilir mi?

Evet; açık yetkilendirme, doğru Rules of Engagement ve production safety modeliyle yapılabilir. Bazı riskler yalnızca production'da görünür. Ancak bütün test teknikleri production için uygun değildir.

Production testinde şu kontroller yazılı olmalıdır:

• Yetkili hedef ve hesaplar
• Yasak action'lar
• Test rate ve time window
• Stop condition
• Emergency contact
• Test data ve cleanup yöntemi
• Monitoring/deconfliction modeli
• Third-party sınırları
• Gerçek data için evidence minimization
• Critical notification süreci

Testin production'da yapılması, kontrolsüz yapılması anlamına gelmez.

WAF veya EDR tester için allowlist'e alınmalı mı?

Tek cevap yoktur; test objective'ine göre iki ayrı bakış gerekebilir.

Kontroller açıkken test

Gerçek external posture ölçülür. WAF, bot management, rate limit, EDR ve diğer prevention control'lerin saldırı zincirini nasıl etkilediği görülür.

Kontrollü bypass veya origin track

Amaç application'ın kendi root cause'larını derinlemesine değerlendirmekse, ayrı ve açıkça kayıtlı bir track'te tester source'u belirli edge control'den geçirilmeyebilir. Bu, “WAF varken açık yok” yanılgısını önler ve origin behavior'ı gösterir.

Sağlıklı rapor iki sonucu birbirine karıştırmaz:

External path sonucu: WAF payload varyasyonunu blockladı.
Origin application sonucu: Server-side query parameterization bulunmadığı için injection root cause'u devam ediyor.

Pentest boyunca bütün güvenlik kontrollerini sessizce kapatmak gerçek posture'u ölçmez. Kontrolleri hiç bypass etmemek de application riskini yalnızca edge ürünün o anki signature coverage'ine indirger. Objective ve test track'i baştan yazılmalıdır.

Aşama 8 — Maintenance: Change-triggered ve periyodik pentest birlikte çalışır

CI/CD ortamında “yılda bir” tek trigger olmamalıdır. İki model birlikte kullanılmalıdır:

1. 1Change-triggered testing: Security boundary'yi etkileyen release'lerde targeted veya full-scope test
2. 2Periodic independent testing: Değişikliklerden bağımsız olarak zaman içinde biriken drift, bilinmeyen attack path ve yeni tester perspektifi için kapsamlı test

Takvim bazlı pentest şu nedenlerle hâlâ değerlidir:

• Küçük görünen değişikliklerin birleşik etkisi
• Yeni attack technique ve test knowledge
• Configuration drift
• Scope inventory değişimi
• Önceki testte incelenmeyen flow'lar
• Bağımsız assurance ihtiyacı
• Regülasyon ve müşteri şartları

Change-trigger modeli “uzun süredir major release yok” diyerek yıllarca test yapılmamasına dönüşmemelidir. Periyodik model de “nasıl olsa yıl sonunda test var” diyerek riskli release'i bekletmemelidir.

Sızma testinin yayına çıkmadan önce, significant change sonrasında ve olay sonrası nasıl konumlandırılması gerektiğini Sızma testi ne zaman yaptırılmalı? yazımızda daha geniş lifecycle açısından inceliyoruz.

Continuous penetration testing gerçekten ne anlama gelir?

Piyasada continuous penetration testing ifadesi birbirinden oldukça farklı hizmetler için kullanılabiliyor. Bir platformun sürekli scanner çalıştırması, her gün aynı payload setini göndermesi veya dashboard'da açık ticket bulunması tek başına sürekli pentest değildir.

Kurumsal açıdan anlamlı bir continuous model en az dört ayrı loop içerir:

1. 1Continuous discovery: Yeni domain, API route, cloud endpoint, mobile backend ve exposure değişikliği inventory'ye girer.
2. 2Continuous automated validation: SAST, SCA, secret, IaC, container, DAST ve security regression belirlenmiş event'lerde çalışır.
3. 3Change-triggered expert testing: Riskli değişiklik belirli SLA içinde uzman review veya targeted pentest kuyruğuna alınır.
4. 4Periodic deep assessment: Automation ve bilinen change set'lerinden bağımsız, geniş kapsamlı manuel test yapılır.

Bu modelin “continuous” olan tarafı bir pentester'ın application'a 7/24 kesintisiz request göndermesi değildir. Asset, change, risk ve finding lifecycle'ının kesintisiz işlemesidir.

Sürekli model için minimum service contract

“Unlimited pentest” gibi sınırsız görünen ifadeler bu alanları açıklamıyorsa gerçek capacity ve depth belirsiz kalır. Aynı hafta beş yüksek riskli release olduğunda hangisinin ne kadar uzman eforu alacağı sözleşmede anlaşılmalıdır.

Continuous modelin en güçlü çıktısı sürekli yeni rapor üretmek değil, önceki finding'lerin tekrarını azaltmaktır. Aynı authorization root cause'u farklı service'lerde yeniden görülüyorsa program çok sayıda test yapıyor olabilir; fakat development standardı, reusable control veya regression katmanı öğrenmiyordur.

Significant change nasıl tanımlanmalı?

Major veya minor version etiketi güvenlik etkisini tek başına göstermez. Binlerce satırlık UI değişikliği düşük riskli olabilir; beş satırlık authorization değişikliği tenant isolation'ı bozabilir.

Bir değişiklik şu sorulardan birine “evet” cevabı veriyorsa pentest trigger'ı olarak değerlendirilmelidir:

• Yeni internet-facing entry point oluşturuyor mu?
• Authentication, authorization veya session modelini değiştiriyor mu?
• Tenant veya organization boundary'sini etkiliyor mu?
• Hassas verinin toplandığı, işlendiği, saklandığı veya aktarıldığı yolu değiştiriyor mu?
• Para, fiyat, kupon, refund, limit veya approval kararını etkiliyor mu?
• Yeni file, template, document veya media processing getiriyor mu?
• Outbound request, webhook veya third-party trust ekliyor mu?
• Yeni admin/support capability açıyor mu?
• Cloud IAM, network segmentation veya secret modelini değiştiriyor mu?
• CI/CD runner, deployment identity veya artifact promotion modelini değiştiriyor mu?
• Önceki pentest'in geçerli kabul ettiği bir control'ü kaldırıyor veya değiştiriyor mu?
• Compromise halinde blast radius'u büyütüyor mu?

PCI Security Standards Council'ın resmi significant change FAQ açıklaması da bağlama göre değerlendirme yapılması gerektiğini; CDE'ye eklenen yeni hardware/software/network, major upgrade, account data flow veya storage değişikliği, kapsam boundary'si, supporting infrastructure ve third-party service değişikliklerini en azından değerlendirilmesi gereken örnekler arasında sayar. Bu tanım yalnızca PCI kapsamına mekanik biçimde kopyalanmamalı; kurumun kendi application ve risk modeli için genişletilmelidir.

Risk-trigger modeli: Hangi değişiklik hangi test türünü çağırmalı?

Bu tablo örnek başlangıçtır. Uygulamanın risk tier'ı, data sensitivity'si, exposure'ı ve threat model'i aynı değişiklik için kararı değiştirebilir.

Policy-as-code ile pentest trigger örneği

Pentest kararı yalnızca Jira label'ına veya bir kişinin hafızasına bağlı kalmamalıdır. Release manifest içindeki risk sinyalleri basit bir policy engine tarafından değerlendirilebilir.

Örnek release-risk.json:

{
  "release_id": "billing-api-2026.08.14",
  "commit": "4f3c81d9",
  "image_digest": "sha256:8f9a0f4d4f1f2b3c",
  "internet_facing": true,
  "new_entry_point": false,
  "changes": {
    "authentication": false,
    "authorization": true,
    "tenant_boundary": true,
    "payment_or_value_flow": true,
    "sensitive_data_flow": false,
    "file_processing": false,
    "cloud_trust": false,
    "pipeline_identity": false
  },
  "release": {
    "new_product": false,
    "major_release": false,
    "last_full_pentest_days": 96
  }
}

Örnek karar script'i:

#!/usr/bin/env python3
import json
import sys
from pathlib import Path

WEIGHTS = {
    "authentication": 4,
    "authorization": 5,
    "tenant_boundary": 5,
    "payment_or_value_flow": 5,
    "sensitive_data_flow": 4,
    "file_processing": 3,
    "cloud_trust": 4,
    "pipeline_identity": 4,
}

HARD_TRIGGERS = {
    "authorization",
    "tenant_boundary",
    "payment_or_value_flow",
}


def decide(manifest: dict) -> dict:
    changes = manifest.get("changes", {})
    release = manifest.get("release", {})

    score = sum(
        weight for name, weight in WEIGHTS.items()
        if bool(changes.get(name))
    )

    active_hard_triggers = sorted(
        name for name in HARD_TRIGGERS if bool(changes.get(name))
    )

    if manifest.get("new_entry_point"):
        score += 4
    if manifest.get("internet_facing"):
        score += 2

    if release.get("new_product") or release.get("major_release"):
        decision = "full_pentest"
    elif len(active_hard_triggers) >= 2 or score >= 12:
        decision = "targeted_pentest_and_security_review"
    elif score >= 6:
        decision = "focused_security_review"
    else:
        decision = "automated_gates_and_regression"

    if int(release.get("last_full_pentest_days", 0)) >= 365:
        decision = "full_pentest"

    return {
        "release_id": manifest.get("release_id"),
        "score": score,
        "hard_triggers": active_hard_triggers,
        "decision": decision,
    }


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: pentest_gate.py release-risk.json")

    data = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
    result = decide(data)
    print(json.dumps(result, ensure_ascii=False, indent=2))

Bu örneğin çıktısı:

{
  "release_id": "billing-api-2026.08.14",
  "score": 17,
  "hard_triggers": [
    "authorization",
    "payment_or_value_flow",
    "tenant_boundary"
  ],
  "decision": "targeted_pentest_and_security_review"
}

Bu formül standart veya evrensel risk modeli değildir. Ama üç önemli ilkeyi gösterir:

1. 1Karar code satırı sayısından değil security boundary etkisinden türetilir.
2. 2Bazı değişiklikler toplam skordan bağımsız hard trigger olabilir.
3. 3Takvim bazlı tam kapsamlı test, change-trigger modeline eklenebilir.

Gerçek uygulamada risk tier, data classification, exposure, active threat, previous finding ve regulatory requirement gibi alanlar eklenmeli; kararın owner'ı ve exception akışı tanımlanmalıdır.

Full pentest, targeted pentest, retest ve regression aynı şey değildir

Bir targeted pentest, tam kapsamlı testin yerine sonsuza kadar kullanılamaz. Yalnızca değişikliğin bilinen risk bölgesine odaklanır. Benzer şekilde retest, application'ın yeni vulnerability taşımadığına dair genel assurance üretmez.

Retest'in hangi readiness koşullarında başlaması ve finding'in hangi evidence ile kapanması gerektiğini Retest ne zaman yapılmalı, ne zaman beklemeli? yazımızda teknik örneklerle açıklıyoruz.

Release gate nasıl tasarlanmalı?

Security gate'in iki kötü uç noktası vardır:

• Her finding'de build'i kırıp ekipleri süresiz exception'a zorlamak
• Bütün security job'larını allow_failure benzeri non-blocking ayarla çalıştırmak

Doğru gate finding'in yalnızca severity'sine bakmaz. Şu context'leri değerlendirir:

• Finding yeni mi, baseline'dan mı geliyor?
• Detection confidence nedir?
• Değişen code veya component ile ilişkili mi?
• Production'da reachable mı?
• Internet-facing veya privileged path üzerinde mi?
• Business impact nedir?
• Exploitability manuel olarak doğrulandı mı?
• Compensating control var mı?
• Exception owner ve expiry mevcut mu?
• Fix edilen artifact yeniden test edildi mi?

Örnek release kararları

Gate bypass edilebilir olmalıdır demek kontrolün isteğe bağlı olması değildir. Emergency release gibi istisnalar için açık, süreli ve denetlenebilir risk acceptance yolu olmalıdır.

Hotfix pentest beklemeli mi?

Aktif exploitation veya ciddi production arızası için yapılan hotfix'i günlerce tam pentest kuyruğunda bekletmek daha büyük risk yaratabilir. Fakat “acil” etiketi güvenlik kontrolünü tamamen kaldırmamalıdır.

Hotfix modeli şu şekilde kurulabilir:

1. 1Değişiklik ve root cause hızlıca review edilir.
2. 2İlgili automated gate'ler zorunlu çalışır.
3. 3Original exploit veya failure güvenli testte yeniden üretilir.
4. 4Fix, focused security review'dan geçer.
5. 5Production deployment sonrası verification yapılır.
6. 6Normal takvimde tamamlanamayan targeted test için süreli follow-up açılır.
7. 7Security regression test'i repository'ye eklenir.

Burada amaç hız ile güvenlik arasında seçim yapmak değil, test derinliğini risk ve zaman kısıtı altında sıralamaktır.

Staging production'a benzemiyorsa pentest neyi kanıtlar?

Staging'in production ile birebir aynı olması her zaman mümkün değildir. Ancak finding'in oluşmasını etkileyen security-relevant farklar bilinmelidir.

Parity manifest örneği

Rapor şu iki cümleden birini söylemelidir:

veya:

Environment limitation'ı saklamak test kalitesini artırmaz. Açık yazmak, yanlış güvence verilmesini önler.

Microservice mimarisinde her service ayrı pentest mi gerektirir?

Her repository'yi ayrı bir “uygulama” saymak çoğu zaman yanlış scope üretir. Microservice mimarisinde pentest boundary'si repository sayısından değil business capability ve trust ilişkilerinden çıkarılmalıdır.

NIST SP 800-204C, cloud-native application ortamında application code, application services code, infrastructure as code, policy as code ve observability as code gibi farklı code türlerini ayırır. Bunların ayrı pipeline'ları olabilir; fakat runtime'da tek attack path üzerinde birleşirler.

Örneğin order service, pricing service ve coupon service ayrı repository'lerde olabilir. Saldırgan açısından soru şudur:

• İstemci price değerini etkileyebiliyor mu?
• Order service pricing sonucuna hangi identity ile güveniyor?
• Coupon state atomik mi tüketiliyor?
• Service-to-service authorization var mı?
• Message yeniden oynatılırsa çift indirim oluşuyor mu?
• Internal endpoint gateway dışında erişilebilir mi?

Bu nedenle targeted test değişen service'ten başlasa bile upstream/downstream trust boundary'lerini kapsamalıdır. Tam kapsamlı test ise customer journey veya critical business capability üzerinden birden fazla service'i zincir halinde değerlendirmelidir.

API ve mobil release'lerde pentest nasıl konumlanır?

Mobile application ile backend API aynı release takvimine sahip olmayabilir. API haftada birkaç kez, mobile binary ise store approval nedeniyle daha seyrek çıkabilir.

Sağlıklı model:

• API değişiklikleri kendi risk trigger'larıyla test edilir.
• Mobile binary'nin storage, deep link, WebView, exported component, tampering ve production configuration alanları ayrıca değerlendirilir.
• Ortak authentication/session flow uçtan uca test edilir.
• Eski mobile version'ların çağırdığı API version'ları inventory'de tutulur.
• Production binary hash ve backend release ID raporda belirtilir.
• Store release sonrasında production endpoint/configuration verification yapılır.

API pentest'i mobil binary'nin device-side risklerini, mobil pentest de backend authorization'ın bütün object ve action kombinasyonlarını tek başına kapsamaz. Ayrımı API ve mobil uygulama için ayrı sızma testi gerekir mi? rehberimizde ayrıntılı olarak ele alıyoruz.

CI/CD pipeline'ın kendisi ayrıca test edilmeli mi?

Evet. Application pentest ile pipeline security assessment aynı çalışma değildir.

CI/CD compromise, güvenli source code'u production'a kötü niyetli artifact olarak taşıyabilir. Aşağıdaki alanlar ayrıca değerlendirilmelidir:

• Repository ve branch protection
• Pull request approval bypass'ları
• CI configuration değişiklik yetkisi
• Untrusted fork/PR code'un privileged runner'da çalışması
• Runner isolation ve persistence
• Cache ve artifact poisoning
• Deployment credential scope'u
• Long-lived secret yerine workload/OIDC identity kullanımı
• Third-party action/plugin pinning ve trust'i
• Package registry permission'ları
• Artifact signing, attestation ve provenance
• Environment approval ve separation of duties
• Production deployment rollback ve audit trail
• Secret masking ile gerçek secret exposure arasındaki fark

Örnek risk:

Pull request açabilen dış contributor
    -> self-hosted runner üzerinde code execution
    -> runner'da kalan deployment token'ına erişim
    -> artifact registry'ye package push
    -> production deployment

Web application pentest bu zinciri doğal olarak görmeyebilir; çünkü target application runtime'ıdır. Pipeline assessment repository, runner, artifact, identity ve deployment plane'i ayrı scope'a alır.

Pentest için test account ve data nasıl hazırlanmalı?

Kötü hazırlanan account matrix, manuel testin en değerli alanlarını görünmez kılar.

Minimum ihtiyaç application'a göre değişse de şunlar düşünülebilir:

• İki farklı standard user
• Aynı tenant içinde farklı owner'lara ait object'ler
• İki ayrı tenant/organization
• Read-only, editor, approver, support ve admin role'leri
• Active, suspended, invited ve deleted account state'leri
• Kullanılmış/kullanılmamış coupon veya token
• Pending/approved/rejected business object'ler
• Düşük ve yüksek riskli data classification örnekleri
• Resetlenebilir payment veya workflow state'i
• API client credential ve mobile test build'i

Test data sentetik olabilir; önemli olan security relationship'i temsil etmesidir. Yalnızca tek admin account vermek authorization testi için “erişim var” demektir, coverage sağlamaz.

Bulgular development workflow'una nasıl dönmeli?

Pentest raporu PDF olarak mailde kaldığında DevSecOps entegrasyonu oluşmaz. Her finding şu bağlantıları taşımalıdır:

• Finding ID
• Affected application/component
• Environment
• Commit/build/image/configuration identity
• Endpoint, role, tenant ve business state
• Replayable request/response veya güvenli PoC
• Root cause
• Business impact
• Owner
• Remediation branch/PR
• Target deployment
• Retest readiness
• Closure evidence
• Regression test reference

Örnek lifecycle:

Finding WEB-2026-037
  -> owner: Identity Platform
  -> fix PR: auth-service#1842
  -> build: auth:sha256:4c9...
  -> staging deployment: dep-7714
  -> retest: partially fixed
  -> bypass fix PR: auth-service#1858
  -> build: auth:sha256:91a...
  -> retest: closed
  -> regression: SEC-AUTH-022
  -> production verification: passed

Bu izlenebilirlik olmadan “developer fixed” ile “risk production'da kapandı” arasındaki boşluk görülemez.

Finding geldiğinde release otomatik durmalı mı?

Her finding için aynı karar verilmez. Ancak şu durumlar güçlü blocking candidate'tır:

• Internet-facing unauthenticated code execution
• Authentication bypass
• Cross-tenant data veya action erişimi
• Privileged function authorization bypass
• Kritik business flow manipulation
• Production secret veya deployment credential exposure
• Pipeline üzerinden production artifact manipulation
• Hassas data'nın geniş ve doğrulanmış exposure'ı

Kararı etkileyen diğer değişkenler:

• Exploit precondition
• Reachability
• Blast radius
• Active exploitation
• Compensating control
• Fix availability
• Rollback seçeneği
• Business continuity etkisi
• Regulatory obligation

Risk acceptance güvenlik ekibinin sessizce verdiği teknik waiver olmamalıdır. Yetkili business risk owner; gerekçe, süre, compensating control ve yeniden değerlendirme tarihiyle karar vermelidir.

DevSecOps pentest programının metrikleri

“Bu yıl 12 pentest yaptık” aktivite metriğidir. Güvenlik sonucunu tek başına göstermez.

Coverage metrikleri

• High-risk application'ların güncel full-scope pentest coverage'i
• Significant change'lerin risk classification oranı
• Trigger olduğu halde test edilmeden çıkan release sayısı
• Role, tenant ve critical flow coverage'i
• Production parity limitation sayısı
• Test edilen artifact ile deployed artifact eşleşme oranı

Flow metrikleri

• Risk trigger'dan scope onayına geçen süre
• Release candidate'dan test başlangıcına geçen süre
• Critical finding triage süresi
• Fix deployment'tan retest'e geçen süre
• Exception yaş ve expiry ihlal oranı
• Finding'den regression test'e dönüşüm oranı

Kalite metrikleri

• Reopened finding oranı
• Aynı root cause'un tekrar oranı
• Production'a kaçan yüksek riskli finding sayısı
• Targeted test'in sonradan full testte yakalayamadığı/yakaladığı gap analizi
• False positive değil, doğrulanmış exploitability oranı
• Test account/data eksikliği nedeniyle oluşan limitation oranı
• Fix'in yalnızca original payload'ı engellediği partial remediation oranı

Kötü teşvik üreten metrikler

• Tester başına finding sayısı
• Ne kadar çok Critical bulunduğu
• Pipeline'daki security job sayısı
• Yalnızca scan coverage yüzdesi
• Release'i kaç kez blockladığınız

Pentester'ı daha çok bulgu yazmaya, developer'ı finding gizlemeye veya security ekibini gereksiz gate kurmaya teşvik eden metric programı bozar.

En sık yapılan 11 hata

1. Yıllık pentest raporunu bütün yıl geçerli kabul etmek

Rapor belirli scope, artifact ve tarihteki environment hakkında konuşur. Significant change sonrasında ilgili assurance yeniden değerlendirilmelidir.

2. Her commit'te tam pentest hedeflemek

Ölçeklenmez ve test derinliğini düşürür. Commit aşamasında automation; riskli change ve release aşamasında manuel test kullanılmalıdır.

3. DAST ile pentesti aynı saymak

DAST hızlı dynamic coverage sağlar; role, state, tenant ve business logic attack path'lerini tek başına garanti etmez.

4. Pentest'i go-live'dan hemen önce başlatmak

Remediation ve retest için takvim kalmaz; rapor release kararına yetişsin diye test kalitesi düşer.

5. Test edilen build'i sabitlememek

Tester değişen hedefte çalışır ve raporun hangi artifact'e ait olduğu belirsizleşir.

6. Staging ile production farkını yazmamak

Identity, WAF, IAM veya integration farkı finding'in exploitability'sini değiştirebilir.

7. Scope'u yalnızca değişen service'e kapatmak

Trust boundary ve upstream/downstream flow'lar kaçırılır.

8. Tester'a yalnızca admin account vermek

Horizontal ve vertical authorization coverage'i oluşmaz.

9. Bütün control'leri test için kapatmak

Gerçek external posture ölçülemez. Gerekirse control-on ve controlled-bypass track'leri ayrılmalıdır.

10. Finding'i kapatıp regression üretmemek

Aynı root cause sonraki release'te geri dönebilir.

11. Application pentest'in pipeline'ı da test ettiğini varsaymak

Runner, artifact, deployment identity ve supply-chain route'ları ayrıca scope edilmelidir.

30–60–90 günlük entegrasyon planı

İlk 30 gün: Envanter ve trigger

• Application'ları risk tier'a ayırın.
• Critical business flow ve owner'ları tanımlayın.
• Mevcut automated security gate'leri envanterleyin.
• Pentest trigger olacak change türlerini yazın.
• Release manifest'e commit, digest ve configuration identity ekleyin.
• Test account/role/tenant standardı oluşturun.
• Exception için owner ve expiry şartı koyun.

31–60 gün: Pilot

• Yüksek değişiklik hızına sahip bir application seçin.
• PR risk signal'larını üretin.
• Bir targeted change testini pipeline workflow'una bağlayın.
• Stable release candidate ve delta manifest modelini deneyin.
• Finding-to-PR-to-build-to-retest izlenebilirliğini kurun.
• Production-safe verification checklist'ini çalıştırın.

61–90 gün: Ölçekleme

• Policy-as-code trigger'ı application tier'larına yayın.
• Full, targeted, retest ve regression ayrımını service catalog'a ekleyin.
• Security Champion ve AppSec/Pentest owner modelini netleştirin.
• Metrikleri release ve risk dashboard'una taşıyın.
• Pipeline security assessment'i application pentest programıyla ilişkilendirin.
• Periyodik bağımsız test takvimini change-trigger modeliyle birleştirin.

Olgunluk seviyesine göre pentest modeli

Olgunluk, pipeline'da daha fazla tool bulunması değildir. Doğru riskin doğru anda, doğru derinlikte ve tekrar edilebilir kanıtla değerlendirilmesidir.

SECNODEX DevSecOps pentest yaklaşımı

SECNODEX'te hızlı release yapan bir ürün için sızma testini yalnızca takvimdeki yıllık bir çalışma olarak ele almayız. Önce application boundary, riskli change türleri, release modeli ve test edilebilir environment koşullarını netleştiririz.

OSCP ve OSWE yetkinliklerine sahip uzmanlarımızın yürüttüğü çalışmalarda ihtiyaca göre şu katmanları birleştiririz:

• Major release öncesi full-scope web ve API pentest
• Authentication, authorization, tenant ve business logic değişikliklerinde targeted pentest
• Production-safe deployment verification
• Finding bazlı retest ve reasonable variation kontrolü
• Security regression için replayable test case önerileri
• SAST bulgularında uzman triage ve gerektiğinde manuel secure code review
• Source code, IaC, API schema ve architecture context'iyle white-box derinlik
• Artifact, environment ve version bilgisiyle izlenebilir raporlama

Amaç pipeline'a bir kez daha scanner eklemek değildir. Application'ın delivery hızını korurken hangi release'in hangi güvenlik kanıtına ihtiyaç duyduğunu belirleyen, geliştirici ve güvenlik ekiplerinin birlikte işletebildiği bir test modeli oluşturmaktır.

SECNODEX Sızma Testi hizmeti kapsamında web, API, mobil ve altyapı katmanları için release ve risk odaklı kapsam tasarlanabilir. Source code değişikliklerinin daha erken aşamada değerlendirilmesi gereken projelerde Kaynak Kod Analizi hizmetimiz aynı assurance modelini SAST ve manuel secure code review ile tamamlar.

Sonuç: Pentest'i release'in son kapısı değil, risk doğrulama katmanı yapın

CI/CD kullanan ekiplerde pentest'in doğru yeri tek bir kutucuk değildir. Her aşamada aynı derinlikte test yapmak da güvenlik değildir.

Doğru model:

• Design sırasında security requirement ve threat model üretir.
• Commit ve PR aşamasında hızlı automated feedback verir.
• Build'i commit, digest ve configuration ile izlenebilir hale getirir.
• Riskli change'lerde targeted manual testing tetikler.
• Stable release candidate üzerinde kapsamlı pentest yapar.
• Production deployment sonrasında parity ve exposure'ı doğrular.
• Bulguları retest ve regression ile kalıcı biçimde kapatır.
• Takvim, threat ve incident trigger'larıyla bağımsız assessment derinliğini korur.

Pentest ne her commit'te çalıştırılacak bir scanner'dır ne de yılda bir kez alınan ve bütün release'leri kapsadığı varsayılan bir rapordur. DevSecOps içindeki gerçek rolü, automation'ın üretemediği güvenlik kanıtını en fazla risk taşıyan değişiklik ve attack path'lerde sağlamaktır.

CI/CD hızınıza, application mimarinize ve release risklerinize uygun full-scope, targeted ve retest modelini birlikte oluşturmak için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• OWASP SAMM — Security Testing
• OWASP Web Security Testing Guide — The Web Security Testing Framework
• OWASP Application Security Verification Standard 5.0.0
• NIST SP 800-218 — Secure Software Development Framework Version 1.1
• NIST SP 800-204C — Implementation of DevSecOps for a Microservices-based Application with Service Mesh
• NIST SP 800-204D — Software Supply Chain Security in DevSecOps CI/CD Pipelines
• PCI SSC FAQ 1317 — What is meant by “significant change” in PCI DSS?