SAST ve DAST Arasındaki Fark Nedir?

Modern yazılım geliştirme süreçlerinde güvenlik, ürün teslimatının son aşamasında yürütülen izole bir kontrol adımı olmaktan çıkıp mimarinin temeline entegre edilen bir disipline dönüşmüştür. İşletmelerin dijital varlıklarını koruma altına alırken sıklıkla karşılaştığı temel soru şudur: SAST ve DAST Arasındaki Fark Nedir? SAST (Static Application Security Testing), kaynak kodunu (source code) veya derlenmiş ikili dosyaları içeriden statik yöntemlerle tarayarak geliştirme aşamasında zafiyetleri yakalayan beyaz kutu (white-box) test yaklaşımıdır. DAST (Dynamic Application Security Testing) ise çalışan bir uygulamayı dışarıdan, saldırgan perspektifiyle dinamik olarak test eden siyah kutu (black-box) metodolojisidir. Her iki yaklaşım birbirinin alternatifi değil, kurumsal savunma hattını tamamlayan iki kritik bileşendir.

SAST (Statik Uygulama Güvenlik Testi) Nedir? İçeriden Güvenlik Yaklaşımı

Statik Uygulama Güvenlik Testi (SAST), bir yazılımın kaynak kodunu, bayt kodunu (bytecode) veya derlenmiş ikili dosyalarını (binaries), yazılım çalıştırılmadan doğrudan analiz eden bir güvenlik test metodolojisidir. Güvenlik literatüründe "Beyaz Kutu Testi" (White-box Testing) olarak adlandırılan bu yöntem, analiz aracının uygulamanın iç mimarisine, sınıf hiyerarşisine, kütüphane bağımlılıklarına ve veri akış yollarına tam erişim sahibi olduğu varsayımı üzerine kuruludur. SAST araçları, kod tabanını baştan sona tarayarak sözdizimsel kalıpları (syntactic patterns), zafiyetli fonksiyon çağrılarını ve güvenli olmayan veri transferi rotalarını (taint analysis) inceler.

Kurumsal yazılım yaşam döngüsünde SAST, "Shift-Left" (Güvenliği Sola Çekme) stratejisinin temel taşıdır. Geliştiricilerin kod yazım aşamasında IDE eklentileri veya Git repolarına yapılan her @@CODE0@@ / @@CODE1@@ sırasında tetiklenen CI/CD boru hattı (pipeline) entegrasyonlarıyla çalışır. SonarQube, Checkmarx, Fortify veya Veracode gibi endüstri standardı SAST platformları; kod tabanında tespit edilen SQL Injection (SQLi), Cross-Site Scripting (XSS), bellek sızıntıları (memory leaks), güvensiz kriptografik algoritmalar ve sabit kodlanmış (hardcoded) kimlik bilgileri gibi kritik zafiyetleri doğrudan satır numarası vererek raporlar.

Bu analiz modelinin merkezinde "Lekeli Veri Analizi" (Taint Analysis) ve "Soyut Sözdizim Ağacı" (Abstract Syntax Tree - AST) haritalama teknikleri yer alır. AST, kaynak kodun yapısal temsilini çıkararak denetleyicilerin mantıksal akışı anlamasını sağlarken; leke analizi, dış dünyadan (kullanıcı girdisi, API isteği vb.) gelen güvenilmeyen verinin hangi arındırma (sanitization) filtrelerinden geçerek veritabanı veya işletim sistemi sorgularına ulaştığını adım adım takip eder. Eğer girdi yeterince doğrulanmadan tehlikeli bir fonksiyona (sink) ulaşırsa, SAST aracı geliştiriciye zafiyet uyarısı üretir.

SAST'ın Kurumsal Avantajları ve SDLC'deki Yeri

