Güvenli Yazılım Mühendisliği: Tehdit Modelinden Sızma Testine Uygulamalı Siber Güvenlik

Bir sistemi güvenli kılmak, son aşamada birkaç tarama aracı çalıştırmak değildir. Güvenlik; gereksiz güveni kaldırmak, sınırları görünür hâle getirmek, saldırganın ilerleyebileceği yolları daraltmak ve geriye kalan yolları ölçülebilir biçimde denetlemektir.

Ünite 1: Güvenlik Temelleri, Tehdit Modeli ve Güvenli Yaşam Döngüsü

Tehdit modellemesi başlatılırken önce korunacak varlıklar, güven sınırları ve olası giriş noktaları belirlenir. Bir saldırı yolunun uygulanabilirliği, saldırganın başlangıç yetkileri ve ihtiyaç duyduğu önkoşullar üzerinden sınanır. Bulgular yalnız sayıya göre değil, istismar edilebilirlik, etki ve mevcut korumalarla birlikte önceliklendirilir. Önlem seçildikten sonra aynı saldırı yolunun artık hangi aşamada kesildiği test edilerek tasarım varsayımı doğrulanır.

Giriş: Bayrağı kimden önce göreceğiz?

Siber güvenlik eğitimlerinde saldırı araçları kolay hatırlanır. Nmap ile port taranır, Wireshark ile paket yakalanır, Burp Suite üzerinden HTTP isteği değiştirilir, BloodHound bir Active Directory ortamındaki ilişkileri graf hâline getirir, Metasploit bir güvenlik açığının nasıl istismar edilebildiğini gösterir. Araçların somut çıktı üretmesi öğreticidir; ilk başarı duygusu da çoğu zaman buradan gelir. Fakat bir yazılımı gerçekten güvenli kılmak için araçların gerisindeki ortak soruyu görmek gerekir: saldırgan hangi varsayımımızdan yararlandı?

Uzun süre farklı saldırı ve savunma teknikleriyle çalışınca birbirinden bağımsız görünen açıkların aynı birkaç tasarım hatasına geri döndüğü fark edilir. SQL injection ile işletim sistemi komut enjeksiyonu farklı yorumlayıcılara yönelir ama ikisinde de veri ile komut arasındaki sınır kaybolmuştur. IDOR/BOLA ile hatalı dosya erişimi farklı kaynakları hedefler ama ikisinde de nesne üzerindeki yetki doğrulanmamıştır. Kerberoasting, fazla yetkili servis hesabı ve zayıf parola ilk bakışta üç ayrı konu gibi görünür; saldırı zincirinde ise aynı kimliğin hem kolay ele geçirilebilir hem de gereğinden fazla etkili olması tek bir mimari probleme dönüşür. XSS yalnız JavaScript meselesi değildir; güvenilmeyen verinin çalıştırılabilir bir bağlama taşınmasıdır. Güvensiz tersine serileştirme de benzer biçimde veriye, nesne oluşturma ve kimi zaman kod çalıştırma yeteneği kazandırır.

Güvenlik, saldırı isimlerini ezberlemek yerine ortak nedenleri izleyen bir mühendislik problemi olarak ele alınır. Amaç bir saldırı kataloğu oluşturmak değil, beyaz şapkalı hacker bakışını yazılım ve siber güvenlik mühendisliğiyle birleştirerek bir sistemi tasarımdan işletime kadar savunulabilir hâle getiren sınırları, varsayımları ve doğrulama yöntemlerini görünür kılmaktır.

CTF terminolojisiyle bir bayrağımız var. Fakat bu kez hedef saldırganın bayrağı alması değil; sistemin hangi aşamada saldırı zincirini kırdığını kanıtlamak. Bunun için hayalî fakat gerçekçi bir sistem düşünelim:

İnternet
   |
Ters Vekil / API Geçidi
   |
Web / Mobil İstemci ---- Kimlik Sağlayıcı
   |                         |
Uygulama API'si -------- Yetkilendirme
   |
Veritabanı ---- Dosya Deposu ---- Mesajlaşma / Harici Servisler
   |
İşletim Sistemi / Konteyner / Sanal Makine
   |
Kurumsal Ağ ---- Active Directory / DNS / SIEM

Bu yapının tek bir “güvenlik duvarı” yoktur. Her ok bir veri akışı, her bileşen bir varlık, her kimlik bir ayrıcalık kümesi, her protokol bir güven sınırı, her dış bağımlılık yeni bir saldırı yüzeyidir. Savunmanın seviyesi, en pahalı güvenlik ürününün gücüyle değil bu sınırların ne kadar doğru kurulduğuyla belirlenir.

Bu yaklaşım güncel çerçevelerle de uyumludur. OWASP Top 10:2025 yalnız klasik enjeksiyon ve kimlik doğrulama hatalarını değil; bozuk erişim denetimini, güvenlik yanlış yapılandırmalarını, yazılım tedarik zinciri başarısızlıklarını, güvensiz tasarımı, bütünlük problemlerini, yetersiz loglama ve alarm üretimini ve istisnai durumların hatalı ele alınmasını da en kritik web uygulaması riskleri arasında sayar. NIST Secure Software Development Framework (SSDF) güvenliği yazılım geliştirme yaşam döngüsüne eklenen bir son kontrol değil, sürecin içine yerleşen bir mühendislik pratiği olarak ele alır. NIST Cybersecurity Framework 2.0 ise yönetişimden kurtarmaya kadar daha geniş bir kurumsal çevrim kurar. Bu standartlar birer kontrol listesi olmaktan çok, uygulamadaki problemlerin düzenli bir güvenlik diline çevrilmesini sağlar.

1. Güvenlik bir özellik değil, sistem davranışıdır

Bir sistemde kilit simgesi, TLS, çok faktörlü kimlik doğrulama, güvenlik duvarı, EDR, WAF veya SIEM görmek tek başına güvenlik düzeyini anlatmaz. Her kontrol belirli bir tehdit modeline ve belirli varsayımlara cevap verir; asıl değerlendirme bu kontrollerin sistemin güven sınırlarında birlikte nasıl davrandığı üzerinden yapılmalıdır.

Güvenliği bir sistem davranışı olarak tanımlamak daha kullanışlıdır. Sistem istenen işi yaparken yetkisiz aktörün istemediğimiz sonucu üretmesini engelleyebiliyor mu? Engelleyemediği davranışı yeterince erken görebiliyor mu? Bir ihlal olduğunda hasarı sınırlayabiliyor ve güvenilir duruma dönebiliyor mu?

Klasik gizlilik, bütünlük ve erişilebilirlik üçlüsü hâlâ iyi bir başlangıçtır:

• Gizlilik, bilgiyi yalnız yetkili tarafların görebilmesini ister.
• Bütünlük, verinin ve işlemin yetkisiz biçimde değiştirilememesini ister.
• Erişilebilirlik, yetkili kullanıcının hizmete ihtiyaç duyduğu anda erişebilmesini ister.

Gerçek sistemde bunlara kimlik doğruluğu, inkâr edememe, izlenebilirlik, mahremiyet ve emniyet gibi özellikler eklenebilir. Kritik nokta, bunların soyut sözcük olarak kalmamasıdır. “Müşteri verisinin gizliliği önemlidir” gereksinimi test edilemez. “A kullanıcısı B kullanıcısının kaydını doğrudan nesne kimliği değiştirerek okuyamamalıdır” ise test edilebilir. Güvenlik gereksinimini test edilebilir hâle getirdiğimiz anda mühendislik başlamış olur.

1.1 Varlık, tehdit, güvenlik açığı ve risk

Bu kavramları birbirine karıştırmak yanlış önceliklendirmeye yol açar.

Bir varlık, korunması gereken şeydir: veri, hesap, anahtar, kaynak kodu, işlem kapasitesi, itibar, hizmet sürekliliği veya fiziksel süreç olabilir. Tehdit, bu varlığa zarar verme potansiyeli taşıyan durum veya aktördür. Güvenlik açığı, tehdidin kullanabileceği zayıflıktır. Risk ise bağlama göre olasılık ve etkinin birlikte değerlendirilmesidir.

Aynı güvenlik açığının riski iki sistemde aynı değildir. İnternetten erişilemeyen, ayrı bir ağda çalışan ve yalnız düşük yetkili deneme verisi tutan bir servis ile internete açık, kritik kimlik verisine erişen servis aynı CVSS puanına sahip bir açığı taşısa bile operasyonel riskleri farklıdır. Bu nedenle yalnız tarayıcı skoruyla güvenlik yönetmek, sistem bağlamını kaybetmektir.

1.2 Saldırı zinciri ve bileşik risk

Üretim sistemlerinde en tehlikeli olaylar çoğu zaman “kritik” etiketi taşıyan tek bir açıktan doğmaz. Birkaç orta düzey zayıflık birleşir:

Gereksiz bilgi sızıntısı
        -> kullanıcı adlarının öğrenilmesi
        -> parola püskürtme için hedef listesi
        -> düşük yetkili hesabın ele geçirilmesi
        -> yanlış dosya paylaşımı yetkisi
        -> yapılandırma dosyasından servis parolası
        -> fazla yetkili servis hesabı
        -> etki alanında yanal hareket

Her adım tek başına “sistemi ele geçirmek” anlamına gelmez. Fakat saldırgan graf üzerinde yol arar. BloodHound'un Active Directory ortamında güçlü olmasının nedeni de budur: tekil nesneleri değil ilişkileri görünür kılar. Güvenli tasarımın amacı yalnız açık sayısını azaltmak değil, saldırganın başlangıç noktasından kritik varlığa ulaşabileceği yolları kesmektir.

Bu düşünceyi uygulamanın tamamına yayacağız.

2. Önce sınırı çizmek: neyi test ediyoruz, neyi koruyoruz?

Sızma testinde ilk ciddi hata teknik değil, kapsam hatasıdır. Yetkili test ile izinsiz saldırı arasındaki çizgi yalnız niyetten ibaret değildir; kapsam, zaman, veri, yöntem ve durdurma koşulları açık olmalıdır. Bir CTF laboratuvarında her hedef test edilebilir. Üretim sisteminde aynı serbestlik yoktur.

Bir güvenlik çalışmasına başlamadan önce en az şu bilgiler belirlenmelidir:

• Varlık: Hangi sistem, veri ve hizmet korunuyor?
• Sahiplik: Teknik ve iş sahibi kim?
• Kapsam: Hangi IP, alan adı, uygulama, API, istemci ve hesap test kapsamında?
• Hariç tutulanlar: Kesintiye uğramaması gereken sistemler hangileri?
• Veri: Gerçek veri kullanılabilir mi, maskeleme gerekir mi?
• Test türü: Kod inceleme, mimari inceleme, sızma testi, kırmızı takım, yapılandırma denetimi?
• Zaman: Yük ve kesinti riski olan testler ne zaman yapılabilir?
• Kanıt: Hangi loglar, ekran görüntüleri veya örnek kayıtlar tutulacak?
• Durdurma: Veri kaybı, performans bozulması veya beklenmeyen yayılım olduğunda ne yapılacak?
• İletişim: Kritik bulgu veya kesinti durumunda kim bilgilendirilecek?

Bu çalışma yalnız hukuki güvence sağlamaz. Teknik sonucu da iyileştirir. Kapsam bilinmiyorsa varlık envanteri eksik kalır; envanter eksikse saldırı yüzeyi bilinmez; saldırı yüzeyi bilinmiyorsa risk değerlendirmesi yalnız tahmindir.

3. Varlık envanteri: bilmediğiniz sistemi koruyamazsınız

Güvenlik ekibinin göremediği sunucu saldırgan için görünmez değildir. Unutulmuş bir alt alan adı, eski test servisi, internete açık yönetim paneli, artık kullanılmayan VPN hesabı, eski mobil API sürümü veya terk edilmiş bir nesne depolama alanı sık rastlanan başlangıç noktalarıdır.

Bu nedenle güvenli kılma algoritmasının ilk teknik adımı envanterdir. CIS Controls v8.1'in ilk iki kontrolünün kurumsal ve yazılım varlıklarının envanterine ayrılması tesadüf değildir.

3.1 Envanter yalnız sunucu listesi değildir

Aşağıdakilerin her biri ayrı bir varlık sınıfıdır:

• fiziksel ve sanal sunucular,
• istemciler ve mobil cihazlar,
• ağ cihazları ve kablosuz erişim noktaları,
• alan adları, alt alan adları, DNS kayıtları ve sertifikalar,
• API'ler ve sürümleri,
• veritabanları ve veri kümeleri,
• servis hesapları, kullanıcılar, gruplar ve roller,
• kriptografik anahtarlar, sertifikalar ve diğer sırlar,
• kaynak kodu depoları,
• derleme sistemleri ve CI/CD çalışanları,
• üçüncü taraf kütüphaneler ve işletim sistemi paketleri,
• konteyner imajları,
• log kaynakları,
• yedekler,
• SaaS veya dış servis entegrasyonları,
• Active Directory nesneleri ve güven ilişkileri.

Özellikle servis hesabı ve makine kimliği envanteri çoğu projede insan kullanıcı envanterinden daha zayıftır. Oysa bir saldırgan için parolası yıllardır değişmeyen ve yüksek yetkili bir servis hesabı, güçlü MFA kullanan insan hesabından daha çekici olabilir.

3.2 Veri sınıflandırma

Her veri aynı korunma düzeyini gerektirmez. Şema tasarımından loglamaya kadar birçok karar, verinin niteliğini bilmeden doğru verilemez.

Pratik bir sınıflandırma şu sorularla başlar:

1. Bu veri ifşa olursa kim zarar görür?
2. Değiştirilirse sistem hangi yanlış kararı verir?
3. Kaybolursa geri üretilebilir mi?
4. Ne kadar süre tutulmalıdır?
5. Kimlerin gerçekten erişmesi gerekir?
6. Yedeklerde, loglarda veya hata raporlarında kopyası oluşuyor mu?

Bir parola hiçbir zaman uygulama loguna yazılmamalıdır. Bir erişim belirteci “hata ayıklama için” loglandığında belirtecin kriptografik olarak güçlü olması anlamını yitirir. Kişisel veri veritabanında şifrelenmiş olsa bile yedekte açık bulunuyorsa koruma yarımdır. Güvenlik, verinin yalnız ana depoda değil bütün yaşam döngüsünde izlenmesini gerektirir.

4. Saldırganın ilk işi: görünür yüzeyi haritalamak

Beyaz şapkalı testlerde bilgi toplama aşamasının değeri, yıllar önce kullanılan araç isimleri değişse de değişmedi. Pasif bilgi toplama ile aktif keşif arasındaki ayrım hâlâ önemlidir.

Pasif keşifte hedefe doğrudan veya belirgin trafik üretmeden açık kaynaklar, DNS bilgileri, sertifika şeffaflık kayıtları, kaynak kodu depoları, dokümantasyon, iş ilanları, geçmiş web içerikleri ve yayımlanmış meta veriler incelenebilir. Aktif keşifte hedef sistemle etkileşime girilir; portlar, servisler, protokoller, sürümler, uygulama yolları ve davranışlar ölçülür.

Bu aşamanın savunma açısından asıl değeri şudur: saldırganın görebildiği şeyi siz de görmelisiniz.

4.1 Bilgi sızıntısı küçük görünür, zincirde büyür

Bir HTTP Server başlığı, ayrıntılı hata ekranı veya kaynak haritadaki klasör yapısı tek başına sistem ihlali değildir. Ancak keşif maliyetini düşürür. Sürüm bilgisi belirli CVE'lere yöneltir. Kullanıcı adı biçimi parola püskürtme hedefi oluşturur. Çalışan teknoloji yığını doğru istismar sınıfını seçtirir. Dahili host adı Active Directory veya DNS topolojisi hakkında ipucu verir.

Bu nedenle hata mesajlarını “saldırgan hiçbir şey öğrenmesin” refleksiyle anlamsızlaştırmak yerine iki kanala ayırmak gerekir:

• kullanıcıya kararlı, sınırlı ve işlem yapılabilir hata kimliği,
• yalnız yetkili gözlemleme sisteminde ayrıntılı teknik bağlam.

OWASP Top 10:2025'te istisnai durumların hatalı ele alınmasının ayrı bir kategori hâline gelmesi de bu noktayı güçlendirir. Hata yolu, normal yol kadar tasarlanmalıdır.

4.2 Ağ keşfi bize mimarinin gerçeğini söyler

Mimari diyagram ile çalışan ağın aynı şey olduğunu varsaymak tehlikelidir. Port tarama ve servis keşfi çoğu zaman dokümantasyonda bulunmayan gerçekleri gösterir: unutulmuş yönetim portu, dışarı açılmış veritabanı dinleyicisi, eski SSH servisi, test amaçlı bırakılmış HTTP uç noktası veya yanlış VLAN'da duran cihaz.

Savunmada hedef “Nmap çalışmasın” değildir. Hedef, keşfedilen yüzeyin bilinçli ve gerekli olmasıdır. Bir servis iş gereği dışarı açık değilse kapatılır. Açık olmak zorundaysa kimlik, yetki, ağ kaynağı ve istek hızı sınırları tasarlanır. Portu gizlemek kontrol değildir; erişimi sınırlandırmak kontroldür.

5. Tehdit modelleme: kod yazmadan önce saldırı yolu aramak

Güvenlik testinin en ucuz açığı, henüz kodlanmamış açıktır. Tehdit modelleme bunun için yapılır.

Bir tasarım toplantısında veri akışını çizip “burada kim kime güveniyor?” sorusunu sormak, aylar sonra sızma testinde aynı problemin bulunmasından daha ucuzdur. Üstelik sızma testi her iş mantığı hatasını yakalayamaz. Test uzmanı sistemin bütün iş kurallarını geliştirici kadar bilmeyebilir; tehdit modelleme bu bilgiyi tasarım sırasında güvenlik açısından kullanır.

5.1 Veri akış diyagramı ve güven sınırı

Örnek bir akışı ele alalım:

[Tarayıcı]
    |
    | HTTPS
    v
[API Geçidi] ---- [Kimlik Sağlayıcı]
    |
    v
[Sipariş Servisi] ---- [Mesaj Kuyruğu] ---- [Faturalama]
    |
    v
[Veritabanı]

Her kutu süreç veya veri deposudur; oklar veri akışıdır. Fakat güvenlik açısından asıl önemli çizgiler güven sınırlarıdır. Tarayıcı bizim kontrolümüzde değildir. API geçidinden servis ağına geçiş başka bir sınırdır. Mesaj kuyruğundan gelen veri, daha önce bizim servisimiz üretmiş olsa bile değiştirilemez olduğunu varsaymamalıdır. Veritabanından okunan içerik de geçmişte saldırgan tarafından yazılmış olabilir.

“İç ağdan geliyor, güvenlidir” cümlesi birçok zayıflığın başlangıcıdır.

5.2 STRIDE bir düşünme aracı olarak

STRIDE hâlâ hızlı bir tehdit taraması için yararlıdır:

• Spoofing: Bir aktör başka bir kimlik gibi davranabilir mi?
• Tampering: Veri veya işlem yetkisiz değiştirilebilir mi?
• Repudiation: Bir işlem sonradan inkâr edilebilir mi; yeterli kanıt var mı?
• Information Disclosure: Yetkisiz bilgi açığa çıkabilir mi?
• Denial of Service: Kaynak tüketilerek hizmet durdurulabilir mi?
• Elevation of Privilege: Düşük yetki daha yüksek yetkiye çevrilebilir mi?

Bu sınıflandırmayı doldurmak sonuç değildir. Her tehdit, doğrulanabilir güvenlik gereksinimine çevrilmelidir. Örneğin “tampering olabilir” yerine “mesaj tüketicisi kaynağı doğrulanmamış veya bütünlük koruması olmayan mesajı iş emrine dönüştürmeyecek” gibi bir gereksinim üretilir.

5.3 Saldırı ağacı ve graf düşüncesi

Active Directory çalışmalarında BloodHound'un öğrettiği en kalıcı derslerden biri graf düşüncesidir. Aynı düşünceyi uygulama mimarisine taşıyabiliriz.

Hedef: kritik raporu değiştirmek.

Muhtemel yollar:

Kritik raporu değiştir
├── Yönetici hesabını ele geçir
│   ├── oltalama
│   ├── zayıf parola
│   └── oturum belirtecinin sızdırılması
├── Yetki kontrolünü atla
│   ├── nesne düzeyi yetki eksikliği
│   └── rol kontrolündeki mantık hatası
├── Veritabanına doğrudan eriş
│   ├── SQL injection
│   ├── servis hesabı sırrı
│   └── ağ segmentasyonu hatası
└── Dağıtım zincirini ele geçir
    ├── CI/CD kimliği
    ├── bağımlılık zehirleme
    └── imzasız artefakt

Savunma stratejisi burada daha açıktır. Aynı hedefe giden dört yol varsa yalnız birini kapatmak yeterli değildir. Aynı kontrol birden fazla yolu kesiyorsa değeri yüksektir. Örneğin güçlü kimlik doğrulama kullanıcı hesabı yolunu daraltırken, en az ayrıcalıklı veritabanı hesabı hem SQL injection'ın etkisini hem sızmış servis sırrının etkisini azaltır.

6. Risk önceliklendirme: en çok bulguyu değil en tehlikeli yolu kapatmak

Güvenlik taramalarında yüzlerce bulgu üretmek kolaydır. Zor olan hangisinin önce düzeltilmesi gerektiğidir.

Pratikte şu bileşenleri birlikte düşünmek daha sağlıklıdır:

Risk ≈ istismar edilebilirlik × etki × maruziyet × saldırı zincirindeki kaldıraç

Bu matematiksel bir standart formül değildir; düşünme modelidir. İnternete açık, kimlik gerektirmeyen ve kolay istismar edilen orta etkili bir açık, yalnız ayrı yönetim ağından erişilen yüksek etkili bir açıktan önce ele alınabilir. Tersine, düşük yetkili hesaptan Domain Admin'e giden tek kenarı oluşturan yanlış grup üyeliği, sıradan bir yapılandırma bulgusundan çok daha önemlidir.

CVSS, CWE, OWASP, MITRE ATT&CK ve kurumun kendi risk matrisi birbirinin yerine geçmez. CVSS teknik şiddeti standartlaştırır; CWE hata sınıfını anlatır; ATT&CK saldırgan davranışını taktik ve tekniklerle ilişkilendirir; OWASP uygulama risklerini kümeler; iş etkisini ise sistemi işleten kurum bilir.

7. Güvenli mimari: saldırıyı kod seviyesine gelmeden zorlaştırmak

İyi mimarinin güvenlik avantajı, geliştiricinin her satırda kusursuz olmasını beklememesidir. İnsan hata yapar. Güvenli mimari, tek hatanın bütün sistemi ele geçirmesini zorlaştırır.

7.1 En az ayrıcalık

Bir servis yalnız üç tabloyu okuyup bir tabloya yazıyorsa bütün şemada DDL yetkisi istemez. Bir arka plan işi yalnız bir nesne deposuna yazıyorsa tüm depolara erişmemelidir. Bir konteyner root yetkisi gerektirmiyorsa root çalışmamalıdır. Bir kullanıcı rapor okuyorsa yönetim uç noktasına erişmemelidir.

En az ayrıcalık, “yetkiyi kısalım” yaklaşımı değil, işlev için gerekli en küçük yetki kümesini tanımlama işidir.

Bu ilkeye uyulmadığında küçük bir açık büyük bir ihlale dönüşür. SQL injection yalnız belirli kayıtları okuyabilecekken veritabanı hesabının aşırı yetkisi yüzünden dosya sistemi veya yönetim işlemlerine uzanabilir. Uygulama sunucusundaki bir RCE, süreç root çalışıyorsa işletim sistemini doğrudan etkiler. Domain servis hesabının gereksiz yönetici üyeliği, parola ele geçirilince yanal hareketi kolaylaştırır.

7.2 Yetkileri ayırmak

Tek hesapla geliştirme, dağıtım, veritabanı yönetimi ve üretim işletimi yapmak operasyonel olarak hızlı görünür. Güvenlik açısından ise tek kimliği sistemin ana anahtarına dönüştürür.

Yetki ayrılığı şu düzeylerde kurulabilir:

• geliştirici ve üretim işletim rolleri,
• uygulama ve veritabanı yönetim hesapları,
• okuma ve yazma servisleri,
• dağıtım imzası ve artefakt üretimi,
• günlük kullanım hesabı ve ayrıcalıklı yönetim hesabı,
• kritik işlemlerde iki kişi veya ek doğrulama gereksinimi.

Ayrılık yalnız saldırgana karşı değildir. Yanlış komut, hatalı otomasyon ve içeriden kaynaklanan riski de sınırlar.

7.3 Katmanlı savunma

Katmanlı savunma aynı kontrolü beş kez kurmak değildir. Birbirinden bağımsız hata türlerini yakalayan kontroller kurmaktır.

Örneğin bir API için:

Ağ erişim kısıtı
    + güçlü kimlik doğrulama
    + nesne düzeyi yetkilendirme
    + girdi doğrulama
    + parametreli sorgu
    + en az ayrıcalıklı DB hesabı
    + güvenlik logu ve alarm

SQL injection açığı yanlışlıkla ortaya çıksa bile DB hesabının sınırlı yetkisi etkiyi küçültür; anormal sorgu davranışı gözlenebilir; yedek ve olay müdahalesi geri dönüş olanağı sağlar. Katmanların değeri, aynı varsayıma bağlı olmamalarından gelir.

7.4 Güvenli varsayılan

CISA'nın Secure by Design yaklaşımındaki önemli fikirlerden biri güvenlik yükünün müşteriye bırakılmamasıdır. Ürün kurulduğunda varsayılan parola, açık yönetim portu veya “isterseniz MFA'yı açabilirsiniz” yaklaşımı güvenli varsayılan değildir.

En kolay yol güvenli yol olmalıdır. Güvenlik özelliği ayrıca satın alınan veya onlarca gizli ayarla etkinleştirilen bir seçenek hâline gelirse gerçek dağıtımların önemli bölümü güvensiz kalır.

7.5 Hata durumunda güvenli davranış

Bir yetkilendirme servisine erişilemediğinde “iş devam etsin” diye erişim vermek fail-open davranıştır. Bazı yüksek erişilebilirlik gereksinimlerinde kontrollü istisna tasarlanabilir; fakat bunun bilinçli bir risk kararı olması gerekir.

Hata yolunda şu sorular sorulmalıdır:

• Kimlik sağlayıcı yoksa ne olur?
• Sertifika doğrulanamazsa bağlantı devam eder mi?
• Yetki servisi zaman aşımına uğrarsa izin mi, ret mi üretir?
• Log diski dolarsa uygulama durur mu, log atlar mı?
• Rate limiter deposu çalışmazsa sınır kalkar mı?
• İmza doğrulama anahtarı bulunamazsa belirteç kabul edilir mi?

Saldırgan yalnız normal akışı kullanmaz. Hata koşulu da saldırı yüzeyidir.

8. Güvenli geliştirme yaşam döngüsü: güvenliği sona bırakmamak

Bir uygulama tamamlandıktan sonra güvenlik ekibine verilip “açıklarını bulun” denildiğinde güvenlik maliyeti en yüksek noktadadır. Mimari hata bulunursa düzeltme yalnız kodu değil API sözleşmesini, veri modelini, istemcileri ve dağıtımı etkileyebilir.

NIST SSDF 1.1 güvenli geliştirme pratiklerini dört ana grupta düzenler: kuruluşu hazırlamak, yazılımı korumak, iyi güvenli yazılım üretmek ve güvenlik açıklarına karşılık vermek. Bu çerçeveyi günlük geliştirmeye çevirdiğimizde şu akış ortaya çıkar:

Gereksinim
   -> tehdit modelleme
   -> güvenlik kabul ölçütleri
   -> mimari karar
   -> güvenli kodlama
   -> kod inceleme
   -> otomatik analiz
   -> güvenlik testi
   -> güvenilir derleme
   -> kontrollü dağıtım
   -> gözlemleme
   -> güvenlik açığı yönetimi
   -> kök neden analizi
   -> yeni gereksinim

Buradaki son ok önemlidir. Aynı hata sınıfı üçüncü kez bulunuyorsa yalnız üç bug kapatılmamıştır; geliştirme sürecinde sistematik eksik vardır.

8.1 Güvenlik kabul ölçütleri

Bir kullanıcı hikâyesi'nin “çalışıyor” olması yeterli değildir. Güvenlik açısından da kabul ölçütü gerekir.

Örnek: “Kullanıcı kendi belgesini indirebilir.”

Güvenlik kabul ölçütleri:

• nesne kimliği değiştirilse bile başka kullanıcının belgesi dönmez,
• kullanıcı kimliği istemciden gelen userId alanına güvenilerek belirlenmez,
• indirme işlemi yetki denetiminden sonra yapılır,
• dosya yolu kullanıcı girdisinden doğrudan oluşturulmaz,
• erişim olayı denetlenebilir biçimde kaydedilir,
• hata cevabı dosyanın varlığını yetkisiz tarafa gereksiz yere ifşa etmez.

Bunlar sızma testinden önce yazıldığında güvenlik, test ekibinin bulmasını beklediğimiz gizli bir özellik olmaktan çıkar.

Ünite 2: Kimlik, Yetkilendirme, Oturum ve Kriptografi

9. Kimlik doğrulama: parola alanından daha büyük bir problem

Kimlik doğrulama, “kullanıcı adı ve parola doğru mu?” sorusundan ibaret değildir. Kayıt, kimlik kanıtlama, kimlik doğrulayıcı bağlama, giriş, MFA, oturum oluşturma, kurtarma, parola sıfırlama, cihaz kaybı ve hesabın kapatılması tek bir yaşam döngüsüdür.

En güçlü giriş ekranı bile zayıf parola sıfırlama akışıyla aşılabilir. Güvenlik sorusunun cevabı sosyal medyadan bulunabiliyorsa MFA'nın yanındaki “hesabı kurtar” bağlantısı saldırganın tercih ettiği yol olur.

9.1 Parola politikası: karmaşıklık tiyatrosundan maliyet modeline

Uzun süre parola politikaları büyük harf, küçük harf, sayı, sembol ve periyodik değişiklik üzerine kuruldu. Güncel NIST SP 800-63B-4 bu yaklaşımı değiştirmiştir. Tek faktör olarak kullanılan parolalarda en az 15 karakter ister; MFA'nın parçası olarak kullanılan parolalarda en az 8 karaktere izin verir, en az 64 karakterlik üst sınır desteğini önerir, keyfî karakter sınıfı kurallarını ve kanıt olmadan periyodik parola değişimini reddeder. Yaygın, beklenen veya ele geçirilmiş parolaların blok listesiyle engellenmesini ve çevrimiçi tahminlere karşı hız sınırlamasını ister.

Bu yaklaşım saldırganın gerçek maliyetine odaklanır. Password1! karmaşıklık kuralını geçebilir ama güçlü değildir. Uzun ve benzersiz parola, parola yöneticisi, ihlal edilmiş parola blok listesi, güvenli saklama ve doğru hız sınırlama birlikte daha anlamlıdır.

9.2 Parolayı saklamak

Parola şifrelenip daha sonra çözülecek bir veri değildir. Doğrulama için tek yönlü, maliyeti ayarlanabilir parola özetleme algoritması kullanılmalıdır. Genel amaçlı SHA-256 gibi hızlı özet algoritmaları parola saklama için uygun değildir; saldırganın saniyede çok fazla tahmin yapmasına izin verir.

OWASP Password Storage Cheat Sheet güncel olarak Argon2id'i birincil seçeneklerden biri olarak önerir. Algoritmanın parametreleri üretim donanımında ölçülmelidir. Amaç meşru giriş gecikmesini kabul edilebilir düzeyde tutarken çevrimdışı tahmin maliyetini yükseltmektir.

password
   + benzersiz salt
   + maliyet parametreleri
   -> Argon2id / uygun parola KDF'si
   -> saklanan doğrulayıcı

pepper kullanılıyorsa veritabanından ayrı bir sır yönetiminde tutulmalıdır. Veritabanı ile pepper aynı yapılandırma dosyasında bulunuyorsa beklenen ayrışma oluşmaz.

9.3 MFA'nın sınırı

MFA her saldırıyı çözmez. SMS tabanlı faktör SIM değişimi veya telekom saldırılarından etkilenebilir. TOTP kodu gerçek zamanlı oltalama proxy'siyle çalınabilir. Push bildirimleri kullanıcı yorgunluğu üzerinden kötüye kullanılabilir. Phishing-resistant kimlik doğrulayıcılar bu nedenle daha değerlidir.

Doğru soru “MFA açık mı?” değil, hangi tehdide karşı hangi kimlik doğrulayıcı kullanılıyor ve kurtarma yolu aynı güvenceyi koruyor mu? sorusudur.

9.4 Parola püskürtme ve hesap kilitleme

Active Directory ve CrackMapExec çalışmalarında görülen parola püskürtme mantığı, klasik brute force'tan farklıdır. Bir hesapta çok parola denemek yerine az sayıda muhtemel parola çok kullanıcıya uygulanır. Basit hesap kilitleme politikası bu davranışı her zaman yakalayamaz; saldırgan kilitlenme eşiğinin altında kalabilir.

Savunma için başarısız girişleri yalnız kullanıcı başına değil kaynak, hedef kümesi, zaman aralığı ve davranış paterniyle birlikte değerlendirmek gerekir. Bunun yanında MFA, zayıf parola blok listesi, eski protokollerin kapatılması ve servis hesaplarının doğru yönetimi saldırı yüzeyini azaltır.

10. Yetkilendirme: giriş yapmış olmak izin sahibi olmak değildir

Uygulama güvenliğinde en kalıcı hatalardan biri kimlik doğrulama ile yetkilendirmeyi aynı şey sanmaktır. Kullanıcının kim olduğunu bilmek, o kullanıcının istenen nesne üzerinde belirtilen işlemi yapabileceğini göstermez.

Bir API şu isteği alıyor olsun:

GET /api/documents/73152
Authorization: Bearer <belirteç>

Belirteç geçerli olabilir. Kullanıcı gerçekten giriş yapmış olabilir. Fakat 73152 numaralı belge ona ait değilse cevap yine reddedilmelidir. Menüde “Belgeler” bağlantısını gizlemek, JavaScript'te butonu devre dışı bırakmak veya kullanıcı rolünü istemcide kontrol etmek sunucu tarafı yetkilendirmenin yerine geçmez.

10.1 Nesne düzeyinde yetkilendirme

En güvenilir desen, kaynağı getirirken yetki kapsamını sorguya taşımaktır:

SELECT id, name, content
FROM document
WHERE id = ?
  AND owner_id = ?;

Burada ikinci parametre istemcinin gönderdiği ownerId değildir; doğrulanmış kimlik bağlamından gelir. Daha karmaşık sistemlerde RBAC, ABAC veya politika motoru kullanılabilir. İlke değişmez: işlem, nesne ve aktör birlikte değerlendirilir.

10.2 Deny by default

Yeni uç nokta eklenip yetki kuralı unutulduğunda herkesin erişebilmesi tehlikeli varsayılandır. Yetkilendirme mimarisi mümkün olduğunca “açıkça izin verilmediyse reddet” biçiminde kurulmalıdır.

Bu yaklaşım özellikle büyük projelerde önemlidir. Birkaç uç nokta için manuel kontrol kolaydır; yüzlerce route, mesaj tüketicisi ve arka plan görevi olan sistemde unutulan tek kontrol üretim açığına dönüşebilir.

10.3 Dikey ve yatay yetki yükseltme

Yatay yetki yükseltme, aynı yetki seviyesindeki başka kullanıcının kaynağına erişmektir. Dikey yetki yükseltme, daha yüksek rolün yapabildiği işlemi yapabilmektir.

Testte ikisini ayrı düşünmek gerekir:

• kullanıcı A, kullanıcı B'nin nesnesini okuyabiliyor mu?
• normal kullanıcı yönetici uç noktasını çağırabiliyor mu?
• yalnız okuma yetkisi olan kullanıcı yazabiliyor mu?
• bir tenant kullanıcısı başka tenant'ın nesnesine erişebiliyor mu?
• toplu uç nokta tekil uç noktadaki yetki kontrolünü atlıyor mu?
• export, arama, geçmiş veya ek dosya yolları ana nesne kadar sıkı korunuyor mu?

Birçok yetki açığı ana CRUD uç noktasında değil, ikincil işlevde ortaya çıkar.

11. Oturum güvenliği: kimliği bir istekten diğerine taşımak

HTTP durum tutmaz. Kullanıcının bir kez kimlik doğruladıktan sonra sonraki isteklerde tanınması için oturum kimliği veya belirteç kullanılır. Bu değer ele geçirilirse saldırgan parolayı bilmeden kullanıcı gibi davranabilir.

Bu yüzden oturum kimliği bir sırdır.

11.1 Çerez tabanlı oturum

Tarayıcı tabanlı uygulamalarda çerez kullanılıyorsa en az şu özellikler değerlendirilmelidir:

• Secure: yalnız HTTPS üzerinden gönderim,
• HttpOnly: JavaScript'in çerezi doğrudan okumasını sınırlama,
• SameSite: siteler arası istek davranışını kontrol etme,
• uygun Domain ve Path: gereksiz kapsamı azaltma,
• kimlik doğrulamadan sonra oturum ID yenileme,
• çıkışta sunucu tarafı geçersizleştirme,
• mutlak ve hareketsizlik zaman aşımı.

HttpOnly XSS'yi çözmez; yalnız belirli çerez hırsızlığı yolunu daraltır. XSS varsa saldırgan kullanıcı adına aynı origin üzerinde işlem yapabilir. Katmanlı savunmayı yanlış yorumlamamak gerekir.

11.2 JWT: imzalı olmak güvenli olmak değildir

JWT bir kimlik doğrulama protokolü değildir; belirli iddiaları taşıyabilen bir belirteç biçimidir. İmzayı doğrulamak zorunludur ama yeterli değildir. Kaynak sunucu en az şu bağlamı doğrulamalıdır:

• beklenen imza algoritması,
• güvenilen anahtar,
• iss veren taraf,
• aud hedef kitle,
• exp süresi,
• gerektiğinde nbf,
• yetki iddialarının semantiği,
• anahtar döndürme ve iptal stratejisi.

Belirteç içeriği Base64URL ile kodlanmış olduğu için gizli değildir. Parola, özel anahtar veya gereksiz kişisel veri JWT içine konmamalıdır.

Asimetrik imza mimarisi, kaynak sunucuların doğrulama anahtarını bilip imzalama anahtarına sahip olmamasını sağlar. Bu ayrım mikroservis ortamında değerlidir. Buna rağmen uzun ömürlü bearer belirteci çalındığında imza saldırganı durdurmaz. Belirteç ömrü, yenileme, hedef kitle (aud) kısıtı, gönderim kanalı ve hassas işlemlerde yeniden doğrulama birlikte düşünülmelidir.

12. Kriptografi: algoritma seçmekten çok anahtar yönetmek

Kriptografi güvenli sistemlerin temelidir; fakat yanlış uygulandığında yalnız güven hissi üretir. AES kullanmak tek başına verinin güvende olduğunu göstermez. Mod, nonce/IV üretimi, anahtar uzunluğu, anahtar saklama, bütünlük, anahtar döndürme, yedek ve erişim modeli de önemlidir.

12.1 Şifreleme, özet, MAC ve imza farklı problemleri çözer

• Şifreleme: Gizlilik
• Kriptografik özet: Veri için sabit uzunluklu özet; tek başına kimlik doğrulamaz
• **HMAC/MAC:** Paylaşılan sırla bütünlük ve kaynak doğrulama
• Dijital imza: Özel/açık anahtar modeliyle bütünlük ve imzalayanın doğrulanması
• Parola KDF'si: Parola tahminini maliyetli hâle getirmek

Güvensiz tersine serileştirmede HMAC ile istemciye verilen seri hâle getirilmiş verinin değişip değişmediğini kontrol etme fikri önemli bir ayrımı gösterir: bütünlük ile gizlilik aynı şey değildir. HMAC veriyi gizlemez; değiştirilmesini tespit etmeye yarar. Üstelik güvenilmeyen veriyi native nesne grafiğine dönüştürmek zorunlu değilse daha iyi çözüm serileştirme biçimini güvenli bir veri modeline çevirmektir. Kriptografik doğrulama, tehlikeli ayrıştırıcı davranışını meşrulaştırmamalıdır.

12.2 Kendi kriptografinizi tasarlamayın

Kriptografik ilkelere aşina olmak gerekir; fakat üretim protokolünü “AES + SHA-256 + Base64 yaptım” biçiminde birleştirmek ciddi risk taşır. Doğrulanmış protokoller ve iyi incelenmiş kütüphaneler kullanılmalıdır.

TLS'de sertifika doğrulamasını kapatmak, güçlü şifreleme algoritmasını anlamsızlaştırır. Mobil testlerde certificate pinning'i aşma çalışmaları da bunu görünür kılar: istemci, güven kararını nerede ve nasıl veriyor? Pinning bazı tehditlerde ek savunma sağlayabilir; fakat ana güven modeli standart sertifika doğrulamasının doğru uygulanmasına dayanmalıdır. Test için TrustAll benzeri kodun üretime taşınması, TLS'i yalnız şifreli ama kimliği belirsiz bir tünele dönüştürür.

12.3 Sır yönetimi

Sırları şu yerlerde bırakmamak gerekir:

• kaynak kodu,
• Git geçmişi,
• istemci uygulaması,
• Docker image katmanı,
• CI logu,
• hata mesajı,
• genel yapılandırma dosyası,
• herkesin okuyabildiği ortam değişkeni dökümü,
• destek paketleri ve diagnostic dump'lar.

Bir sır sızdığında yalnız dosyayı silmek yetmez; sırın ele geçirilmiş kabul edilip döndürülmesi gerekir. Git geçmişindeki anahtarı son commit'ten kaldırmak onu internetten geri çağırmaz.

Ünite 3: Güvenilmeyen Veri ve Uygulama Saldırı Yüzeyi

Güvenilmeyen bir girdi işlenirken önce kaynağın hangi güven sınırından geçtiği ve hangi dil veya protokol bağlamında yorumlanacağı belirlenir. Geçerlilik kontrolü, kanonikleştirme ve bağlama uygun çıktı kodlaması birbirinin yerine geçmez. Veri SQL, HTML veya işletim sistemi komutu içinde kullanılıyorsa, ilgili yorumlayıcıya ait parametreleme veya güvenli arayüz tercih edilmelidir. Güvenlik denemeleri yalnız bilinen örnek dizgilere değil, sınır karakterlerine ve kodlama farklılıklarına da odaklanmalıdır.

13. Güvenilmeyen veri: saldırıların ortak kökü

Bir verinin kaynağını “kendi frontend'im”, “veritabanım”, “mesaj kuyruğum” veya “iç ağ” olarak adlandırmak onu güvenilir yapmaz. Güven, verinin geçmişine göre değil kullanıldığı güven sınırına göre değerlendirilmelidir.

Bir tarayıcı isteği değiştirilebilir. Mobil uygulama tersine mühendislikle incelenebilir ve istemci kontrolleri atlanabilir. Veritabanındaki kayıt geçmişte XSS ile yazılmış olabilir. Mesaj kuyruğundaki veri ele geçirilmiş bir üreticiden gelmiş olabilir. Dosya adı kullanıcı kontrolünde olabilir. LDAP özniteliği dış sistem tarafından doldurulmuş olabilir.

Bu nedenle her yorumlayıcı sınırında iki soru sorulur:

1. Veri hangi biçimde kabul edilecek?
2. Bu veri hangi bağlamda kullanılacak?

İlk soru girdi doğrulama, ikincisi çoğu zaman bağlama uygun güvenli API veya çıktı kodlama problemidir.

13.1 İzin listesi düşüncesi

“Tehlikeli karakterleri silelim” yaklaşımı uzun vadede zayıftır. Yasak liste saldırganın bütün temsil biçimlerini öngörmeye çalışır. Unicode, farklı kodlamalar, canonicalization, ayrıştırıcı farkları ve yeni sözdizimleri bu yaklaşımı kırar.

Bir alan UUID ise UUID biçimini kabul edin. Bir sayfa numarası pozitif tam sayıysa bunu parse edin ve aralığını doğrulayın. Bir enum yalnız belirli değerleri alıyorsa diğerlerini reddedin. Dosya uzantısı güvenlik kararıysa yalnız dosya adına bakmayın; içerik, MIME ve işleme biçimini birlikte değerlendirin.

Doğrulama uygulama gereksinimini tanımlar. Enjeksiyonu tek başına çözmez. SQL için parametreli sorgu, HTML için bağlama uygun çıktı kodlama gibi mekanizmalar ayrıca gerekir.

14. Enjeksiyon: veri komuta dönüştüğünde

Enjeksiyon saldırılarının farklı isimleri vardır; kök problem aynıdır. Uygulama, dışarıdan gelen veriyi komutun veya kodun parçası hâline getirir.

14.1 SQL injection

Savunmasız düşünce biçimi:

String sql = "SELECT id, role FROM users WHERE username = '" + username + "'";

Buradaki sorun yalnız tek tırnaktır. Kullanıcı verisi SQL sözdiziminin içine birleştirilmiştir. Karakter kaçırma ile bütün SQL lehçelerini, kodlamaları ve gelecekteki değişiklikleri doğru yönetmeye çalışmak gereksiz risk üretir.

Güvenli sınır parametreli sorgudur:

PreparedStatement ps = connection.prepareStatement("SELECT id, role FROM users WHERE username = ?");
ps.setString(1, username);

Parametreli sorguda SQL yapısı ile veri ayrı kanallardadır. Bu ayrım güvenlik ilkesidir; PreparedStatement yalnız uygulama aracıdır.

Dinamik tablo adı, kolon adı veya ORDER BY yönü parametrelenemiyorsa kullanıcı girdisini doğrudan birleştirmek yerine uygulama içindeki sabit bir izin listesinden seçim yapılır.

İkinci savunma DB hesabının en az ayrıcalığıdır. Enjeksiyon hatası oluşsa bile uygulama hesabı yalnız işlevi için gereken işlemleri yapabiliyorsa etki sınırlandırılır.

14.2 İşletim sistemi komut enjeksiyonu

Bir dosyayı dönüştürmek için shell komutu oluşturup kullanıcı dosya adını metne eklemek, SQL injection'ın başka yorumlayıcıdaki karşılığıdır. Mümkünse shell yerine doğrudan kütüphane veya process API'si kullanılmalı, argümanlar ayrı aktarılmalıdır. sh -c benzeri ek yorumlayıcı katmanı saldırı yüzeyini büyütür.

Güvenlik açısından en güçlü çözüm çoğu zaman “daha iyi escape” değil, yorumlayıcıyı aradan çıkarmaktır.

14.3 LDAP, template ve diğer yorumlayıcılar

LDAP filter injection, expression language injection, template injection ve benzeri sınıflar da aynı modele girer. Uygulama geliştirirken “bu string daha sonra hangi ayrıştırıcıya gidecek?” sorusu alışkanlık hâline gelmelidir.

Bir değişken sırayla URL, JSON, HTML ve JavaScript bağlamına giriyorsa her sınırın kuralları farklıdır. Tek bir sanitize() fonksiyonuyla bütün bağlamları güvenli kılmak gerçekçi değildir.

15. XSS: karakter filtresi değil, bağlam problemi

Eski eğitim materyallerinde XSS çoğu zaman <script>alert(...)</script> saldırı yükünün çalışmasıyla gösterilir ve çözüm olarak belirli etiketleri silme önerilir. Bu, açığı anlamak için başlangıç olabilir fakat güncel savunma için yetersizdir.

XSS'nin asıl sorusu şudur: güvenilmeyen veri tarayıcıda hangi bağlamda yorumlanıyor?

Aynı veri şu bağlamlarda farklı kurallara tabidir:

<div>METİN</div>
<input value="ÖZNİTELİK">
<script>const x = "JAVASCRIPT_DİZGESİ";</script>
<a href="URL">bağlantı</a>
<style>CSS_BAĞLAMI</style>

HTML metin düğümünde güvenli olan kodlama JavaScript bağlamında aynı anlamı taşımayabilir. Bu nedenle bağlama duyarlı çıktı kodlama gerekir.

15.1 DOM XSS

İstemci tarafında innerHTML gibi sink'lere kullanıcı kontrollü veri taşımak risklidir. Metin göstermek için textContent gibi semantiği güvenli API'ler tercih edilir. Gerekiyorsa HTML sanitizasyonu, bu amaç için olgun bir kütüphane ve dar bir izin listesi ile yapılmalıdır.

15.2 CSP savunma katmanıdır

Content Security Policy, doğru tasarlandığında XSS etkisini ciddi biçimde azaltabilir. Fakat CSP'yi çıktı kodlamanın yerine koymak yanlıştır. Nonce/hash tabanlı sıkı politika, inline script bağımlılığını azaltır ve beklenmeyen script kaynaklarını sınırlar.

Örnek ilke:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<istek-specific>'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'

Gerçek politika uygulamanın kaynak ihtiyaçlarına göre oluşturulmalı, önce raporlama modunda ölçülmeli ve gereksiz genişletmelerden kaçınılmalıdır. unsafe-inline ile açılan geniş bir script-src, politikanın değerini önemli ölçüde azaltabilir.

15.3 Çerez çalınmıyorsa XSS önemsiz değildir

HttpOnly çerez nedeniyle document.cookie okunamaması XSS'nin etkisini ortadan kaldırmaz. Saldırgan aynı origin'de kullanıcının yapabildiği istekleri yapabilir, DOM'u değiştirebilir, hassas veriyi okuyabilir veya kullanıcıyı yanıltabilir. Savunmada güvenlik açığını gerçek yetenek modeliyle değerlendirmek gerekir.

