Test başlamadan önceekibiniz neyi hazırlamalıdır?

1 : Ön koşullar

Test başlamadan önce yazılı yetki, sahiplik kanıtı ve varlık envanteri tamamlanmalıdır. Bu üç madde tamamlanmadan teknik aşamaya geçilmemektedir.

• Yazılı yetkilendirme: kapsam, geçerlilik süresi ve iptal koşulu birlikte tanımlanır.
• Sahiplik doğrulaması: test edilen varlık üzerindeki tasarruf yetkinizi kanıtlayan belge sunulur.
• Varlık envanteri: hangi web, API ve mobil bileşenlerin kapsamda, hangilerinin hariç olduğu belirlenir.
• Kritik akış listesi: yetki sınırı, müşteri ayrımı veya iş mantığı içeren akışlar önceliklidir.

2 : Erişim sağlama

Web, API ve mobil bileşenlerinin her biri için ayrı bir erişim seti hazırlanmaktadır. Belge veya hesap eksik kaldığında test, sınırlı erişimli düzeyinden kara kutu düzeyine inmekte ve bulgu derinliği azalmaktadır.

• Web için: URL envanteri ve rol bazlı test hesapları (yönetici, normal kullanıcı, sınırlı) sağlanır.
• API için: temel URL, OpenAPI, Swagger veya Postman koleksiyonu ve test anahtarları iletilir.
• Mobil için: APK ve IPA ikili dosyaları ile ilgili API erişim bilgisi verilir.
• Mimari diyagramı veya sistem akış özeti. Tek sayfa yeterlidir.
• IP beyaz listesi gerekiyorsa test kaynak IP aralığı önceden netleştirilir.

3 : Paydaş listesi

Test penceresi boyunca üç paydaş hattı açık tutulmalıdır: teknik, ürün ve güvenlik. Her hat için birincil ve yedek irtibat kişisi yazılı olarak kayda alınmaktadır.

• Teknik irtibat: mühendislik tarafındaki karar verici (CTO veya Mühendislik Lideri).
• Ürün irtibatı: kritik akışları ve iş mantığını bilen ürün sahibi.
• Güvenlik irtibatı: bilgi güvenliği lideri veya uygulama güvenliği sorumlusu.
• Yedek irtibat: birincil kişiye ulaşılamadığında tek aramayla erişilebilecek alternatif.

4 : Çıktı tercihleri

Rapor dili, uyumluluk eşlemesi ve ek çıktı kararları kapsamla birlikte sabitlenmektedir. Geç iletilen çıktı talebi takvimi kaydırmaktadır.

• Rapor dili: Türkçe veya İngilizce. Çift dil ayrı bir maliyet kalemidir.
• Uyumluluk eşlemesi: ISO 27001, SOC 2 ve PCI DSS opsiyoneldir.
• Yönetici özeti dağıtım listesi: yönetimin görmek isteyeceği karar okuyucuları belirlenir.
• Yeniden test (retest) tercihi: kapat ve doğrula çevriminin parçası olarak planlanır.

5 : Takvim ve test penceresi

Test takvimi. Sürümün donduruluyor olup olmadığı, mesai içi veya dışı yürütüm ve paralel çalışmaların varlığı sorularıyla netleşmektedir. Hızlandırılmış teslim primli bir ek üretmektedir.

• Sürüm dondurma: test penceresinde donmuş bir sürüm tercih edilir.
• Mesai içi veya dışı tercihi: nöbet hattı ve iletişim kanalı buna göre kurulur.
• Paralel çalışma: aynı ortamda başka test veya migrasyon yoksa sonuç temizliği artar.
• Hızlandırılmış teslim: 10 iş günü altında yüzde 15, 5 iş günü altında yüzde 30 prim uygulanır.

1 : Ön koşullar

Test başlamadan önce yazılı yetki belgesi, varlık envanteri ve sahiplik doğrulaması tamamlanmaktadır. Üçüncü taraf altyapı mevcutsa ek bir yetkilendirme zinciri hazırlanmakta. Aksi halde ilgili varlık kapsam dışında kalmaktadır.

• Müşteri imzalı çalışma yetkisi (SoW) ve çalışma kuralları (RoE) eki hazırdır.
• IP, alan adı, SSID ve segment envanterinin sahipliği belgelenmiştir.
• Üçüncü taraf altyapı için ek yetkilendirme süreci açılmıştır.

2 : Erişim sağlama

