Kaynak Kod Analizi ile Sızma Testi Aynı Problemi Çözmez: Nerede Ayrışır?

Bir uygulama için kaynak kod analizi yapılıyor. Ekip onlarca potansiyel güvenlik problemi tespit ediyor. Aynı uygulamaya uygulanan sızma testinde ise bunların yalnızca birkaçı doğrulanıyor. Buna karşılık sızma testi, kaynak kod raporunda hiç görünmeyen kritik bir yetkilendirme açığı buluyor.

Bu tablo ilk bakışta çelişkili görünür. Hangi çalışma eksik yapıldı? Kaynak kod analizi gereksiz bulgular mı üretti? Sızma testi kodun içindeki açıkları neden göremedi?

Çoğu zaman ortada bir çelişki yoktur. İki çalışma aynı sisteme bakar, fakat aynı soruyu sormaz ve aynı kanıtı toplamaz.

Kaynak kod analizi bir zayıflığın kök nedenini gösterebilir. Sızma testi o zayıflığın gerçek saldırı yüzeyindeki karşılığını kanıtlayabilir. Birincisi kodun içinde olup bugün erişilemeyen riski görebilir. İkincisi kod deposunda bulunmayan fakat deployment, configuration, identity, network veya entegrasyon katmanında oluşan açığı yakalayabilir.

Bu nedenle doğru soru “Hangisi daha iyi?” değildir. Doğru sorular şunlardır:

• Hangi güvenlik varsayımını doğrulamak istiyoruz?
• İncelenen artifact ile çalışan artifact aynı mı?
• Potansiyel weakness mı, doğrulanmış exploitability mi arıyoruz?
• Tek bir endpoint'i mi, aynı hatalı pattern'in kod tabanındaki bütün örneklerini mi görmek istiyoruz?
• Sonucun amacı release kararı, kök neden analizi, compliance kanıtı veya gerçek saldırı senaryosu mu?

Bu yazıda kaynak kod analizi ile sızma testi arasındaki farkı yalnızca tanımlar üzerinden değil, gerçek teknik kararlar üzerinden ele alacağız. SQL injection, IDOR, SSRF, insecure deserialization, cryptography, hardcoded secret, race condition ve deployment drift örneklerinde iki yöntemin neyi gördüğünü ayrı ayrı inceleyeceğiz.

Önce terimleri doğru ayıralım

“Kaynak kod analizi” ifadesi piyasada farklı hizmetler için kullanılabiliyor. Bu karışıklık, sızma testiyle yapılan karşılaştırmayı daha en baştan hatalı hale getiriyor.

Kaynak kod analizi nedir?

Kaynak kod analizi, uygulamanın source code, configuration, manifest, build tanımı ve ilgili teknik artifact'larının güvenlik bakış açısıyla incelenmesidir. Amacı yalnızca bilinen tehlikeli fonksiyonları bulmak değildir. Güven sınırlarının, data flow'un, authorization kararlarının, error handling davranışının, cryptographic kullanımın ve business rule implementation'ının güvenlik gereksinimlerini karşılayıp karşılamadığını araştırır.

İyi tasarlanmış bir kaynak kod analizi iki bileşeni birlikte kullanabilir:

1. 1SAST: Kod üzerinde otomatik pattern, semantic model ve data flow analizi yapan araçlardır. Geniş bir kod tabanında tekrarlanan weakness sınıflarını hızlı biçimde taramak için değerlidir.
2. 2Manual Source Code Review: Bir uzmanın uygulama mimarisini, trust boundary'leri, framework davranışını, özel business logic'i ve araçların bağlamlandıramadığı kod yollarını incelemesidir.

SAST ile kaynak kod analizi eş anlamlı değildir. SAST, kapsamlı bir kaynak kod analizinin otomatik bileşenlerinden biridir. Ham SAST çıktısını “manuel kaynak kod analizi raporu” olarak sunmak, coverage ile güvence seviyesini birbirine karıştırır.

Ayrıca “SCA” kısaltması da dikkatli kullanılmalıdır. Güncel Application Security terminolojisinde SCA çoğunlukla Software Composition Analysis anlamına gelir. Bu çalışma üçüncü taraf dependency'leri, bilinen CVE kayıtlarını, package sürümlerini ve lisans risklerini inceler. Source Code Review ile Software Composition Analysis ilişkili olsa da aynı çalışma değildir.

Sızma testi nedir?

Sızma testi, erişilebilir bir sistemin gerçek veya gerçeğe yakın çalışma koşullarında, yetkili saldırı simülasyonlarıyla incelenmesidir. Tester uygulamaya HTTP request gönderir, farklı user role'leri kullanır, input'ları değiştirir, workflow'ları kötüye kullanır, güvenlik kontrollerini aşmaya çalışır ve kontrollü exploit adımlarıyla etkisini doğrular.

Bir web uygulaması sızma testi yalnızca vulnerability scanner çalıştırmak değildir. Scanner geniş bir başlangıç görünürlüğü sağlayabilir. Fakat authentication state, tenant ayrımı, business logic, chained attack, race condition ve authorization gibi konular manuel muhakeme gerektirir.

Sızma testinin incelediği hedef source code değildir. Hedef, çalışan sistemin saldırgana sunduğu davranıştır. Bu davranış şu bileşenlerin tamamından doğar:

• Uygulama kodu
• Framework ve runtime
• Reverse proxy, API gateway ve WAF
• Identity provider ve authorization configuration
• Container veya server image
• Environment variable ve secret yönetimi
• Cloud IAM izinleri
• Network segmentation ve egress kuralları
• Database, message broker ve cache
• Üçüncü taraf servis entegrasyonları
• Deployment sırasında eklenen veya değiştirilen ayarlar

Dolayısıyla sızma testi bazen koddaki bir hatayı, bazen yanlış deployment kararını, bazen de iki doğru kontrolün hatalı etkileşimini bulur.

Asıl ayrım nerede başlar?

Kaynak kod analizi ile sızma testi arasındaki en belirleyici fark, baktıkları kanıt kaynağıdır.

Kaynak kod analizi şu soruyla başlar:

Sızma testi ise şu soruyla başlar:

Bu ayrım küçük görünse de raporların anlamını tamamen değiştirir. Kod analizi çoğu zaman bir hypothesis üretir. Belirli bir source'tan alınan verinin tehlikeli bir sink'e ulaştığını, bir authorization check'in atlanabildiğini veya güvenli olmayan bir cryptographic primitive kullanıldığını gösterir. Sızma testi bu hypothesis'i runtime üzerinde doğrulayabilir, çürütebilir ya da koşula bağlı hale getirebilir.

Tersi de geçerlidir. Sızma testi bir endpoint üzerinden başka tenant'a ait verinin okunabildiğini kanıtlar. Kaynak kod analizi daha sonra bunun yalnızca tek bir endpoint'te unutulmuş kontrol olmadığını, ortak repository helper'da yapılan tasarım hatası nedeniyle 17 farklı işlemde tekrarlandığını gösterebilir.

Özetle kaynak kod analizi neden ve yayılım, sızma testi erişilebilirlik ve sonuç konusunda daha güçlü kanıt üretir.

Kaynak kod analizi ve sızma testi karşılaştırması

Bu tablo iki önemli noktayı görünür hale getirir.

Birincisi, “kodda bulundu” ile “internetten exploit ediliyor” aynı cümle değildir. İkincisi, “pentest sırasında exploit edilemedi” ile “kod güvenli” de aynı cümle değildir.

Kaynak kod analizi neyi sızma testinden daha iyi gösterir?

