Uygulama Güvenliğinin Alfabesi: SAST, DAST ve IAST Arasındaki Farklar

Eğer güvenli bir yazılım mimarisi kurmak istiyorsanız, güvenlik araçları pazarındaki kısaltma çorbasının içinde kaybolmanız işten bile değildir. Yönetim toplantılarında havada uçuşan SAST, DAST ve IAST terimleri, aslında DevSecOps sürecinizin hangi durakta güvenliği denetleyeceğini belirleyen basit test yöntemlerinin adlarıdır.

Milyonlarca satır kodu olan devasa bir finans uygulaması yazdığınızı düşünün. Kodun yazıldığı (Local/IDE) bilgisayardan, uygulamanın çalışır hale geldiği (Canlı/Production) ana kadar, zafiyetleri hangi aşamada avlamak istersiniz?

Bu üç teknolojiyi tek bir cümlede özetlemek gerekirse: SAST kodun anatomisine, DAST uygulamanın davranışına, IAST ise her ikisine içeriden bakar.

Şimdi her birinin anatomisine ve teknoloji liderlerinin bu araçları nasıl entegre ettiğine bakalım.

1. SAST (Static Application Security Testing)

Tanım: "Statik" test yöntemidir. İsminden de anlaşılacağı üzere, uygulama daha çalıştırılmadan (derlenmeden / build edilmeden) ham kaynak kodu (Source Code) üzerinden doğrudan hataları tarar. Sistemin içeriden nasıl kodlandığını gördüğü için bu bir tür White Box (Beyaz Kutu) testidir.

Nasıl Çalışır: Geliştiriciniz kodu Github/Gitlab sistemine yolladığı (Commit) an tarama başlar. Adeta bir öğretmenin öğrencinin taslak sınav kağıdını okuyup kırmızı kalemle gramer hatası çizmesi gibidir.
En İyi Bulduğu Açıklar: SQL Injection (SQLi), Cross-Site Scripting (XSS), koda gömülü/unutulmuş (hardcoded) şifreler, güvensiz asimetrik şifreleme pratikleri.
Avantajları: Açıkların tam olarak hangi klasörde ve hangi satırda olduğunu gösterdiği için yazılımcılar hatayı ışık hızında bulup düzeltebilir. Sola Kaydırma (Shift-Left) felsefesinin kalbidir.
Dezavantajları: SAST sistemin çalışır halini görmediği için İş Mantığı Hatalarını (Business Logic Flaws) veya API yetkilendirme (BOLA) sızıntılarını asla göremez. Ayrıca geleneksel SAST'lar, kodu çok yanlış anladığı için devasa oranda "False Positive" (Yanlış Alarm) üreterek yazılım ekiplerini bezdirir.

2. DAST (Dynamic Application Security Testing)

Tanım: "Dinamik" test yöntemidir. SAST'ın tam zıttıdır. Kodun içeriğine veya veritabanına bakmaz. Uygulama ayağa kalkıp (Staging/Production) tamamen çalışır hale geldiğinde, dışarıdan otomatik şekilde HTTP istekleri atarak tıpkı gerçek bir hacker gibi sistemi denemeye başlar. Bir Black Box (Siyah Kutu) testidir.

Nasıl Çalışır: Sahte kullanıcı verileriyle sistemdeki tüm form alanlarını doldurur, bozuk oturum çerezleri (cookies) ve geçersiz URL parametreleri yollayarak uygulamanın "Canlıda nasıl tepki verdiğini" ölçer.
En İyi Bulduğu Açıklar: Sunucu Konfigürasyon hataları, CORS zafiyetleri, Kimlik denetleme (Authentication) sorunları ve Cross-Site Request Forgery (CSRF).
Avantajları: Sistem gerçek anlamda çalışırken test edildiği için "False Positive" (Yanlış Alarm) oranı çok düşüktür. Bir zafiyet buluyorsa, o açıktan içeri "gerçekten" girilebiliyordur. Dillerden bağımsızdır (PHP, Python veya Rust olması fark etmez).
Dezavantajları: Çalışan bir ürün görmesi gerektiği için yazılımın son aşamalarında devreye girer. Bugları çok geç bulur (Shift-Right) ve hata bulduğunda SAST gibi "şu satırda" demez, sorunu geliştiricinin kendisinin bulup çözmesi gerekir.

3. IAST (Interactive Application Security Testing)

Tanım: "İnteraktif" ve yeni nesil test yöntemidir. SAST'ın "Kod görme" yeteneği ile DAST'ın "Çalışan sistemi görme" yeteneğini tek bir bedende birleştiren hibrit modeldir. (Grey Box veya Glass Box olarak geçer)

Nasıl Çalışır: Uygulama kodu oluşturulurken sistemin içine bir nevi "Ajan" (Agent) olarak enjekte edilir. İşlem sonrasında uygulama çalışırken de onu içeriden gözlemler. Sistem dışarıdan bir DAST aracı tarafından dövülürken (veya QA ekibi elle test yaparken), içerideki IAST ajanı "Ah, dışarıdan gelen X parametresi şu anda kodun 14. satırındaki güvenli olmayan SQL sorgusu üzerinden veritabanına ulaştı!" diyerek ihlali raporlar.
Avantajları: Açıkları %100 kesinlikle ve anında (gerçek zamanlı) bulur. "Yanlış Alarm" oranı sıfıra yakındır. Açığı tespit etmekle kalmaz, uygulamanın hangi dosyasında, hangi satırın hataya neden olduğunu doğrudan geliştiriciye gönderir.
Dezavantajları: Kullanımı her programlama dili veya framework için kolayca entegre edilemeyebilir. Kurulumu karmaşıktır.

Karşılaştırma Matrisi

Geleneksel Araçlar Neden Ölüyor? Eresus Security'nin Ajan Mimarisi

Bugün kurumsal pazarın en büyük sıkıntısı, sırf teknolojiye sahip olmak için uyumsuz SAST veya DAST araçlarını devasa paralarla satın alan firmaların Gürültü (Noise) altında boğulmasıdır.

Geleneksel bir SAST aracı size 10.000 adet zafiyet (!?) bulduğunu iddia edebilir. Bunların 9.900'ü tamamen yanlış alarmdır ve geliştirici ekibiniz bu alarmları incelerken projeyi zamanında yetiştiremez, araç tamamen kapatılır.

Eresus Security'nin Otonom Ajan Çözümleri bu karmaşayı bitirir: Yapay zeka modellerimiz sadece standart imza (pattern) takibi yapan aptal bir tarayıcı (Scanner) değil, sistemi yorumlayan Otonom Ajanlardır. İster Pipeline'da kod aşamasında olsun, ister çalışan API sistemlerinizin sızma testinde olsun; Eresus AI Ajanları tıpkı kıdemli bir beyaz şapkalı hacker gibi kodun mantığını yorumlar, yanlış alarmları zekice filtreler ve size sadece Gerçek ve Acil müdahale edilmesi gereken zafiyetlerin PR (Pull Request) önerilerini sunar.

Sizi yavaşlatan değil, otonomy ile sizi koruyan DevSecOps altyapısını kurmak için Eresus Security uzmanlarıyla anında iletişime geçin.

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.

Operasyonel İnceleme Checklisti

Kritik iş akışları kapsamda mı?
Admin paneli ve destek rolü test ediliyor mu?
Scanner çıktısı manuel doğrulandı mı?
Business logic senaryosu yazıldı mı?
Dosya yükleme ve indirme akışları incelendi mi?
Kimlik doğrulama ve session kontrolleri test edildi mi?
Yetki yükseltme zinciri denendi mi?
WAF varlığı manuel testi daraltmıyor mu?
Rapor bulguları remediation sırasına göre ayrıldı mı?
Retest tarihi ve kabul kriteri belli mi?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?