Erişim sağlama listesi modüle göre farklılaşmaktadır. Dış Ağ uzaktan yürütüldüğü için IP ve alan adı listesi yeterlidir. İç Ağ sınırlı erişimli hesap modeli ile VPN veya güvenli geçiş sunucusu (jumpbox) altyapısı istemektedir. Wi-Fi modülü saha erişimi ve lokasyon listesi olmadan başlatılmamaktadır.

Dış Ağ erişim listesi

• İnternete açık IP blokları ve özel uç IP adresleri.
• Alan adı ve alt alan adı listesi (varsa hibrit kapsam için).
• VPN geçidi, ters vekil ve WAF veya CDN uç katmanı bilgisi.

İç Ağ erişim listesi

• VPN veya güvenli geçiş sunucusu (jumpbox) erişim hesabı. Gerekli yetki seviyesi tanımlıdır.
• Active Directory veya Entra ID dizin yapısı ve segment haritası.
• Kritik servis envanteri ve hesap modeli (sınırlı erişimli hesap özellikleri).

Wi-Fi erişim listesi

• Saha erişimi ve lokasyon listesi (zaman ve refakatçi bilgisiyle).
• SSID listesi ve VLAN eşleşmeleri (kurumsal ile misafir ayrımı).
• Kimlik doğrulama tipi (WPA2, WPA3, 802.1X) ve NAC yapılandırması.

3 : Paydaş listesi

Paydaş listesi dört rolden oluşmakta ve her birinin müşteri tarafında somut bir sahibi bulunmaktadır. Eskalasyon hattı bu dört kişiyi kapsamakta. Testin kapsamı veya çalışma kuralları (RoE) belgesi değişirse karar bu listeden çıkmaktadır.

• Ağ ve altyapı sahibi: kapsam, segmentler, erişim modeli.
• Kimlik sahibi: AD veya Entra dizin yapısı, hesap modeli, ayrıcalık politikası.
• Güvenlik sponsoru: çalışma kuralları, onay kapıları, raporlama tercihi.
• Yerinde irtibat (Wi-Fi modülü için): saha erişimi, refakat, lokasyon takvimi.

4 : Çıktı tercihleri

Çıktı tercihleri test başlamadan önce sabitlenmektedir. Saldırı yolu anlatısı Paket Seviyesi 2 ve üzeri için varsayılandır. Raporlama dili tek dil veya çift dil olarak seçilmekte. Kontrol eşlemesi (ISO 27001, NIST CSF, KVKK, BDDK) ekleme talebi kapsam fiyatına yansımaktadır.

• Saldırı yolu ve yatay geçiş anlatısı: Paket Seviyesi 2 ve üzeri için tercihlidir.
• Raporlama dili: tek dil veya Türkçe ile İngilizce çift dil.
• Kontrol eşlemesi tercihi: ISO 27001, NIST CSF, KVKK, BDDK referansları.

5 : Takvim ve test penceresi

Test penceresi. Mesai içi veya dışı seçimi, üretim donma takvimi ve müşteri operasyon ritmiyle birlikte sabitlenmektedir. Hızlandırılmış teslim talebi varsa fiyat çarpanı çalışma kuralları (RoE) ekinde belirtilmekte. Üretim ortamı çok hassassa pencere daraltılmaktadır.

• Mesai içi veya dışı tercihi ve gerekçesi.
• Üretim donma dönemleri ve kritik sürüm takvimi.
• Wi-Fi modülü için lokasyon ziyaret takvimi (saha refakatçisi dahil).

1 : Ön koşullar

Yetki, sahiplik ve envanter üç temel ön koşuldur. Üçü birden tamamlanmadan bir kapsam beyanı çıkarılamamaktadır.

• Sağlayıcı yetkisi ve sahiplik kanıtı: hangi sağlayıcı (AWS, Azure, GCP veya çoklu bulut) ve hangi tüzel kişilik üzerinden yetkilendirildiği belirlenir.
• Hesap, abonelik veya proje envanteri: AWS hesap kimliği, Azure abonelik kimliği veya GCP proje kimliği listesi yazılı olarak sabitlenir.
• Bölge listesi, yerleşim mimarisi (landing zone), kontrol düzlemi paylaşımı (ortak servisler hesabı) ve kritik veri tanımı önceden netleştirilir.

2 : Erişim sağlama

Erişim modeli salt okunur bir rolle başlamakta. Saldırı yolu kalitesi gerektirdiğinde kontrollü bir test rolü eklenmektedir. Yönetici destekli erişim opsiyoneldir.