Kaynak koduna erişim, tester'ın tahmin yürütmek zorunda kaldığı birçok noktayı doğrudan incelemesini sağlar. Ancak bunun gerçek avantajı sadece daha çok satır görmek değildir. Avantaj, uygulamanın güvenlik kararlarının nasıl verildiğini takip edebilmektir.

1. Source-to-sink data flow

Bir input'un sisteme nereden girdiğini, hangi transformation'lardan geçtiğini ve sonunda hangi tehlikeli operasyonda kullanıldığını takip etmek kaynak kod analizinin en güçlü alanlarından biridir.

Örneğin kullanıcıdan gelen sort parametresi önce bir DTO'ya, sonra bir service method'a, oradan shared query builder'a taşınıyor olabilir. Dışarıdan bakıldığında hata mesajı üretmeyen bu akış, kod üzerinde dynamic SQL fragment'ına kadar izlenebilir. Reviewer yalnızca tek request'i değil, aynı helper'ı çağıran bütün code path'leri araştırabilir.

Sızma testi bu zafiyeti bir endpoint'te kanıtlayabilir. Kaynak kod analizi ise hatanın hangi reusable component'ten yayıldığını gösterir.

2. Ulaşılması zor ve koşula bağlı kod yolları

Bazı kodlar yalnızca şu koşullarda çalışır:

• Belirli bir feature flag açıksa
• Eski bir API version kullanılıyorsa
• Yalnızca administrator veya support role'ünde
• Belirli bir tenant configuration'ında
• Queue'dan özel bir message geldiğinde
• Ay sonu, batch kapanışı veya retry sırasında
• Beklenmeyen exception oluştuğunda
• Normal UI içinde bağlantısı olmayan bir route çağrıldığında

Sızma testinin bu yolların tamamını keşfetmesi ve gerekli state'i üretmesi her zaman mümkün değildir. Kaynak kod analizi route registration, feature flag branch, worker consumer ve error handling path'lerini doğrudan görebilir.

Bu durum özellikle “şu anda erişilemiyor” ile “uygulamada yok” arasındaki fark için önemlidir. Bugün kapalı olan bir feature flag yarın açılabilir. Unutulmuş bir endpoint yeni gateway kuralıyla dışarı açılabilir. Latent weakness üretimde aktif hale geldiğinde daha önce temiz sonuçlanan pentest raporu bunu önceden haber vermemiş olur.

3. Authorization kararının gerçek implementation'ı

Authorization problemi çoğu zaman tek bir if eksikliğinden ibaret değildir. Kontrol controller, middleware, service, repository ve policy engine arasında dağılmış olabilir.

Manual Source Code Review şu sorulara cevap arayabilir:

• Object ownership hangi katmanda doğrulanıyor?
• Tenant ID kullanıcı girdisinden mi, authenticated context'ten mi geliyor?
• Ortak middleware bütün route'lara gerçekten uygulanmış mı?
• Admin bypass hangi role veya claim ile çalışıyor?
• Service-to-service çağrılarda user context kayboluyor mu?
• Toplu işlem endpoint'i tekil işlemle aynı policy'yi kullanıyor mu?
• Cache key içinde tenant veya user ayrımı var mı?
• Deny kararı exception sonrası fail-open hale geliyor mu?

Sızma testi iki veya daha fazla account ile authorization açığını gösterebilir. Kod analizi, bu açığın hangi güvenlik varsayımının bozulmasından doğduğunu ve aynı varsayımın nerelerde tekrarlandığını açığa çıkarır.

4. Cryptography ve key handling

Bir dış test, verinin şifreli göründüğünü veya token'ın değiştirildiğinde reddedildiğini gösterebilir. Fakat implementation içinde kullanılan algorithm, mode, IV üretimi, key derivation, random source ve key lifecycle her zaman response üzerinden anlaşılamaz.

Kaynak kod analizi şu problemleri daha doğrudan görebilir:

• Sabit veya tahmin edilebilir IV
• Aynı nonce'ın yeniden kullanılması
• Encryption olup integrity koruması olmaması
• Güvenli olmayan random generator
• Key'in source code içinde bulunması
• Bütün tenant'lar için aynı key'in kullanılması
• Password hashing için uygunsuz veya düşük maliyetli parametreler
• Custom cryptographic scheme geliştirilmesi
• Certificate validation'ın devre dışı bırakılması
• Key rotation sonrası eski veriye erişimin hatalı ele alınması

Pentest bunların bir bölümünün pratik etkisini gösterebilir. Fakat bütün cryptographic implementation'ı yalnızca black box davranıştan güvenilir biçimde çıkarmak çoğu zaman mümkün değildir.

5. Fail-open ve exception path'leri

Bir security control hata verdiğinde ne olur? Identity provider zaman aşımına uğradığında işlem durur mu, yoksa kullanıcıya izin mi verilir? Policy service ulaşılamadığında varsayılan karar nedir? Signature verification bir exception ürettiğinde code path doğrulamayı atlar mı?

Bu tür fail-open davranışlar normal test koşullarında tetiklenmeyebilir. Kaynak kod analizi catch, fallback, retry ve default branch'leri sistematik biçimde inceleyebilir. Sızma testi ancak ilgili dependency kontrollü olarak bozulabiliyor veya failure state üretilebiliyorsa runtime kanıt sağlayabilir.

6. Repo genelindeki hatalı pattern

Bir pentest bulgusu çoğunlukla görülen endpoint ve doğrulanan senaryo üzerinden raporlanır. Kaynak kodunda ise aynı anti-pattern aranabilir.

Örneğin pentest /api/invoices/{id} üzerinde IDOR buldu. Yalnızca bu endpoint'i düzeltmek yeterli olmayabilir. Reviewer, findById(id) çağrısının ownership filter olmadan kullanıldığı bütün yerleri arayabilir. Böylece invoice, export, attachment, notification ve archive işlemlerindeki aynı kök neden tek çalışma içinde tespit edilebilir.

Bu yaklaşım “bulguyu kapatmak” ile “vulnerability class'ı sistemden kaldırmak” arasındaki farktır.

7. Kod içine gömülmüş secret ve kasıtlı işlevler

Hardcoded credential, private key, API token, debug bypass, test account veya gizli administrative branch dışarıdan hiçbir belirti vermeyebilir. Secret scanning bazı örnekleri otomatik yakalayabilir. Manual review ise obfuscation, özel encoding, koşula bağlı bypass ve beklenmeyen administrative davranışları anlamlandırabilir.

Buradaki önemli ayrım şudur: Kodda bir secret bulunması yüksek önemde bir bulgudur, fakat secret'ın hâlâ aktif olup olmadığı, hangi ortamda geçerli olduğu ve hangi yetkiye sahip olduğu runtime veya kontrollü doğrulama gerektirir.

Kaynak kod analizi neyi kaçırabilir?

Kaynak koduna erişmek güçlü bir görünürlük sağlar, fakat çalışan sistemin tam kopyasını vermez. Kod güvenli göründüğü halde üretimde ciddi açık bulunmasının birçok makul nedeni vardır.

İncelenen commit ile deployed artifact farklı olabilir

Kaynak kod analizinde en kritik scope bilgilerinden biri commit hash'tir. Reviewer main branch'in güncel halini incelerken production üç hafta önceki bir build'i çalıştırıyor olabilir. Ya da production image, repo dışında yürütülen bir build step ile değiştirilmiş olabilir.

Şu uyumsuzlukların her biri sonucu etkiler:

• Yanlış branch veya eski tag incelenmesi
• Production hotfix'inin repository'ye dönmemesi
• CI/CD sırasında farklı environment file kullanılması
• Build aşamasında code generation yapılması
• Container image içine farklı package sürümü alınması
• Runtime patch veya plugin eklenmesi
• Frontend source map ile gerçek bundle'ın farklı olması
• Infrastructure repository'nin scope dışında bırakılması

Bu nedenle kaynak kod raporu “uygulamanın production hali güvenlidir” demeden önce analyzed commit ile deployed artifact arasında traceability kurmalıdır.

Runtime configuration görünmeyebilir

Repository içinde güvenli default'lar bulunabilir, ancak production environment variable bunları override edebilir. secure=true tanımlanan cookie farklı proxy header davranışı nedeniyle yanlış üretilebilir. CORS policy deploy sırasında wildcard hale gelmiş olabilir. Debug mode yalnızca production profile'da açık kalmış olabilir.

Kod analizi configuration mekanizmasını ve riskli option'ları görür. Sızma testi hedef ortamda hangi option'ın fiilen etkili olduğunu davranış üzerinden sınar.

Network ve cloud permission etkisi eksik kalabilir

SSRF'in gerçek etkisi yalnızca kodda URL fetch yapılmasına bağlı değildir. Uygulamanın egress erişimi, metadata service koruması, DNS davranışı ve internal network segmentation sonucu değiştirir. Aynı kod development ortamında düşük, production cloud account'unda kritik risk oluşturabilir.

Benzer şekilde application code yalnızca bir storage client çağrısı yapar. O client'ın kullandığı workload identity gereğinden geniş IAM yetkisine sahipse blast radius kaynak kod deposundan tek başına anlaşılamayabilir.

Üçüncü taraf ve managed service davranışı bilinmeyebilir

Payment provider, identity service, CDN, API gateway veya managed database üzerinde yapılan ayarlar source repository'nin dışında tutulabilir. Authentication akışındaki redirect URI problemi uygulama kodundan değil provider panelindeki configuration'dan doğabilir.

Kaynak kod analizi entegrasyonun nasıl çağrıldığını gösterir. Sızma testi, sistemler arasındaki gerçek etkileşimde güven sınırının korunup korunmadığını test eder.

Gerçek exploitability ve business impact her zaman kanıtlanamaz

Kod üzerinde tehlikeli bir sink'e ulaşan input bulunabilir. Fakat önündeki gateway validation, runtime sanitizer veya database permission saldırıyı engelliyor olabilir. Bu durum source finding'i yok etmez, fakat güncel exploitation olasılığını ve severity değerlendirmesini değiştirir.

Kaynak kod analizi tek başına “bu açık üzerinden production customer verisi okunabilir” sonucuna atlamamalıdır. Bu iddia için koşulların doğrulanması gerekir.

Sızma testi neyi kaynak kod analizinden daha iyi gösterir?

Sızma testinin temel gücü, bileşenleri ayrı ayrı değil çalışan sistemi bir bütün olarak sınamasıdır. Kod, configuration, identity, network ve gerçek data state aynı request zincirinde buluşur.

1. Gerçek attack surface

Repository'de yüzlerce route tanımlı olabilir. Fakat hangilerinin internete açık olduğu, hangilerinin gateway arkasında kaldığı ve hangi legacy host'un hâlâ cevap verdiği deployment ile belirlenir.

Sızma testi reconnaissance ve attack surface mapping ile şunları görebilir:

• Unutulmuş subdomain ve API version
• Public olması beklenmeyen management endpoint
• Eski deployment veya staging ortamı
• Swagger, GraphQL introspection veya debug interface
• Farklı host header ile erişilen virtual host
• CDN origin exposure
• Authentication uygulanmamış service endpoint
• Mobile API'nin web uygulamasından farklı davranması

Source code bu endpoint'lerin varlığını gösterebilir. Fakat hangisinin gerçekten dışarıdan erişilebilir olduğunu ancak ortam bilgisi veya runtime testi doğrular.

2. Exploit zinciri

Tek bir weakness düşük önem taşıyabilir. Birkaç küçük problem birleştiğinde kritik bir attack path oluşabilir.

Örneğin:

1. 1Kullanıcı listesinde e-mail adresleri tahmin edilebiliyor.
2. 2Rate limit yalnızca IP bazında uygulanıyor ve proxy header üzerinden aşılabiliyor.
3. 3Password reset token'ı referer üzerinden üçüncü tarafa sızıyor.
4. 4Yeni oturum açıldığında eski session iptal edilmiyor.

Kod analizi bu parçaları farklı module'lerde ayrı bulgular olarak görebilir. Pentester gerçek workflow boyunca ilerleyerek bunların account takeover'a dönüştüğünü kanıtlayabilir. Bu zincir, riskin business impact üzerinden anlaşılmasını sağlar.

3. Rol, tenant ve state etkileşimi

Business logic açığı çoğu zaman “zararlı karakter gönderildi ve hata alındı” biçiminde ortaya çıkmaz. İki kullanıcı, bir approval state, belirli sıra ve zamanlama gerekir.

Sızma testi şu senaryoları gerçek hesaplarla yürütebilir:

• Kullanıcı A'nın oluşturduğu kaydı Kullanıcı B'nin güncellemesi
• Düşük yetkili kullanıcının admin workflow'unu doğrudan çağırması
• Onaylanan işlemin parametresini onay sonrası değiştirme
• İptal edilen kuponu eşzamanlı request'lerle birden fazla kullanma
• Tenant değiştirirken cache üzerinden eski tenant verisini alma
• Invite akışını kötüye kullanarak yetki yükseltme
• File upload ile background processor arasında content-type uyuşmazlığı oluşturma

Manual code review business rule'ı ve eksik kontrolü bulabilir. Pentest ise sistemin state transition'larını gerçekte nasıl ele aldığını gösterir.

4. Koruyucu kontrollerin gerçek etkisi

Kodda SQL injection pattern'i bulunması önemli bir sinyaldir. Fakat endpoint'in önündeki allowlist validation saldırı karakterlerini reddediyor olabilir. WAF belirli payload'ları engelleyebilir. Database account yalnızca sınırlı tabloya read izni taşıyabilir.

Sızma testi şu ayrımları yapmaya yardımcı olur:

• Weakness ulaşılabilir mi?
• Authentication gerekiyor mu?
• Hangi role gerekiyor?
• Koruyucu kontrol güvenilir mi, bypass edilebiliyor mu?
• Exploit yalnızca error üretmekle mi kalıyor?
• Data extraction, modification veya privilege escalation mümkün mü?
• Etki tek tenant ile mi sınırlı?
• Aynı payload farklı encoding ile çalışıyor mu?

Bu bilgiler severity'nin yalnızca weakness sınıfına göre değil gerçek koşullara göre belirlenmesini sağlar.

5. Deployment ve integration hataları

Production'da bulunan birçok önemli açık source line ile eşleştirilemez. Hatalı cloud storage policy, yanlış CORS ayarı, açık management port, default credential, debug mode, zayıf TLS configuration veya reverse proxy kaynaklı authentication bypass buna örnektir.

Sızma testi çalışan hedefi incelediği için “kod doğru, sistem yanlış” durumunu ortaya çıkarabilir.

Sızma testi neyi kaçırabilir?

Sızma testi gerçek sisteme dokunduğu için bazen bütün güvenlik problemlerini bulacağı düşünülür. Bu beklenti teknik olarak gerçekçi değildir. Pentest, belirli scope ve zaman içinde mümkün olan en değerli attack path'leri arar. Matematiksel olarak eksiksiz bir kanıt sunmaz.

Erişilemeyen kod test edilemez