Yazılım Geliştirme Yaşam Döngüsü (SDLC) içinde SAST araçlarının erken evrede devreye alınması, kurumlar için hem teknik borcu (technical debt) hem de operasyonel maliyetleri ciddi oranda düşürür. NIST (National Institute of Standards and Technology) verilerine göre, tasarım veya geliştirme aşamasında tespit edilip düzeltilen bir güvenlik açığının maliyeti, üretim (production) ortamında ortaya çıkan aynı açığın kapatılma maliyetine kıyasla onlarca kat daha düşüktür. SAST, geliştiriciye doğrudan hatanın bulunduğu dosya adını ve satır numarasını işaret ederek düzeltme süresini (MTTR - Mean Time to Remediate) saatler seviyesine indirir.

Kurumsal kod standartlarının korunması ve regülasyon uyumluluğu (ISO 27001, PCI-DSS, KVKK, GDPR) açısından SAST denetimleri zorunlu bir kontrol noktasıdır. Yazılım ekibinin yazdığı her kod bloğu, OWASP Top 10 ve CWE (Common Weakness Enumeration) kataloglarındaki zafiyet tanımlarına göre taranarak sertifikasyon süreçlerine hazır hale getirilir. Ayrıca SAST motorları, geliştiricilere sadece hatayı göstermekle kalmaz; hatanın nasıl düzeltileceğine dair güvenli kodlama örnekleri sunarak kurum içi güvenlik farkındalığını ve yetkinliğini kalıcı olarak artırır.

+-----------------------------------------------------------------------------+
|               SAST SÜRECİ (KAYNAK KOD & DERLEME AŞAMASI)                    |
|                                                                             |
|  [Kaynak Kod] ---> [AST & Taint Analizi] ---> [Kural Seti Eşleştirme]        |
|        |                                              |                     |
|  (Commit/PR)                                 (Zafiyet: Satır & Dosya)       |
+-----------------------------------------------------------------------------+

Dikkat Edilmesi Gereken Sınırlamalar: SAST Bizi Nelerden Koruyamaz?

SAST mimarisinin getirdiği derin görünürlük, beraberinde önemli kısıtlamalar da barındırır. En belirgin operasyonel zorluk "Yanlış Pozitif" (False Positive) oranlarının yüksekliğidir. Statik analiz araçları, uygulamanın mantıksal akışını ve çalışma zamanı koşullarını tam olarak simüle edemediği için, aslında kod içerisinde başka bir katmanda filtrelenmiş zararsız girdileri de kritik bir zafiyet gibi raporlayabilir. Bu durum, güvenlik ekipleri ile geliştiriciler arasında iş yükü çatışmalarına ve geliştirici tarafında "uyarı yorgunluğuna" (alert fatigue) neden olur.

Bunun yanı sıra SAST, uygulamanın çalışacağı sunucu yapılandırmalarını, kimlik doğrulama/oturum yönetimi hatalarını ve çalışma zamanında ortaya çıkan dinamik bellek manipülasyonlarını göremez. Örneğin, API Gateway üzerindeki bir CORS yanlış yapılandırması veya Kubernetes ortamındaki bir yetkilendirme açığı kaynak kod satırlarında bulunmadığı için SAST filtrelerinden tamamen kaçar. Ayrıca derleme aşamasında devasa kod tabanlarında saatler sürebilen tarama süreleri, hızlı yayın (continuous deployment) süreçlerinde darboğaz yaratabilir.

DAST (Dinamik Uygulama Güvenlik Testi) Nedir? Dışarıdan Hacker Bakış Açısı

Dinamik Uygulama Güvenlik Testi (DAST), çalışan, derlenmiş ve aktif bir ortamda (Staging, UAT veya Production) barındırılan web uygulamalarını ve API servislerini dışarıdan hedef alan bir güvenlik test yöntemidir. DAST, siber güvenlik dünyasında "Siyah Kutu Testi" (Black-box Testing) prensibiyle çalışır. Analiz aracının elinde uygulamanın kaynak kodu, veritabanı şeması veya mimari tasarım dokümanı bulunmaz; araç, tıpkı gerçek bir saldırgan gibi uygulamanın HTTP/HTTPS istek ve yanıt başlıklarını, form alanlarını, URL parametrelerini ve API uç noktalarını (REST, GraphQL, gRPC) manipüle ederek zafiyet arar.