• Test IAM rolü veya principal: AWS için hesaplar arası okuma rolü ve sınırlı test rolü, Azure için Reader, Security Reader ve sınırlı özel rol, GCP için Viewer ve sınırlı özel rol.
• Log okuma erişimi: AWS CloudTrail, Azure Activity Log ve Cloud Audit Logs okuma yetkisi izlenebilirlik için baştan açılır. İzleme kaybı bir eskalasyon nedenidir.
• Hiyerarşi kapsamı: AWS Organizations, Azure Management Group ve GCP folder yapısı dikkate alınır. Kapsam kök hesap altına yanlışlıkla kaymaz.
• MFA, VPN, geçiş sunucusu, PIM ve JIT kısıtları erişim modelinin parçasıdır. Teklif öncesi netleştirilir ve test penceresi bu kısıtlara göre hizalanır.

3 : Paydaş haritası

Bulut platform, IAM, güvenlik ve faturalama olmak üzere dört paydaş bulunmaktadır. Dördü de yetki belgesinin ve test penceresi teyit zincirinin parçasıdır.

• Bulut platform sahibi (SRE, DevOps veya platform mühendisliği): kapsam kararını ve mimari topolojiyi teyit eder.
• IAM ve dizin yöneticisi (AWS IAM, Microsoft Entra, GCP IAM): test rolü oluşturma, yetki ataması ve geri alma işlemini yönetir.
• Güvenlik ekibi (CISO, SecOps): çalışma kuralları, eskalasyon ve onay kapıları için karar mercii. İzleme akışını denetler.
• Faturalama irtibatı: olağandışı kaynak tüketimi sinyalinde anlık koordinasyon kurar. Test sonrası temizlik kayıtlarını alır.

4 : Çıktı tercihleri

Çıktı tercihleri. Kontrol eşlemesi ve ek kanıt formatı düzeyinde önceden seçilmekte, raporlama yükü teklife yansımaktadır.

• Kontrol eşlemesi: CIS AWS, Azure veya GCP Foundations Benchmarks, NIST CSF 2.0, NIST SP 800-53, SOC 2 veya Microsoft Cloud Security Benchmark referanslarından hangisinin haritalanacağı önceden seçilir.
• Müşteri güvenlik incelemesi (FedRAMP, SOC 2, ISO 27001, BDDK, KVKK) önceliği varsa kontrol eşleme özeti taşınabilir güven katmanına devredilir.
• Yönetici özeti, teknik bulgu raporu, yeniden üretim adımları, saldırı yüzeyi envanteri ve öncelikli kapatma listesi standart pakette gelir.
• Saldırı yolu diyagramı, yönetim kurulu seviyesi risk özeti ve atölye çalışması paket seviyesine bağlı eklentilerdir.

5 : Takvim

Takvim. Üretim trafiği yoğunluk pencereleri, sürüm takvimi ve müşteri güvenlik incelemesi tarihleri dikkate alınarak kurulmaktadır.

• Üretim trafiği yoğunluğu (kampanya pencereleri, ay sonu dönemi, sürüm trenleri) test penceresinin dışına alınır. Geri dönüş hattı önceden tanımlanır.
• Tipik süre 2 ile 4 hafta arasındadır. Kapsam, erişim kalitesi ve test penceresi süreyi belirler.
• Hızlandırılmış teslim (10 iş günü ve altı, 5 iş günü ve altı) kapsamı dar tutar. Manuel doğrulama hattı baştan kısaltılır.
• Yeniden test ve üç aylık tekrar doğrulama mantığı baştan takvime yazılır. Aynı kapsam ve aynı mimaride 45 gün içinde indirimli yeniden test alınabilir.

1 : Ön koşullar

İnsan kaynakları, hukuk ve Bilgi Güvenliği üçlü yazılı onayı tamamlanmaktadır. KVKK aydınlatma yükümlülüğü, çalışan veri minimizasyonu ve aydınlatma yaklaşımı (önceden açık aydınlatma ile kampanya bütünlüğünü koruma arasındaki denge) yazılı olarak sabitlenmektedir. Onay zinciri tamamlanmadan kampanya yürürlüğe girmemektedir.

• İK, hukuk ve Bilgi Güvenliği yazılı onayı.
• KVKK aydınlatma yükümlülüğü kontrolü.
• Çalışan veri minimizasyonu yazılı olarak sabittir.

2 : Erişim sağlama

Hedef çalışan listesi (segment ve persona dağılımıyla), bildirim kanalı (report-phish butonu, e-posta, telefon) ve doğrulanacak kontrol kümesi (e-posta ağ geçidi, MFA, müdahale platformu) tanımlanmaktadır. Erişim girdileri eksikse ölçüm baz çizgisi kurulamamaktadır.