Pentester bir route'u, parameter'ı, role'ü veya state'i bilmiyorsa o code path'e ulaşamayabilir. Endpoint yalnızca internal queue message ile çalışıyorsa dış yüzeyden test edilemez. Feature flag kapalıysa arkasındaki zafiyet görünmez.

Kaynak kod analizi ise route ve call graph üzerinden bu alanı inceleyebilir.

Zaman sınırlı olduğu için bütün kombinasyonlar denenemez

Beş role, on tenant tipi, yüzlerce endpoint ve binlerce parameter bulunan bir uygulamada bütün kombinasyonları manuel test etmek mümkün değildir. Risk bazlı örnekleme yapılır. Bu yaklaşım değerlidir, fakat coverage sınırını raporda açıkça belirtmek gerekir.

“Bulgu bulunmadı” ifadesi hiçbir zaman “açık yok” anlamına gelmez. Daha doğru ifade şudur:

Root cause yanlış tahmin edilebilir

Black box testte aynı response birden fazla nedenden oluşabilir. Authorization bypass controller'daki eksik kontrolden, cache key hatasından, gateway route kuralından veya policy engine'deki yanlış eşlemeden kaynaklanabilir.

Pentester saldırıyı güvenilir biçimde tekrarlar ve etkisini kanıtlar. Fakat source code olmadan kesin remediation noktası hakkında yalnızca çıkarım yapabilir. Yanlış root cause üzerine yapılan dar bir düzeltme açığın başka varyantlarını bırakabilir.

Tek örnek bulunur, sistemik yayılım görülmeyebilir

Bir reflected XSS, IDOR veya unsafe file operation tek endpoint'te kanıtlandığında rapora girer. Benzer implementation'ın diğer module'lerde de bulunup bulunmadığı pentest sırasında tam olarak anlaşılamayabilir.

Kaynak kod analizi aynı function, annotation, helper veya query pattern'ini repository boyunca arayarak systemic remediation sağlayabilir.

Güvenli görünen dış davranış hatalı implementation'ı saklayabilir

Bir endpoint dışarıdan saldırıyı reddediyor olabilir. Fakat bunu yanlış katmandaki geçici bir kontrol sağlıyor olabilir. Yarın gateway kuralı değiştiğinde alttaki unsafe code doğrudan açığa çıkar.

Pentest mevcut koruma katmanını doğrular. Kaynak kod analizi defense in depth var mı, yoksa güvenlik tek bir çevresel kontrole mi bağlı sorusunu yanıtlar.

Aynı vulnerability sınıfı iki çalışmada nasıl farklı görünür?

Teorik ayrımın en iyi karşılığı teknik örneklerde görülür.

SQL injection

Kaynak kod analizi ne görür?

Reviewer untrusted input'un string concatenation ile SQL query'ye eklendiğini görür. Input farklı function'larda taşınıyorsa source-to-sink akışını izler. Aynı query helper'ın kullanıldığı bütün çağrıları belirler. Parameterized query kullanılmamasının kök nedenini gösterir.

Sızma testi ne görür?

Tester endpoint'e payload gönderir. Syntax, encoding, content type ve request structure varyasyonlarını dener. Error-based, boolean-based veya time-based davranışı doğrular. WAF ve input validation'ın bypass edilip edilemediğini araştırır. Database account'ın yetkisine bağlı olarak veri okuma veya değiştirme etkisini kontrollü biçimde kanıtlar.

Neden sonuç farklı olabilir?

Unsafe query gerçekten vardır, fakat dış input allowlist ile sayısal değere indirgeniyor olabilir. Bu durumda kod weakness'i gerçektir, mevcut attack surface üzerinden exploitability düşüktür. Tersine kodda güvenli görünen ORM kullanımı, yanlış raw query veya production'a özgü stored procedure nedeniyle runtime'da açık verebilir.

IDOR ve Broken Object Level Authorization

Kaynak kod analizi ne görür?

getDocument(id) çağrısında ownership veya tenant filter bulunmadığını, controller'ın yalnızca authentication kontrolü yaptığını ve service katmanının object-level authorization uygulamadığını görür. Aynı repository method'unu kullanan bütün endpoint'leri bulabilir.

Sızma testi ne görür?

İki account ile nesne oluşturur. Birinci kullanıcıya ait ID'yi ikinci kullanıcının request'ine yerleştirir. Read, update, delete, export ve attachment işlemlerini ayrı ayrı test eder. Numeric ID tahmini gerekmese bile UUID'nin başka response'lardan sızıp sızmadığını araştırır. Gerçek cross-user veya cross-tenant etkiyi kanıtlar.

Neden sonuç farklı olabilir?

Ownership kontrolü kodda görünmeyen policy gateway'de uygulanıyor olabilir. Ya da kodda genel bir authorization middleware vardır, fakat belirli route registration sırasında middleware atlanmıştır. Birinci senaryoyu runtime doğrulama, ikinci senaryoyu hem route incelemesi hem pentest yakalayabilir.

SSRF

Kaynak kod analizi ne görür?

Kullanıcı kontrollü URL'nin HTTP client'a gönderildiğini, validation'ın yalnızca string prefix kontrolü yaptığını, redirect sonrası host'un yeniden doğrulanmadığını veya DNS resolution sonrasında private IP kontrolü yapılmadığını görür. URL parser farklılıklarını ve allowlist implementation'ını inceleyebilir.

Sızma testi ne görür?

Uygulamanın dış bir interaction server'a istek gönderdiğini kanıtlar. Redirect, alternative IP notation, DNS rebinding ve protocol variation senaryolarını scope içinde test eder. Internal host, cloud metadata veya yönetim servisine network erişiminin mümkün olup olmadığını güvenli yöntemlerle doğrular.

Neden sonuç farklı olabilir?

Vulnerable sink kodda vardır, fakat production egress policy bütün internal destination'ları engelliyor olabilir. Bu, weakness'i ortadan kaldırmaz fakat mevcut blast radius'u sınırlar. Diğer tarafta development'ta kısıtlı olan service account production'da geniş network erişimine sahip olabilir.

Insecure deserialization

Kaynak kod analizi ne görür?

Untrusted data'nın native deserialization API'sine ulaştığını, type restriction bulunmadığını veya polymorphic deserialization'ın geniş biçimde etkinleştirildiğini görür. Hangi class'ların ve custom converter'ların süreçte yer aldığını araştırır.

Sızma testi ne görür?

İlgili input formatını ve endpoint'i belirler. Runtime classpath'te kullanılabilir gadget bulunup bulunmadığını, signature veya integrity control'ün uygulanıp uygulanmadığını ve güvenli bir PoC ile code execution dışındaki etkileri test eder.

Neden sonuç farklı olabilir?

Dangerous API kullanımı vardır, fakat input güçlü bir signature ile yalnızca trusted producer'dan kabul ediliyordur. Tersine source review'e verilmeyen bir plugin, runtime'a exploitable class eklemiş olabilir.

Hardcoded secret

Kaynak kod analizi ne görür?

Repository history veya current source içinde credential, token, private key ya da connection string bulur. Secret'ın hangi service tarafından kullanıldığını ve log, test fixture veya sample configuration yoluyla nasıl yayıldığını inceler.

Sızma testi ne görür?

Secret public asset, JavaScript bundle, mobile package, error response veya accessible configuration dosyasından elde edilebiliyorsa bunun erişilebilirliğini kanıtlar. Yetkili ve güvenli doğrulama koşullarında credential'ın aktifliğini ve sahip olduğu privilege'i belirler.

Neden sonuç farklı olabilir?