OWASP ZAP, Burp Suite Enterprise, Acunetix veya Invicti gibi DAST çözümleri, iki temel aşamada görev yapar: "Örümcek/Tarama" (Crawl/Spider) ve "Saldırı/Denetim" (Attack/Audit). İlk aşamada DAST motoru, hedef uygulamanın tüm sayfalarını, butonlarını, girdi formlarını ve arka plan API isteklerini keşfederek kapsamlı bir saldırı yüzeyi haritası (attack surface map) çıkarır. İkinci aşamada ise bu girdilere özel olarak hazırlanmış saldırı vektörleri (payloads) gönderilir. DAST aracı; sunucudan dönen durum kodlarını, hata mesajlarını, yanıt gecikmelerini ve DOM değişikliklerini izleyerek uygulamanın güvenlik direncini ölçümler.

DAST testleri dile ve çatıya (framework) tamamen bağımsızdır. Uygulamanın Java, Python, .NET, Node.js veya Go ile yazılmış olması DAST için bir fark yaratmaz; çünkü analiz kod satırlarını değil, istemci ile sunucu arasındaki ağ trafiğini ve çıktıları denetler. Bu bağımsızlık, mikroservis mimarilerinde ve çok dilli (polyglot) kurumsal ekosistemlerde DAST'ı standart bir güvenlik onay mekanizması haline getirir.

+-----------------------------------------------------------------------------+
|               DAST SÜRECİ (ÇALIŞAN UYGULAMA & RUNTIME AŞAMASI)              |
|                                                                             |
|  [DAST Motoru] --(HTTP/Saldırı Payload)--> [Çalışan Uygulama (Runtime)]     |
|        ^                                             |                      |
|        +----------(Yanıt & Durum Analizi)<-----------+                      |
+-----------------------------------------------------------------------------+

DAST Nasıl Çalışır ve Kritik Faydaları Nelerdir?

DAST araçlarının en büyük kurumsal avantajı, istismar edilebilirliği (exploitability) kanıtlanmış zafiyetleri ortaya çıkarmasıdır. Bir DAST aracı SQL Injection veya XSS tespit ettiğinde, uygulamanın bu saldırıya gerçekten zafiyet gösterdiğini kanıtlayan HTTP isteği ve sunucu yanıtını (Proof-of-Concept) raporlar. Bu mekanizma sayesinde DAST taramalarındaki "Yanlış Pozitif" (False Positive) oranı SAST'a kıyasla son derece düşüktür. Güvenlik operasyon ekipleri (SecOps), geliştiricilere asılsız uyarılar göndermek yerine doğrulanmış riskleri iletir.

Bunun yanı sıra DAST; oturum yönetimi açıkları (Session Fixation, eksik CSRF tokenları), sunucu ve web sunucusu (Nginx, Apache, IIS) yapılandırma hataları, güvensiz SSL/TLS şifreleme paketleri, açık bırakılmış yönetim panelleri ve hassas dosya sızıntılarını tespit etmede benzersizdir. DAST aynı zamanda üçüncü parti kütüphanelerin ve entegre API'lerin bir araya geldiğinde oluşturduğu bileşik güvenlik risklerini, sistemin gerçek çalışma koşulları altında sınayabilir.

DAST Kullanımında Kurumsal Riskler ve Kısıtlar

DAST metodolojisinin doğası gereği barındırdığı operasyonel riskler mevcuttur. DAST, çalışan bir sisteme binlerce rastgele ve zararlı istek gönderdiği için, hedef ortamda veri kirliliğine, veritabanı tablolarının bozulmasına veya hizmet kesintisine (Denial of Service - DoS) yol açabilir. Örneğin bir e-ticaret sitesinde çalışan DAST aracı, test formunu tetiklerken yüzlerce sahte sipariş oluşturabilir veya bakiye güncelleme servisini kilitleyebilir. Bu nedenle DAST testlerinin üretim (Production) ortamından ziyade üretim benzeri (Staging/UAT) izole ortamlarda, dikkatle tanımlanmış oturum ve kapsam sınırlarıyla yürütülmesi zorunludur.

Diğer bir temel kısıt ise kod görünürlüğünün olmamasıdır. DAST bir güvenlik açığı bulduğunda sistem yöneticisine "/api/v1/checkout uç noktası SQL enjeksiyonuna izin veriyor" uyarısını verir; ancak bu açığın hangi mikroserviste, hangi sınıfta veya kodun kaçıncı satırında olduğunu bilemez. Düzeltme sorumluluğu geliştiriciye geçer ve geliştiricinin kod tabanında kök neden analizi (root cause analysis) yapması gerekir. Ayrıca DAST testleri SDLC'nin sonlarına doğru (uygulama derlenip ayağa kalktıktan sonra) yapılabildiği için, bulunan açıkların kapatılması geliştirme döngüsünün uzamasına neden olur.

SAST ve DAST Arasındaki Temel Farklar (Kapsamlı Karşılaştırma)

Yazılım güvenliği stratejisi oluşturulurken SAST ve DAST yöntemlerinin hangi operasyonel parametrelerde birbirinden ayrıldığını netleştirmek gerekir. İki teknoloji arasındaki temel ayrım; testin zamanlaması, hedefin durumu, görünürlük seviyesi ve elde edilen sonuçların niteliğinde yatar. SAST iç mimariyi denetlerken, DAST dış sınırları ve iletişim kanallarını zorlar.

Aşağıdaki karşılaştırma tablosu, her iki metodolojinin kurumsal karar vericiler ve teknik ekipler için temel parametrelerini özetlemektedir:

Tespit Edilebilen Zafiyet Türlerindeki Ayrım

Her iki test metodolojisi, çalışma mantıkları gereği farklı zafiyet sınıflarında uzmanlaşmıştır. SAST, kod satırları arasına gizlenmiş mantıksal ve kriptografik kusurları yakalamada üstündür. Örneğin; zayıf rastgele sayı üreteçleri (@@CODE0@@ yerine @@CODE1@@ kullanılmaması), hardcoded API anahtarları, SQL sorgularının String birleştirmesiyle (concatenate) oluşturulması veya kapatılmamış veritabanı bağlantıları SAST'ın hızla tespit ettiği alanlardır.

+-----------------------------------------------------------------------------+
|                          ZAFİYET KAPSAM MATRİSİ                             |
|                                                                             |
|        SAST UZMANLIĞI                  DAST UZMANLIĞI                       |
|   - Hardcoded Secrets             - Session Hijacking                       |
|   - Insecure Cryptography         - Broken Object Level Auth (BOLA)         |
|   - Buffer Overflow (C/C++)       - CORS / CSP Misconfiguration             |
|   - Unsanitized Code Sinks        - SSRF (Server-Side Request Forgery)      |
|                                                                             |
|                     ORTAK ALAN (HER İKİSİ DE YAKALAR)                       |
|                 * SQL Injection    * Reflected/Stored XSS                   |
+-----------------------------------------------------------------------------+

Buna karşılık DAST; uygulamanın çalışma anındaki durumuna (state) ve çevre bileşenlerine dayalı açıkları bulur. Sunucu yanıt başlıklarındaki @@CODE0@@ (CSP) veya @@CODE1@@ (HSTS) eksiklikleri, kimlik doğrulama baypasları, Kırık Nesne Düzeyi Yetkilendirme (BOLA / IDOR), Sunucu Taraflı İstek Sahteciliği (SSRF) ve oturum zaman aşımı hataları yalnızca DAST tarafından güvenilir şekilde analiz edilebilir. SQL Injection ve XSS gibi yaygın OWASP Top 10 açıkları ise hem SAST hem DAST tarafından farklı açılardan tespit edilebilir; SAST koddaki eksik filtreyi gösterirken, DAST bu filtrenin dışarıdan nasıl aşıldığını ispatlar.

Güvenlik Açıklarını Kapatmak: Neden Sadece Biri Yeterli Değildir?

Yalnızca SAST veya yalnızca DAST kullanan kurumlar, güvenlik mimarilerinde kaçınılmaz kör noktalar (blind spots) yaratır. Bir yazılım projesinde yalnızca SAST kullanıldığını varsayalım: Kaynak kodunuz mükemmel derecede temiz, güvenli ve CWE standartlarına tam uyumlu olabilir. Ancak bu kod, yanlış yapılandırılmış bir Apache web sunucusuna, varsayılan şifrelerle bırakılmış bir veritabanı sürücüsüne veya güvensiz bir TLS sertifikasına sahip bir sunucuya yüklendiğinde, sistem dışarıdan gelecek saldırılara karşı tamamen savunmasız kalacaktır. SAST bu yapılandırma hatalarını tespit edemez.

Ters senaryoda, kurumun yalnızca DAST kullandığını düşünelim: DAST araçları, çalışan uygulamanın sadece taranabilen ve tıkla ulaşılabilen sayfalarını denetler. Arka planda çalışan, doğrudan HTTP uç noktasına bağlı olmayan cron job'lar, kuyruk yöneticileri, veri işleme fonksiyonları veya henüz arayüze bağlanmamış işlevsel kod blokları DAST'ın saldırı yüzeyi dışında kalır. Ayrıca DAST, sistemin derinliklerinde yer alan arka kapıları (backdoor), gizli yönetici parametrelerini veya kaynak koda kasıtlı olarak eklenmiş mantık bombalarını (logic bombs) fark edemez.

Modern siber güvenlik stratejileri, "Savunma Derinliği" (Defense-in-Depth) ilkesini benimser. Bu ilke uyarınca güvenlik, tek bir araca veya kontrol noktasına emanet edilemez. SAST ve DAST araçlarının birlikte kullanılması, yazılımın hem iç mantığının hem de dış davranışının eş zamanlı olarak güvenceye alınmasını sağlar. SAST ile geliştiriciler kod kalitesini ve temel mimariyi korurken, DAST ile güvenlik operasyon ekipleri sistemin dış tehditlere karşı direncini gerçek zamanlı olarak doğrular.

DevSecOps ve Modern CI/CD Süreçlerinde Hibrit Yaklaşım

DevSecOps kültürü, yazılım teslimat hızını düşürmeden güvenliği boru hattının her aşamasına yerleştirmeyi hedefler. Bu hedefe ulaşmanın en etkili yolu, SAST ve DAST araçlarını CI/CD süreçlerinde stratejik noktalara konumlandırmaktır. SAST araçları, geliştiricinin Git reposuna her kod gönderiminde (Push / PR) dakikalar içinde çalışan hafif (lightweight) kural setleriyle devreye girer. Kritik bir zafiyet tespit edildiğinde derleme işlemi otomatik olarak durdurulur (Quality Gate), böylece zafiyetli kodun ana dala (main branch) karışması engellenir.

DAST ise sürekli entegrasyon sürecinin daha ileri bir aşamasında, uygulama test ortamına (Staging) başarıyla deploy edildikten sonra otomatik olarak tetiklenir. Gece derlemelerinde (nightly builds) veya sürüm öncesi (release candidate) aşamalarda kapsamlı dinamik taramalar çalıştırılır. Tespit edilen bulgular, Jira veya GitLab Issues gibi görev yönetim sistemlerine otomatik olarak bilet (ticket) olarak aktarılır. Bu hibrit akış, güvenlik açıklarının hem erken tespit edilmesini hem de canlıya çıkmadan önce çalışma zamanında doğrulanmasını garanti eder.