• Hedef çalışan listesi: segment ve persona dağılımı.
• İhbar kanalı: kanal kapasitesi ve eskalasyon zinciri.
• Kontrol kümesi tanımı: ölçülecek teknik kontroller.

3 : Paydaş haritası

İnsan kaynakları, Bilgi Güvenliği, iç iletişim, fark edip bildirme ve müdahale ekibi (SOC veya yardım masası) ile üst yönetim temsilcisi paydaş listesinde yer almaktadır. Her paydaşın rolü, iletişim kanalı ve kampanya bilgilendirme zamanlaması yazılı olarak netleşmektedir.

• İK ve iç iletişim: çalışan etkisinin yönetimi.
• Fark edip bildirme ve müdahale ekibi: kanal akışı doğrulaması.
• Üst yönetim: yönetici özeti ve kapatma özeti görüşmesi.

4 : Çıktı tercihleri

Raporlama tercihi anonim toplu yapıdadır. Kişi adı, kullanıcı kimliği veya bireysel sicil bilgisi raporun dışında tutulmakta. Segment, persona ve dalga dağılımı korunmaktadır. Bireysel rapor kanonik bir tercih değildir. İstisnai durumlar ayrı bir onay kapısıyla değerlendirilmektedir.

• Kanonik: anonim toplu raporlama.
• Bireysel rapor varsayılan değildir. Ayrı onay gerekir.
• Dağılım: segment, persona ve dalga.

5 : Takvim ve dönem kontrolü

Kampanya takvimi yoğun dönemlerden kaçınmaktadır. Finansal yıl sonu dönemi, dini bayramlar, resmi tatiller, kriz iletişimi dönemi, işten çıkarma ve birleşme veya devralma süreçleri otomatik olarak kapsam dışıdır. Takvim kararı paydaş onayıyla netleşmekte. Sürpriz dönem değişikliği kampanya bütünlüğünü bozmaktadır.

• Finansal yıl sonu dönemi kapsam dışıdır.
• Dini bayramlar ve resmi tatiller kapsam dışıdır.
• Kriz, işten çıkarma ve birleşme dönemleri kapsam dışıdır.

1 : Ön koşullar

Ön koşul kontrolü, programın doğru hizmet olup olmadığını sınamaktadır. Üç soru program canlıya alınmadan önce yanıtlanmakta. "hayır" çıkan satırlar doğru hizmete yönlendirmektedir.

• Sürüm ritmi 3 ay ve üzeri sürdürülebilir mi? Aylık veya iki haftalık üretim sürümü taahhüt edilebiliyor mu?
• Hedef varlık web veya API yüzeyi olarak tanımlı mı? Mobil, iç ağ veya bulut duruşu ana ihtiyaç değil mi?
• Sürüm öncesi tek doğrulama yeterli mi? Cevap evetse Uygulama Güvenliği Sızma Testi sayfasına geçilir.

2 : Erişim sağlama

Program boyunca sürekli bir erişim modeli kurulmaktadır. Tek pencereli proje testinden farkı, test hesabının bir kez değil, her ritim için canlı doğrulanmasıdır. OpenAPI ve sürüm bildirim entegrasyonu programa bağlanmaktadır.

• Sürekli erişim hesabı: rol bazlı test hesapları program süresince aktif tutulur.
• OpenAPI veya Postman koleksiyonu canlı senkronize edilir. Her sürümde güncel tutulur.
• Sürüm bildirim entegrasyonu (CI/CD veya release notes akışı) test ekibine açılır.
• WAF, rate-limit ve operasyon kısıtları test ekibiyle paylaşılır. İstisna pencereleri ay başında tanımlanır.

3 : Paydaş haritası

Kapat ve doğrula çevrimi yalın bir iletişim hattı istemektedir. Ürün, güvenlik, operasyon ve üst yönetim sahiplerinin programa nasıl bağlandığı ay başında netleşmekte. Her bulgu belirli bir sahiple kalmaktadır.

• Ürün ekibi: iş listesi sahibi. Kapatma penceresi ve sürüm planlaması burada işler.
• Güvenlik ekibi: bulgu doğrulama, risk önceliklendirme ve kapatma sonrası yeniden test onayı sahibi.
• Operasyon ekibi: WAF, rate-limit ve test penceresi koordinasyonu.
• Üst yönetim: aylık yönetici özeti ve çeyreklik eğilim okuması. Karar destek hattı.

4 : Çıktı tercihleri