Kodda bulunan secret revoke edilmiş olabilir. Bu yine de secret management sürecindeki sorunu gösterir. Pentestte bulunan aktif credential ise repository dışında deployment sırasında enjekte edilmiş veya yanlışlıkla public artifact'a eklenmiş olabilir.

Cryptography hatası

Kaynak kod analizi ne görür?

Reviewer algorithm selection, mode, key derivation, salt, IV, nonce, entropy ve key storage kararlarını inceler. Aynı key'in farklı amaçlarda kullanılması veya encryption ile authentication'ın yanlış birleştirilmesi gibi yapısal sorunları bulabilir.

Sızma testi ne görür?

Token ve ciphertext davranışını karşılaştırır. Replay, tampering, predictable output ve padding davranışlarını test eder. Hatanın gerçek bir privilege escalation veya data disclosure üretip üretmediğini araştırır.

Neden sonuç farklı olabilir?

Weak algorithm kullanımı teknik borç ve güvenlik riskidir, fakat kısa ömürlü ve düşük değerli data nedeniyle anlık impact sınırlı olabilir. Buna karşılık güçlü algorithm yanlış nonce yönetimiyle kullanılıyorsa pazarlama dokümanında “AES kullanıyoruz” denmesine rağmen sistem kırılabilir.

Race condition

Kaynak kod analizi ne görür?

Balance check ile update arasındaki işlemlerin atomic olmadığını, transaction isolation'ın yetersiz kaldığını veya distributed lock'ın yanlış key ile alındığını görür. Thread, process ve node sınırlarını hesaba katarak problemli critical section'ı belirler.

Sızma testi ne görür?

Aynı kupon, ödeme, para transferi veya stok işlemi için eşzamanlı request'ler gönderir. Bir kez gerçekleşmesi gereken işlemin iki kez tamamlandığını ve finansal ya da operasyonel etkiyi kanıtlar.

Neden sonuç farklı olabilir?

Kod üzerinde riskli görünen akış database constraint ile korunuyor olabilir. Ya da application transaction doğru görünürken message consumer'ın retry davranışı duplicate processing oluşturabilir. Runtime testi, dağıtık sistemde ortaya çıkan sonucu gösterir.

Stored ve second-order vulnerability

Kaynak kod analizi ne görür?

Input'un bir aşamada database'e kaydedilip başka bir component tarafından farklı context'te işlendiğini takip eder. Örneğin kullanıcı adı güvenli biçimde saklanır, fakat admin export ekranında spreadsheet formula olarak yorumlanır.

Sızma testi ne görür?

Payload'u bir workflow üzerinden kaydeder, background job veya farklı role tarafından işlendiği sonraki adımı tetikler ve gerçek second-order etkiyi doğrular.

Neden sonuç farklı olabilir?

Kod analizi data lineage'ı görür fakat production'daki downstream integration scope dışında olabilir. Pentest ise entegrasyonu tetikleyebilir, fakat payload'un geçtiği bütün internal dönüşümleri kaynak kod olmadan açıklayamayabilir.

Deployment drift

Kaynak kod analizi ne görür?

Repository'de debug kapalı, güvenli headers etkin ve authentication doğru tanımlanmış olabilir. İncelenen commit bu yönüyle sorun göstermeyebilir.

Sızma testi ne görür?

Production benzeri ortamda stack trace döndüğünü, eski JavaScript bundle'ın servis edildiğini, yanlış gateway route nedeniyle internal API'nin açık olduğunu veya security header'ın reverse proxy tarafından kaldırıldığını gösterir.

Neden sonuç farklı olabilir?

Sorun application source içinde değildir. Build, release ve runtime configuration arasındaki farktan doğmuştur. İşte bu örnek, neden yalnızca kaynak kod analizine dayanarak production exposure hakkında kesin hüküm verilemeyeceğini açık biçimde gösterir.

“Kodda var ama exploit edilemiyor” ne anlama gelir?

Bu ifade genellikle yanlış yorumlanır. Bir source finding'in test sırasında exploit edilememesi üç farklı durumu gösterebilir:

1. 1Yanlış pozitif: Tool data flow'u yanlış kurmuştur veya reviewer bağlamı eksik değerlendirmiştir. Gerçekte weakness yoktur.
2. 2Mevcut koruyucu kontrol: Weakness vardır, fakat başka bir kontrol bugünkü attack path'i kesmektedir. Risk düşebilir, ancak defense in depth zayıftır.
3. 3Test koşulu yetersizliği: Gerekli role, state, feature flag, data veya network path pentest kapsamında yoktur. Exploit edilememesi güvenli olduğu anlamına gelmez.

Bu üç duruma aynı remediation kararı verilmez.

Yanlış pozitif kapatılır ve tool tuning'e girdi olur. Mevcut koruyucu kontrol varsa alttaki unsafe implementation yine düzeltilir veya control dependency açıkça risk kabulüne bağlanır. Test koşulu yetersizse ek doğrulama planlanır.

Severity belirlerken şu ayrımı korumak gerekir:

• Weakness severity: Kod yapısının ne kadar tehlikeli olduğu
• Exploitability: Saldırganın gerekli koşulları ne ölçüde sağlayabildiği
• Business impact: Başarılı exploitation'ın kuruma ve kullanıcıya etkisi
• Compensating control strength: Attack path'i kesen kontrolün güvenilirliği ve bağımsızlığı
• Exposure lifetime: Feature veya route açıldığında riskin değişip değişmeyeceği

Pentest sonucu, source finding'in riskini bağlamlandırır. Onu otomatik olarak silmez.

“Pentest temiz ama kodda açık var” ne anlama gelir?

Bu sonuç da beklenebilir. Sızma testinin bulamadığı source finding şu nedenlerden biriyle görünmemiş olabilir:

• Vulnerable endpoint keşfedilmemiştir
• Gerekli user role verilmemiştir
• Feature flag kapalıdır
• Test datası gerekli state'i oluşturmuyordur
• Exploit özel timing veya concurrency gerektiriyordur
• WAF payload'u engelliyordur
• Attack path yalnızca internal service üzerinden çalışıyordur
• Pentest süresi bütün kombinasyonlara yetmemiştir
• İlgili kod henüz deployed build içinde değildir

Dolayısıyla temiz pentest raporu, kaynak kod bulgusunu geçersiz kılan bir sertifika değildir. İki çalışma arasındaki fark triage edilmelidir. Bulgular aynı asset, version, route, role ve configuration üzerinde eşleştirilmeden karşılaştırma yapılmamalıdır.

White box pentest ile kaynak kod analizi aynı şey mi?

Hayır. White box pentest, tester'a source code, mimari doküman, API specification, test account, network diagram veya developer açıklaması gibi iç bilgilerin verildiği sızma testi yaklaşımıdır. Tester bu bilgileri daha isabetli attack case üretmek için kullanır.

Kaynak kod analizi ise source code'un güvenlik gereksinimlerine göre sistematik biçimde incelenmesidir. White box pentester kodu belirli attack path'leri hızlandırmak amacıyla okuyabilir. Bu, bütün kritik module'lerin code review coverage'ına alındığı anlamına gelmez.

Aradaki fark deliverable'da da görülür:

• White box pentest, exploit edilebilir route ve business impact merkezli rapor üretir.
• Kaynak kod analizi, file, function, data flow, root cause ve repo genelindeki pattern merkezli rapor üretir.

En verimli model, bu iki çalışmayı birbirine bilgi sağlayacak biçimde tasarlamaktır. OWASP Code Review Guide bu karşılıklı beslemeyi “360 review” yaklaşımıyla açıklar. Code review bulguları pentest senaryolarını yönlendirir. Pentestte doğrulanan bir açık da aynı pattern'in kod tabanındaki diğer örneklerini aramak için review'e geri döner.