+-----------------------------------------------------------------------------+
|               DEVSECOPS BORU HATTI ENTEGRASYON MODELİ                       |
|                                                                             |
|  [Kod Yazımı] ---> [Commit / PR] ---> [Derleme & SAST] ---> [Quality Gate]  |
|                                                                    |        |
|  [Rapor / Düzeltme] <--- [DAST Taraması] <--- [Staging Deploy] <---+ (Geçti)|
+-----------------------------------------------------------------------------+

IAST ve RASP ile Bütüncül Güvenlik: Test Yaklaşımlarının Evrimi

SAST'ın yüksek yanlış pozitif oranı ve DAST'ın kod satırı görememe kısıtlaması, siber güvenlik endüstrisini yeni nesil hibrit çözümler geliştirmeye yöneltmiştir. Bu arayışın sonucunda ortaya çıkan IAST (Interactive Application Security Testing) ve RASP (Runtime Application Self-Protection) teknolojileri, statik ve dinamik analizin avantajlarını tek bir çatı altında birleştirir.

IAST, uygulamanın çalıştığı sunucu veya çalışma zamanı ortamına (JVM, CLR, Node.js runtime vb.) yerleştirilen özel bir ajan (agent / sensor) vasıtasıyla çalışır. Fonksiyonel testler (QA, otomatik Selenium/Cypress testleri veya manuel kullanıcı testleri) yürütülürken, IAST ajanı bellek içindeki veri akışını, SQL sorgularını, API çağrılarını ve kütüphane yürütmelerini içeriden izler. Bu sayede IAST; DAST gibi uygulamanın çalışma zamanındaki gerçek davranışını test ederken, SAST gibi hatanın tam olarak hangi dosya ve satır numarasından kaynaklandığını tespit eder.

+-----------------------------------------------------------------------------+
|             GÜVENLİK TESTİ EVRİMİ (SAST -> DAST -> IAST -> RASP)            |
|                                                                             |
|  SAST : Kod var, çalışma zamanı yok   (Statik & İçeriden)                   |
|  DAST : Çalışma zamanı var, kod yok   (Dinamik & Dışarıdan)                 |
|  IAST : Kod var + Çalışma zamanı var  (Etkileşimli & Ajan Tabanlı)          |
|  RASP : Canlı ortamda aktif savunma   (Çalışma Zamanı Öz-Koruma)            |
+-----------------------------------------------------------------------------+

IAST Nedir ve Hangi Güvenlik Boşluklarını Doldurur?

IAST araçları, yanlış pozitif oranlarını neredeyse sıfıra indirir. Çünkü bir açığı raporlamadan önce, o açığın çalışma zamanında gerçekten tetiklendiğini ve uygulamanın veri akışında yürütüldüğünü kendi ajanıyla doğrular. Ayrıca IAST, geleneksel DAST gibi dışarıdan kaba kuvvetle milyonlarca istek göndermek zorunda kalmaz; standart fonksiyonel testlerin trafiğini dinleyerek pasif veya yarı-aktif şekilde analiz yapar. Bu durum, test sürelerini kısaltır ve CI/CD süreçlerindeki gecikmeleri ortadan kaldırır.

RASP teknolojisi ise test aşamasının ötesine geçerek üretim ortamına odaklanır. RASP ajanları, canlıdaki uygulamaya yönelik bir SQL Injection veya deserialization saldırısı algıladığında, bu saldırıyı web uygulama güvenlik duvarı (WAF) gibi ağ katmanında değil; doğrudan uygulamanın bellek ve kod çalıştırma katmanında engeller. IAST ve RASP, SAST ve DAST'ın yerini tamamen almaktan ziyade, yüksek güvenlik gerektiren kritik finans, e-ticaret ve sağlık uygulamalarında tamamlayıcı üst katmanlar olarak konumlandırılmaktadır.