Program çıktıları yalnız teknik rapordan ibaret değildir. Yönetim panosu, eğilim grafiği ve ritim sonu rapor formatı ay başında tercih olarak kaydedilmektedir. Çift dil ihtiyacı (TR/EN) varsa eklenti olarak tanımlanmaktadır.

• Yönetim panosu: kapatma oranı, MTTR ve risk eğilimi takip görseli.
• Ritim sonu raporu: yönetici özeti, teknik iş listesi, kapatma kanıtı.
• Çift dil çıktı (TR ve EN): müşteri güvenlik incelemesi gerekiyorsa eklenti olarak tanımlanır.
• Jira veya iş takip alanı dışa aktarımı paket seviyesi ve eklentiye göre planlanır.

5 : Ritim takvimi

Aylık ritim takvimi, sürüm donduruş günleri ve kritik iş akışlarına göre konumlanmaktadır. Ay başı, ay ortası veya ay sonu seçimi sürüm temposuna ve müşteri güvenlik incelemesi takvimine göre yapılmakta. Bir kez seçildikten sonra üç ay boyunca sabit tutulmaktadır.

• Ritim seçimi: ay başı, ay ortası veya ay sonu. Sürüm donduruş gününün dışında.
• Sürüm donduruş ile uyum: kritik dönemlerde test penceresi kaydırılır.
• Ritim dışı sürüm doğrulama hakkı paket seviyesine göre ek olarak planlanır.

1 : Ön koşullar

Modüler Red Team Simülasyonu. Yazılı üst yönetim onayı, belirlenmiş bir koordinasyon ekibi kümesi ve savunma olgunluğu öz değerlendirmesi olmadan başlamamaktadır. Savunma ekibi bilgilendirilmemekte. Bu, gerçek tespit kabiliyetinin ölçülebilmesi için zorunludur. Savunma olgunluğu zayıf bir ortamda Red Team yerine sızma testi öncelikli olabilir. Karar bu masada alınmaktadır.

• Üst yönetim onayı (CISO veya CTO. Kritik senaryolarda CEO bilgisi) yazılı belge ile sabittir.
• Koordinasyon ekibi belirlenmesi: 2 ile 4 kişi. CISO, güvenlik direktörü, üst yönetim irtibatı, hukuk.
• Savunma ekibi bilgilendirme yasağı: gerçek tespit kabiliyetinin ölçümü için zorunludur.
• Savunma olgunluğu öz değerlendirmesi: SOC, EDR, SIEM kapsamı ve runbook olgunluğu kontrol edilir.

2 : Erişim ve başlangıç dayanağı

Senaryonun başlangıç dayanağı çekirdek modüle göre değişmektedir. RT-1 tehdit aktörü senaryosunda saldırgan profiline uygun gerçekçi bir başlangıç vektörü sabittir. RT-2 hedef odaklı senaryoda kara kutu, sınırlı erişimli veya yönlendirilmiş başlangıç tercih edilmekte. RT-3 varsayılan ihlal senaryosunda ise saldırganın iç ağa zaten girdiği varsayılan başlangıç noktası (örneğin ele geçirilmiş bir kullanıcı kimliği veya uç nokta) yazılı olarak tanımlanmaktadır. RT-4A için sosyal mühendislik kanalı ve hedef persona kümesi sabitlenmektedir.

• RT-1 başlangıcı: tehdit aktörüne uygun dış vektör (saldırgan tipiyle uyumlu).
• RT-2 başlangıcı: kara kutu, sınırlı erişimli veya yönlendirilmiş. Crown jewel hedefine göre seçilir.
• RT-3 başlangıcı: varsayılan ihlal noktası (kullanıcı kimliği, uç nokta, kimlik bileti) yazılıdır.
• RT-4A başlangıcı: hedef persona kümesi, kanal (e-posta, SMS, sesli, QR) ve iletişim metni onayı.

3 : Paydaş matrisi

Koordinasyon ekibi dar tutulmaktadır. Tipik kümeleme: CISO veya güvenlik direktörü (yetki sahibi), bir üst yönetim irtibatı (eskalasyon hattı), kritik altyapı sahibi (varlık doğrulayıcı) ve hukuk müşaviri (yetki ve veri sınırı). Savunma ekibi (SOC, MSSP, IR ekibi) bilgilendirilmemekte ve çalışma kapsamı dışında kalmaktadır. Üçüncü taraf hizmet sağlayıcı varsa yetkilendirme zinciri ayrı bir sözleşme şartına bağlanmaktadır.

4 : Çıktı tercihleri