İki yöntem birlikte nasıl uygulanmalı?

Kaynak kod analizi ve sızma testini ayrı satın alma kalemleri olarak görmek kolaydır. Güvenlik değerini artıran yaklaşım ise iki çalışmanın evidence'ını ilişkilendirmektir.

1. Security requirement ve threat model'i netleştirin

Test başlamadan önce korunacak asset'ler, user role'leri, trust boundary'ler, yüksek riskli workflow'lar ve kabul edilmeyen abuse case'ler belirlenmelidir.

Örneğin yalnızca “OWASP Top 10 kontrol edilecek” demek bir B2B SaaS için yeterli değildir. Şunlar daha ölçülebilir gereksinimlerdir:

• Bir tenant başka tenant'ın object ID'sini bilse bile veriye erişememeli
• Support role payment detail'i görememeli
• Webhook yalnızca doğrulanmış provider request'lerini işlemeli
• Password reset token'ı tek kullanımlık ve kısa ömürlü olmalı
• Export işlemi formula injection üretmemeli
• URL fetch özelliği private network destination'larına ulaşamamalı

Bu gereksinimler hem kod üzerinde hem runtime'da farklı test case'lere dönüştürülebilir.

2. Artifact ve version eşleşmesini kurun

Kaynak kod analizi ve pentest aynı release'i değerlendirmiyorsa bulgular sağlıklı biçimde korele edilemez.

Minimum traceability seti şunları içermelidir:

• Repository ve commit hash
• Build number ve artifact digest
• Container image digest
• Dependency lock file
• Deployment environment ve tarih
• Etkin feature flag listesi
• Relevant infrastructure configuration version
• Test edilen API ve frontend version'ı

Mümkünse CI/CD sistemi, analyzed commit'ten üretilen artifact'ın test ortamına deploy edildiğini doğrulamalıdır. Aksi halde “kodda düzeltildi ama pentestte hâlâ var” tartışması version belirsizliğine dönüşür.

3. Otomatik analizleri doğru amaçla çalıştırın

SAST, secret scanning ve Software Composition Analysis erken aşamada geniş görünürlük sağlar. Ancak üçü de farklı veri üretir:

• SAST: First-party code içindeki potential weakness'ler
• Secret scanning: Credential ve key olabilecek değerler
• Software Composition Analysis: Third-party component ve dependency riskleri

Tool çıktıları doğrudan final rapora taşınmamalıdır. False positive, generated code, test fixture, reachability, framework control ve business context değerlendirilmelidir.

4. Manual Source Code Review ile yüksek riskli yolları inceleyin

Her satıra aynı yoğunlukta bakmak yerine risk bazlı önceliklendirme yapılmalıdır. Authentication, authorization, tenant isolation, payment, file handling, deserialization, cryptography, webhook, administrative function ve external request üreten module'ler öne alınabilir.

Reviewer ayrıca SAST'in işaretlemediği tasarım sorularını araştırmalıdır:

• Trust boundary yanlış mı kurulmuş?
• User-controlled identifier yetki kararında kullanılıyor mu?
• Kritik işlem birden fazla service arasında atomicity kaybediyor mu?
• Security control tek bir middleware'e aşırı bağımlı mı?
• Hata durumunda default karar güvenli mi?
• Audit log kritik olayın kim tarafından yapıldığını gösterebiliyor mu?

5. Code-informed pentest planlayın

Kod analizinden gelen bilgiler pentest scope'unu daraltmak için değil, test derinliğini artırmak için kullanılmalıdır.

Örnek yönlendirmeler:

• Riskli query builder kullanan endpoint'lere özel injection testleri
• Ownership kontrolü dağınık module'lerde cross-tenant testler
• URL fetch helper'ı kullanan bütün feature'larda SSRF testleri
• Custom token parser için tampering ve replay senaryoları
• Non-atomic payment method için concurrency testleri
• Error handling branch'leri için dependency failure senaryoları

Bu yaklaşım tester'ın yalnızca yaygın payload listesi çalıştırmasını engeller ve uygulamaya özgü attack case üretmesini sağlar.

6. Pentest bulgusunu kod tabanına geri taşıyın

Pentestte bir vulnerability doğrulandığında yalnızca görülen endpoint düzeltilmemelidir. İlgili code pattern tanımlanmalı ve repository genelinde aranmalıdır.

Örneğin bir endpoint'te output encoding eksikliği bulunduysa şu sorular sorulmalıdır:

• Aynı template helper başka nerede kullanılıyor?
• Aynı component farklı output context'lerinde render ediliyor mu?
• Mobile API veya admin panel aynı veriyi işliyor mu?
• Framework'ün auto-escaping özelliği nerelerde devre dışı?
• Bu vulnerability için regression test yazılabilir mi?

Bu geri besleme, tek bir exploit'i kalıcı engineering iyileştirmesine dönüştürür.

7. Retest ve regression control uygulayın

Remediation sonrası iki ayrı doğrulama gerekebilir.

Kaynak kod tarafında fix'in unsafe pattern'i kaldırdığı ve başka code path'i bozmadığı kontrol edilir. Runtime tarafında exploit adımları tekrar edilir, bypass varyasyonları denenir ve deployed artifact'ın gerçekten düzeltmeyi içerdiği doğrulanır.

Uygun bulgular unit test, integration test veya security regression test'e dönüştürülmelidir. Aksi halde sonraki refactor aynı açığı yeniden üretebilir.

Hangisi önce yapılmalı?

Tek bir sıra bütün projeler için doğru değildir. En uygun sıralama, uygulamanın yaşam döngüsüne ve mevcut görünürlüğe bağlıdır.

Development devam ederken kaynak kod analizi önce

Uygulama aktif geliştiriliyorsa source review ve SAST erken başlamalıdır. Bu sayede unsafe pattern production'a taşınmadan düzeltilir. Release candidate oluştuğunda sızma testi aynı güvenlik gereksinimlerini runtime'da doğrular.

Bu sıra özellikle şu durumlarda güçlüdür:

• Yeni ürün veya büyük feature geliştiriliyorsa
• Kritik authorization modeli kuruluyorsa
• Payment, identity veya sensitive data işleniyorsa
• Custom protocol veya cryptography kullanılıyorsa
• Aynı code pattern birçok module'e yayılabilecekse

Legacy sistemde sızma testi önce başlayabilir

Dokümantasyonu zayıf, kod tabanı çok büyük ve attack surface'i belirsiz bir legacy uygulamada pentest ilk önceliği belirleyebilir. Runtime'da doğrulanan riskli alanlar daha sonra odaklı code review için giriş sağlar.

Bu, kaynak kod analizinin gereksiz olduğu anlamına gelmez. İlk pentest, nereye daha derin bakılması gerektiğini gösteren reconnaissance katmanı olur.

Kritik release öncesi paralel ve koordineli çalışma

Yüksek riskli bir uygulamada iki çalışma aynı release candidate üzerinde paralel yürüyebilir. Burada önemli olan ekiplerin birbirinden kopuk çalışmamasıdır. Kısa ve düzenli finding exchange, iki tarafın test case'lerini geliştirmesini sağlar.

Paralel modelde dikkat edilmesi gereken nokta, pentest ekibinin source finding'leri görmeden önce bağımsız attack surface incelemesi de yapmasıdır. Böylece sadece bilinen hypothesis'leri doğrulayan dar bir test oluşmaz.

Incident sonrası farklı sıra