Çıktı kodlama, güvenilmeyen verinin hangi sözdizimsel bağlamda kullanıldığına göre değişir. HTML metin düğümü, HTML özniteliği, URL bileşeni ve JavaScript dizgesi aynı kaçış kurallarına sahip değildir. Bir değerin HTML içinde güvenle gösterilmesi, aynı değerin olay işleyici özniteliğine veya JavaScript koduna güvenle yerleştirilebileceğini kanıtlamaz. Uygulamada dinamik veriyi mümkün olduğunda textContent gibi metin kabul eden API'lerle taşımak, HTML yorumlayıcıya gereksiz yetki vermekten kaçınır. URL veya stil gibi başka bağlamlar için ayrı doğrulama ve güvenli kullanım sözleşmeleri gerekir.

16. CSRF ve CORS: birbirine benzeyen isimler, farklı güven sınırları

CSRF, tarayıcının kullanıcının kimlik bilgilerini otomatik olarak hedef siteye eklemesinden yararlanır. Kullanıcı saldırganın sayfasındayken hedef uygulamaya istek gönderilir; hedef yalnız çereze bakıyorsa isteği gerçek kullanıcı isteği sanabilir.

Savunmada durum değiştiren işlemlerde CSRF belirteci, uygun SameSite politikası, Origin/Referer değerlendirmesi ve çerçevenin yerleşik koruması kullanılabilir. Hangi mekanizmanın gerektiği kimlik doğrulama taşıma modeline bağlıdır.

CORS ise tarayıcının farklı origin'ler arasında script tarafından erişilebilecek cevapları belirleyen politikadır. CORS bir kimlik doğrulama veya sunucu tarafı yetkilendirme mekanizması değildir.

Şu politika gereksiz geniştir:

Access-Control-Allow-Origin: *

Hassas uygulamalarda ihtiyaç duyulan origin'ler açıkça tanımlanmalıdır. Dinamik origin yansıtılıyorsa girdinin gerçekten izin listesinde olduğu doğrulanmalıdır. Origin değerini körlemesine geri yansıtmak kontrol değildir.

17. SSRF: sunucunun ağ konumunu saldırgana kiralamak

Bir uygulama kullanıcıdan URL alıp o adrese sunucu tarafından istek gönderiyorsa yalnız “URL indiriyoruz” işi yapmıyordur; saldırgana sunucunun ağ erişim konumundan istek üretme yeteneği verebilir.

Örnek kullanım alanları meşrudur:

• uzak resim alma,
• webhook doğrulama,
• PDF oluşturmak için dış URL çekme,
• entegrasyon testi,
• URL önizleme.

Ancak saldırgan hedefi iç ağ adresine, loopback'e, link-local servise veya beklenmeyen protokole yöneltebilirse SSRF oluşabilir.

Güvenli tasarımda mümkünse hedefler izin listesi ile sınırlanır. DNS çözümlemesinin zaman içinde değişebileceği, redirect'in ilk doğrulamayı aşabileceği ve IPv4/IPv6'nin farklı gösterimleri olduğu düşünülmelidir. Uygulama katmanındaki doğrulamaya ek olarak sunucunun gereksiz ağ erişimi egress firewall veya ağ politikasıyla kapatılmalıdır.

Bu, katmanlı savunmanın iyi örneğidir: ayrıştırıcı hatası olsa bile ağ katmanı kritik hedefe giden yolu kesebilir.

18. Yol geçişi ve dosya yükleme: dosya adı veri değildir

Kullanıcıdan alınan dosya adını doğrudan dizinle birleştirmek, ../ ve benzeri yol geçişi davranışlarına kapı açabilir. Normalizasyon ve canonical path denetimi önemlidir; daha güçlü tasarım ise fiziksel dosya yolunu kullanıcı girdisinden türetmemektir.

Dosya yüklemede yalnız uzantı kontrolü güvenilir değildir. Şu boyutlar birlikte değerlendirilir:

• izin verilen dosya türleri,
• içerik doğrulama,
• boyut ve adet limiti,
• kullanıcıdan bağımsız üretilen depolama adı,
• web root dışında depolama,
• çalıştırma yetkisinin olmaması,
• görüntü/medya ise güvenli yeniden işleme,
• antivirüs veya içerik analizi gereksinimi,
• indirme sırasında doğru Content-Type ve Content-Disposition,
• erişim yetkisinin her indirmede yeniden doğrulanması.

Bir yükleme servisi yalnız “dosya kabul eden uç nokta” değildir; ayrıştırıcı, depolama ve servis etme zinciridir.

19. Güvensiz tersine serileştirme: veriyi nesne grafiğine dönüştürmenin bedeli

Serileştirme, nesneyi taşınabilir veya saklanabilir biçime dönüştürür. Sorun, güvenilmeyen baytların güçlü bir native nesne modeline geri çevrilmesinde başlar. Bazı platformlarda nesne oluşturma sırasında magic method, gadget chain veya geri çağırım (callback) mekanizmaları beklenmeyen davranış üretebilir.

PHP, Python pickle/YAML ve .NET serileştirme örneklerinin ortak dersi araçtan bağımsızdır: güvenilmeyen veriyi davranış taşıyan nesne grafiğine dönüştürmeyin.

Daha güvenli desen, sınırlı veri şeması kullanmaktır:

{
  "userId": 42,
  "theme": "dark",
  "language": "tr"
}

JSON da otomatik olarak güvenli değildir; ayrıştırıcı ve tip bağlama seçenekleri önemlidir. Ancak yalnız gerekli primitive alanları tanımlayan şema, keyfî sınıf üretimine göre saldırı yüzeyini önemli ölçüde küçültür.

HMAC veya dijital imza, verinin güvenilir üreticiden geldiğini doğrulamak için yararlı olabilir. Fakat imzalı tehlikeli nesne formatı, anahtar sızdığında veya başka bir güvenilir üretici yanlış veri oluşturduğunda yine tehlikelidir. En güçlü çözüm veri modelini daraltmaktır.

20. API güvenliği: protokol kadar iş mantığını korumak

API güvenliği yalnız HTTP header seti değildir. Modern uygulamada iş mantığının büyük bölümü API üzerinden erişilebilir olduğundan, istemci arayüzünde görünmeyen işlevlerin de saldırı yüzeyi olduğu unutulmamalıdır.

Her uç nokta için şu beş soru etkili bir inceleme çerçevesi oluşturur:

1. Kim çağırıyor? Kimlik nasıl doğrulanıyor?
2. Neyi yapmaya yetkili? Nesne ve işlem bazında kontrol var mı?
3. Ne gönderebilir? Şema, boyut, biçim ve semantik sınırlar var mı?
4. Ne kadar çağırabilir? Kaynak tüketimi ve otomasyon sınırı nedir?
5. Ne öğrenebilir? Cevap, hata, süre ve durum kodları gereksiz bilgi sızdırıyor mu?

20.1 Mass assignment

İstemciden gelen JSON'u doğrudan domain nesnesine bağlamak beklenmeyen alanların değişmesine izin verebilir:

{
  "displayName": "Ali",
  "role": "ADMIN",
  "approved": true
}

UI yalnız displayName gönderiyor olabilir; saldırgan HTTP isteğini kendisi oluşturur. DTO/command modeli yalnız değiştirilebilir alanları taşımak için kullanılmalı, hassas alanlar sunucu tarafındaki iş kuralından üretilmelidir.

20.2 Hız sınırlama yalnız DoS için değildir

İstek hızını sınırlandırmak parola tahmini, OTP denemesi, kullanıcı adı keşfi, pahalı rapor üretimi, toplu veri çekme ve scraping gibi birçok saldırıda maliyeti artırır. Ancak sabit “IP başına 100 istek” kuralı her problem için yeterli değildir. NAT, botnet, kullanıcı kimliği, işlem türü ve uç nokta maliyeti hesaba katılmalıdır.

Bir parola uç noktası ile statik içerik uç noktasının aynı limite tabi olması anlamlı değildir.

21. Veri katmanı: enjeksiyondan daha fazlası

Veritabanı güvenliği çoğu eğitimde SQL injection ile başlar ve orada biter. Üretim sisteminde veri katmanı çok daha geniştir: kimlik bilgileri, ağ erişimi, şema yetkileri, denetim izi, yedek, replikasyon, veri yaşam döngüsü, toplu dışa aktarma ve yönetim araçları aynı güven sınırının parçalarıdır.

21.1 Uygulama hesabı ile yönetici hesabını ayırmak

Uygulamanın çalışma hesabı şema sahibi veya DBA olmamalıdır. Normal işlev için gereken DML yetkileri mümkün olduğunca sınırlı tutulmalıdır. Şema göçü gerekiyorsa bunu ayrı kimlik ve ayrı dağıtım adımı yapmalıdır.

Bunun iki sonucu vardır. Birincisi, uygulama açığının etki alanı küçülür. İkincisi, hatalı uygulama kodunun yanlışlıkla şemayı değiştirmesi zorlaşır.

21.2 Veritabanı ağ sınırı

İnternete açık uygulamanın veritabanı portunun da internete açık olmasına gerek yoktur. Uygulama ve DB arasında gereken akış net biçimde tanımlanmalıdır. Yönetim erişimi ayrı ağ veya bastion üzerinden yapılabilir. “Parolası güçlü” diye gereksiz ağ erişimini açık bırakmak iyi savunma değildir.

21.3 Yedek de üretim verisidir

Canlı veritabanı şifreli, erişim kontrollü ve denetlenebilir olabilir; ancak günlük yedek herkesin erişebildiği paylaşıma yazılıyorsa sistemin gerçek veri güvenliği yedek kadar güçlüdür.

Yedeklerde şu kontroller düşünülmelidir:

• erişim yetkisi,
• şifreleme ve anahtar ayrılığı,
• bütünlük doğrulama,
• değiştirilemez veya offline kopya gereksinimi,
• geri yükleme testi,
• saklama süresi,
• güvenli silme,
• test ortamına veri taşırken maskeleme.

Ransomware olaylarında yedeğin varlığı değil geri yüklenebilir, saldırgandan ayrılmış ve doğrulanmış yedeğin varlığı önemlidir.

22. Bellek güvenliği: birkaç bayttan süreç denetimine

The Shellcoder's Handbook gibi klasik kaynakların kalıcı değeri, belirli istismar'lerin bugün hâlâ aynı biçimde çalışması değildir. Değeri, bir bellek hatasının makinenin yürütme modeline nasıl bağlandığını göstermesidir.

C ve C++ ile çalışırken dizi sınırı, pointer ömrü, integer dönüşümü, format string veya use-after-free gibi hatalar yalnız programın çökmesine neden olmaz. Uygun koşullarda saldırganın bellek düzenini etkilemesine, veri yönlendirmesine veya kontrol akışını değiştirmesine kadar ilerleyebilir.

22.1 Stack taşması bize ne öğretir?

Klasik bir stack overflow örneğinde sabit boyutlu tamponun sınırı aşılır. Tarihsel örneklerde dönüş adresinin üzerine yazılması, instruction pointer'ın saldırganın seçtiği adrese yönelmesi ve shellcode çalıştırılması gösterilir.

Modern sistemlerde şu azaltımlar saldırıyı zorlaştırır:

• stack canary,
• NX/DEP,
• ASLR,
• PIE,
• RELRO,
• Control-Flow Integrity'nin çeşitli biçimleri,
• donanım destekli kontrol akışı korumaları,
• güvenli derleyici seçenekleri.

Bunların varlığı “buffer overflow artık önemsiz” anlamına gelmez. İstismar tekniği değişir; bellek bozulması kök problem olarak kalır.

22.2 Savunmanın ilk katmanı istismar azaltımı değildir

Canary veya ASLR hatayı gidermediği için birinci savunma olamaz. Asıl hedef bellek hatasını üretmemektir:

• boyutu bilinen buffer API'leri,
• doğru integer ve uzunluk kontrolü,
• sahiplik/ömür modelinin açık olması,
• fuzzing,
• sanitizers,
• statik analiz,
• güvenli standard library bileşenleri,
• mümkün olan bileşenlerde bellek güvenli dil tercihi.

Güvenlik azaltımları ikinci katmandır. Bir hata kaçarsa istismar maliyetini yükseltir.

22.3 Heap, use-after-free ve karmaşık bellek hataları

Heap overflow veya use-after-free klasik stack taşmasına göre daha az sezgiseldir. Modern allocator davranışı, metadata yapısı ve nesne yerleşimi istismar edilebilirliği belirler. Savunmada kaynak kodu seviyesinde lifetime disiplini, sahiplik modeli, güvenli kapsayıcılar ve dinamik analiz araçları önem kazanır.

Bu alanda istismar geliştirme deneyiminin savunmaya en büyük katkısı şudur: “program çöküyor” ifadesi güvenlik analizini bitirmez. Çöküşün saldırgan kontrollü veriyle deterministik biçimde tekrar üretilebilmesi, instruction pointer veya kritik pointer'ların etkilenebilmesi ve bellek düzeninin yönlendirilebilmesi ayrıca incelenmelidir.

23. Tersine mühendislik: istemcide saklanan sır, sır değildir

Reversing: Secrets of Reverse Engineering çizgisindeki çalışmalar, derlenmiş programı yalnız assembly okumaya indirgemez. Bir uygulamanın güvenlik varsayımlarını binary seviyesinde gözlemlemeyi öğretir.

Mobil veya masaüstü istemcide şu varsayımlar tehlikelidir:

• “API adresini gizledik, bulunamaz.”
• “Admin butonu görünmüyor, çağrı yapılamaz.”
• “Anahtarı binary içine gömdük.”
• “Lisans kontrolü istemcide, kullanıcı değiştiremez.”
• “Certificate pinning var, trafik incelenemez.”
• “Kod obfuscate edildi, iş mantığı güvenli.”

Saldırgan dosyayı kendi makinesinde çalıştırır. Statik analiz, hata ayıklamager, API hooking, instrumentation veya bellek inceleme yeteneğine sahiptir. İstemcinin sahibi saldırgandır varsayımıyla tasarım yapmak gerekir.

23.1 Obfuscation güven sınırı değildir

Kod karartma tersine mühendislik maliyetini artırabilir. Fikri mülkiyet veya otomatik analiz direnci için yararlı olabilir. Ancak sunucu tarafı yetkilendirmenin yerine geçmez. Binary içinde bulunan uzun ömürlü ortak sır, yeterli zaman verildiğinde çıkarılabilir kabul edilmelidir.

23.2 Güvenlik testinde tersine mühendisliğin yeri

Tersine mühendislik özellikle şu sorular için değerlidir:

• istemci hangi uç noktaları çağırıyor?
• hata ayıklama/test işlevi unutulmuş mu?
• sertifika doğrulama gerçekten yapılıyor mu?
• hassas veri diske hangi biçimde yazılıyor?
• yerel veritabanında belirteç veya parola var mı?
• native kütüphanelerde bellek güvenliği problemi var mı?
• sunucunun yapması gereken yetki kararı istemciye bırakılmış mı?

Amaç binary'yi “kırmak” değil, istemcinin taşıyamayacağı güven sorumluluklarını ortaya çıkarmaktır.

İstek yüzeyini güven ve maliyet sınıfına göre korumak

DoS savunması yalnız saniyedeki istek sayısını saymak değildir. Aynı istek adedi, statik bir dosya ile veritabanı ve uzak servis kullanan dinamik bir işlem için aynı maliyeti üretmez. Bu nedenle koruma modeli iki ekseni birlikte ele almalıdır: isteğin güven düzeyi ve sunucuda tükettiği kıt kaynak.

istek
  |
  +--> kimlik / güven sınıfı
  |
  +--> maliyet sınıfı
           |
           v
    rate + concurrency bütçesi
           |
           v
       uygulama

Rate limit belirli zaman aralığında kabul edilen istek miktarını sınırlar; concurrency limit ise aynı anda içeride bulunan pahalı işi sınırlar. Bunlar birbirinin yerine geçmez. Çok kısa süren binlerce istek rate limit problemi olabilirken, az sayıda fakat uzun süren işlem bütün bağlantı veya thread kapasitesini concurrency yönünden tüketebilir. Güçlü bir koruma katmanı her iki davranışı da ayrı ölçer.

Kimliği doğrulanmış kullanıcı trafiği ile anonim trafik için aynı hata bütçesini kullanmak da her zaman doğru değildir. Kimlik doğrulama güvenilirlik garantisi sağlamaz; ancak işlevsel sözleşme ve hizmet önceliği farklı olabilir. Kritik oturum akışlarının anonim tarama veya pahalı keşif trafiği tarafından aç bırakılmaması için bulkhead yaklaşımı kullanılabilir. Bunun karşılığında yetkili kullanıcı yolunun sınırsız bırakılması da doğru değildir; arka uç kıt kaynakları yine fiziksel sınırlara sahiptir.

Güvenlik kontrolü ortam bağlamını da hesaba katmalıdır. Üretimde zorunlu bir koruma ayarının eksikliği başlatmayı engelleyebilirken geliştirme veya çevrimdışı doğrulama ortamında aynı politika gereksiz olabilir. Bu ayrım gevşeklik değil, tehdidin ve çalışma bağlamının açık tanımıdır. Ortam kararı kodun farklı yerlerine dağılmak yerine tek ve gözlenebilir bir politika sınırında tutulmalıdır.

Aşırı yük yanıtı da saldırı yüzeyinin parçasıdır. Pahalı hata sayfası üretmek, büyük log satırları yazmak veya her reddedilen istekte harici servise başvurmak savunma mekanizmasını yeni bir darboğaza çevirebilir. Ret yolu normal iş yolundan daha ucuz ve deterministik olmalıdır. Rate limiting, tehdit modelleme ve Yazılım Test Mühendisliği bu tasarımın ölçüm ve doğrulama tarafını tamamlar.

Ünite 4: İşletim Sistemi, Ağ, Mobil ve Tedarik Zinciri Güvenliği

24. İşletim sistemi güvenliği: uygulamanın altında kalan katman

Uygulama güvenli olsa bile üzerinde çalıştığı işletim sistemi gereksiz servisler, aşırı yetkiler veya zayıf dosya izinleri taşıyorsa saldırı yüzeyi devam eder.

24.1 Süreci olabildiğince güçsüz çalıştırmak

Bir web servisi root yetkisine ihtiyaç duymuyorsa root olarak çalışmamalıdır. Linux üzerinde systemd gibi mekanizmalar ek izolasyon sağlayabilir:

[Service]
User=app
Group=app
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

Gerçek servis gereksinimine göre ReadWritePaths, capability sınırları, syscall filtreleri veya namespace özellikleri ayrıca değerlendirilebilir. Sıkılaştırma'i körlemesine kopyalamak doğru değildir; servis davranışı ölçülmeli ve gereken en küçük izin verilmelidir.

24.2 Dosya izinleri

Sır dosyası yalnız servis hesabı tarafından okunmalıysa 0644 uygun değildir. Log dosyası hassas bilgi içeriyorsa herkesin okuyabildiği dizine yazılmamalıdır. Uygulamanın binary veya config dizinine yazma ihtiyacı yoksa çalışma hesabına yazma yetkisi verilmemelidir.

Bu küçük izin kararları RCE sonrası saldırganın ne kadar ilerleyebileceğini belirler.

24.3 Yama yönetimi

“Çalışan sisteme dokunma” refleksi kritik üretim sistemlerinde anlaşılırdır; fakat yıllarca yama uygulanmaması da güvenlik stratejisi değildir. Doğru yöntem test, aşamalı dağıtım, geri dönüş planı ve envanterle kontrollü güncellemedir.

Yama kararı şu verilerle yönetilmelidir:

• bileşen gerçekten kullanılıyor mu?
• güvenlik açığı bizim yapılandırmamızda erişilebilir mi?
• istismar biliniyor mu veya aktif istismar var mı?
• bileşen hangi güven sınırında?
• telafi edici kontrol var mı?
• güncellemenin operasyonel riski nedir?

Risk kabulü süreli ve kayıtlı olmalıdır. “Şimdilik dokunmuyoruz” kararı sonsuz erteleme anlamına gelmemelidir.

25. Active Directory: kimlik sistemi aynı zamanda saldırı grafıdır

Active Directory ortamında kullanıcı, bilgisayar, grup, oturum, ACL, GPO, servis hesabı ve trust ilişkileri birlikte değerlendirilmelidir. BloodHound'un graf yaklaşımı bu karmaşıklığı görünür kılar.

Bir kullanıcının doğrudan Domain Admin grubunda olmaması güvenli olduğu anlamına gelmez. Kullanıcı A, Grup B üzerinde değişiklik yetkisine; Grup B, Bilgisayar C üzerinde yerel yönetici yetkisine; Bilgisayar C'de Domain Admin oturumuna erişim olanağına sahip olabilir. Saldırgan açısından kritik olan doğrudan üyelik değil ulaşılabilir yoldur.

25.1 BloodHound'u yalnız kırmızı takım aracı olarak görmemek

BloodHound, saldırı yolunu saldırgandan önce görmek için savunmada da kullanılabilir. Özellikle şu sorular değerlidir:

• yüksek değerli varlıklara en kısa yollar neler?
• hangi kullanıcı veya grup beklenmedik derecede merkezi?
• hangi servis hesapları fazla yetkili?
• hangi bilgisayarlardaki oturumlar kimlik zincirini büyütüyor?
• ACL üzerinden gizli yetki yükseltme yolları var mı?
• GPO veya delegation ilişkileri hangi yolları açıyor?

Grafı periyodik karşılaştırmak, yeni bir grup üyeliğinin veya ACL değişikliğinin saldırı yolu oluşturup oluşturmadığını gösterebilir.

25.2 Kerberos'u protokol olarak anlamak

Kerberos yalnız “ticket kullanan Windows kimlik doğrulaması” değildir. Ticket Granting Ticket (TGT), Ticket Granting Service (TGS), KDC, SPN ve anahtar ilişkisini anlamadan Kerberoasting, AS-REP Roasting veya ticket saldırılarını doğru değerlendirmek zordur.

Kerberoasting'in savunma açısından önemli dersi şudur: servis hesabının parolası çevrimdışı tahmine konu olabilir. Bu nedenle servis hesabı parolasının uzun, rastgele ve yönetilen olması; mümkün olduğunda Group Managed Service Account gibi mekanizmaların kullanılması; eski şifreleme türlerinin ve gereksiz SPN'lerin azaltılması önemlidir.

AS-REP Roasting ise Kerberos ön kimlik doğrulaması devre dışı bırakılmış hesapların neden özel risk taşıdığını gösterir. Kullanılmayan eski yapılandırmaların “çalışıyor, dokunmayalım” diye kalması kimlik sisteminde saldırı yüzeyi üretir.

25.3 Pass-the-Hash ve Pass-the-Ticket'in öğrettiği ayrım

Saldırgan her zaman açık metin parolaya ihtiyaç duymaz. Kimlik doğrulama mekanizmasının kabul ettiği hash veya ticket ele geçirildiğinde bunlar yeniden kullanılabilir. Bu, sır yönetiminde “parolayı göremedi, güvendeyiz” varsayımının hatalı olduğunu gösterir.

Bellek ve kimlik bilgisi korumaları, ayrı yönetici hesapları, ayrıcalıklı oturumların düşük güvenli istemcilerde açılmaması, SMB/NTLM kullanımının azaltılması ve modern kimlik güvenlik özellikleri bu riskin parçalarını azaltır.

25.4 krbtgt ve etki alanı güven kökü

Etki alanının kritik sırlarından biri krbtgt hesabıyla ilişkilidir. Bu seviyedeki bir ihlal normal kullanıcı parolası değişikliğiyle çözülemez. Olay müdahalesi etki alanı güven modelini ve ticket yaşam döngüsünü hesaba katmalıdır.

Bu örnek, kritik kimlik materyalinin envanterde ayrıca sınıflandırılması gerektiğini gösterir. Her parola aynı değildir; bazı sırların ele geçirilmesi bütün güven alanını etkiler.

26. Ağ güvenliği: paketi görmeden varsayım üretmeyin

Wireshark ve tcpdump ile çalışmak, ağ güvenliğini soyut diyagramdan gerçek paketlere indirir. Bir uygulamanın “HTTPS kullanıyor” dediği durumda DNS sorgusunun, TLS el sıkışmasının, yönlendirme davranışının ve gerçek hedefin görülmesi birçok yanlış varsayımı ortaya çıkarabilir.

26.1 Paket analizi neden hâlâ önemlidir?

Modern sistemlerde trafik şifreli olsa bile şu meta veriler değerlidir:

• kaynak ve hedef,
• port ve protokol,
• bağlantı sıklığı,
• TCP bayrakları,
• paket boyutları,
• DNS istekleri,
• TLS handshake bilgileri,
• yeniden iletimler,
• bağlantı kurma ve kapatma davranışı.

Uygulama katmanında loglanmayan bir davranış ağ katmanında görülebilir. Tersine, ağ katmanındaki anomaliyi yorumlamak için uygulama bağlamı gerekir.

26.2 Segmentasyon

Düz ağ saldırgana yanal hareket için geniş alan verir. Segmentasyonun amacı VLAN sayısını artırmak değil, güven sınırlarını ağ üzerinde uygulamaktır.

Örneğin:

İnternet -> Ters Vekil: 443
Ters Vekil -> Uygulama: 8443
Uygulama -> DB: 5432
Uygulama -> Kimlik Servisi: 443
Yönetim Ağı -> Sunucular: yönetim portları
Diğer her şey: reddet

Bu politika yalnız giriş trafiğine değil çıkış trafiğine de uygulanmalıdır. RCE alan uygulama sunucusunun internette her adrese ve iç ağdaki her porta bağlanabilmesi saldırganın seçeneklerini artırır.

26.3 Güvenlik duvarı uygulama açığını çözmez

Firewall, belirli ağ akışlarını sınırlar. İzin verilen 443 portundaki uygulama SQL injection içeriyorsa firewall bunu otomatik çözmez. WAF bazı saldırı yüklerini engelleyebilir; ancak uygulama güvenlik açığının kök nedenini ortadan kaldırmaz.

En iyi kullanım, kontrolleri görevlerine göre konumlandırmaktır:

• firewall: ağ erişim sınırı,
• WAF: belirli web saldırı örüntülerine ek koruma ve görünürlük,
• uygulama: iş mantığı, yetki, veri/komut ayrımı,
• IDS/IPS: şüpheli davranışı tespit/engelleme,
• SIEM: olayları birleştirme ve korelasyon.

27. IDS/IPS, Snort, Suricata ve Wazuh: gördüğümüz şeyi anlamlandırmak

Önleme katmanlarının hiçbiri kusursuz değildir. Bu nedenle sistemin saldırı belirtilerini gözleyebilmesi gerekir.

Snort ve Suricata ağ trafiği üzerinde imza ve davranış temelli algılama sağlayabilir. Wazuh gibi platformlar uç nokta olaylarını, dosya bütünlüğünü, güvenlik loglarını, güvenlik açığı verilerini ve çeşitli alarm kaynaklarını merkezi değerlendirmeye taşıyabilir.

27.1 İmza ile gerçek olay arasındaki fark

Bir IDS kuralı pakette belirli örüntüyü gördüğünde alarm üretebilir. Fakat bu her zaman başarılı saldırı değildir. Aynı saldırı yükü savunmasız olmayan sürüme gitmiş olabilir; test ortamından gelmiş olabilir; saldırı denemesi uygulama tarafından reddedilmiş olabilir.

Tersine, yalnız bilinen imzaları aramak yeni veya değiştirilmiş davranışı kaçırabilir.

Bu nedenle güvenlik izleme üç bağlamı birleştirmelidir:

Ağ olayı
 + uygulama olayı
 + kimlik olayı
 + varlık bağlamı
 + zaman
 = daha anlamlı alarm

Örneğin aynı kaynaktan önce yüzlerce başarısız giriş, sonra başarılı giriş, ardından alışılmadık veri dışa aktarımı görülmesi tek tek üç normal log satırı gibi değerlendirilemez.

27.2 Yanlış pozitif ve yanlış negatif

Güvenlik operasyonunda çok alarm iyi algılama demek değildir. Sürekli yanlış alarm üreten kural, operatör tarafından zihinsel olarak kapatılır. Buna alarm yorgunluğu eşlik eder.

Bir kural şu metriklerle izlenebilir:

• günlük alarm sayısı,
• doğrulanan olay oranı,
• yanlış pozitif oranı,
• tespit süresi,
• müdahale süresi,
• kapsadığı saldırı tekniği,
• veri kaynağının güvenilirliği.

Tuning, alarmı susturmak değil sinyal/gürültü oranını iyileştirmektir.

27.3 MITRE ATT&CK ile görünürlük matrisi

MITRE ATT&CK'in güncel Enterprise matrisi saldırgan davranışlarını taktik ve teknikler altında sınıflandırır. ATT&CK v19.2, 28 Nisan 2026 itibarıyla güncel sürümdür. Bunu “bütün teknikleri engelleyelim” listesi olarak kullanmak yerine şu soruyu sormak daha değerlidir:

Bizim tehdit modelimizde muhtemel tekniklerin hangilerini görebiliyoruz?

Bir teknik için önleme mümkün olmayabilir ama güvenilir tespit olabilir. Bazı tekniklerde ise tespit yerine mimari olarak yolu kapatmak daha doğru olur.

28. Erişilebilirlik güvenliği: DoS/DDoS bir performans probleminden fazlasıdır

DoS ve DDoS çalışmalarında paket üretme araçları, SYN flood, UDP flood, amplification ve benzeri örnekler saldırının ağ davranışını anlamak için yararlıdır. Fakat modern uygulamada erişilebilirlik yalnız bant genişliği değildir.

Bir sistem şu kaynaklardan herhangi biri tükenerek hizmet dışı kalabilir:

• ağ bant genişliği,
• connection table,
• iş parçacığı (thread) veya event-loop kapasitesi,
• CPU,
• bellek,
• dosya descriptor,
• DB connection pool,
• sorgu kapasitesi,
• disk I/O,
• kuyruk (queue) backlog,
• üçüncü taraf API kotası,
• pahalı kriptografik işlem,
• log diski.

28.1 Uygulama katmanı DoS

Bir uç nokta tek istekle yüz milyon satırlık rapor üretiyorsa saldırganın milyonlarca paket göndermesine gerek yoktur. On pahalı istek yüz bin ucuz istekten daha etkili olabilir.

Bu nedenle hız sınırlama yalnız istek sayısına değil iş maliyetine göre düşünülmelidir. Arama sorgusuna maksimum zaman, sayfalama sınırı, dosya boyutu sınırı, concurrency bütçesi ve backpressure uygulanabilir.

28.2 Kuyruk her zaman dayanıklılık değildir

Mesaj kuyruğu ani yükü absorbe edebilir. Ancak üretim hızı tüketim hızından uzun süre yüksekse backlog büyür ve yalnız çöküş zamanını erteler. Little's Law gibi temel kuyruk teorisi güvenlikte de önemlidir: saldırgan sistemi kaynak tüketim rejimine sokabiliyorsa kapasite planı savunmanın parçasıdır.

28.3 DDoS savunmasında katmanlar

Yüksek hacimli ağ DDoS saldırısını yalnız uygulama sunucusunda çözmeye çalışmak mümkün olmayabilir. Upstream sağlayıcı, CDN/edge, scrubbing, hız sınırlama, SYN korumaları ve uygulama düzeyi maliyet kontrolü birlikte ele alınır.

Adli analiz açısından paket örnekleri, NetFlow/IPFIX benzeri akış verileri, load balancer logları ve uygulama metrikleri olayın tipini ve etkisini belirlemek için saklanmalıdır.

29. Mobil uygulama güvenliği: istemciyi düşman ortamda çalıştırmak

Mobil uygulama, kontrol ettiğimiz sunucunun uzantısı değildir. Kullanıcının cihazında çalışır; cihaz root/jailbreak olabilir, trafik proxy'lenebilir, binary analiz edilebilir ve çalışma zamanı (runtime) davranışı değiştirilebilir.

Bu nedenle şu kontroller sunucu tarafına ait kalmalıdır:

• yetkilendirme,
• fiyat ve kritik iş kuralı,
• hesap statüsü,
• işlem limiti,
• veri sahipliği,
• kritik bütünlük kararı.

29.1 Certificate pinning'in doğru yeri

Pinning bazı tehdit modellerinde MITM direncini yükseltebilir; özellikle yönetilen mobil uygulamalarda ek kontrol olarak değerlendirilebilir. Ancak sertifika/anahtar döndürme, acil durum, CDN ve işletim maliyeti oluşturur. Yanlış pinning servis kesintisine yol açabilir.

Güvenlik testinde pinning'in devre dışı bırakılabilmesi, uygulama protokolünün test edilmesine yardım eder. Buradan çıkarılacak savunma dersi “pinning kırılabiliyor, gereksiz” değildir. Asıl ders istemci üzerindeki kontrolün nihai güven sınırı olmadığıdır.

29.2 Yerel veri

Mobil cihazda şu veriler dikkatle ele alınmalıdır:

• access/yenileme belirteci,
• kullanıcı verisi önbelleği,
• loglar,
• SQLite veritabanı,
• indirilen dosyalar,
• clipboard,
• ekran görüntüleri,
• çökme dump,
• push notification içeriği.

Platformun güvenli saklama mekanizmaları kullanılmalı, gereksiz veri kalıcılığı azaltılmalıdır.

29.3 OWASP MASVS ile doğrulama kapsamı

Mobil uygulama güvenlik incelemesinde testlerin yalnız paket taraması veya sertifika denetimi etrafında kalmaması için OWASP MASVS kontrol grupları kullanılabilir. Depolama (MASVS-STORAGE), kriptografi (MASVS-CRYPTO), kimlik doğrulama (MASVS-AUTH), ağ (MASVS-NETWORK), platform etkileşimi (MASVS-PLATFORM), kod (MASVS-CODE), tersine mühendisliğe dayanıklılık (MASVS-RESILIENCE) ve gizlilik (MASVS-PRIVACY) ayrı doğrulama alanlarıdır. MASVS kontrol hedefini tanımlar; MASTG test yöntemi ve gözlenebilir kanıt üretimi için tamamlayıcı kaynaktır.

Örneğin cihazda oturum belirteci bulan bir test yalnız depolama kusurunu raporlamaz: belirtecin kapsamı, süresi ve sunucudaki iptal davranışı da doğrulanmalıdır. Trafiği değiştirerek yapılan test, TLS denetiminden ayrı olarak sunucunun yetkilendirme kararını sınar. Bulgular uygulama sürümü, cihaz/işletim sistemi, test önkoşulu, yeniden üretim adımları ve beklenen/gerçekleşen sonuçla ilişkilendirilirse kontrol listesi gerçek bir güvenlik doğrulamasına dönüşür.

30. Yazılım tedarik zinciri: sizin yazmadığınız kod da sizin saldırı yüzeyinizdir

Modern uygulamaların büyük bölümü üçüncü taraf kütüphanelerden oluşur. Güvenlik açığı artık yalnız kendi kaynak kodunuzda bulunmaz; bağımlılık, derleme eklentisi, konteyner temel imajı, CI eylemi, paket deposu veya derleme altyapısı üzerinden gelebilir.

OWASP Top 10:2025'te Software Supply Chain Failures'ın A03 olarak yer alması bu değişimin önemini gösterir.

30.1 Bağımlılık envanteri

“Log4j kullanıyor muyuz?” sorusuna hızlı cevap veremeyen ekip, güvenlik açığı duyurulduğunda saatler veya günler kaybeder. SBOM bu nedenle yararlıdır. Fakat SBOM üretip hiç kullanmamak güvenlik değildir.

Envanter şu bilgileri mümkün olduğunca taşımalıdır:

• paket adı ve sürüm,
• kaynağı,
• doğrudan/dolaylı bağımlılık,
• hash veya bütünlük bilgisi,
• lisans,
• kullanıldığı artefakt,
• destek/yaşam döngüsü durumu.

30.2 Dependency confusion ve paket kaynağı

Kurumsal paket adı dış registry'de saldırgan tarafından yayımlanabiliyor ve derleme sistemi yanlış kaynağı tercih ediyorsa aynı isimdeki paket tedarik zincirine girebilir. Paket yöneticisi yapılandırması, namespace kontrolü, özel registry kullanımı ve lockfile/integrity doğrulaması bu nedenle önemlidir.

30.3 Derleme ortamı kritik varlıktır

CI/CD sistemi üretime yazılım gönderebiliyorsa üretim yetkisine sahiptir. Derleme çalıştırıcısı, imzalama anahtarı, dağıtım belirteci ve kaynak kodu deposu yetkileri kritik kimlik materyalidir.

Güvenli zincirde:

Kaynak
  -> gözden geçirilmiş değişiklik
  -> kontrollü bağımlılıklar
  -> izole derleme
  -> test
  -> SBOM/provenance
  -> imzalı artefakt
  -> doğrulanan dağıtım

Artefakt'ın hangi commit'ten, hangi bağımlılıklarla ve hangi derleme ortamında üretildiğini kanıtlayabilmek olay müdahalesinde de değerlidir.

31. CI/CD güvenliği: otomasyonun yetkisi insanı geçebilir

CI/CD işlem hattı genellikle kaynak kodu okuyabilir, secret kullanabilir, artefakt yayımlayabilir ve üretime dağıtabilir. Bu nedenle “yardımcı araç” değil ayrı bir güven alanıdır.

31.1 Pull istek güven sınırı

Dış katkı veya güvenilmeyen branch kodu, secret erişimi olan runner üzerinde otomatik çalıştırılmamalıdır. Derleme betiğinin kendisi koddur; saldırgan test dosyasına bile secret exfiltration davranışı ekleyebilir.

31.2 Sırlar kısa ömürlü olmalı

Mümkün olduğunda statik uzun ömürlü cloud/API anahtarları yerine workload identity ve kısa ömürlü kimlik bilgisi kullanılmalıdır. Bu, sızıntı penceresini küçültür ve döndürmeyi kolaylaştırır.

31.3 Güvenlik kapıları

İşlem hattına her tarayıcıyı eklemek kalite sağlamaz. Gürültülü ve bağlamsız araç geliştiricinin güvenlik bulgularını görmezden gelmesine neden olur.

Daha iyi politika:

• yeni kritik/yüksek bulguda derlemeyi durdur,
• mevcut teknik borcu ayrı baseline ile izle,
• secret sızıntısını kesin hata yap,
• dependency riskinde istismar edilebilirlik ve çalışma bağlamını değerlendir,
• artefakt bütünlüğünü dağıtım öncesi doğrula,
• yanlış pozitif için kayıtlı ve süreli istisna kullan.

Ünite 5: Güvenlik Testi, Olay Müdahalesi ve Adli Bilişim

32. Güvenlik testi: tek araç hiçbir zaman yeterli değildir

Statik analiz, dinamik analiz, dependency taraması, fuzzing ve sızma testi aynı şeyi yapmaz. Birinin bulamadığını diğerinin bulması beklenir.

• Kod inceleme: Güçlü olduğu alan: İş mantığı, bağlam, tasarım niyeti; Kör noktası: İnsan zamanı, kapsam.
• SAST: Güçlü olduğu alan: Kaynakta tehlikeli veri akışları, örüntüler; Kör noktası: Yanlış pozitif, çalışma zamanı bağlamı.
• DAST: Güçlü olduğu alan: Çalışan uygulamanın dış davranışı; Kör noktası: Kodun tamamını göremez.
• SCA: Güçlü olduğu alan: Bilinen bağımlılık açıkları; Kör noktası: Özel kod ve yanlış kullanım.
• Fuzzing: Güçlü olduğu alan: Ayrıştırıcı, bellek ve beklenmeyen girdi hataları; Kör noktası: Doğru harness/oracle gerektirir.
• Sızma testi: Güçlü olduğu alan: Zincirleme, iş mantığı, gerçek saldırgan bakışı; Kör noktası: Zamanla sınırlı örnekleme.
• Yapılandırma denetimi: Güçlü olduğu alan: Güvenlik ayarları, sıkılaştırma; Kör noktası: Uygulama mantığı.

32.1 SAST çıktısını doğrulamak

Statik analiz bir fonksiyona SQL Injection etiketi koyduğunda bunu otomatik gerçek açık kabul etmek kadar “araç hep yanlış söylüyor” diyerek kapatmak da hatalıdır. Veri kaynağından sink'e kadar akış incelenmelidir. Parametre binding gerçekten kullanılıyor mu? Dinamik query parçası var mı? İzin listesi doğru mu?

32.2 DAST ve Burp Suite

Proxy tabanlı web testi HTTP'nin gerçek hâlini görünür kılar. UI'nin göndermediği alan eklenebilir, ID değiştirilebilir, method değiştirilebilir, header kaldırılabilir. Bu deneyim yazılım geliştirici için önemlidir; istemci kontrollerinin güvenlik sınırı olmadığını elle gösterir.

Testin hedefi yalnız saldırı yükü çalıştırmak değildir. Sistematik olarak authn, authz, validation, state transition, hata davranışı ve concurrency incelenmelidir.

32.3 Fuzzing

Fuzzing özellikle native ayrıştırıcı, dosya biçimi, protokol ve karmaşık veri dönüştürücülerde değerlidir. Rastgele byte üretmekten daha fazlasıdır; coverage-guided fuzzing programın yeni yollarına ulaşan girdileri seçerek arama uzayını etkili kullanabilir.

Çökme bulunduğunda süreç bitmez:

1. tekrar üretilebilir mi?
2. en küçük girdiye indirgenebilir mi?
3. memory sanitizer ne gösteriyor?
4. attacker-controlled hangi veri hangi yapıyı bozuyor?
5. güvenlik etkisi var mı?
6. aynı kök neden başka ayrıştırıcı yollarında var mı?

Bir çökmeyi yalnız patch'lemek yerine hata sınıfını kapatmak daha değerlidir.

33. Sızma testi: taramadan farklı bir mühendislik faaliyeti

Zafiyet tarayıcısı bilinen problemleri ölçekli biçimde bulur. Sızma testi ise saldırgan gibi düşünerek kontrollerin birbirine nasıl bağlandığını inceler.

İyi bir test akışı şu disipline sahiptir:

Kapsam
 -> pasif keşif
 -> aktif keşif
 -> saldırı yüzeyi
 -> güvenlik açığı hipotezi
 -> kontrollü doğrulama
 -> yetki yükseltme olasılığı
 -> yanal hareket olasılığı
 -> etki doğrulaması
 -> kanıt
 -> temizleme
 -> kök neden
 -> düzeltme
 -> yeniden test

“İstismar başarılı” tek başına rapor değildir. Hangi önkoşul gerekti, hangi kontrol eksikti, saldırgan ne elde etti, gerçek iş etkisi neydi, nasıl tespit edilebilirdi ve kök neden nasıl kapatılacak soruları cevaplanmalıdır.

33.1 Metasploit'in doğru öğretim değeri

Metasploit hızlı doğrulama için güçlü bir çerçevedir; fakat modül çalıştırmayı bilmek güvenlik açığını anlamakla aynı değildir. En yararlı yaklaşım, modülün ne yaptığını protokol ve hedef davranışıyla birlikte okumaktır.

Bir istismar şu zinciri izliyorsa:

hedef sürümü tanı
 -> özel isteği oluştur
 -> bellek/logic hatasını tetikle
 -> kontrol elde et
 -> saldırı yükü çalıştır

savunma her adımı farklı yerde kesebilir. Sürüm yükseltmek kök açığı kapatabilir; WAF belirli isteği geçici olarak engelleyebilir; process sandbox etkiyi azaltabilir; EDR post-istismaration davranışını görebilir. Hangisinin kalıcı, hangisinin telafi edici kontrol olduğunu ayırmak gerekir.

34. Sosyal mühendislik: insanı “en zayıf halka” diye suçlamak yetmez

Kevin Mitnick'in sosyal mühendislik örneklerinin kalıcı tarafı belirli telefon senaryoları değildir. İnsanların otorite, aciliyet, yardım etme isteği, merak ve alışkanlık üzerinden karar vermesidir.

“İnsan en zayıf halkadır” cümlesi çoğu zaman tasarım sorumluluğunu kullanıcıya atar. Daha doğru soru şudur: bir insanın tek yanlış kararı ne kadar etki yaratabiliyor?

Bir kullanıcı oltalama sayfasına parola girdiğinde phishing-resistant MFA saldırıyı kesebilir. Yardım masası telefonla MFA'yı kaldırabiliyorsa teknik kontrol dolanılabilir. Yönetici kullanıcısı günlük e-postasını yüksek ayrıcalıklı hesapla okuyorsa oltalamanın etkisi büyür.

34.1 Süreç de güvenlik kontrolüdür

Özellikle şu işlemler sosyal mühendisliğe dayanıklı tasarlanmalıdır:

• parola/MFA sıfırlama,
• yeni cihaz kaydı,
• ayrıcalıklı grup üyeliği,
• para veya hassas veri transferi,
• uzaktan erişim açma,
• üçüncü taraf kullanıcı oluşturma,
• acil durum istisnaları.

Kimlik doğrulama sorularının cevabı internette bulunabiliyorsa güvenlik sorusu değildir. “Müdür istedi” tek başına yetki kanıtı değildir. Kritik işlemde bağımsız ikinci kanal veya ikinci onay insan hatasının etkisini azaltır.

34.2 Güvenlik farkındalığı ölçülmelidir

Yılda bir kez sunum izletmek güvenlik programı değildir. Eğitim, iş rolüne göre gerçek davranışa dönüşmelidir. Oltalama simülasyonu yalnız “kim tıkladı?” metriğine indirgenirse korku üretir. Daha yararlı metrikler:

• şüpheli mesajı raporlama süresi,
• doğru kanala raporlama oranı,
• yardım masasının kimlik doğrulama prosedürüne uyumu,
• ayrıcalıklı kullanıcıların güvenli istemci kullanımı,
• olaydan sonra aynı hata sınıfının tekrarı.

Amaç kullanıcıyı sınamak değil, sistemin insan hatasına dayanıklılığını geliştirmektir.

35. Loglama: olaydan sonra “keşke kaydetseydik” dememek

Güvenlik logu uygulamanın hata ayıklama logundan farklıdır. Hata ayıklama log geliştiriciye hata ayıklamada yardımcı olur; güvenlik logu bir güvenlik kararının, kimlik olayının veya önemli durum değişikliğinin denetlenebilir kaydını tutar.

35.1 Neyi kaydetmeli?

Bağlama göre şu olaylar değerlidir:

• başarılı/başarısız kimlik doğrulama,
• MFA kayıt ve sıfırlama,
• parola değişimi,
• ayrıcalık değişimi,
• kullanıcı/servis hesabı oluşturma ve kapatma,
• kritik veri okuma/yazma/silme,
• yetkilendirme reddi,
• yönetim işlemleri,
• güvenlik ayarı değişiklikleri,
• belirteç/anahtar yaşam döngüsü olayları,
• dosya yükleme ve indirme,
• toplu export,
• rate limit tetiklenmesi,
• beklenmeyen ayrıştırıcı veya doğrulama hataları.

Log olayında en az zaman, aktör, kaynak, işlem, hedef, sonuç ve korelasyon kimliği bulunması çoğu analizi kolaylaştırır.

35.2 Neyi kaydetmemeli?

• parola,
• tam oturum belirteç,
• özel anahtar,
• kredi kartı gibi gereksiz hassas veri,
• kullanıcı tarafından girilen sırlar,
• bütün istek body'yi körlemesine.

Log enjeksiyonu da düşünülmelidir. Kullanıcı girdisi newline veya kontrol karakteriyle log biçimini bozmamalı; yapılandırılmış log kullanımı analizi kolaylaştırır.

35.3 Zaman senkronizasyonu

Dağıtık sistemde olay sırasını kurmak için saatlerin tutarlı olması gerekir. Adli incelemede birkaç dakikalık sapma bile farklı sistemlerden gelen olayları yanlış sıraya sokabilir. NTP/kurumsal zaman kaynağı, log mimarisinin sessiz ama kritik bileşenidir.

36. Olay müdahalesi: saldırı olduğunda ilk kez düşünmeye başlamamak

Güvenlik açığı yönetimi saldırı öncesini, olay müdahalesi saldırı anı ve sonrasını yönetir. Plan üretimde olay yaşandığında ilk kez yazılıyorsa geç kalınmıştır.

NIST CSF 2.0'ın Govern, Identify, Protect, Detect, Respond ve Recover fonksiyonları bu sürekliliği iyi ifade eder.

36.1 Hazırlık

Olaydan önce bilinmesi gerekenler:

• kritik sistem sahipleri,
• iletişim zinciri,
• log ve kanıt kaynakları,
• izolasyon yetkisi,
• hesap/anahtar iptal mekanizması,
• yedek ve geri yükleme yöntemi,
• hukuki/kurumsal bildirim gereksinimleri,
• olay sınıflandırması,
• temiz sistem kurulum kaynağı.

36.2 Tespit ve doğrulama

Her IDS alarmı olay değildir. Fakat “yanlış pozitiftir” varsayımıyla kapatmak da risklidir. Alarmın varlık bağlamı, kullanıcı davranışı ve diğer loglarla korelasyonu yapılır.

36.3 Sınırlama

Containment saldırganın yayılmasını durdurur. Ağ izolasyonu, hesabın devre dışı bırakılması, belirteç iptali, anahtar döndürme veya servis erişiminin sınırlandırılması gerekebilir.

Burada kritik karar delili korumak ile operasyonu sürdürmek arasındadır. Körlemesine sunucuyu kapatmak volatil bellekteki önemli kanıtı kaybettirebilir; sistemi açık bırakmak saldırganın ilerlemesine izin verebilir. Olay türüne göre playbook gerekir.

36.4 Temizleme ve kurtarma

Saldırganın bıraktığı dosyayı silmek yeterli olmayabilir. Kalıcılık mekanizması, yeni hesap, scheduled task, servis, SSH key, OAuth consent, GPO değişikliği veya başka bir arka kapı bulunabilir.

Güvenilir kurtarma, bilinen temiz durumdan yeniden kurulum gerektirebilir. “Antivirüs temizledi” ifadesi her olay için yeterli güvence değildir.

36.5 Kök neden

Olay kapatıldıktan sonra en değerli soru “hangi IP saldırdı?” olmayabilir. Şunlar daha kalıcı sonuç üretir:

• saldırgan ilk erişimi nasıl aldı?
• neden bu erişim kritik varlığa ulaşabildi?
• hangi kontrol çalışmadı?
• hangi log eksikti?
• benzer zayıflık başka sistemlerde var mı?
• süreç hangi değişikliği yapmalı?

Aynı olay sınıfı tekrar ediyorsa yalnız IOC temizlenmiştir; sistem öğrenmemiştir.

37. Adli bilişim: kanıtın güvenilirliğini korumak

Adli bilişim güvenlik olayının yalnız “ne oldu?” sorusuna değil, ne zaman, hangi sıra ile, hangi kanıtla sorularına cevap verir.

37.1 Volatil ve kalıcı veri

Olay sırasında bazı bilgiler sistem kapanınca kaybolabilir:

• çalışan süreçler,
• ağ bağlantıları,
• memory-resident kimlik bilgisi veya artefakt,
• geçici dosya sistemi bilgileri,
• process memory.

Disk, log, registry, dosya sistemi metadata'sı ve merkezi kayıtlar daha kalıcı olabilir. Toplama sırası olay bağlamına göre belirlenmelidir.

37.2 Bütünlük

Kanıt kopyalanırken hash alınması ve zincirleme teslim kayıtlarının tutulması, sonradan verinin değişmediğini göstermek için önemlidir. İnceleme orijinal kanıt üzerinde yapılmamalı; mümkün olduğunda doğrulanmış kopyalar kullanılmalıdır.

Bu disiplin yalnız hukuki süreç için değil teknik güvenilirlik için de değerlidir. “Bu dosya saldırgan bıraktı” diyebilmek için olay müdahalesi sırasında analistin dosyayı kendisinin üretmediğini gösterebilmesi gerekir.

37.3 Uygulama geliştiricinin adli bilişime katkısı

Geliştirici log tasarımını yaparken ileride olay analizi yapılacağını düşünmelidir. İstek korelasyon kimliği, kullanıcı/servis kimliği, güvenlik kararı sonucu ve veri değişikliği kimliği olay zincirini kurmayı kolaylaştırır.

Aşırı log da çözüm değildir; kişisel veri, sır ve yüksek hacimli gürültü hem risk hem maliyet üretir. Amaç sonradan anlamlı soruları cevaplayacak kadar kanıt bırakmaktır.

38. Güvenlik açığı yönetimi: tarama sonucu yaşam döngüsünün başlangıcıdır

Bir CVE bulunduğunda ilk refleks “patch var mı?” olabilir. Fakat büyük ortamlarda önceliklendirme gerekir.

Bir bulgu için şu kayıt yararlıdır:

Varlık
Bileşen / sürüm
CVE / CWE
Maruziyet
İstismar önkoşulu
Aktif istismar bilgisi
İş etkisi
Mevcut kontroller
Önerilen kalıcı düzeltme
Geçici azaltım
Sorumlu
Hedef tarih
Yeniden test sonucu

38.1 Yalnız versiyon eşleşmesi yetmez

SCA aracının vulnerable sürüm bulması, açık kod yolunun uygulamada erişilebilir olduğunu her zaman göstermez. Tersi de önemlidir: “şu anda reachable değil” kararı, gelecekte kod yolu değiştiğinde geçersiz olabilir. Bu nedenle en iyi çözüm mümkün olduğunda güncellemektir; reachability bilgisi önceliklendirme için kullanılır.

38.2 Güvenlik borcu

Bir bulgu için “risk kabul edildi” demek onu yok etmez. Kabul kararı süreli olmalı, sahibi olmalı ve hangi telafi edici kontrole dayandığı yazılmalıdır. Son kullanma tarihi olmayan istisna güvenlik politikasının kalıcı deliğine dönüşür.

39. Güvenlik yanlış yapılandırmaları: kod doğru, sistem yine açık

OWASP Top 10:2025'te Security Misconfiguration'ın ikinci sırada bulunması, güvenlik açığının yalnız kaynak kodu olmadığını hatırlatır.

Yaygın örnekler:

• varsayılan hesaplar,
• hata ayıklama modunun açık olması,
• directory listing,
• gereksiz HTTP method'ları,
• ayrıntılı stack trace,
• herkese açık yönetim arayüzü,
• geniş CORS,
• bulut/storage public erişimi,
• gereksiz servisler,
• zayıf TLS yapılandırması,
• test anahtarının üretimde kullanılması,
• örnek uç nokta veya actuator/management yüzeyinin korunmaması.

Configuration as Code burada avantaj sağlar: ayarlar gözden geçirilebilir, sürümlenebilir ve otomatik test edilebilir. Ancak secret'ları aynı repository'ye koymak çözüm değildir.

Ünite 6: Güvenlik Mühendisliği, Protokoller ve Modern Altyapı

40. Güvenlik ve performans birbirinin düşmanı olmak zorunda değildir

Kritik ve yüksek trafikli sistemlerde güvenlik kontrolü tasarlarken gecikme, işlem hacmi (throughput) ve kaynak tüketimi göz ardı edilirse ekip sonunda kontrolü kapatmaya yönelir. Bu yüzden güvenlik mekanizması da performans mühendisliği ister.

40.1 Parola hash maliyeti

Argon2id maliyeti ne kadar yüksekse o kadar iyi değildir. Kimlik doğrulama servisinin kapasitesi ölçülmeden aşırı parametre seçmek meşru kullanıcılar için DoS vektörü oluşturabilir. Hedef, saldırganın çevrimdışı tahmin maliyetini artırırken meşru çevrimiçi doğrulamanın kapasitesini yönetmektir.

40.2 Belirteç doğrulama mimarisi

Her istekte yetkilendirme sunucusuna senkron belirteç introspection çağrısı yapmak merkezi servisi darboğaza dönüştürebilir. İmzalı JWT ile yerel doğrulama gecikme (latency) ve bağımlılığı azaltır; karşılığında iptal ve yetki değişikliğinin yayılma süresi gibi problemler oluşur.

Burada güvenlik–performans değiş tokuşu ölçülmelidir:

• belirteç ömrü,
• key rotation,
• revocation gereksinimi,
• önbellek (cache),
• kritik işlemde yeniden doğrulama,
• audience daraltma.

40.3 Loglama

Her istek body'yi senkron diske yazmak performans ve gizlilik problemi yaratır. Yapılandırılmış, sınırlı güvenlik olayları; uygun buffer/kuyruk; backpressure politikası ve log kaybı davranışı açık tasarlanmalıdır.

Güvenlik kontrolü sistemin çalışma modeline uymazsa kâğıt üzerinde kalır.

41. Güvenlik ve kullanılabilirlik: kullanıcıyı kontrolü aşmaya zorlamamak

İnsanların tahmin edilebilir davranışları yalnız saldırı değil tasarım girdisidir. Çok karmaşık parola kuralları parolanın yazılmasına veya tekrar kullanılmasına neden olabilir. Her işlemde gereksiz MFA istemek kullanıcıyı onay bildirimlerine duyarsızlaştırabilir. Aşırı kısa oturum süresi çalışma akışını bozup güvensiz workaround üretebilir.

Güvenli tasarımın hedefi kullanıcıyı cezalandırmak değildir. CISA'nın Secure by Design yaklaşımındaki “müşteri güvenlik yükünü tek başına taşımamalı” ilkesi burada da geçerlidir.

En iyi kontrol mümkün olduğunca:

• varsayılan açık,
• anlaşılır,
• iş akışına uygun,
• güvenli hata veren,
• kullanıcının güvenliği kapatmasını gerektirmeyen

bir davranış üretir.

42. Kod incelemede saldırgan gibi okumak

Güvenlik kod incelemesi yalnız eval, exec, string query veya hardcoded password aramak değildir. Kodun güven varsayımlarını okumaktır.

Bir uç nokta incelerken şu sıra etkilidir:

Girdi nereden geliyor?
 -> kimlik nasıl kuruluyor?
 -> yetki nerede kontrol ediliyor?
 -> veri normalize/doğrulanıyor mu?
 -> hangi yorumlayıcıya gidiyor?
 -> hangi kaynağı tüketiyor?
 -> hangi sır/yetkiyle işlem yapıyor?
 -> hata yolunda ne oluyor?
 -> olay nasıl loglanıyor?

Bu yöntem dil ve uygulama çerçevesinden bağımsızdır.

42.1 Tehlikeli kolaylıklar

Uygulama çerçeveleri güvenlik yükünü azaltır; yanlış kullanımda ise açığı standartlaştırabilir. Şunlar özellikle dikkat ister:

• entity'yi doğrudan istek body'ye bind etmek,
• joker karakterli CORS,
• CSRF'yi nedenini anlamadan kapatmak,
• TLS doğrulamasını test için devre dışı bırakıp unutmak,
• template'e raw HTML vermek,
• query string birleştirmek,
• object deserialization'ı geniş tiplerle açmak,
• dosya yolunu kullanıcı girdisinden üretmek,
• yetkilendirmeyi controller/UI seviyesinde bırakmak.

Güvenli uygulama çerçevesi kullanımı, varsayılan güvenlik mekanizmasını koruyup yalnız gerekçeli yerde değiştirmektir.

43. Spring Security'yi güvenlik ilkelerinin uygulaması olarak okumak

Spring Security eğitimlerinde filtre zinciri, SecurityFilterChain, kimlik doğrulama sağlayıcısı, kullanıcı ayrıntıları, CSRF, CORS, OAuth 2 ve yöntem düzeyi güvenlik gibi başlıklar ayrı ayrı öğrenilir. Üretim tasarımında bunların her birini daha temel soruya bağlamak gerekir.

• Kimlik doğrulama: kimlik hangi kanıta dayanıyor?
• Security context: doğrulanmış kimlik istek yaşam döngüsünde nasıl taşınıyor?
• Yetkilendirme: karar hangi kaynak ve işlem üzerinde veriliyor?
• Filter chain: güvenlik kararı uygulama kodundan önce hangi sırada uygulanıyor?
• CSRF: tarayıcının otomatik kimlik bilgisi gönderimi hangi saldırı yolunu açıyor?
• OAuth 2/OIDC: kimlik ve yetki farklı sistemler arasında nasıl aktarılıyor?
• JWT: kaynak sunucu assertion'ın bütünlüğünü ve kapsamını nasıl doğruluyor?

Sürüm bağımlı API'leri ezberlemek yerine bu model öğrenildiğinde uygulama çerçevesi değişse bile güvenlik mantığı korunur.

43.1 Güvenlik testleri regresyon testidir

Bir uç nokta için yetkilendirme testi yazılmadıysa yeniden düzenleme sırasında güvenlik kuralının kaybolması fark edilmeyebilir. Pozitif test kadar negatif test önemlidir:

ADMIN -> 200
USER  -> 403
Anonim -> 401
Başka kullanıcıya ait nesne -> 403/404 tasarımına göre

Aynı davranış method security, uç nokta kuralı ve alan yetkilendirmesi katmanlarında uygun testlerle korunmalıdır.

44. Hata ve istisna yönetimi: olağan dışı yol da tasarımın parçasıdır

Birçok sistem “happy path” üzerinde güvenlidir. Beklenmeyen durumda ise gizli ayrıntı döndürür, yetki kontrolünü atlar veya transaction'ı yarım bırakır.

OWASP Top 10:2025'in A10 kategorisi olan Mishandling of Exceptional Conditions bu alanı görünür kılar.

44.1 Ayrıştırıcı başarısızlığı

Geçersiz JSON, aşırı derin nesne, dev sayı, bozuk Unicode, çok büyük multipart veya beklenmeyen content type sistemin davranışını değiştirebilir. Ayrıştırıcı limitleri açık olmalıdır.

44.2 Transaction bütünlüğü

Kritik işlem üç adım yapıyor ve ikinci adım hata veriyorsa ilk adım geri alınacak mı? Dağıtık sistemde yeniden deneme (retry) aynı işlemi iki kez üretebilir mi? Idempotency güvenlik açısından da önemlidir; ödeme, kota, yetki değişimi gibi işlemlerde tekrar gönderim saldırı veya veri bütünlüğü problemine dönüşebilir.

44.3 Error oracle

“Bu kullanıcı yok”, “parola yanlış”, “MFA cihazı bulunamadı” gibi ayrıntılar saldırgana hesap keşfi yaptırabilir. Her durumda tamamen aynı cevap vermek de kullanılabilirliği bozabilir. Tehdit modeline göre dış cevap ile iç log ayrılır.

45. DNS güvenliği: isim çözümleme bir güvenlik bağımlılığıdır

DNS çoğu mimari diyagramda ince bir okla geçilir; gerçekte uygulamanın kime bağlanacağını belirleyen temel altyapılardan biridir. DNS yanıtı yanlışsa TLS gibi üst katman kontrolleri doğru yapılandırılmadığı sürece istemci yanlış sisteme yönlenebilir. İç ağda DNS ayrıca Active Directory, servis keşfi ve çok sayıda yönetim işlevinin parçasıdır.

45.1 Zone transfer ve gereksiz envanter ifşası

Yetkisiz zone transfer, saldırgana alt alan adlarının ve host adlarının toplu listesini verebilir. Modern DNS sunucusunda transfer yalnız yetkili ikincil sunuculara sınırlandırılmalıdır. Buradaki ders yalnız AXFR değildir: yönetim işlevi ile genel hizmet aynı erişim modelini paylaşmamalıdır.

Bir DNS kaydının kendisi hassas olmayabilir; fakat vpn, dev, jenkins, backup, db, old-admin gibi adlar saldırı yüzeyinin keşif maliyetini düşürür. İsimlendirme güvenlik kontrolü değildir, fakat kullanılmayan kaydı kaldırmak saldırı yüzeyi yönetimidir.

45.2 DNS spoofing ve önbellek poisoning

DNS önbellek poisoning tarihsel olarak transaction ID ve kaynak port öngörülebilirliği gibi zayıflıklardan yararlandı. Modern resolver'lar daha güçlü rastgelelik ve ek korumalar kullanır; DNSSEC uygun senaryoda veri bütünlüğü ve kaynak doğrulaması sağlar. Fakat DNSSEC, DNS trafiğinin gizliliğini sağlamaz ve uygulama katmanındaki TLS doğrulamasının yerine geçmez.

Savunma katmanları:

• güvenilir ve güncel resolver,
• gereksiz recursion'ın dışarı kapatılması,
• zone transfer kısıtı,
• DNSSEC'in uygun alanlarda kullanımı,
• istemci–sunucu TLS kimlik doğrulaması,
• anormal DNS davranışının izlenmesi,
• iç ve dış DNS rolünün ayrılması gereken ortamlarda split-horizon tasarımının kontrollü uygulanması.

45.3 DNS aynı zamanda tespit kaynağıdır

Zararlı yazılımlar ve komuta-kontrol altyapıları sıklıkla DNS kullanır. Olağandışı uzun alt alan adları, yeni görülen domain'ler, yüksek hata oranı, domain generation algorithm davranışları veya normal iş profilinden sapan sorgular tespit sinyali olabilir.

Burada yine tek başına gösterge yeterli değildir. Yeni bir CDN veya telemetry servisi de benzer örüntü üretebilir. DNS logu varlık ve süreç bağlamıyla ilişkilendirildiğinde anlam kazanır.

46. ARP, MITM ve kablosuz ağ: yerel ağ da güvenilir değildir

Eski beyaz şapkalı hacker eğitimlerinde ARP spoofing/poisoning ve kablosuz ağ trafiği yakalama örnekleri, yerel ağdaki temel bir varsayımı çok net biçimde kırar: aynı LAN'da olmak kimlik kanıtı değildir.

ARP, IPv4 yerel ağında IP adresini MAC adresine eşlemek için tasarlanmıştır; güçlü kimlik doğrulama sağlamaz. Saldırgan uygun konumdaysa sahte ARP cevaplarıyla trafiği kendi üzerinden geçirmeye çalışabilir. Üst katmanda TLS doğru uygulanmışsa içeriğin okunması zorlaşır; sertifika doğrulaması kapatılmışsa veya kullanıcı yanlış sertifikayı kabul ediyorsa saldırı etkisi büyür.

46.1 “İç ağ güvenli” varsayımını kaldırmak

Yerel ağ saldırılarının savunma açısından en önemli sonucu, hizmet kimliğinin ağ konumuna bağlanmamasıdır. Bir istek kurumsal IP'den geliyor diye yetkili sayılmamalıdır. Yönetim arayüzünü yalnız iç ağa açmak yararlı bir katmandır fakat kimlik doğrulamanın yerine geçmez.

Ağ anahtarlarında DHCP snooping, Dynamic ARP Inspection, port security ve uygun segmentasyon gibi kontroller belirli ortamlarda yararlı olabilir. Yine de uçtan uca protokol kimlik doğrulaması korunmalıdır.

46.2 Kablosuz güvenlik

WEP tarihsel açıdan önemlidir çünkü kriptografik tasarım hatalarının pratikte nasıl hızlı kırılabildiğini gösterir; güncel sistemlerde kullanılmamalıdır. WPA/WPA2/WPA3 ailesinde güvenlik, mod ve yapılandırmaya bağlıdır. Kişisel ağlarda zayıf PSK çevrimdışı tahmin riskini büyütebilir. Kurumsal 802.1X/EAP dağıtımlarında istemcinin RADIUS sunucu sertifikasını doğru doğrulamaması evil-twin senaryolarını kolaylaştırabilir.

Kablosuz güvenlikte şu ilkeler daha kalıcıdır:

• eski ve kırılmış protokolleri kapatmak,
• güçlü ve benzersiz kimlik bilgisi,
• kurumsal kimlik doğrulamada sunucu sertifikasını doğrulamak,
• misafir ağını kurumsal ağdan ayırmak,
• istemci izolasyonunu ihtiyaca göre kullanmak,
• erişim noktası envanteri ve rogue AP tespiti,
• yönetim düzlemini kullanıcı trafiğinden ayırmak.

Deauthentication gibi yönetim çerçevelerinin kötüye kullanımı, 802.11w/Protected Management Frames gibi mekanizmaların neden ortaya çıktığını açıklar. Araç ve saldırı adından çok, kimlik doğrulanmamış yönetim mesajının erişilebilirliği etkileyebilmesi tasarım dersidir.

46.3 VPN bir güven seviyesi değil taşıma kanalıdır

VPN bağlantısı kuruldu diye istemci güvenilir hâle gelmez. VPN, belirli ağlar arasında güvenli kanal ve erişim yolu sağlayabilir; ancak ele geçirilmiş istemci aynı tüneli saldırgan adına kullanabilir. Bu nedenle VPN sonrası da cihaz durumu, kullanıcı kimliği, segmentasyon ve uygulama yetkisi değerlendirilmelidir.

47. Zararlı yazılım, rootkit ve ransomware: saldırganın kalıcılık ve etki mühendisliği

Zararlı yazılım konusu çok geniştir. Virüs, worm, trojan, rootkit, bot, downloader, information stealer ve ransomware farklı davranışlara sahip olabilir. Savunma açısından isimden daha kullanışlı yaklaşım saldırganın yaşam döngüsünü incelemektir:

İlk erişim
 -> çalıştırma
 -> kalıcılık
 -> ayrıcalık yükseltme
 -> savunmadan kaçınma
 -> kimlik bilgisi erişimi
 -> keşif
 -> yanal hareket
 -> veri toplama / dışarı çıkarma
 -> etki

Bu akış MITRE ATT&CK taktikleriyle de uyumludur.

47.1 Trojan bize güven zincirini öğretir

Kullanıcı beklediği uygulama yerine içine zararlı davranış eklenmiş bir programı çalıştırıyorsa sorun yalnız antivirüs değildir. Yazılımın kaynağı ve bütünlüğü doğrulanmamıştır. Kod imzası, güvenilir dağıtım kanalı, izin listesiing ve tedarik zinciri kontrolleri bu nedenle değerlidir.

47.2 Rootkit ve görünürlük problemi

Rootkit'in savunmadaki ana fikri, gözlem aracının kendisi ele geçirilmiş sistemin içinde çalışıyorsa gerçeği göremeyebileceğidir. Kernel veya düşük seviye bileşen değiştirilmişse ps, dosya listeleme veya yerel loglara kör güven duyulamaz.

Bu nedenle kritik ortamlarda merkezi/uzak loglama, ağ telemetry'si, bütünlük kontrolü, secure boot/ölçümlü boot gibi mekanizmalar ve güvenilir yeniden kurulum kaynağı önemlidir.

47.3 Ransomware yalnız şifreleme değildir

Modern ransomware operasyonları çoğu zaman şifreleme öncesinde kimlik bilgisi toplama, yanal hareket, yedekleri devre dışı bırakma ve veri dışarı çıkarma içerir. “Yedeğimiz var” tek başına savunma değildir.

Dayanıklı tasarım için:

• ayrıcalık alanlarını ayırmak,
• yönetici hesabını günlük işte kullanmamak,
• yanal hareket yollarını azaltmak,
• kritik yedekleri saldırganın normal domain yetkilerinden ayırmak,
• geri yüklemeyi düzenli test etmek,
• anormal toplu dosya değişikliği ve kimlik davranışını tespit etmek,
• kritik servisler için yeniden kurulum planı oluşturmak

gerekir.

Ransomware olayında bir makineyi temizlemek yerine saldırganın kimlik sisteminde hangi yetkilere ulaştığını anlamak belirleyicidir.

48. E-posta ve oltalama: kimlik sistemine açılan sosyal protokol

Oltalama teknik olarak bir web sayfası veya e-posta problemi gibi görünür; aslında kimlik doğrulama, insan davranışı, e-posta altyapısı ve süreç güvenliğinin kesişimidir.

48.1 Teknik e-posta doğrulama

SPF, DKIM ve DMARC gönderen alanın kötüye kullanımını azaltmak için birlikte kullanılabilir. Hiçbiri kullanıcıyı her oltalama mesajından korumaz; benzer yazılmış domain, ele geçirilmiş gerçek hesap veya üçüncü taraf servis üzerinden gelen kötü amaçlı mesaj hâlâ mümkündür.

Bu yüzden e-posta güvenliği şu katmanları birleştirir:

• gönderen alan politikaları,
• bağlantı ve ek analizi,
• makro/aktif içerik kısıtları,
• sandbox gereksinimi,
• kullanıcı raporlama mekanizması,
• phishing-resistant MFA,
• ayrıcalıklı hesapların e-posta kullanımından ayrılması,
• olay korelasyonu.

48.2 Oltalamanın başarısı sonrası ne oluyor?

Bir çalışan parola girdiyse olay yalnız “kullanıcı hata yaptı” diye kapanmamalıdır. Şunlar kontrol edilir:

• parola başka sistemlerde tekrar kullanılmış mı?
• MFA faktörü ele geçirilmiş mi?
• oturum belirteç oluşturulmuş mu?
• OAuth consent verilmiş mi?
• mailbox forwarding rule eklenmiş mi?
• yeni kimlik doğrulayıcı kaydedilmiş mi?
• aynı kimlikle VPN veya kurumsal uygulama erişimi yapılmış mı?

Kimlik olayını yalnız parola değiştirerek kapatmak kalıcılık yollarını kaçırabilir.

49. OSINT ve güvenlik tarayıcıları: ne kadar görünür olduğumuzu ölçmek

Google hacking/dorking, arama motorlarının özel sorgu operatörleriyle internete yanlışlıkla açılmış içeriği bulma yaklaşımıdır. Bugün aynı düşünce yalnız Google ile sınırlı değildir. Kod depoları, certificate transparency, internet ölçüm servisleri, paket registry'leri, arşiv siteleri ve veri ihlali kaynakları saldırganın pasif keşif yüzeyidir.

Savunma açısından düzenli external attack surface management yapılmalıdır. Amaç “arama motorundan gizlenmek” değil, internet üzerinden erişilebilir olmaması gereken varlığın gerçekten erişilebilir olup olmadığını görmektir.

49.1 Nmap, Nessus/OpenVAS/Nikto benzeri araçların sınırı

Tarayıcıların en büyük avantajı tekrarlanabilir ve geniş kapsamlı olmalarıdır. Yanlış sürüm, açık port, bilinen CVE veya belirli web yanlış yapılandırmalarını hızlı bulabilirler.

Fakat tarayıcı şu soruları her zaman cevaplayamaz:

• bu kullanıcı başka tenant'ın verisini okuyabilir mi?
• iş akışındaki onay adımı atlanabilir mi?
• iki orta seviye bulgu birleşince kritik yol oluşuyor mu?
• özel kriptografik protokol yanlış mı tasarlanmış?
• uygulama yanlış güven sınırına mı dayanıyor?

Bu nedenle “Nessus temiz çıktı, sistem güvenli” çıkarımı hatalıdır.

49.2 Kimlik doğrulamalı tarama

İşletim sistemi ve sunucu güvenlik açığı taramasında kimlik doğrulamalı tarama, yalnız dış banner'a bakmaktan daha doğru envanter sağlayabilir. Ancak tarayıcı hesabının kendisi yüksek yetkili sır olduğundan erişimi, saklanması ve rotasyonu güvenli olmalıdır.

50. OAuth 2, OpenID Connect ve SAML: kimlik ile yetkiyi protokole dökmek

OAuth 2 bir yetkilendirme çerçevesidir; kullanıcının parolasını üçüncü taraf uygulamaya vermeden belirli kaynağa sınırlı erişim devri sağlar. OpenID Connect (OIDC), OAuth 2 üzerine kimlik katmanı ekler. SAML ise özellikle kurumsal federasyon ve SSO dünyasında XML tabanlı assertion modeliyle yaygındır.

Bu ayrımı bilmemek ciddi tasarım hatalarına yol açar. Erişim belirtecini “kullanıcının kimlik kartı” diye her yerde kullanmak, ID belirtecini API yetkilendirme belirteci gibi kabul etmek veya belirtecin yalnız varlığına bakmak doğru değildir.

50.1 OAuth 2 akışında güven sınırları

Modern web/mobil istemcilerde Authorization Code + PKCE yaygın ve güvenli temel akıştır. İstemci türü, sır saklayabilme yeteneği ve redirect URI güvenliği dikkate alınır.

Kaynak sunucu şunları doğrulamalıdır:

• belirteç güvenilen issuer'dan mı?
• bu API için mi verilmiş (aud)?
• süresi geçerli mi?
• gereken scope/authority var mı?
• signature güvenilen anahtarla doğrulanıyor mu?

scope uygulamanın bütün alan yetkilendirmesini ifade etmek zorunda değildir. “documents.read” yetkisine sahip kullanıcının her belgeyi okuyabileceği sonucu çıkmaz; nesne sahipliği ayrıca değerlendirilir.

50.2 Redirect URI

OAuth/OIDC tasarımında redirect URI geniş joker karakterli ile kabul edilirse yetkilendirme kodu veya belirteç saldırganın kontrol ettiği adrese yönlendirilebilir. Redirect hedefleri önceden kayıtlı ve mümkün olduğunca kesin eşleşmeli olmalıdır.

50.3 PKCE neden vardır?

Public client, gömülü client secret'ı güvenilir biçimde saklayamaz. PKCE, yetkilendirme isteği ile belirteç değişimini aynı istemci örneğine bağlamak için tek kullanımlık verifier/challenge modeli sağlar. Mobil uygulamaya sabit secret gömmek PKCE'nin yerine geçmez.

50.4 SAML ve XML güvenliği

SAML assertion'ın imza doğrulaması, issuer, audience, recipient, süre ve replay koşulları doğru değerlendirilmelidir. XML Signature Wrapping gibi tarihsel açıklar, “XML imzalıysa güvenlidir” varsayımının yetersiz olduğunu göstermiştir; uygulama doğrulanan düğüm ile işlediği düğümün aynı olduğundan emin olmalıdır.

Federasyon protokollerinde çoğu kritik hata kriptografik algoritmadan değil assertion'ın hangi bağlamda geçerli olduğunun eksik doğrulanmasından doğar.

51. XML, XXE, LFI/RFI ve template injection: ayrıştırıcı özelliklerini saldırı yüzeyi saymak

Ayrıştırıcı'lar kolaylık için güçlü özellikler sunar. Güvenilmeyen içerikte bu özellikler beklenmeyen dosya, ağ veya kod erişimine dönüşebilir.

51.1 XXE

XML External Entity saldırılarında ayrıştırıcı dış entity çözümlemeye izin veriyorsa uygulama yerel dosya veya ağ kaynağı okuyabilir. Güvenli yaklaşım ihtiyaç yoksa DTD/external entity özelliklerini kapatmaktır. Sadece saldırı yükü filtrelemek ayrıştırıcının bütün sözdizimini öngörmeye çalışır.

XXE, SSRF ile de birleşebilir. Ayrıştırıcı'ın dış kaynağa bağlanabilmesi sunucunun ağ konumunu kullanır. Bu yüzden ayrıştırıcı sıkılaştırma ve egress kısıtı birlikte değerlidir.

51.2 LFI/RFI ve include semantiği

Local File Inclusion ve Remote File Inclusion tarihsel olarak özellikle dinamik dosya include eden uygulamalarda görülmüştür. Kök neden, kullanıcı girdisinin çalıştırılacak veya okunacak kaynağı belirlemesine izin verilmesidir.

Modern tasarımda route veya template seçimi kullanıcı dosya adıyla yapılmamalı; izin verilen kaynaklar kod içindeki sabit eşlemeyle seçilmelidir:

"home"    -> templates/home
"profile" -> templates/profile
"report"  -> templates/report

Kullanıcının ../../... veya URL üretebildiği serbest kaynak seçimi gereksizdir.

51.3 Server-Side Template Injection

Template motoru kullanıcı girdisini yalnız veri olarak değil template kodu olarak derliyorsa SSTI oluşabilir. “Kullanıcı kendi şablonunu yazsın” iş gereksinimi varsa sandbox gerçekten güvenlik sınırı mıdır, hangi fonksiyonlara ve nesnelere erişilebilir soruları ayrıca incelenmelidir.

İdeal durumda güvenilmeyen kullanıcı yalnız değişken değerlerini sağlar; çalıştırılabilir template yapısını belirlemez.

52. Yarış durumları ve TOCTOU: doğru kontrol yanlış zamanda yapıldığında

Güvenlik kontrollerinin yalnız varlığı değil zamanı da önemlidir. Time-of-check to time-of-use (TOCTOU) hatasında bir kaynak kontrol edildikten sonra kullanılmadan önce değişebilir.

Basit örnek:

1. Dosya yolunun güvenli olduğunu kontrol et
2. Başka işlem symlink'i değiştirir
3. Dosyayı aç

Kontrol edilen nesne ile kullanılan nesne aynı olmayabilir.

52.1 İş mantığında yarış

yarış durumu (Race condition) yalnız native dosya sistemi problemi değildir. Web uygulamalarında:

• bakiye kontrolü sonrası iki eşzamanlı çekim,
• tek kullanımlık kuponun paralel kullanımı,
• kota kontrolü sonrası paralel kaynak oluşturma,
• “yalnız bir kez onayla” işleminin iki kez çalışması,
• belirteç iptali ile kullanım arasındaki yarış

güvenlik veya veri bütünlüğü sorununa dönüşebilir.

52.2 Çözüm mutex eklemekten ibaret değildir

Dağıtık sistemde uygulama içi mutex yalnız tek süreçte çalışır. Çözüm işlemin doğasına göre DB transaction/locking, unique constraint, compare-and-set, idempotency key, atomik datastore işlemi veya doğru seri hale getirme olabilir.

Güvenlik testi concurrency içermezse normal sırada doğru çalışan iş kuralı yarışta kırılabilir.

53. Konteyner, Kubernetes ve bulut: izolasyonu güven sınırı sanmamak

Konteyner uygulamayı paketleme ve izolasyon için güçlü araçtır; sanal makineyle aynı güven modeli değildir. Host kernel paylaşılır. --privileged, hostPath, geniş capability, Docker socket veya aşırı Kubernetes RBAC yetkileri izolasyonu önemli ölçüde zayıflatabilir.

53.1 Konteyner imajı

İmaj güvenliği şunları içerir:

• küçük ve kontrollü base image,
• gereksiz paketleri kaldırma,
• root olmayan kullanıcı,
• secret'ı image katmanına koymama,
• digest ile sabitleme gereken yerler,
• bilinen güvenlik açığı taraması,
• imza/provenance,
• read-only filesystem gereksinimi.

Çok aşamalı derleme, son imajdaki derleme araçlarını azaltarak saldırı yüzeyini küçültebilir.

53.2 Kubernetes

Kubernetes'te güvenlik hataları çoğu zaman orkestratörün güçlü yeteneklerinin gereğinden geniş verilmesinden doğar:

• cluster-admin servis hesabı,
• varsayılan servis hesabı belirtecine gereksiz erişim,
• geniş NetworkPolicy,
• secret'ların kontrolsüz kullanımı,
• privileged pod,
• host namespace erişimi,
• admission kontrolünün eksikliği.

Namespace tek başına güçlü tenant güvenlik sınırı sayılmamalıdır. Çok kiracılı ortamın tehdit modeli ayrıca tasarlanmalıdır.

53.3 Bulut kimliği

Bulutta klasik “iç ağ” kavramından çok IAM belirleyici hâle gelir. Fazla yetkili rol, public object storage veya sızmış access key büyük etki yaratabilir. Metadata servisine SSRF de bu nedenle tehlikelidir: uygulamanın instance/workload kimliğine erişim yolu açabilir.

Uzun ömürlü access key yerine workload identity/managed identity gibi kısa ömürlü mekanizmalar tercih edilmelidir. Denetim logları merkezi ve değiştirilmeye karşı korumalı tutulmalıdır.

53.4 Azure/AD grafının genişlemesi

BloodHound/AzureHound türü çalışmalar hibrit kimlik ortamında on-premises AD ile bulut kimliği arasındaki ilişkilerin de saldırı yolu oluşturabileceğini gösterir. Bir kullanıcı doğrudan yüksek yetkili olmayabilir; grup, uygulama kaydı, service principal, role assignment veya secret üzerinden kritik kaynağa yol bulunabilir.

Savunma burada yine graf düşüncesine döner: kritik varlığa ulaşabilen dolaylı kimlik yollarını periyodik çıkarmak gerekir.

54. Honeypot ve aldatma: saldırganın davranışından erken sinyal üretmek

Honeypot normal iş akışında kullanılmaması gereken fakat saldırgan etkileşimini gözlemek için tasarlanan sistem veya kaynaktır. Honeynet daha geniş kontrollü ortamı ifade eder. Doğru kullanıldığında yüksek sinyal/gürültü oranı sağlayabilir: kimsenin erişmemesi gereken bir kimlik bilgisi veya paylaşım kullanıldıysa bu güçlü göstergedir.

Ancak honeypot savunmanın yerine geçmez. Kötü izole edilmiş yüksek etkileşimli honeypot saldırganın başka sistemlere sıçrama noktası olabilir. Hukuki, mahremiyet ve veri toplama gereksinimleri de değerlendirilmelidir.

Daha hafif deception örnekleri:

• honey kimlik bilgisi,
• normalde kullanılmayan izlenen dosya,
• sahte yönetim kaynağı,
• decoy servis hesabı,
• erişilmemesi gereken özel paylaşım.

Bu kaynakların değeri “saldırganı kandırmak” kadar, normal kullanıcının üretmeyeceği davranışı yüksek güvenle alarm hâline getirmesidir.

Ünite 7: Güvenli Kılma, Değerlendirme ve Sonuç

55. Güvenli tasarım ilkelerini kısa kurallara indirgemek

Bazı ilkeler araçlardan daha kalıcıdır:

1. Güvenilmeyen veriyi komutla birleştirmeyin.
2. Kimliği doğrulamak yetki vermek değildir.
3. İstemci güven sınırı değildir.
4. En az ayrıcalık tek açığın etkisini küçültür.
5. Güvenli varsayılan, dokümantasyondaki güvenlik tavsiyesinden güçlüdür.
6. Sır saklanan yerde değil kullanıldığı bütün yaşam döngüsünde korunur.
7. Kriptografi anahtar yönetimi kadar güçlüdür.
8. Gözleyemediğiniz saldırıya güvenilir biçimde müdahale edemezsiniz.
9. Yedek geri yüklenmedikçe yedek değildir.
10. Tarama bulgu üretir; risk analizi öncelik üretir.
11. Sızma testi kontrolün varlığını değil gerçekten çalışıp çalışmadığını sınar.
12. Aynı güvenlik açığı tekrar ediyorsa süreç hatası vardır.
13. İç ağ güvenilir kabul edilmez; her sınırın kendi kimlik ve yetki modeli vardır.
14. Bir hata kaçacakmış gibi tasarlayın; etki alanını sınırlayın.
15. Savunma saldırı zincirindeki yolları kesmelidir, yalnız göstergeleri saklamamalıdır.

Bunlar slogan olarak değil tasarım inceleme sorusu olarak kullanılmalıdır.

56. Uygulamalı güvenli kılma algoritması

Şimdi bütün parçaları tek süreçte birleştirebiliriz. Yeni veya mevcut bir projeyi güvenli kılarken aşağıdaki sıra pratikte iyi sonuç verir.

Adım 1 — Varlığı belirle

Sistemin ne yaptığını ve hangi veri/işlevin kritik olduğunu yazın. Varlık bilinmeden risk konuşmayın.

Çıktı: varlık ve veri sınıflandırma listesi.

Adım 2 — Gerçek saldırı yüzeyini çıkar

Kod deposundan mimari diyagramı alın ama onunla yetinmeyin. DNS, port, API, sertifika, mobil istemci, üçüncü taraf ve yönetim yüzeylerini doğrulayın.

Çıktı: doğrulanmış envanter ve veri akış diyagramı.

Adım 3 — Güven sınırlarını çiz

İstemci–sunucu, servis–servis, uygulama–DB, kurum–üçüncü taraf, normal kullanıcı–yönetici ve geliştirme–üretim sınırlarını işaretleyin.

Çıktı: hangi sınırda hangi kimlik ve kontrolün gerektiği.

Adım 4 — Tehditleri üret

STRIDE, attack tree, abuse case ve MITRE ATT&CK bilgisiyle sistem bağlamına uygun yolları çıkarın.

Çıktı: test edilebilir tehdit senaryoları.

Adım 5 — Mimariyle yolları kapat

En az ayrıcalık, segmentasyon, güvenli varsayılan, trust minimization, görev ayrılığı ve egress kontrolünü koddan önce uygulayın.

Çıktı: bir hata oluşsa bile sınırlı etki.

Adım 6 — Kimlik ve yetkiyi merkezî ilkelere bağla

Kimlik doğrulama yaşam döngüsünü, MFA/kurtarma yolunu, servis kimliklerini ve nesne düzeyi yetkilendirmeyi tanımlayın.

Çıktı: “kim, neye, hangi koşulda?” sorusunun tek ve test edilebilir cevabı.

Adım 7 — Veri ile komut arasına sert sınır koy

Parametreli sorgu, güvenli process API, context-aware output encoding, dar ayrıştırıcı şeması, dosya yolunun bağımsız üretilmesi gibi yapıları kullanın.

Çıktı: enjeksiyon sınıflarının kökten daraltılması.

Adım 8 — Sır ve kriptografiyi yaşam döngüsüyle yönet

Üretim, saklama, erişim, döndürme, iptal ve yok etmeyi birlikte tasarlayın.

Çıktı: sızıntının fark edilebilir ve yönetilebilir olması.

Adım 9 — Çalışma ortamını kısıtla

Servis kullanıcısı, dosya izinleri, capability, container/systemd sıkılaştırma, ağ politikası ve DB yetkilerini küçültün.

Çıktı: RCE veya kimlik bilgisi sızıntısının etki alanının düşmesi.

Adım 10 — Tedarik zincirini doğrula

Bağımlılıkları, temel imajları, CI çalıştırıcılarını, sırları, artefaktları ve dağıtım yetkilerini envantere alın. SBOM ve provenance üretin.

Çıktı: “bu binary nereden geldi?” sorusuna kanıtlı cevap.

Adım 11 — Otomatik ve manuel testleri birleştir

SAST, SCA, DAST, fuzzing, configuration test, unit/integration security test ve sızma testini farklı hata sınıfları için kullanın.

Çıktı: tek aracın kör noktasına bağımlı olmayan doğrulama.

Adım 12 — Sisteme saldır

Yetkili laboratuvar veya tanımlı sızma testi kapsamında en gerçekçi saldırı yollarını deneyin. UI'yi değil protokolü test edin; tek açığı değil zinciri düşünün.

Çıktı: kontrolün teorik değil gerçek davranışı.

Adım 13 — Görünürlük üret

Önemli güvenlik kararlarını loglayın, ağ/host/application telemetry'yi ilişkilendirin, anlamlı alarmlar oluşturun.

Çıktı: başarısız olmayan ama fark edilen saldırı.

Adım 14 — Olayı prova et

Hesap ele geçirilmesi, ransomware, belirteç sızıntısı veya web RCE senaryosu seçin. Kim karar veriyor, hangi sistemi izole ediyor, hangi anahtarı döndürüyor, hangi kanıtı topluyor test edin.

Çıktı: kâğıt üzerindeki IR planının gerçek kapasiteye dönüşmesi.

Adım 15 — Kök nedeni sisteme geri besle

Bulgunun yalnız örneğini değil sınıfını kapatın. Güvenli library, lint kuralı, reusable component, mimari kural veya test üreterek aynı hatanın tekrarını zorlaştırın.

Çıktı: her olaydan sonra daha düşük tekrar olasılığı.

57. Son CTF: Bayrağa giden yolu kapatmak

Başlangıçtaki sistemi yeniden ele alalım. İlk sürümde şu kusurlar bulunsun:

• hata ayıklama uç nokta internete açık,
• hata mesajı kullanıcı adlarını ifşa ediyor,
• zayıf parola politikası var,
• MFA yok,
• API nesne sahipliğini kontrol etmiyor,
• arama sorgusu string birleştiriyor,
• uygulama DB hesabı şema sahibi,
• dosya indirme yolu kullanıcı girdisinden oluşuyor,
• servis root çalışıyor,
• iç ağa sınırsız çıkış yapabiliyor,
• servis hesabı AD'de gereğinden fazla yetkili,
• loglar korelasyon kimliği taşımıyor,
• CI statik dağıtım belirteç kullanıyor.

Saldırgan ilk bayrağa ulaşmak için tek açığa bağlı değildir:

Bilgi sızıntısı
 -> hesap keşfi
 -> parola püskürtme
 -> kullanıcı hesabı
 -> IDOR
 -> servis yapılandırması
 -> servis kimlik bilgisi
 -> AD saldırı yolu
 -> ayrıcalık yükseltme
 -> kritik veri
 -> BAYRAK

Başka yol:

SQL injection
 -> DB sahibinin yetkileri
 -> kritik veri değişikliği
 -> BAYRAK

Başka yol:

Dosya yükleme / ayrıştırıcı açığı
 -> RCE
 -> root süreç
 -> iç ağa sınırsız erişim
 -> yanal hareket
 -> BAYRAK

Şimdi savunma kararlarını yerleştirelim.

Hata ayıklama uç noktası kaldırıldığında keşif kolaylığı azalır ama sistem güvenli değildir. Parola politikasını ve MFA'yı düzelttiğimizde hesap yolu daralır ama yetkilendirme açığı hâlâ vardır. Nesne düzeyi yetkilendirme IDOR'u kapatır. Parametreli sorgu SQL injection yolunu keser. En az ayrıcalıklı DB hesabı gelecekteki bilinmeyen bir DB açığının etkisini küçültür. Dosya işleme sandbox'ı ve root olmayan servis RCE'nin etkisini azaltır. Egress kısıtı iç ağa sıçramayı zorlaştırır. AD grafındaki gereksiz grup/ACL yollarını temizlemek ele geçirilmiş servis hesabının değerini düşürür. SIEM korelasyonu başarısız girişlerden yanal harekete kadar zinciri görünür kılar.

Sonunda “hiç açık yok” iddiasında bulunmayız. Böyle bir iddia ölçülemez. Daha güçlü bir ifade kullanırız:

Bilinen saldırı yüzeyi çıkarıldı; kritik varlığa giden tehdit yolları modellendi; öncelikli yollar bağımsız güvenlik kontrolleriyle kesildi; bu kontroller otomatik ve manuel testlerle doğrulandı; kalan riskler kayıtlı; tespit ve olay müdahale yolları prova edildi.

Bayrağı böyle koruruz.

58. Güvenlik değerlendirme matrisi

Bir projeyi kısa sürede gözden geçirirken aşağıdaki matris ilk geçiş için kullanılabilir. Bu bir standardın yerini tutmaz; araştırılacak alanı hızla görünür kılar.

• Envanter: Tüm internet yüzeyi, servisler, API'ler ve bağımlılıklar biliniyor mu?
• Veri: Hassas veri sınıflandırılmış, saklama süresi ve erişim modeli belirli mi?
• Tehdit modeli: Güven sınırları ve kritik saldırı yolları çıkarılmış mı?
• Kimlik: Güncel parola/MFA/kurtarma politikası var mı?
• Yetki: Sunucu tarafında nesne ve işlem düzeyi yetkilendirme yapılıyor mu?
• Oturum: Belirteç/çerez yaşam döngüsü, süre, iptal ve güvenli taşıma doğru mu?
• Enjeksiyon: Yorumlayıcı sınırlarında veri ve komut ayrılıyor mu?
• XSS: Bağlama uygun çıktı kodlama ve güvenli DOM kullanımı var mı?
• CSRF/CORS: Tarayıcı güven modeli doğru anlaşılmış ve dar politika uygulanmış mı?
• SSRF: Sunucu çıkışları ve hedef URL davranışı sınırlandırılmış mı?
• Dosya: Yol, tür, boyut, saklama ve servis etme güvenliği var mı?
• Kriptografi: Standart algoritmalar, doğru key management ve rotation var mı?
• Sırlar: Kod/repo/log dışında, denetimli sır yönetiminde mi?
• DB: Parametreli sorgu, en az ayrıcalık, ağ sınırı ve yedek güvenliği var mı?
• İşletim sistemi: Root olmayan süreç, az servis, sıkı izin ve güncel yamalar var mı?
• AD: Ayrıcalıklı yollar, servis hesapları, Kerberos/NTLM riskleri izleniyor mu?
• Ağ: Segmentasyon ve egress kontrolü gerçek veri akışıyla uyumlu mu?
• Tedarik zinciri: SCA, SBOM, güvenilir paket deposu, derleme köken bilgisi ve imza var mı?
• CI/CD: Runner ve dağıtım kimlikleri en az ayrıcalıklı ve kısa ömürlü mü?
• Test: SAST/DAST/SCA/fuzzing/manual test birlikte kullanılıyor mu?
• Loglama: Güvenlik olayları korele edilebilir ama sır içermeyecek şekilde loglanıyor mu?
• Algılama: Kritik ATT&CK davranışları için görünürlük var mı?
• IR: İzolasyon, kimlik bilgisi rotation ve recovery playbook'ları test edildi mi?
• Yedek: Geri yükleme düzenli ve güvenli biçimde doğrulanıyor mu?
• İnsan: Kritik süreçler sosyal mühendisliğe tek adımlı açık bırakılmış mı?

59. Olgunluk: güvenlik açığı sayısından daha anlamlı göstergeler

Bir güvenlik programının başarısını yalnız “kaç açık kapattık?” ile ölçmek yanıltıcıdır. Tarama kapsamını artırdığınızda açık sayısı artabilir; bu güvenliğin kötüleştiğini değil görünürlüğün arttığını gösterebilir.

Daha anlamlı metrikler bağlama göre şunlar olabilir:

• kritik varlıkların envanter kapsama oranı,
• threat model yapılmış kritik akış oranı,
• güvenlik gereksinimi bulunan özellik oranı,
• kritik/yüksek bulgunun ortalama kapatılma süresi,
• aynı CWE sınıfının tekrar oranı,
• privileged account sayısı ve trendi,
• uzun ömürlü secret sayısı,
• MFA/phishing-resistant kimlik doğrulayıcı kapsaması,
• log kaynağı kapsaması,
• mean time to detect / respond,
• yedek geri yükleme başarısı,
• attack path sayısı veya kritik path uzunluğu,
• security test işlem hattı başarısızlıklarının türü,
• süreli risk kabulünün zamanında yeniden değerlendirilme oranı.

Metrik davranışı değiştirdiği için dikkatle seçilmelidir. Ekibi “bulgu sayısını azaltmakla” ödüllendirirseniz tarama kapsamı küçülebilir. Hedef gerçek riski azaltmaktır.

Eyleme Dönük Tanılama ile Bilgi Sızdırma Arasındaki Sınır

Güvenli hata yönetiminde iki kötü uç vardır. Birincisi, her problemi “beklenmeyen hata” gibi anlamsız bir mesaja indirgemektir. İkincisi ise stack trace, SQL, sürücü mesajı, dosya yolu veya sunucu bilgisi gibi iç ayrıntıları kullanıcıya taşımaktır. Güvenli tasarım bu iki uç arasında, sorunu çözmeye yetecek kadar bilgi veren fakat saldırı yüzeyini büyütmeyen bir katman kurar.

Aynı hata üç görünürlük seviyesinde ele alınabilir:

Kullanıcı yüzeyi
  -> güvenli kaynak, neden ve çözüm

Yetkili teknik tanılama
  -> sınırlı ek bağlam ve hata referansı

Sunucu günlüğü
  -> gerçek exception zinciri ve teknik ayrıntı

Örneğin veritabanı bağlantısı kurulamıyorsa kullanıcıya ham Oracle veya JDBC mesajı göstermek gerekmez. “Veritabanına şu anda erişilemiyor; sorun devam ederse hata referansını teknik birime iletin” ifadesi operasyonel olarak yeterli olabilir. Buna karşılık sunucu günlüğünde gerçek istisna zincirinin bulunması gerekir. Bu ayrım, Web Uygulamalarında UI/UX Mühendisliği notunda ele alınan kendi kendini açıklayan hata deneyiminin güvenlik sınırıdır.

Hata kodu ile korelasyon referansı da aynı şey değildir. Hata kodu, tekrar eden ve anlamı kararlı bir hata türünü temsil eder. Korelasyon referansı ise belirli bir olayın teknik günlüklerde bulunmasını sağlar. Kullanıcı aynı hata kodunu farklı zamanlarda görebilir; her olayın referansı farklı olabilir.

hata kodu -> problem sınıfı
referans  -> belirli olay

Korelasyon değeri kullanıcı kimliği, birim, sunucu adı veya başka hassas bilgi taşımamalıdır. Rastgele ve yeterli çakışma direncine sahip kısa bir değer destek sürecini kolaylaştırır; aynı değer kullanıcı ekranında ve teknik günlükte yer alır.

Gözlemlenebilirlik kanalının arızalanan bileşene tek başına bağımlı olmaması da önemlidir. Bir veritabanı arızasının tek kaydını aynı veritabanındaki hata tablosuna yazmaya çalışmak, en gerekli anda tanılama bilgisini de kaybettirebilir. Kritik altyapı hataları için uygulama veya işletim sistemi düzeyinde bağımsız bir teknik günlük yolu bulunması bu nedenle daha dayanıklıdır.

Hata kaynağını doğru adlandırmak bilgi güvenliği açısından da önemlidir. Kullanıcı girdisinin yanlış olması ile arayüzün hatalı istek üretmesi aynı şey değildir. Yetki reddi ile kaydın varlığını açık etmek de aynı şey değildir. Güvenli tanılama, daha fazla bilgi vermek değil doğru soyutlama seviyesinde doğru bilgiyi vermektir. Bu ayrımın doğrulanması Yazılım Test Mühendisliği kapsamındaki negatif yol ve yetki testleriyle birlikte ele alınmalıdır.

Tehdit modelini doğrulanabilir güvenlik gereksinimine çevirmek

Tehdit modeli yalnız saldırı listesi üretirse tasarıma yön vermez. Her anlamlı tehdit, test edilebilir bir güvenlik gereksinimine bağlanmalıdır. "Yetkisiz erişim engellenecek" yerine hangi özne, hangi kaynak ve hangi koşulda erişememeli sorusu açıklaştırılmalıdır.

Örneğin "normal kullanıcı başka kullanıcının raporunu okuyamaz" gereksinimi; API yetkilendirme testi, doğrudan nesne kimliği değiştirme denemesi ve log doğrulamasıyla sınanabilir. Böylece tehdit modeli, güvenlik test planının girdisi olur.

Residual risk de kaydedilmelidir. Bir risk teknik olarak tamamen ortadan kaldırılamıyorsa olasılık/etki, algılama mekanizması ve olay anındaki müdahale yolu tanımlanır. Bu yaklaşım güvenliği tek seferlik penetration test yerine yaşam döngüsü boyunca izlenen mühendislik niteliğine dönüştürür.

Güvenlik iddiasını tehdit modeliyle sınırlamak

“Güvenli” tek başına ölçülebilir bir özellik değildir. Korunan varlık, saldırgan yeteneği, güven sınırı ve kabul edilen risk tanımlanmadan bir kontrolün yeterli olduğu söylenemez.

Güvenlik kanıtı farklı katmanlardan gelir: tasarım incelemesi, statik/dinamik analiz, yetkilendirme testleri, bağımlılık ve yapılandırma denetimi, olay kaydı ve gerektiğinde sızma testi. Bir aracın “temiz” sonucu diğer katmanlardaki hataları dışlamaz.

Düzeltme önerisi saldırı örneğini kapatmanın ötesine geçmelidir. Kök neden veri modelinde, yetki sınırında veya yorumlayıcıya güvenilmeyen veri taşımakta ise aynı sınıf hatanın başka biçimlerde tekrar etmesini önleyen kontrol tercih edilir.

Öğrenen ve Üretken Sistemlerde Güven Sınırları

Bir uygulamaya üretken model eklemek mevcut güven sınırlarını ortadan kaldırmaz; yeni sınırlar ve veri akışları ekler. Özellikle belge erişimi, araç çağrısı veya kurumsal veri kullanan sistemlerde modelin ürettiği metin ile yetkili uygulama işlemi aynı şey değildir.

Basitleştirilmiş akış:

kullanıcı girdisi
      ↓
model
      ↓
getirilen bağlam
      ↓
araç / fonksiyon
      ↓
korunan kaynak

Bu zincirde her ok ayrı bir doğrulama noktasıdır. Kullanıcının modele bir talimat yazabilmesi, modelin erişebildiği bütün verilere veya araçlara kullanıcının da yetkili olduğu anlamına gelmez.

Prompt injection ve dolaylı prompt injection

Prompt injection, güvenilmeyen girdinin model talimatlarını amaç dışına yönlendirmeye çalışmasıdır. Saldırı doğrudan kullanıcı girdisinden gelebileceği gibi modelin okuduğu belge, web sayfası, e-posta veya arama sonucuna gömülmüş talimattan da gelebilir. İkinci durum dolaylı prompt injection olarak değerlendirilir.

Bu nedenle getirilen içerik için temel kural şudur:

bilgi kaynağı ≠ talimat otoritesi

Bir RAG sistemi belgeyi bağlama eklediğinde belgenin içeriği güvenilir bir komuta dönüşmez. Model ve uygulama, güvenilmeyen veri ile sistem talimatı arasındaki sınırı korumalıdır. İstem tasarımı ve şablon sınırları İstem Mühendisliği notunda ayrı ele alınır.

Araç yetkisi ve en az ayrıcalık

Bir modelin fonksiyon çağırabilmesi, model çıktısına doğrudan yetki verilmesi anlamına gelmemelidir. Her araç çağrısında kullanıcı kimliği, nesne kapsamı ve işlem yetkisi uygulama katmanında yeniden doğrulanmalıdır.

model önerir
uygulama doğrular
politika yetkilendirir
araç uygular

Modelin yalnız görev için gereken araçları görmesi ve araçların da yalnız gereken veri kapsamına erişmesi en az ayrıcalık ilkesinin doğal uzantısıdır. Yüksek etkili silme, ödeme, yetki verme veya dış sisteme veri gönderme gibi işlemler ayrıca açık kullanıcı onayı gerektirebilir. İnsan onayı faydalı bir kontrol olsa da yetkilendirmenin yerine geçmez.

Kod, dosya ve çıktı sınırı

Model tarafından üretilen kod, sorgu, dosya adı veya komut güvenilir kabul edilmemelidir. Kod çalıştırma gerekiyorsa kaynak, ağ, dosya sistemi ve işlem yetkileri sınırlandırılmış bir çalışma alanı kullanılmalıdır. Model çıktısı başka bir yorumlayıcıya aktarılıyorsa o yorumlayıcının enjeksiyon kuralları ayrıca geçerlidir.

Aynı ilke dosya yükleme ve belge işleme için de geçerlidir. Dosya türü, boyut, ayrıştırıcı davranışı ve arşiv içeriği uygulama sınırında doğrulanmalıdır.

Gizlilik, günlükleme ve model tedarik zinciri

Prompt, getirilen içerik ve model çıktısı otomatik olarak güvenli günlük verisi değildir. Kişisel veri, erişim belirteci, kurumsal sır veya başka hassas içerik kayda girebilir. Günlükleme amacı, saklama süresi ve maskeleme politikası veri sınıfına göre belirlenmelidir.

Model ağırlıkları, belirteçleyici (tokenizer), çalışma zamanı, eklenti ve model dönüştürme araçları da yazılım tedarik zincirinin parçalarıdır. Kaynağı bilinmeyen model kontrol noktası (checkpoint) veya kod, yalnız “model dosyası” olduğu için güvenilir kabul edilmemelidir. Bütünlük doğrulaması, güvenilir kaynak ve sürüm takibi klasik bağımlılık yönetimindeki kadar önemlidir.

Yapay zeka uygulamasındaki güvenlik problemi modelin tek başına “güvenli” olup olmadığı değildir. Güvenilir sistem; modelin hata yapabileceğini, yönlendirilebileceğini ve güvenilmeyen veri okuyabileceğini varsayarak veri, araç ve yetki sınırlarını model dışındaki deterministik kontrollerle korur. Genel yapay zeka yetenekleri ve sınırları Yapay Zeka: Felsefe, Kuram ve Uygulama notunda daha geniş çerçevede ele alınır.

Model yaşam döngüsü de saldırı yüzeyidir

Klasik uygulamada saldırı yüzeyi çoğunlukla kod, protokol ve yapılandırma üzerinden düşünülür. Öğrenen sistemde eğitim verisi, model artifact'i, değerlendirme kümesi ve model güncelleme kanalı da güven sınırına girer. Veri poisoning, model dosyasının değiştirilmesi veya güvensiz deserialization gibi riskler aynı yaşam döngüsünün farklı aşamalarındadır.

veri → eğitim / seçim → model artifact → dağıtım → inference

Her aşamanın bütünlüğü ayrı doğrulanmalıdır. Modelin checksum veya imzası dosyanın değişmediğini gösterebilir; modelin doğru veriyle eğitildiğini veya göreve uygun olduğunu göstermez.

Kestirim modelleri ile üretken model saldırılarını ayırmak

Evasion ve poisoning gibi adversarial machine learning problemleri, prompt injection ile aynı saldırı sınıfı değildir. Kestirim modelinde saldırgan girdiyi karar sınırını aşacak biçimde değiştirmeye çalışabilir; üretken modelde ise doğal dil içeriği talimat hiyerarşisini etkilemeye çalışabilir. Ortak nokta güvenilmeyen girdidir, savunma mekanizması ise modele ve tehdide göre değişir.

Güvenlik metriği model metriğinden ayrıdır

Yüksek doğruluk (accuracy), F1 veya düşük kayıp (loss) bir güvenlik özelliği değildir. Güvenlik değerlendirmesi saldırgan kapasitesi, erişim düzeyi, korunacak varlık ve kabul edilebilir sonuç üzerinden yapılmalıdır. Model robustness testi normal doğrulama kümesinin yerine geçmez; normal doğrulama da saldırgan odaklı değerlendirme yerine geçmez.

Bu nedenle yapay zekâ sistemlerinde güvenli tasarımın temel çizgisi değişmez: güvenilmeyen veriyi yetki olarak kabul etme, en az ayrıcalığı koru, model çıktısını uygulama kararıyla eşitleme ve model yaşam döngüsünü tedarik zincirinin parçası olarak doğrula.

60. Sonuç: güvenli sistemin sade tarifi

Siber güvenliğe ilk girildiğinde araç sayısı ürkütücüdür. Nmap, Wireshark, Burp Suite, Metasploit, BloodHound, CrackMapExec/NetExec, Hashcat, Snort, Suricata, Wazuh, hata ayıklayıcılar, disassembler'lar, fuzzing araçları, SAST ve DAST ürünleri birbirinden bağımsız uzmanlıklar gibi görünür.

Zamanla araçların geçici, ilkelerin daha kalıcı olduğu anlaşılır.

Bir paket analizinde öğrendiğimiz güven sınırı, bir REST API'de de karşımıza çıkar. Stack overflow çalışırken gördüğümüz “küçük veri hatası kontrol akışını değiştirebilir” ilkesi, güvensiz tersine serileştirmede başka biçimde görünür. Active Directory grafında gördüğümüz saldırı yolu, mikroservis yetki grafında tekrar eder. Sosyal mühendislik, kimlik doğrulamanın yalnız kriptografi olmadığını gösterir. DDoS, erişilebilirliğin kapasite mühendisliğinden ayrı düşünülemeyeceğini öğretir. Adli bilişim ise tasarım sırasında bırakmadığımız kanıtı olaydan sonra üretemeyeceğimizi hatırlatır.

Bu nedenle güvenli yazılım mühendisliğini tek cümleye indirgemem gerekirse şu şekilde ifade ederim:

Sistemin hangi varsayımlara güvendiğini görünür kıl, gereksiz güveni kaldır, kalan güveni doğrula, hatanın etkisini sınırla ve kontrolün gerçekten çalıştığını saldırganın bakışıyla kanıtla.

Zen yaklaşımının güvenlikteki karşılığı da burada belirir. Daha çok araç, daha çok ürün, daha çok kural her zaman daha güvenli sistem üretmez. Gereksiz servis kapalıysa firewall kuralına ihtiyaç duymaz. Shell kullanılmıyorsa command escaping problemi küçülür. Kullanıcıdan fiziksel dosya yolu alınmıyorsa path traversal sınıfı daralır. Native nesne deserialization yapılmıyorsa gadget chain aramak gerekmez. Servis gereksiz yetkiye sahip değilse RCE'nin etkisi sınırlanır. Veri tutulmuyorsa sızdırılamaz.

En güçlü güvenlik kontrolü bazen eklediğimiz değil, ihtiyaç olmadığı için sistemden çıkardığımız yetenek olur.

Bayrak hâlâ oradadır. Fakat ona ulaşan yol artık rastlantılardan oluşmaz. Her geçitte kimlik sorulur, her kaynakta yetki doğrulanır, her yorumlayıcıda veri komuttan ayrılır, her süreç yalnız ihtiyacı kadar yetki taşır, her önemli olay iz bırakır. Bir kontrol kırılırsa diğeri saldırının etkisini sınırlar. Bir şey yine de geçerse görürüz. Görürsek müdahale ederiz. Müdahale ettikten sonra aynı hatanın tekrarını zorlaştırırız.

Güvenli sistem, saldırıya hiç uğramayan sistem değildir. Saldırıya hazırlanmış, sınırları belirli, davranışı ölçülebilir ve ihlal karşısında dirençli sistemdir.

Standartları Birlikte Kullanmak İçin Kısa Not

Bu kaynakların işlevleri farklıdır. OWASP Top 10 farkındalık ve risk kümeleri için; ASVS uygulama seviyesinde doğrulanabilir güvenlik gereksinimleri için; NIST SSDF güvenli geliştirme süreci için; NIST CSF kurumsal siber risk yaşam döngüsü için; CIS Controls uygulanabilir kurumsal öncelikler için; MITRE ATT&CK saldırgan davranışı ve algılama kapsamını düşünmek için uygundur. Birini diğerinin yerine kullanmak yerine aralarında izlenebilirlik kurmak daha doğru sonuç verir.

Arşiv ve Açma Bombaları

Dosya yükleme veya içerik işleme sınırında yalnız dosya boyutunu kontrol etmek yeterli değildir. Küçük bir sıkıştırılmış girdinin açıldığında aşırı CPU, bellek veya disk tüketmesine yol açan ZIP Bomb sınıfı, kaynak bütçesinin de güvenlik kontrolü olduğunu gösteren iyi bir örnektir.

Güvenli Yazılım Yaşam Döngüsünün Kavramsal Haritası

Güvenli geliştirme tek bir tarama aracına indirgenemez. Tehdit modelleme tasarım aşamasında hangi varlığın hangi tehdit altında olduğunu görünür kılarken, saldırı yüzeyi erişilebilir giriş noktalarını ve güven sınırlarını somutlaştırır. Katmanlı savunma ile en az ayrıcalık ise tek bir kontrolün başarısızlığının tüm sistemi açığa çıkarmamasını hedefler.

Zayıflık ve açık terminolojisini birbirinden ayırmak önemlidir. CWE bir yazılım zayıflığı sınıfını, CVE belirli ve yayımlanmış bir güvenlik açığını, CVSS ise bu açığın şiddetini standartlaştırılmış ölçütlerle ifade eder. Bu ayrım, kaynak kod seviyesindeki kusur ile sahada izlenen somut açığın aynı şey olarak değerlendirilmesini önler.

Doğrulama katmanında statik uygulama güvenlik testi çalıştırılmadan önce kaynak veya ara gösterim üzerinde kusur ararken, dinamik uygulama güvenlik testi çalışan uygulamanın dışarıdan gözlenen davranışını sınar. Fuzz testi ise beklenmeyen ve bozuk girdiler altında ayrıştırıcıların, protokollerin ve sınır kontrollerinin nasıl davrandığını ortaya çıkarmaya yardımcı olur.

Bağımlılık görünürlüğü için yazılım malzeme listesi, uygulamanın hangi üçüncü taraf bileşenleri taşıdığını izlenebilir hale getirir. Web katmanında sunucu tarafı istek sahteciliği sunucunun başka kaynaklara yaptığı istekleri saldırgan lehine yönlendirebilirken, siteler arası istek sahteciliği kullanıcının mevcut tarayıcı oturumunu istenmeyen bir durum değişikliğine aracılık ettirmeyi hedefler. İki saldırı sınıfı aynı “istek sahteciliği” adını taşısa da güven sınırları ve savunma mekanizmaları farklıdır.

Üretken Yapay Zekâ Uygulamalarının Saldırı Yüzeyi

LLM kullanan yazılımda tehdit modeli yalnız modele sorulan kötü niyetli metinlerden oluşmaz. Uygulama; model, istem, retrieval, araç, veri tabanı, embedding indeksi, model dosyası ve kullanıcı oturumu gibi birden çok güven sınırı içerir.

Kullanıcı
   |
   v
İstem / API
   |
   +--> RAG / Vector Store
   +--> Araçlar
   +--> Harici içerik
   |
   v
LLM
   |
   v
Çıktı
   |
   +--> Kullanıcı
   +--> Kod / komut / veri tabanı

Tehdit modeli bu sınırların her birini ayrı ele almalıdır.

Doğrudan ve dolaylı istem enjeksiyonu

Doğrudan istem injection, kullanıcının model davranışını sistem politikasına aykırı biçimde değiştirmeye çalışmasıdır.

Dolaylı istem injection, modelin okuduğu belge, web sayfası, e-posta veya RAG kaynağı içine saldırgan talimat yerleştirilmesidir.

Sistem talimatı
       |
       v
      Model <----- güvenilmeyen belge
                       |
                       +--> "önceki kuralları yok say"

Belge içeriği veri olarak kalmalıdır; otorite kazanıp sistem politikası hâline gelmemelidir.

İstem injection neden yalnız filtreyle çözülmez?

Saldırgan talimat doğal dilin içinde taşındığı için kara liste:

"ignore previous instructions"

gibi tek tek dizileri engelleyerek güvenilir sınır oluşturmaz.

Daha güçlü savunma katmanları:

• görev ve araç yetkisini daraltma,
• dış veriyi ayrı güven alanında işaretleme,
• araç argümanlarını doğrulama,
• kritik eylemde insan/onay kapısı,
• least privilege,
• çıktı doğrulama,
• eylem ve kaynak kullanımını audit log ile izleme.

Amaç modelin saldırıyı hiç “görmemesi” değil, model yanlış yönlendirilse bile zararlı eylemin sınırlandırılmasıdır.

Araç Yetkisi ve Aşırı Eylem Alanı

Bir ajanın dosya sistemi, kabuk, e-posta, veri tabanı veya dış API'lere erişmesi saldırı etkisini büyütür.

Model yanılgısı
   x
Araç yetkisi
   =
operasyonel risk

Araçlar:

read_file
search
execute_sql_readonly

gibi dar ve amaca özel tasarlanmalıdır.

run_any_shell_command gibi geniş araçlar daha büyük saldırı yüzeyi oluşturur.

Yazma işlemleri için:

plan
 -> dry-run
 -> diff
 -> validation
 -> approval
 -> commit

deseni güvenlik ve geri alınabilirlik sağlar.

RAG, Vektör ve Gömme Güvenliği

OWASP 2025 LLM08, vektör ve gömme kullanan RAG sistemlerinde özellikle:

• yetkisiz erişim,
• bağlamlar arası bilgi sızıntısı,
• gömme tersine çevirme (embedding inversion),
• veri zehirleme

gibi riskleri tanımlar.

ACL retrieval'dan önce

Yanlış tasarım:

tüm vektörler
 -> top-k
 -> LLM
 -> sonradan ACL

Doğru tasarım:

kullanıcı / tenant
   |
   v
izinli partition / filter
   |
   v
retrieval
   |
   v
LLM

Yetkisiz belge bağlama girdikten sonra çıktı filtresine güvenmek yeterli değildir.

Poisoning

Saldırgan veya hatalı belge semantik aramada yüksek sıralanacak şekilde hazırlanabilir. Bu durumda model yalnız “halüsinasyon” yapmıyor olabilir; kendisine getirilen zehirli kanıtı doğru biçimde özetliyor olabilir.

İngest aşamasında:

• kaynağın güven düzeyi,
• içerik hash'i,
• editoryal onay,
• sürüm,
• ekleyen kullanıcı,
• kaynak tipi

izlenmelidir.

Model ve Veri Tedarik Zinciri

Yerel model indirmek bulut API riskini azaltabilir; fakat yeni bir tedarik zinciri oluşturur.

Kontrol edilmesi gerekenler:

• model deposu ve yayıncı,
• lisans,
• dosya hash'i / imza,
• model biçimini yükleyen runtime,
• custom code gereksinimi,
• tokenizer ve ek dosyalar,
• bağımlılık paketleri,
• nicemlenmiş türevin kaynağı.

“Açık ağırlıklı” modelin kaynağı belirsiz bir üçüncü taraf quantization paketi, resmi dağıtımdan farklı risk taşır.

Yerel = otomatik güvenli değildir

Yerel çalıştırma:

• veri egemenliği,
• dış API bağımlılığı,
• trafik görünürlüğü

açısından avantaj sağlayabilir.

Fakat şu riskler kalır:

• istem injection,
• kötü niyetli yerel kullanıcı,
• model poisoning,
• hassas log,
• yetkisiz araç çağrısı,
• zayıf dosya izinleri,
• güncel olmayan runtime.

LLM Uygulamalarında Sızma Testi

Geleneksel web güvenlik testi LLM katmanını kapsayacak biçimde genişletilmelidir.

Test sınıfları:

1. yetkilendirme aşımı
2. doğrudan istem injection
3. dolaylı istem injection
4. hassas veri çıkarma
5. RAG poisoning
6. araç kötüye kullanımı
7. çıktı işleme enjeksiyonu
8. kaynak tüketimi / DoS
9. model / plugin supply chain
10. tenant isolation

Her bulgu:

girdi
model/istem sürümü
retrieved evidence
tool calls
çıktı
uygulama etkisi

ile yeniden üretilebilir olmalıdır.

Improper output handling

Model çıktısı:

SQL
HTML
Markdown
shell
URL

gibi başka yorumlayıcılara girebilir. “Model güvenilir” varsayımıyla çıktıyı doğrudan çalıştırmak klasik injection sorunlarını yeniden üretir.

LLM çıktısı da kullanıcı girdisi gibi güvenilmeyen veri sayılmalıdır.

Güvenlik Testini Model Skorundan Ayırmak

Modelin zararlı istek reddetme oranı tek başına uygulama güvenliği değildir.

model safety
   +
application authorization
   +
tool sandbox
   +
data isolation
   +
output validation
   =
system security

NIST Generative AI Profile ve OWASP GenAI Top 10, riskin bütün yaşam döngüsü ve uygulama mimarisi içinde yönetilmesi gerektiğini destekler.

Bu nedenle üretken yapay zekâ güvenliği, yeni bir “istem filtresi” eklemekten çok klasik güvenli yazılım mühendisliği ilkelerini olasılıksal model katmanına genişletme problemidir.

Ünite 8: Politika Kararı, Biçimsel Güvence ve Güvenli Dağıtım

Güvenli yazılım yalnız doğru kimlik doğrulama, girdi doğrulama veya güvenli kriptografi kullanımından oluşmaz. Büyük sistemlerde güvenlik kararı; politikanın nerede tanımlandığı, hangi bağlam bilgisinin kullanıldığı, kararın nerede verildiği ve sonucun hangi noktada zorlandığıyla birlikte ele alınmalıdır. Benzer biçimde güvenlik doğrulaması yalnız dinamik testten ibaret değildir; statik analizden biçimsel yöntemlere uzanan farklı tekniklerin kanıt gücü ve maliyeti birbirinden farklıdır. Üretime geçişte ise güvenli derleme kadar güvenli konfigürasyon, dağıtım ve sürüm bütünlüğü önemlidir.

8.1 Yetkilendirme karar mimarisi: PAP, PIP, PDP ve PEP

Dağıtık bir sistemde “kullanıcının rolüne bak ve izin ver” yaklaşımı, politika büyüdükçe yönetilebilirliğini kaybeder. Yetkilendirme kararını dört soruya ayırmak daha sağlamdır:

Politika nerede yönetiliyor?        -> PAP
Karar hangi bağlamı kullanıyor?     -> PIP
İzin/ret kararını kim hesaplıyor?   -> PDP
Kararı istek üzerinde kim zorluyor? -> PEP

Policy Administration Point (PAP), politikanın tanımlandığı ve yaşam döngüsünün yönetildiği noktadır. Bu katman yalnız kullanıcı arayüzü değildir; politika sürümü, değişiklik yetkisi, onay süreci ve geri alma davranışı da burada ele alınır.

Policy Information Point (PIP), karar için gerekli öznitelik ve bağlamı sağlar. Kullanıcı birimi, cihaz güven durumu, kaynak sınıflandırması, zaman, ağ bölgesi veya risk sinyali PIP girdisi olabilir. PIP'nin verdiği verinin eski veya hatalı olması, PDP'nin mantıksal olarak doğru fakat güvenlik açısından yanlış karar üretmesine neden olabilir.

Policy Decision Point (PDP), özne, eylem, kaynak ve bağlamı politika ile değerlendirir:

karar = f(özne, eylem, kaynak, bağlam, politika_sürümü)

Policy Enforcement Point (PEP) ise bu kararı gerçek isteğin geçtiği noktada uygular. API gateway, servis filtresi, reverse proxy, servis içi interceptor veya veri erişim katmanı PEP rolü üstlenebilir.

Bu ayrım, ürün veya protokolden bağımsız bir mimari düşünme aracıdır. Her sistemde ayrı bir fiziksel PAP/PIP/PDP/PEP servisi kurmak zorunlu değildir; küçük bir uygulamada roller aynı süreç içinde bulunabilir. Önemli olan karar sorumluluklarının karışmamasıdır.

Karar önbelleği ve tutarlılık

PDP çağrısı yüksek trafikte gecikme kaynağı olabilir. Karar veya öznitelik önbelleği gecikmeyi düşürebilir; fakat politika iptali ile önbellek ömrü arasında güvenlik penceresi oluşturur. Özellikle yetki geri alma, hesap kilitleme veya hassas kaynak sınıflandırması değiştiğinde eski kararın ne kadar süre geçerli kalacağı açıkça tanımlanmalıdır.

Daha uzun TTL -> daha düşük karar maliyeti -> daha uzun eski-yetki riski
Daha kısa TTL -> daha güncel politika       -> daha yüksek karar trafiği

Kritik işlemlerde doğrudan yeniden değerlendirme; düşük riskli ve yüksek hacimli okumada kontrollü önbellek daha uygun olabilir. Karar önbelleği yalnız kullanıcı kimliğiyle anahtarlanırsa kaynak, eylem veya bağlam farkları yanlış yetki paylaşımına yol açabilir.

Arıza davranışı

Yetkilendirme altyapısının erişilememesi durumunda varsayılan davranış bilinçli seçilmelidir. “Her zaman fail closed” güçlü bir başlangıç ilkesidir; ancak güvenlik-kritik ve emniyet-kritik sistemlerde erişilebilirlik sonucu ayrıca analiz edilmelidir. Örneğin acil durum işlemi için alternatif ve denetlenebilir bir yetki yolu gerekebilir. Buradaki amaç genel bir “fail open” davranışı değil, arıza durumunun tehdit modeliyle birlikte tasarlanmasıdır.

8.2 Güvenlik doğrulama tekniklerinin kanıt gücü

Hiçbir tek analiz tekniği yazılımın “güvenli olduğunu” kanıtlamaz. Araç ve yöntem seçimi, hangi hata sınıfının hangi gözlem modeliyle bulunabileceğine göre yapılmalıdır.

Statik analiz

Statik analiz programı çalıştırmadan kaynak kod, ara gösterim veya ikili üzerinde özellik arar. Veri akışı, taint propagation, API kötü kullanımı, erişilemeyen kod ve bazı bellek hataları bu sınıfta bulunabilir.

Avantajı geniş kod kapsamıdır; temel sınırlamaları ise yanlış pozitifler, ortam varsayımları ve çalışma zamanı durumunun eksik modellenmesidir. SAST çıktısının sayısı tek başına güvenlik metriği değildir; bulgunun erişilebilirlik, sömürülebilirlik ve iş etkisiyle triage edilmesi gerekir.

Dinamik analiz ve fuzzing

Dinamik analiz gerçek çalışan programı gözlemler. Fuzzing, biçimlendirilmiş veya yarı biçimlendirilmiş girdiler üreterek çökme, kilitlenme, sınır hatası ve beklenmeyen durum geçişleri arar. Coverage-guided fuzzing yürütme kapsamını geri besleme olarak kullanabilir.

Dinamik yöntem gerçek davranışı gözler; ancak yalnız ulaşılan yürütme yollarını sınar. Nadir bir durum hiç üretilemezse kusur görünmez kalabilir.

Sembolik yürütme

Sembolik yürütmede girişler tek tek somut değerler yerine semboller olarak ele alınır ve yürütme yolları yol koşullarıyla temsil edilir:

if x > 10:
    ...

Yol A: x > 10
Yol B: x <= 10

Kısıt çözücü, belirli yola ulaşan girişleri üretmekte kullanılabilir. Bu yöntem derin sınır durumlarını bulabilir; ancak dallanma arttıkça path explosion problemi ortaya çıkar. Karmaşık dış sistem, iş parçacığı eşzamanlılığı veya ortam bağımlılıklarının modellenmesi de maliyetlidir.

Biçimsel yöntemler ve model denetleme

Biçimsel yöntemler, sistem özelliğini matematiksel model ve mantıksal özelliklerle ifade ederek kanıt veya durum uzayı incelemesi yapar. Model denetleme, örneğin “yetkisiz bir durumdan ayrıcalıklı duruma geçiş mümkün değildir” gibi bir güvenlik özelliğini sonlu durum modeli üzerinde sınayabilir.

Biçimsel kanıtın gücü, kanıtlanan özelliğin ve modelin kapsamıyla sınırlıdır. Yanlış model, yanlış varsayım veya kanıt kapsamı dışındaki entegrasyon hatası gerçek sistemi güvensiz bırakabilir. Bu nedenle “formal verification yapıldı” ifadesi, neyin hangi varsayımlar altında doğrulandığı belirtilmeden yeterli güvence değildir.

Proof-carrying code yaklaşımı

Proof-carrying code tarihsel ve akademik açıdan önemli bir fikirdir: kod üreticisi, kodun belirli güvenlik politikasını sağladığına ilişkin makinece denetlenebilir bir kanıt sunar; tüketici pahalı analizi yeniden yapmak yerine kanıtı doğrular. Genel amaçlı uygulama geliştirmede yaygın bir dağıtım modeli değildir, ancak güvenin “üreticiye inanmak” yerine doğrulanabilir kanıta bağlanabileceğini göstermesi bakımından değerlidir.

8.3 Güvenlik testlerinin birlikte kullanılması

Farklı doğrulama katmanları birbirinin alternatifi değil tamamlayıcısıdır:

Gereksinim incelemesi
        |
        v
Tehdit modelleme
        |
        v
Kod inceleme + SAST
        |
        v
Birim/entegrasyon güvenlik testleri
        |
        v
Fuzzing + DAST
        |
        v
Sızma testi
        |
        v
Üretim gözlemi ve olay geri beslemesi

Bir SQL injection testinin geçmesi erişim kontrolünün doğru olduğunu kanıtlamaz; yüksek SAST kapsamı da çalışma zamanı kimlik sınırlarının doğru uygulandığını göstermez. Güvence, farklı hata sınıflarını hedefleyen kanıtların birleşiminden doğar.

Yüksek kritiklikte biçimsel yöntemler veya model denetleme belirli çekirdek özellikler için ek güvence sağlayabilir. Tüm uygulamayı biçimsel olarak kanıtlama hedefi yerine, güvenlik çekirdeği, yetki durumu makinesi veya protokol geçişi gibi dar fakat kritik alanları seçmek çoğu projede daha uygulanabilirdir.

8.4 Güvenli dağıtım ve konfigürasyon kayması

Güvenli kod, güvensiz dağıtımla etkisiz hâle gelebilir. Üretim güvenliği aşağıdaki zincirin bütünlüğüne bağlıdır:

Kaynak -> Derleme -> Eser -> Konfigürasyon -> Dağıtım -> Çalışma zamanı

Her adımda “test edilen şey” ile “çalışan şey” arasındaki fark azaltılmalıdır.

Değişmez eser ve köken bilgisi

Aynı sürüm etiketi altında üretimde yeniden derleme yapmak, test edilen ikili ile çalışan ikilinin farklı olmasına yol açabilir. Tercih edilen yaklaşım, bir kez üretilmiş ve doğrulanmış eserin ortamlar arasında terfi ettirilmesidir. İmza, checksum ve provenance bilgisi eserin kökenini ve bütünlüğünü destekleyebilir; ancak güvenilmeyen anahtarla atılan imza tek başına güven üretmez.

Konfigürasyon kodu ve gizli değerler

Konfigürasyon mümkün olduğunca sürümlenmeli, gözden geçirilmeli ve tekrar üretilebilir olmalıdır. Parola, API anahtarı veya özel anahtar gibi gizli değerler ise kaynak kod ve genel konfigürasyondan ayrılmalıdır.

Güvenlik açısından önemli varsayılanlar açık olmalıdır:

• debug/diagnostic uçları,
• örnek hesaplar,
• varsayılan parolalar,
• açık yönetim portları,
• CORS ve origin politikaları,
• TLS doğrulaması,
• dosya ve dizin izinleri,
• container capability ve ayrıcalıkları,
• servis hesabı yetkileri.

Konfigürasyon kayması

Başlangıçta güvenli olan ortam zaman içinde elle yapılan değişikliklerle referans durumdan uzaklaşabilir. Configuration drift, yalnız operasyonel tutarsızlık değil güvenlik problemidir. Sürekli karşılaştırma, değişiklik kaydı ve gerektiğinde otomatik geri dönüş; “bir zamanlar harden edilmişti” varsayımından daha güçlüdür.

Aşamalı dağıtım ve geri alma

Canary, blue-green veya kademeli dağıtım yalnız kullanılabilirlik amacı taşımaz. Güvenlik güncellemesinin beklenmeyen yetkilendirme veya trafik davranışını küçük etki alanında gözleme imkânı verir. Geri alma mekanizması hazırlanırken güvenlik veri modelinin eski sürümle uyumluluğu da değerlendirilmelidir; örneğin şema değişimi veya anahtar rotasyonu geri dönüşü karmaşıklaştırabilir.

8.5 Konteyner, mikroservis ve sanallaştırma sınırları

Konteyner veya sanal makine kullanmak, uygulamayı otomatik olarak güvenli yapmaz. İzolasyon mekanizmasının hangi tehdide karşı hangi sınırı sağladığı açıkça bilinmelidir.

Konteynerlerde yaygın riskler şunlardır:

• ayrıcalıklı çalışma,
• gereksiz Linux capabilities,
• host dosya sistemi veya socket bağlama,
• kök kullanıcıyla çalışma,
• imzasız veya güncelliğini yitirmiş temel imaj,
• image içinde gizli değer,
• zayıf ağ segmentasyonu,
• sınırsız CPU/bellek tüketimi.

Mikroservis mimarisinde süreç sınırı ağ sınırına dönüşür. Tek süreç içindeki yöntem çağrısı yerine ağ kimliği, servis kimliği, TLS, timeout, retry, circuit breaker ve dağıtık yetkilendirme gibi yeni hata yüzeyleri ortaya çıkar. “İç ağ güvenilirdir” varsayımı bu nedenle yeterli değildir.

8.6 Güvenli geliştirme olgunluğu

Güvenlik faaliyetlerini tek tek araç alımı olarak yönetmek sürdürülebilir değildir. Olgunluk yaklaşımı, güvenlik uygulamalarının kurumsal olarak ne kadar tutarlı ve ölçülebilir yürütüldüğünü değerlendirir.

OWASP Software Assurance Maturity Model (SAMM), kuruluşların mevcut yazılım güvenliği uygulamalarını değerlendirmesine, risklerine göre dengeli bir güvence programı kurmasına ve ilerlemeyi ölçmesine yardımcı olan açık bir çerçevedir. Güncel OWASP proje sayfası SAMM 2.2.0 sürümünü gösterir.

Olgunluk, “en yüksek seviyeye çıkmak” yarışına dönüştürülmemelidir. Kritik ödeme sistemi ile düşük riskli iç araç aynı kontrol yoğunluğunu gerektirmeyebilir. Hedef seviye; tehdit, veri hassasiyeti, mevzuat, değişiklik sıklığı ve olay maliyetiyle uyumlu olmalıdır.

Ayrıca olgunluk puanı gerçek güvenliğin doğrudan ölçüsü değildir. Sürecin tanımlı olması, kontrolün doğru uygulandığını kanıtlamaz. Süreç göstergeleri; gerçek kusur, olay, düzeltme süresi ve saldırı yüzeyi verileriyle birlikte değerlendirilmelidir.

8.7 Güvenlik güvencesini sistem özelliği olarak ele almak

NIST SP 800-160 Vol. 1 Rev. 1, güvenilir güvenli sistemleri sistem mühendisliği yaşam döngüsü boyunca ele alır. Bu bakış açısı, güvenliği tek bir “security team” kontrol noktasından çıkarıp gereksinim, mimari, uygulama, entegrasyon, doğrulama, dağıtım ve işletme kararlarının ortak sonucu hâline getirir.

Pratik karşılığı şudur:

Güvenlik gereksinimi
    -> tehdit modeli
    -> mimari kontrol
    -> uygulanabilir politika
    -> doğrulama kanıtı
    -> güvenli dağıtım
    -> çalışma zamanı gözlemi
    -> olaydan öğrenme

Güvenli yazılım mühendisliğinde güçlü sonuç, tek bir araç veya denetimden değil; bu zincirdeki varsayımların izlenebilir ve birbirleriyle tutarlı olmasından doğar.

Kaynak Tüketimi Saldırıları ve Güvenli Degradasyon

Güvenlik ve güvenilirlik ayrı sonradan-eklenen özellikler değil, ortak hata ve kötüye kullanım yüzeyini yöneten tasarım özellikleridir. Güvenli yazılım tasarımında blast radius yalnız ağ segmentasyonu ile küçülmez; en az yetki, kaynak kotaları, güvenli varsayılanlar, geri alınabilir değişiklikler, açık kurtarma prosedürleri ve olay sonrası kök neden analizi birlikte ele alındığında ihlalin veya hatanın yayılımı gerçekten sınırlandırılabilir. Özellikle DoS sınıfı problemlerde güvenlik kontrolünün kendisinin kullanılabilirliği tüketmemesi gerekir.

• Rate limit ve quota tasarımında meşru kullanıcıların starvation riskinin incelenmesi.
• Fail-open/fail-closed kararının availability ve security etkilerinin senaryolaştırılması.
• Bir koruma mekanizmasının CPU, bellek veya DB bağlantı havuzunu tüketmemesinin doğrulanması.

Ünite 9: Doğal Dil Aracılı Eylemlerde Yetenek, Provenance ve Yan Etki Güvenliği

Bir doğal dil katmanının kullanıcı isteğini doğru anlaması, ilgili işlemi yapmaya yetkili olduğu anlamına gelmez. Güvenli sistemde yorumlama ile yetki farklı güven sınırlarıdır.

kullanıcı metni
  ↓
niyet / parametre çıkarımı
  ↓
ön kabul doğrulama
  ↓
parametre provenance kontrolü
  ↓
yetenek / yetki kapısı
  ↓
izinli araç
  ↓
yan etki

Intent yetki değildir

Bir sistem bir eylem niyetini yüksek güvenle bulabilir. Bu sonuç yalnız kullanıcının ne istediği sorusuna cevap verir.

Gerçek işlem için ayrıca oturum yetkisi, kaynak kapsamı, işlemin mevcut çalışma alanında sunulup sunulmadığı, parametrelerin güvenilir kaynağı ve güvenlik politikası kontrol edilmelidir.

Yan etkili eylemlerde daha sıkı kabul politikası

Doğal dil katmanında salt-okunur analiz ile kalıcı veya fiziksel yan etki üreten eylem aynı kabul politikasını paylaşmak zorunda değildir. Yan etki riski arttıkça sistem daha güçlü dilsel kanıt ve daha açık hedef dayanağı isteyebilir.

Özellikle iki ölçü birlikte değerlidir:

• en güçlü adayın kabul skoru,
• en güçlü iki aday arasındaki marj.

Yüksek skor fakat çok küçük marj, iki niyetin birbirine çok yakın olduğunu gösterebilir. Salt-okunur bir sorguda clarification ile devam etmek kabul edilebilirken yan etkili eylemde belirsizlik doğrudan yürütmeye çevrilmemelidir.

Yan etkili işlem için şu üç kanıt sınıfını ayırmak güvenlidir:

1. kullanıcının mevcut isteğinde açık eylem ifadesi,
2. işlem yapılacak nesnenin güvenilir ve güncel bağlamdan bağlanması,
3. capability ve yetkilendirme kapısının ayrıca geçilmesi.

Geçmiş turda bir nesnenin seçilmiş olması veya retrieval'ın doğru kaydı bulması, kullanıcının şimdi o nesne üzerinde eylem istediğini kanıtlamaz. Bu nedenle nesne dayanağı ile eylem niyeti ayrı doğrulanmalıdır.

Güvenlik açısından temel ilke, yan etkili komutlarda yanlış pozitifi azaltmak için kabul eşiğini yükseltmek ve belirsizliği "en yakın komuta" zorlamamaktır.

Provenance-constrained binding

Kritik parametrenin değeri kadar nereden geldiği de önemlidir.

resourceId = 381
source = USER_LITERAL

veya:

resourceId = 381
source = VERIFIED_RESULT

kabul edilebilir provenance sınıfları olabilir.

FUZZY_GUESS gibi bir kaynak kritik yan etkili eylem için yeterli sayılmamalıdır.

Ön kabul doğrulama

Kullanıcı ikinci sonucu açmak isteyebilir; ancak mevcut listede yalnız bir sonuç olabilir.

Sistem:

istenen öğe gerçekten var mı?
seçim güncel sonuç sürümüne mi ait?
kimlik doğrulanmış mı?
işlem bu nesne türünde geçerli mi?

sorularını sınayabilir.

Bu doğrulama erişim kontrolünden önce gelen bir mantıksal tutarlılık kapısıdır.

Capability gate

Yetkilendirme yalnız kullanıcı rolü değildir. Bir çalışma alanı belirli işlevleri hiç sunmuyor olabilir.

Yetenek kapısı:

canRead
canAnalyze
canOpen
canExport
canExecute

gibi uygulama bağlamını da hesaba katabilir.

Tool registry ve allowlist

Doğal dil katmanının herhangi bir fonksiyonu adından çağırmasına izin vermek saldırı yüzeyini büyütür.

Daha güvenli yaklaşım:

intent
 -> kayıtlı araç kimliği
 -> doğrulanmış şema
 -> parametre doğrulama
 -> çağrı

şeklindedir.

Araç kaydı beklenen parametreleri, yan etki sınıfını, gerekli yetenekleri ve güvenli hata davranışını tanımlayabilir.

Olumsuz komut için sert veto

Dil modeli veya sınıflandırıcı açma ifadesini aç kökü nedeniyle eylem niyetine yaklaştırabilir.

Yan etkili komutlarda:

action detected = true
negation detected = true
=> invoke = false

gibi bağımsız koruma kullanılabilir.

Bu niyet sınıflandırıcısının yerine geçmez; ikinci savunma katmanıdır.

Zincirlenmiş yan etkileri sınırlamak

Analitik olarak güvenli bir adımın ardından otomatik yan etki çalıştırmak risklidir:

ara
 -> sırala
 -> seç
 -> aç
 -> dışa aktar

Analitik bağımlı adımlar sınırlı fan-out ile zincirlenebilir; yan etkili adım ayrı kullanıcı eylemine bırakılabilir.

Güvenli varsayılan

Belirsiz durumda sistem en yakın aracı çağırmak yerine açıklaştırmalı, işlemi çalıştırmamalı veya desteklenen seçenekleri göstermelidir.

Doğrulanmış çıktı

Araç çalıştıktan sonra dönüş değeri de sözleşmeye uymalıdır:

tool result
 -> schema validation
 -> authorization-safe projection
 -> user-facing response

Bu ayrım iç nesnenin bütün alanlarının istemeden kullanıcıya sızmasını engeller.

Denetim için karar izi

Güvenlik denetiminde yararlı kayıt; istek sınıfı, seçilen araç, parametre kaynağı, capability kararı, çalıştırma durumu ve hata ailesi gibi doğrulanabilir olayları içerebilir.

Bu gizli muhakeme kaydı değildir.

Doğal dil aracılı eylem güvenliği yalnız prompt injection filtresi değil; yorum, veri bağlama, yetki, araç seçimi ve yan etkiyi ayrı kapılar hâline getirme disiplinidir.

Kaynakça

• Anley, C.; Heasman, J.; Lindner, F.; Richarte, G., The Shellcoder's Handbook: Discovering and İstismaring Security Holes, 2nd ed., Wiley, 2007.

• Apostol Vassilev et al. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST AI 100-2e2025, 2025. https://doi.org/10.6028/NIST.AI.100-2e2025

• BloodHound Enterprise / Community Edition documentation — https://bloodhound.specterops.io/

• Cadar, Cristian; Dunbar, Daniel; Engler, Dawson. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. OSDI 2008, USENIX Association. https://www.usenix.org/conference/osdi-08/klee-unassisted-and-automatic-generation-high-coverage-tests-complex-systems

• Center for Internet Security, CIS Critical Security Controls v8.1 — https://www.cisecurity.org/controls/v8-1

• CISA ve ortak kurumlar, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software — https://www.cisa.gov/securebydesign

• Easttom, C., Computer Security Fundamentals, Pearson.

• Eilam, E., Reversing: Secrets of Reverse Engineering, Wiley, 2005.

• FIRST, Common Vulnerability Scoring System (CVSS) — https://www.first.org/cvss/

• Heather Adkins; Betsy Beyer; Paul Blankinship; Piotr Lewandowski; Ana Oprea; Adam Stubblefield. Building Secure & Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. O’Reilly Media, 2020.

• Microsoft Learn, Active Directory Domain Services and Windows security documentation — https://learn.microsoft.com/windows-server/identity/

• Mitnick, K. D.; Simon, W. L., The Art of Deception: Controlling the Human Element of Security, Wiley, 2002.

• MITRE, ATT&CK Enterprise Matrix, güncel sürüm bilgisi ve teknik kataloğu — https://attack.mitre.org/

• MITRE, Common Weakness Enumeration (CWE) — https://cwe.mitre.org/

• Necula, George C. Proof-Carrying Code. POPL 1997, pp. 106–119. https://doi.org/10.1145/263699.263712

• National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). 2024. DOI: https://doi.org/10.6028/NIST.AI.600-1

• NIST, Cybersecurity çerçeve (CSF) 2.0, 2024 — https://www.nist.gov/cyberframework

• NIST, SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems, 2022 — https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final

• NIST, SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, 2022 — https://csrc.nist.gov/pubs/sp/800/218/final

• NIST, SP 800-63-4: Digital Identity Guidelines, 2025 — https://csrc.nist.gov/pubs/sp/800/63/4/final

• NIST, SP 800-63B-4: Authentication and Authenticator Management, 2025 — https://csrc.nist.gov/pubs/sp/800/63/B/4/final

• OWASP Foundation, Application Security Verification Standard (ASVS) 5.0.0 — https://owasp.org/www-project-application-security-verification-standard/

• OWASP Foundation, OWASP Cheat Sheet Series — https://cheatsheetseries.owasp.org/

• OWASP Foundation, OWASP Top 10:2025 — https://owasp.org/Top10/

• OWASP Foundation, Software Assurance Maturity Model (SAMM) 2.2.0 — https://owasp.org/projects/samm

• OWASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

• OWASP GenAI Security Project. LLM08:2025 Vector and Embedding Weaknesses. https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/

• OWASP, Mobile Application Security (MAS) Project — https://mas.owasp.org/

• OWASP, Web Security Testing Guide (WSTG) — https://owasp.org/www-project-web-security-testing-guide/

• PortSwigger, Web Security Academy — https://portswigger.net/web-security

• Snort Documentation — https://www.snort.org/documents

• Spilcă, L., Spring Security in Action, Manning Publications.

• Suricata Documentation — https://docs.suricata.io/

• Wazuh Documentation — https://documentation.wazuh.com/

• Wireshark Documentation — https://www.wireshark.org/docs/