Çıktı tercihleri çalışma başlamadan netleşmektedir: yönetici özeti dili (Türkçe veya İngilizce), saldırı yolu zaman çizgisi formatı, MITRE ATT&CK teknik eşleme detayı, MITRE D3FEND kontrol önerisi derinliği ve ortak doğrulama atölye opsiyonu (RT-5 paket içi hafif doğrulama veya ayrı sprint olarak). Bu tercihler kanıt paketinin yatırım masasında ne kadar hızlı karara dönüşeceğini belirlemektedir.

• Yönetici özeti dili tercihi: Türkçe veya İngilizce, çift dil opsiyonu.
• Tespit boşluğu matrisi MITRE ATT&CK teknik seviyesinde eşlenir.
• Zinciri kesen kontrol önerisi MITRE D3FEND defansif teknik kataloguyla eşlenir.
• Purple team atölye opsiyonu (paket içi hafif doğrulama veya ayrı RT-5 sprinti).

5 : Takvim ve pencere

Çalışma süresi senaryo karmaşıklığına bağlı olarak tipik 2 ile 6 hafta aralığındadır. Regüle çerçeveye (TIBER-EU, CBEST) bağlı çalışmalar daha uzun sürmektedir. Hazırlık aşamasında kurumun büyük sürüm pencereleri, yıl sonu dönemi, bayram ve resmi tatil dönemleri ile denetim takvimleri çakışma açısından kontrol edilmektedir. Etik sınır pencereleri çalışma kuralları (RoE) belgesinde sabitlenmektedir.

1 : Ön koşullar

Ön koşullar. Yazılı yetki, ajan envanterinin tamamlanması, üçüncü taraf model sağlayıcı kullanım koşullarının doğrulanması ve izole test ortamı veya sınırlı pilot tenant ortamının hazır olmasını kapsamaktadır. Eksik bir ön koşul kapsam ve takvim kayması doğurmaktadır.

• İmzalı çalışma yetki belgesi (SoW) ile ajan veya hesap sahipliğinin yazılı doğrulanması.
• Ajan iş akışı envanteri: ajan adı, iş amacı, araç sayısı, RAG kaynak ailesi, MCP sunucusu, rol profili.
• Üçüncü taraf model sağlayıcı kullanım koşulları (AUP) ön kontrolü ve uyumlu test profili.
• Sandbox veya sınırlı pilot tenant ortamı: sentetik veri, izole bağlayıcılar, test hesapları.

2 : Erişim sağlama

Test ekibinin ihtiyaç duyduğu erişim test penceresi öncesinde sağlanmaktadır. Sistem istemi, araç kataloğu, RAG vektör veritabanı içerik örneği, MCP sunucu listesi ve log okuma erişimi yazılı en az ayrıcalık ilkesiyle açılmaktadır.

• Sistem istemi ve güvenli yürütüm sınırı tanımlarına okuma erişimi.
• Araç kaydı (tool registry): araç adı, açıklama, parametreler, yetki kapsamı, izin matrisi.
• RAG vektör veritabanı ve temsili içerik örneği (anonimleştirilmiş veya sentetik).
• MCP sunucu listesi: yetkilendirme yöntemi, kapsam, token akışı, oturum yönetimi.
• Log okuma erişimi: ajan davranışı, araç çağrı kaydı, hata izi, ihlali tetikleyen olay logları.
• VPN veya IP izin listesi, MFA ve test hesabı yaşam döngüsü tanımı.

3 : Paydaş masası

Doğru paydaş masası kapsamın gerçekçi kalmasını sağlamaktadır. AI ürün lideri, ML veya platform mühendisi, güvenlik sponsoru, hukuk müşaviri ve üst yönetim teması, kapsam ve karar etkilerinin sahibi olarak masaya oturmaktadır.

• AI ürün lideri veya ajan iş akışı sahibi: kapsam onayı ve karar etkisi tarafı.
• ML veya platform mühendisi: araç, RAG, MCP ve sistem istemi tarafının teknik temsilcisi.
• Güvenlik sponsoru: RoE imzası ve kontrollü test çalışması disiplini tarafı.
• Hukuk müşaviri: model sağlayıcı kullanım koşulları, veri işleme ve eskalasyon hattı.
• Üst yönetim teması: yönetici özetinin alıcısı ve karar etkisinin yönetim tarafı.

4 : Çıktı tercihleri

Çıktı formatı keşif öncesinde netleştirildiğinde rapor okunma süresi ve karar hızı artmaktadır. Zincir paketi formatı, çerçeve eşlemeleri ve zinciri kesen kontrol önerilerinin sunum biçimi yazıya dökülmektedir.