Aktif veya yakın zamanda yaşanmış bir olayda ilk hedef root cause'tan önce containment ve gerçek exposure'ın anlaşılmasıdır. Log, deployed artifact, active credential, network path ve indicator'lar incelenir. Ardından source code üzerinde aynı kök nedenin ve benzer backdoor ya da weakness pattern'lerinin yayılımı araştırılır.

Incident sonrası standart bir pentest tek başına forensic investigation yerine geçmez. Ancak güvenli hale getirilen ortamda kalan attack path'leri doğrulamak için kullanılabilir.

Hangi senaryoda hangi çalışma öncelikli?

Scope doğru kurulmazsa iki çalışma da yanıltır

Kaliteli sonuç yalnızca tester'ın yeteneğine değil, scope'un doğruluğuna da bağlıdır.

Kaynak kod analizi için gerekli girdiler

En azından şu bilgiler sağlanmalıdır:

• İncelenecek repository, branch, tag ve commit
• Uygulamanın nasıl build edildiği
• Generated code ve third-party code sınırları
• Mimari diagram ve ana data flow'lar
• User role ve tenant modeli
• Authentication ve authorization yaklaşımı
• Kritik business workflow'lar
• External service ve trust boundary'ler
• Configuration şeması ve secret kullanım yöntemi
• Bilinen riskler ve önceki güvenlik bulguları
• Scope dışı module'ler ve gerekçeleri

Milyonlarca satırlık repository için “tüm kod incelenecek” ifadesi tek başına yeterli değildir. Manual review coverage'ı file count üzerinden değil riskli component, data flow, security control ve use case üzerinden tanımlanmalıdır.

Sızma testi için gerekli girdiler

Sızma testinde ise şu bilgiler sonucu doğrudan etkiler:

• Test edilecek kesin URL, IP, API ve application listesi
• Environment'ın production ile farkları
• Her önemli role için test account
• Birden fazla tenant veya organization hesabı
• Test datası oluşturma ve temizleme yöntemi
• Rate limit veya account lockout koordinasyonu
• Third-party sistemlere ilişkin test sınırları
• İzin verilen exploitation seviyesi
• Hassas işlemler için Rules of Engagement
• Monitoring ekibinin bilgilendirilme şekli
• Test penceresi ve operasyonel kısıtlar

Yalnızca tek administrator hesabı verilen bir testte horizontal privilege escalation yeterince değerlendirilemez. Yalnızca UI URL'si scope'a yazılıp API inventory verilmezse unutulmuş endpoint'ler kapsam dışında kalabilir.

İyi raporlar nasıl ayrışır?

İki hizmetin raporu aynı template'in kopyası olmamalıdır. Çünkü ürettikleri evidence farklıdır.

Kaynak kod analizi raporunda ne olmalı?

• Etkilenen repository, commit, file, class ve function
• Weakness'in güvenlik gereksinimiyle ilişkisi
• Untrusted source ve tehlikeli sink
• İlgili control flow veya data flow
• Exploit için gereken koşullar
• Aynı pattern'in diğer örnekleri
• CWE ve gerekliyse OWASP ASVS eşlemesi
• False positive değerlendirmesi
• Root cause
• Güvenli implementation önerisi
• Fix'in nasıl doğrulanacağı
• Manual review ve tool coverage sınırları

Yalnızca “XSS bulundu, input validate edin” şeklindeki bulgu developer'a yeterli bilgi vermez. Output context, encoding noktası, affected template ve doğru remediation pattern açıklanmalıdır.

Sızma testi raporunda ne olmalı?

• Etkilenen asset, host, endpoint ve role
• Ön koşullar
• Tekrarlanabilir adımlar
• Maskelenmiş request ve response evidence'ı
• Kontrollü PoC
• Doğrulanan technical impact
• Business impact
• Attack complexity ve privilege gereksinimi
• Compensating control gözlemi
• Risk rating ve gerekçesi
• Remediation yönü
• Retest sonucu
• Scope ve test limitation'ları

Pentest raporu yalnızca scanner screenshot'larından oluşmamalıdır. Bir bulgunun neden gerçek olduğu ve kuruma ne yaptığı açık biçimde anlatılmalıdır.

Birleşik bulgu kaydı nasıl görünür?

İki çalışma birlikte yürütüldüğünde tek risk kaydında şu bağlantılar kurulabilir:

Bu kayıt yalnızca açığı değil, açığın nasıl kalıcı biçimde giderileceğini de anlatır.

Severity neden iki raporda farklı çıkabilir?

Aynı teknik problem kaynak kod raporunda High, pentest raporunda Medium olabilir. Ya da tam tersi yaşanabilir. Bu durum otomatik olarak raporlardan birinin yanlış olduğunu göstermez.

Farkın muhtemel nedenleri şunlardır:

• Source review gelecekte açılabilecek bütün code path'i değerlendirir, pentest mevcut exposure'a bakar
• Pentest gerçek privilege ve network koşulunu görür, source review bunları varsayar
• Kod bulgusu geniş bir pattern'e yayılmıştır, pentest yalnızca tek örneği doğrulamıştır
• Pentest exploit chain ile beklenmeyen business impact göstermiştir
• WAF veya gateway exploitability'yi geçici olarak azaltmıştır
• Source code ve tested artifact aynı version değildir
• Bir ekip CVSS, diğeri kuruma özgü risk modeli kullanmıştır

Doğru yaklaşım skorları mekanik biçimde eşitlemek değildir. Technical severity, exploitability, exposure, data classification ve business impact ortak bir risk modelinde yeniden değerlendirilmelidir.

Başarı nasıl ölçülmeli?

“Kaç bulgu çıktı?” tek başına iyi bir performans ölçütü değildir. Çok sayıda düşük kaliteli bulgu güvenliği artırmayabilir. Az sayıda bulgu da testin derin olduğunu kanıtlamaz.

Kaynak kod analizi için anlamlı metrikler

• İncelenen kritik component ve data flow oranı
• Manual olarak doğrulanan SAST finding oranı
• False positive oranı ve tuning gelişimi
• Aynı root cause'a bağlı tekrar sayısı
• Fix sonrası pattern'in repository'de kalan örnekleri
• High-risk code change için review lead time
• Security regression test'e dönüştürülen bulgu oranı
• Release öncesi yakalanan vulnerability escape oranı

Sızma testi için anlamlı metrikler

• Test edilen role ve tenant kombinasyonları
• Kapsanan kritik business workflow'lar
• Doğrulanan attack path ve chained finding sayısı
• Retestte başarılı kapatma oranı
• Aynı bulgunun sonraki release'te yeniden ortaya çıkma oranı
• Attack surface inventory ile test scope uyumu
• Ortalama remediation süresi

Birlikte izlenebilecek metrikler

• Pentest bulgularından repo genelinde bulunan ek örnek sayısı
• Source finding'lerden runtime'da doğrulananların oranı
• Compensating control'e bağımlı kalan weakness sayısı
• Production'a kaçan ve daha önce hiçbir teknik tarafından görülmeyen bulgu sınıfları
• Aynı root cause'un tekrar etme oranı
• Fix'in code review, build ve runtime doğrulamasını tamamladığı süre

Amaç ekipleri daha çok bulgu üretmeye teşvik etmek değil, unknown risk'i azaltmak ve aynı hatanın yeniden doğmasını engellemektir.

Satın alma sürecinde yapılan yaygın hatalar

Kaynak kod analizi ile sızma testinin birbirinin yerine konmasının önemli bir nedeni, hizmet kapsamlarının net yazılmamasıdır.

“Tool çalıştırıldı” ile “analiz yapıldı” sanmak

