Hızlı cevap: SAST, DAST ve IAST, bir yazılımın güvenliğini farklı açılardan test eden üç yaklaşımdır ve birbirinin alternatifi değil tamamlayıcısıdır. SAST (statik analiz) kaynak kodu çalıştırmadan inceler; kodun içindeki hataları erken, daha yazım aşamasında yakalar ama çalışma zamanındaki davranışı göremez. DAST (dinamik analiz) çalışan uygulamayı dışarıdan test eder; bir saldırgan gibi davranır ama kodun içini görmez. IAST, ikisinin arasında durur; uygulama çalışırken içeriden izler. Bir de insan gözüyle yapılan güvenli kod incelemesi vardır ki otomatik araçların kaçırdığı iş mantığı hatalarını yakalar. Doğru yaklaşım tek bir araca güvenmek değil, bunları yazılım geliştirme sürecinin farklı aşamalarına yerleştirmektir; erken yakalanan bir açık, sonradan bulunandan çok daha ucuza kapatılır.

İlgili rehber: SAST, DAST, IAST ve SCA: Kod Güvenlik Test Yöntemi Seçim Matrisi

Bir güvenlik açığını yazılımın kaynak kodundayken bulmak ile canlıya çıktıktan sonra bulmak arasında dağlar kadar fark vardır; ilki birkaç dakikalık bir düzeltme, ikincisi bir kriz olabilir. Bu yüzden modern güvenlik, açıkları mümkün olan en erken aşamada yakalamaya çalışır. Bunu yapmak için farklı araçlar ve yöntemler vardır: SAST, DAST, IAST ve insan eliyle kod incelemesi. Bu yazı, bu yaklaşımların ne olduğunu, birbirinden farkını ve hangisini ne zaman kullanacağınızı anlatıyor.

Üç yaklaşım, üç bakış açısı

SAST, yani statik uygulama güvenlik testi, kodu çalıştırmadan inceler. Kaynak kodun içine bakar ve tehlikeli desenleri (örneğin doğrulanmadan kullanılan bir girdi) arar. En büyük avantajı erkenliktir; geliştirici kodu yazarken bile uyarı verebilir. Ama çalışma zamanını göremediği için, bazı açıkları ancak teoride tespit eder ve yanlış pozitif üretebilir.

DAST, yani dinamik uygulama güvenlik testi, tam tersini yapar; çalışan uygulamayı dışarıdan, bir saldırgan gibi test eder. Kodu hiç görmez, sadece davranışa bakar. Gerçek dünyada sömürülebilir açıkları bulmada güçlüdür ama kodun neresinde olduğunu söyleyemez ve ancak çalışan bir uygulamada işe yarar.

IAST, bu ikisinin arasında bir yerde durur; uygulama çalışırken onu içeriden izleyen bir ajanla çalışır, böylece hem davranışı hem kod bağlamını görebilir.

Yan yana karşılaştırma

Boyut SAST DAST IAST
Ne test eder Kaynak kod Çalışan uygulama Çalışan uygulama, içeriden
Ne zaman Yazım aşamasında Test/canlı aşamada Test aşamasında
Kodu görür mü Evet Hayır Evet
Çalışma zamanı Göremez Görür Görür
Güçlü yanı Erken yakalama Gerçek sömürülebilirlik İkisinin dengesi
Zayıf yanı Yanlış pozitif Konum belirsiz Kurulum karmaşıklığı

İnsan gözü: güvenli kod incelemesi

Otomatik araçlar hızlıdır ama bir şeyi asla tam yapamaz: bir uygulamanın iş mantığını anlamak. Bir kullanıcının başka bir kullanıcının verisine erişebilmesi ya da bir ödeme akışının atlanabilmesi gibi hatalar, kodda sözdizimsel olarak hiç yanlış görünmez; ancak bir insan bunların mantıksal bir güvenlik açığı olduğunu görebilir. Bu yüzden güvenli kod incelemesi, otomatik araçların üstüne eklenen kritik bir katmandır. Bu tür iş mantığı açıklarını neden yalnızca insan yakalar konusunu OWASP Top 10 web uygulama güvenliği çerçevesinde ele aldık.

DevSecOps: sürece yerleştirmek

Bu araçların gerçek değeri, tek tek kullanılmalarında değil, yazılım geliştirme sürecine yerleştirilmelerinde ortaya çıkar. SAST'ı kod deposuna, DAST'ı test ortamına, kod incelemesini geliştirme akışına yerleştirdiğinizde, açıklar geliştikçe yakalanır ve canlıya hiç ulaşmaz. Buna güvenliği sürece gömmek (DevSecOps) denir. Erken yakalanan bir açığın maliyeti, canlıda bulunanın çok altındadır; bu yüzden "sonra test ederiz" yaklaşımı hem daha pahalı hem daha risklidir. Bu bulguların bir sızma testiyle nasıl doğrulanacağını zafiyet taraması ve sızma testi farkı yazısında ele aldık.

KAOS ve DSET yaklaşımı

DSET, kurumların güvenliği yazılım geliştirme sürecine yerleştirmesine yardım eder ve otomatik analizle insan incelemesini birlikte sunar. Yerel yapay zekâ motorumuz KAOS, hem statik hem dinamik analizi birleştirir ve her bulguyu çalışan bir kanıtla, yanlış pozitif gürültüsü olmadan raporlar; iş mantığı hataları için ise uzman incelemesiyle tamamlar. Amaç, bir açığı canlıya ulaşmadan, en ucuz olduğu anda yakalamaktır.

Sık sorulan sorular

SAST mı DAST mı, hangisi daha iyi? İkisi de farklı işler yapar, biri diğerinden daha iyi değildir. SAST kodu erken aşamada, yazılırken tarar ama çalışma zamanını göremez; DAST çalışan uygulamayı gerçekçi biçimde test eder ama kodun neresinde olduğunu söyleyemez. Doğru yaklaşım birini seçmek değil, ikisini sürecin farklı aşamalarına yerleştirmektir; birlikte kullanıldıklarında birbirlerinin kör noktalarını kapatırlar.

Otomatik araçlar kod incelemesinin yerini tutar mı? Hayır. Otomatik araçlar bilinen desenleri hızlı yakalar ama bir uygulamanın iş mantığını anlayamaz. Bir kullanıcının yetkisiz veriye erişebilmesi gibi mantıksal açıklar, kodda sözdizimsel olarak yanlış görünmez ve ancak bir insan tarafından fark edilir. En etkili yaklaşım, otomatik analizi insan incelemesiyle birlikte kullanmaktır.

Yanlış pozitifler bir sorun mu? SAST araçlarında evet, olabilir. Statik analiz, gerçekte sömürülemeyen pek çok bulguyu işaretleyebilir ve ekip zamanını bunları elemekle harcar. Bu yüzden bulguların bir uzman ya da kanıt-temelli bir süreçle doğrulanması önemlidir; her uyarıyı gerçek bir açık gibi ele almak, ekibi gerçek risklerden uzaklaştırır.

Kaynaklar

Yazılım geliştirme sürecinize güvenliği yerleştirmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan uygulama güvenliği danışmanlığı sağlıyoruz.