• Zincir paketi formatı: istem, araç, veri ve yetki halkalarının görünür dizilimi.
• Çerçeve eşlemesi: OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, NIST AI RMF kategorileri.
• Zinciri kesen kontrol önerileri: sistem istemi, araç izni, RAG erişimi, MCP onayı, çıktı süzgeci.
• Çift dil raporlama (TR ve EN) ihtiyacı varsa baştan belirlenir.

5 : Takvim

Test penceresi sürüm dönemleri ve model sağlayıcı güncelleme takvimleriyle çakıştırılmamaktadır. Hazırlık fazı kapsam ve erişim doğrulamasını, test fazı yürütümü, raporlama fazı ise kabul ve yeniden test kapısını kapsamaktadır.

• Tipik süre 2 ile 4 hafta. Tipik efor 8 ile 14 PD. Manuel kapsamda esnektir.
• Model sağlayıcı güncelleme dönemleri ve sürüm pencereleri kontrol edilir.
• Üretim dokunuşu olacaksa dar pencere ve dondurma dönemleri yazılır.

1 : Ön koşullar

Model sahibinin yazılı yetkilendirmesi bir ön koşuldur. Model envanteri (üretim ve staging), versiyon listesi ve sahibi tanımlı bir biçimde hazırlanmakta. Envantersiz bir başlangıç manuel kapsam bayrağını çalıştırmaktadır.

Üçüncü taraf temel model kullanılıyorsa sağlayıcı listesi (Hugging Face, OpenAI fine-tuning, kapalı sağlayıcı) ve kullanım koşulları belgesi hazır olmalıdır. Lisans yorumu hizmet kapsamının dışındadır. Bayrak işaretleyici düzeyinde ele alınmaktadır.

2 : Erişim sağlama

Erişim halkaları kanıt moduna göre kademelenmektedir. Birincil halka model registry okuma, CI/CD pipeline okuma ve attestation log okumadır. İkincil halka eğitim veri envanteri örnek erişimi ve deployment manifest okumadır.

Erişim sağlama ekipleri ML platform tarafında baştan tanımlanmakta. Rol matrisi ve süre eşiği yazılı yetkilendirmeyle hizalanmaktadır. Air-gapped veya regüle ortamlarda yerinde bir çalışma penceresi açılmaktadır.

3 : Paydaş düzeni

Çoklu paydaş masada bulunmaktadır: ML platform (model sahibi ve MLOps), güvenlik (sponsor ve teknik temas), veri veya governance (eğitim verisi yönetimi) ve hukuk (KVKK, regülasyon, lisans). Eksik bir paydaş çalışmayı durdurmaktadır.

KVKK kapsamında özel nitelikli kişisel veri varsa veri sorumlusu temsilcisi onay zincirine eklenmektedir. Yönetim seviyesindeki sponsor, eskalasyon hattının üst halkası olarak baştan tanımlanmaktadır.

4 : Çıktı tercihleri

Beklenen kanıt çıktıları baştan listelenmektedir: CycloneDX biçiminde ML-BOM, SLSA seviye değerlendirmesi, registry imza denetim raporu, attestation boşluk analizi ve sıkılaştırma iş listesi. Format tercihi denetim ve müşteri incelemesi yüzeyine göre seçilmektedir.

Kanıt modu üç seçeneklidir: iç güvence, denetime hazır kanıt paketi veya yönetim kuruluna hazır paket. Çıktı tercihinin seçimi paket seviyesini ve kanıt eki kapsamını doğrudan belirlemektedir.

5 : Takvim

Çalışma takvimi, MLOps takviminin yeniden eğitim, fine-tune ve sürüm dalgalarıyla çakışmayacak biçimde planlanmaktadır. Tipik süre 2 ile 3 hafta. Hızlandırılmış teslim opsiyonu kanıt modu ve erişim olgunluğuna bağlıdır.

Acil iletişim kanalı, yanıt eşiği ve eskalasyon paydaşı baştan yazılmaktadır. Tatil dönemleri ve sürüm donma pencereleri takvim çakışmasında bayrak olarak işaretlenmektedir.

1 : Ön koşullar

Sızma Testi ve Red Team için Yapay Zeka iç pilotu. Yazılı iç ofansif lider taahhüdü, 1 veya 2 öncelikli kullanım senaryosu ve seçilmiş bir yapay zeka tedarikçisi olmadan başlamamaktadır. Tedarikçi seçimi yalnız teknik bir tercih değildir. Kabul edilebilir kullanım politikası, veri işleme şartları ve kurumsal sözleşme zemini birlikte değerlendirilmektedir. Olgun olmayan bir kullanım senaryosu listesiyle yola çıkmak pilot çıktısını riske atmaktadır. Bu karar bu masada alınmaktadır.

• İç ofansif lider taahhüdü (P12) yazılı belge ile sabittir. Pilot sahibi bellidir.
• Kullanım senaryosu önceliği: başlangıçta 1 veya 2 senaryo. Her biri sahibi ve kabul kriteriyle.
• AI tedarikçi seçimi: model AUP, DPA ve kurumsal sözleşme zemini doğrulanır.
• "Tam otonom saldırı ajanı kurulumu" beklentisi reddedilir. Pilot insan denetimlidir.

2 : Erişim ve değerlendirme seti veri envanteri

Eval setin verisi gerçek pilot başlamadan önce envantere çıkarılmaktadır: anonimleştirilmiş önceki rapor seti, ekran görüntüsü ve log örnekleri, anonimleştirilmiş PoC arşivi ve bulgu kalıbı kütüphanesi. Sandbox pipeline iç ekip tarafından kurulmakta. Gerçek müşteri verisi modele eğitim girdisi olarak beslenmemektedir. Gözlemlenebilirlik platformu (LangSmith, Phoenix veya eşdeğeri) loglama, denetim izi ve geri alma kriterlerini taşıyacak biçimde yapılandırılmakta. Gizlilik politikası KVKK ve AUP uyumlu olarak yazılmaktadır.

• Eval set veri envanteri: rapor, ekran görüntüsü, log ve PoC anonimleştirilmiş.
• Sandbox pipeline: izole ortam. Üretim verisine doğrudan temas yok.
• Gözlemlenebilirlik platformu: loglama, denetim izi, telemetri ve geri alma.
• Gizlilik kontrolü: müşteri verisi modele beslenmez. Opt-out yazılı olarak doğrulanır.

3 : Paydaş matrisi

İç pilot ekibi yapısı yazılı olarak sabittir: iç ofansif lider (P12) pilotun sahibi ve devir alıcısıdır. Kıdemli bir sızma testi veya Red Team uzmanı nihai bulgu kararının merciidir. Güvenlik ekibi gözlemlenebilirlik tasarımının sahibidir. Hukuk müşaviri AUP, DPA ve KVKK uyumunu denetler. Ürün veya IT sahibi izole test ortamı altyapısının erişim ve operasyon sahibidir. Pilot devir alıcısı baştan belirlenmekte. Pilot kabul edildiğinde iş akışı bu kişiye yazılı olarak devredilmektedir.

• İç ofansif lider (P12): pilot sahibi ve devir alıcısı.
• Kıdemli sızma testi veya Red Team uzmanı: nihai bulgu kararının mercii. Uzman onayı kapısı.
• Güvenlik ekibi: gözlemlenebilirlik tasarımının sahibi.
• Hukuk müşaviri: AUP, DPA, KVKK ve veri işleme uyumu.
• Ürün veya IT sahibi: izole test ortamı altyapısı erişim ve operasyonu.

4 : Çıktı tercihleri

Pilot başlamadan dört çıktı netleşmektedir. İş akışı tasarım dokümanı ve değerlendirme seti, kullanım senaryosunu ve kabul eşiklerini tanımlar. Kontrollü pilot raporu yönetici özeti ile uzman analizini içerir. Gözlemlenebilirlik panosu ise loglama, denetim izi, telemetri ve geri alma alanlarını gösterir. Bu tercihler iç ekibin pilotu kabul kapısında ne kadar hızlı değerlendireceğini belirlemektedir.

• İş akışı tasarım dokümanı: kullanım senaryosu birim ölçüsünde.
• Eval set: kabul aralıkları ve durdurma eşikleri yazılıdır.
• Pilot rapor formatı: yönetici özeti ve uzman analist katmanı (çift katmanlı teslim).
• Gözlemlenebilirlik panosu: loglama, denetim izi, telemetri ve geri alma alanları.

5 : Takvim ve pencere

Pilot süresi karmaşıklığa bağlı olarak tipik 4 ile 8 hafta aralığındadır. Devir döngüsü pilot kabulünden sonra 1 ile 2 hafta içinde tamamlanmaktadır. Hazırlık aşamasında kurumun büyük sürüm pencereleri, müşteri teslim takvimi ile denetim ve regülasyon takvimi çakışma açısından kontrol edilmektedir. Pilot, gerçek müşteri teslim akışında durdurma riski yaratacak bir takvimle çakıştırılmamaktadır.