Bir SAST aracı çalıştırılıp ham sonuçlar raporlandığında işin adı kaynak kod analizi olabilir. Benzer biçimde DAST scanner çalıştırılıp sonuç export edildiğinde işin adı pentest olabilir. İki durumda da otomasyon faydalıdır, fakat uzman doğrulaması ve bağlamlandırma olmadan güvence seviyesi sınırlıdır.

Teklifte şu ayrımlar açık olmalıdır:

• Hangi tool'lar kullanılacak?
• Manual review yapılacak mı?
• Hangi component'ler uzman tarafından incelenecek?
• Business logic test edilecek mi?
• Finding'ler manuel doğrulanacak mı?
• Source-to-sink analizi yapılacak mı?
• Exploitation hangi sınırlar içinde gerçekleştirilecek?
• Fix review ve retest dahil mi?

Aynı checklist'i kullandıkları için eşdeğer sanmak

Hem kaynak kod raporu hem pentest raporu OWASP Top 10 başlıklarına referans verebilir. Bu, iki testin aynı coverage'ı sağladığı anlamına gelmez. Broken Access Control kod üzerinde policy implementation olarak, runtime'da ise role ve object manipulation olarak incelenir.

Standart taxonomy, yöntemin kendisi değildir.

Kapsamı yalnızca satır sayısıyla ölçmek

Kod tabanının büyüklüğü eforu etkiler, ancak risk yalnızca LOC ile belirlenmez. Beş yüz satırlık custom authentication component'i, elli bin satırlık düşük riskli CRUD module'ünden daha yoğun inceleme gerektirebilir.

Benzer biçimde pentest eforu yalnızca endpoint sayısıyla ölçülemez. Multi-role ve multi-tenant workflow, az endpoint'e sahip olsa bile ciddi test matrisi oluşturur.

İki ekibin hiç konuşmaması

Kaynak kod analizi ve pentest birbirinden tamamen izole yürütülürse en değerli fırsat kaybedilir. Code review'de bulunan hypothesis pentestte denenmez. Pentestte bulunan vulnerability'nin benzerleri repository'de aranmaz. Sonuçta iki ayrı PDF oluşur, fakat tek bir güvenlik kararı oluşmaz.

Version bilgisini rapora koymamak

Commit hash, artifact digest ve environment bilgisi yoksa sonuçların hangi release için geçerli olduğu belirsizdir. Aylar sonra retest yapılırken doğru code ve doğru target eşleştirilemez.

Kaynak kod gizliliği nasıl korunmalı?

Kaynak kod, kurumun en hassas varlıklarından biri olabilir. Analiz kapsamı güçlü güvenlik kontrolleriyle yürütülmelidir.

Değerlendirilmesi gereken konular şunlardır:

• Repository erişiminin least privilege ile sınırlandırılması
• Named account ve MFA kullanımı
• Erişim süresinin proje sonunda sonlandırılması
• Kodun hangi lokasyonda işlendiğinin belirlenmesi
• Local clone ve geçici artifact'ların saklama süresi
• SAST platformuna source upload edilip edilmediği
• Cloud tool kullanılıyorsa data residency ve retention şartları
• On-premise veya air-gapped çalışma ihtiyacı
• Rapor içindeki code snippet'lerin maskelenmesi
• Secret bulunduğunda izlenecek güvenli bildirim yöntemi
• Çalışma sonunda secure deletion ve erişim kanıtı

Kodun hiçbir koşulda kurum dışına çıkmaması gerekiyorsa analiz müşteri ortamında veya kontrollü on-premise altyapıda yürütülebilir. Bu kısıt, manual review ve tool seçimini teklif aşamasında belirlemelidir.

Pratik karar modeli

Bir sonraki güvenlik çalışmasını planlarken şu dört soruyla başlayabilirsiniz.

1. Çalışan bir hedef var mı?

Henüz deploy edilebilir build yoksa sızma testi mümkün değildir. Threat modeling, security requirement review, SAST ve Manual Source Code Review ile başlanır.

2. Source code'a erişim var mı?

Yoksa sızma testi en önemli teknik seçeneklerden biridir. Ancak eksik görünürlük raporda belirtilir. Vendor'dan SBOM, security architecture, previous assessment ve secure development evidence talep edilebilir.

3. Karar hangi kanıtı gerektiriyor?

“Bu query neden güvensiz?” sorusu code evidence ister. “İnternetten customer datasına ulaşılabiliyor mu?” sorusu runtime evidence ister. “Bu vulnerability sınıfı başka nerelerde var?” sorusu repo-wide review ister. “WAF gerçekten saldırıyı kesiyor mu?” sorusu runtime test ister.

4. Risk yalnızca application code'dan mı doğuyor?

Modern sistemlerde yanıt çoğunlukla hayırdır. Cloud identity, API gateway, container, third-party service ve deployment pipeline riskin parçasıdır. Bu durumda yalnızca source review yeterli olmaz. Benzer biçimde yalnızca dış yüzeyi test etmek de implementation içindeki latent weakness'leri bırakır.

Sonuç: Biri içeriyi, diğeri dışarıyı görmekten fazlasıdır

Kaynak kod analizi ile sızma testi arasındaki fark sık sık “biri koda bakar, diğeri uygulamaya saldırır” diye özetlenir. Bu tanım doğru olsa da karar vermek için yetersizdir.

Asıl fark ürettikleri kanıttadır.

Kaynak kod analizi bir weakness'in implementation içindeki kök nedenini, data flow'unu ve kod tabanına yayılımını görünür hale getirir. Bugün erişilemeyen fakat yarın aktif olabilecek riskleri bulabilir. Sızma testi çalışan sistemdeki gerçek attack surface'i, koruyucu kontrollerin etkisini, configuration farklarını ve vulnerability'nin business impact'e dönüşen exploit zincirini gösterir.

Bu iki sonuç birbirini geçersiz kılmaz. Birbirini tamamlar.

Yalnızca kaynak kod analizi yaptıran kurum, deployed sistemin gerçekten nasıl davrandığını kaçırabilir. Yalnızca sızma testi yaptıran kurum, exploit edilen tek endpoint'in arkasındaki systemic root cause'u ve kodda bekleyen diğer örnekleri göremeyebilir.

Olgun yaklaşım, iki ayrı rapor satın almak değil, iki farklı evidence türünü aynı güvenlik kararında birleştirmektir:

1. 1Güvenlik gereksinimini tanımlayın.
2. 2Aynı commit ve deployed artifact'ı eşleştirin.
3. 3SAST ve manual review ile weakness ve root cause'u bulun.
4. 4Sızma testiyle reachability, bypass ve business impact'i doğrulayın.
5. 5Pentest bulgusunun benzerlerini repository genelinde arayın.
6. 6Düzeltmeyi hem kod üzerinde hem runtime'da yeniden test edin.
7. 7Bulguyu regression control'e dönüştürün.

Secnodex, kaynak kod analizi ve sızma testi çalışmalarını birbirinden kopuk iki kontrol listesi olarak değil, aynı riskin farklı katmanlardaki kanıtları olarak ele alır. Uygulamanızın yalnızca hangi açıkları barındırdığını değil, bu açıkların nerede doğduğunu, çalışan sistemde nasıl bir etkiye dönüştüğünü ve nasıl kalıcı biçimde giderileceğini değerlendirmek için Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• OWASP Web Security Testing Guide: Source Code Review, Penetration Testing ve Balanced Approach
• OWASP Code Review Guide
• OWASP Static Code Analysis
• OWASP Application Security Verification Standard
• NIST SP 800-218: Secure Software Development Framework
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment