SAST, DAST, SCA ve Pentest Arasındaki Farklar: Hangisi Ne Zaman Kullanılmalı?

Modern uygulama güvenliği söz konusu olduğunda en sık karşılaşılan kavramlardan bazıları şunlardır:

SAST

DAST

SCA

Pentest

Bu yöntemlerin tamamı uygulama güvenliğine hizmet eder.

Ancak aynı şeyi yapmazlar.

Farklı noktalara bakarlar.

Farklı güvenlik açıklarını görürler.

Farklı zamanlarda çalıştırılırlar.

Ve en önemlisi, birbirlerinin alternatifi değil tamamlayıcısıdırlar.

Bir kurum yalnızca SAST kullanarak uygulama güvenliğini tam olarak sağlayamaz.

Sadece pentest yaparak da yazılım geliştirme yaşam döngüsünün tamamını güvence altına alamaz.

SCA kullanılmadan açık kaynak bileşenlerin riski görünmez kalabilir.

DAST olmadan çalışan uygulamanın gerçek davranışı yeterince değerlendirilemeyebilir.

Bu nedenle asıl soru:

“Hangisi daha iyi?”

değildir.

Doğru soru şudur:

“Hangi güvenlik yöntemi hangi riski görür ve bunları birlikte nasıl kullanmalıyız?”

Bu bölümde SAST, DAST, SCA ve pentest yaklaşımlarını teknik, operasyonel ve kurumsal bakış açısıyla karşılaştıracağız.

Amacımız yalnızca kavramları açıklamak değil, hangi güvenlik yönteminin hangi durumda kullanılması gerektiğini netleştirmektir.

1. Application Security Neden Tek Bir Testten Oluşmaz?

Bir uygulamanın güvenliği çok katmanlıdır.

Uygulamanın:

• kaynak kodu,
• açık kaynak bileşenleri,
• runtime davranışı,
• API yüzeyi,
• authentication yapısı,
• authorization mekanizması,
• business logic'i,
• deployment ortamı,
• CI/CD süreci

birlikte güvenliği belirler.

Tek bir güvenlik aracı bu alanların tamamını aynı derinlikte analiz edemez.

Örneğin SAST kaynak kodu çok iyi görebilir.

Ancak production ortamındaki HTTP security header'larını değerlendirmeyebilir.

DAST çalışan uygulamayı test edebilir.

Ancak kaynak kod içerisindeki hard-coded API key'i göremez.

SCA açık kaynak dependency risklerini analiz eder.

Ancak uygulamanın business logic açığını tespit edemez.

Pentest gerçek saldırgan davranışını simüle eder.

Ancak milyonlarca satır kodun tamamını sistematik olarak taraması mümkün değildir.

Bu nedenle Application Security'nin temel prensibi şudur:

Tek bir kontrol yerine katmanlı güvenlik.

2. SAST Nedir?

SAST, Static Application Security Testing yaklaşımıdır.

Kaynak kodu veya ilgili yazılım bileşenlerini uygulama çalıştırılmadan analiz eder.

SAST'ın temel sorusu şudur:

“Kodun içerisinde güvenlik açısından riskli bir yapı var mı?”

Örneğin:

• kullanıcı girdisi SQL sorgusuna güvenli olmayan şekilde ulaşıyor mu?
• command execution fonksiyonuna kullanıcı kontrollü veri gidiyor mu?
• hassas bilgi kod içerisinde tutuluyor mu?
• güvenli olmayan kriptografik fonksiyon kullanılıyor mu?
• input validation eksik mi?

SAST özellikle geliştirme aşamasında güçlüdür.

Çünkü güvenlik problemi production ortamına ulaşmadan önce tespit edilebilir.

3. SAST'ın En Güçlü Olduğu Alanlar

SAST özellikle kod seviyesinde görülebilen güvenlik problemlerinde güçlüdür.

Örneğin:

• SQL Injection
• Command Injection
• bazı XSS türleri
• Path Traversal
• insecure deserialization pattern'leri
• hard-coded credential
• insecure crypto usage
• tehlikeli fonksiyon çağrıları
• input validation problemleri

SAST ayrıca kaynak kod içerisinde bulgunun hangi dosya ve satırda olduğunu gösterebilir.

Bu geliştiriciler açısından önemli bir avantajdır.

Bulgu doğrudan remediation yapılacak noktaya bağlanabilir.

4. SAST'ın Sınırları

SAST'ın en önemli sınırı uygulamanın gerçek çalışma davranışını görmemesidir.

Örneğin:

• runtime configuration,
• proxy davranışı,
• WAF etkisi,
• session yönetiminin gerçek davranışı,
• CORS uygulaması,
• business logic saldırıları

SAST tarafından tam olarak anlaşılamayabilir.

Ayrıca karmaşık authorization problemleri ve saldırı zincirleri insan analizi gerektirebilir.

Bu nedenle SAST:

“Kod güvenliği görünürlüğü”

sağlar ama bütün uygulama güvenliğini tek başına temsil etmez.

5. DAST Nedir?

DAST, Dynamic Application Security Testing yaklaşımıdır.

Çalışan uygulamayı dışarıdan test eder.

Kaynak koda erişmek zorunda değildir.

DAST'ın temel sorusu şudur:

“Çalışan uygulama dışarıdan saldırıya açık mı?”

DAST sistemi uygulamaya HTTP veya benzeri istekler göndererek davranışı analiz eder.

Örneğin:

• query parameter,
• form input,
• API body,
• URL,
• header

gibi alanlara test girdileri gönderilebilir.

Uygulamanın verdiği cevaplar analiz edilir.

6. DAST Black Box Yaklaşıma Neden Yakındır?

DAST çoğu zaman uygulamayı dışarıdan gördüğü için black box teste yakındır.

Yani sistem uygulamanın iç kod yapısını bilmeden test yapabilir.

Saldırgan da çoğu zaman uygulamaya dışarıdan yaklaşır.

Bu nedenle DAST gerçek saldırı yüzeyine daha yakın bir perspektif sağlar.

Ancak tamamen saldırgan davranışını simüle ettiği söylenmemelidir.

Çünkü otomatik DAST sistemleri de belirli tarama mantıklarıyla çalışır.

İnsan pentester kadar yaratıcı değildir.

7. DAST Hangi Açıkları Bulabilir?

DAST çalışan uygulamadaki birçok güvenlik problemini tespit etmeye çalışabilir.

Örneğin:

• SQL Injection
• XSS
• bazı authentication problemleri
• server misconfiguration
• security header eksikleri
• açık endpoint'ler
• bazı SSRF senaryoları
• exposed sensitive data

DAST'ın önemli avantajı bulgunun gerçekten çalışan uygulamada gözlemlenmesidir.

Bu nedenle bazı durumlarda exploitability daha net anlaşılabilir.

8. DAST'ın En Güçlü Olduğu Alan Nedir?

DAST'ın en güçlü olduğu alanlardan biri runtime davranışıdır.

Örneğin source code üzerinde güvenli görünen sistem production configuration nedeniyle zayıf olabilir.

DAST çalışan uygulamayı değerlendirdiği için bu tür problemleri görebilir.

Ayrıca:

• response header,
• cookie attribute,
• HTTP method,
• error handling,
• public endpoint davranışı

gibi runtime özellikleri daha iyi analiz edilebilir.

9. DAST'ın Sınırları

DAST uygulamanın dışını görür.

İç kaynak kodu görmez.

Bu nedenle:

• hard-coded credential,
• kullanılmayan ancak riskli fonksiyon,
• kod içerisindeki zayıf algoritma,
• internal security logic

gibi problemleri tespit etmeyebilir.

Ayrıca tarayıcının ulaşamadığı veya crawler'ın keşfedemediği endpoint'ler gözden kaçabilir.

Authentication akışları karmaşıksa DAST kapsamı sınırlanabilir.

10. SAST ve DAST Arasındaki Temel Fark

En basit şekilde:

SAST içeriden dışarı bakar.

DAST dışarıdan içeri bakar.

SAST kaynak kodu inceler.

DAST çalışan uygulamaya request gönderir.

SAST geliştirici perspektifine daha yakındır.

DAST saldırgan perspektifine daha yakındır.

Bu nedenle birlikte kullanıldıklarında çok daha güçlü görünürlük sağlarlar.

11. SAST Bir Açığı Görüp DAST Göremeyebilir mi?

Evet.

Örneğin kaynak kod içerisinde SQL Injection'a açık bir fonksiyon bulunabilir.

SAST bu fonksiyonu tespit edebilir.

Ancak ilgili endpoint production ortamında erişilebilir olmayabilir.

DAST bu nedenle açığı göremeyebilir.

Başka örnekte kod içerisinde hard-coded credential bulunabilir.

DAST bunu hiçbir zaman göremeyebilir.

Bu SAST'ın avantajıdır.

12. DAST Bir Açığı Görüp SAST Göremeyebilir mi?

Evet.

Örneğin security header eksikliği production ortamındaki reverse proxy yapılandırmasından kaynaklanabilir.

SAST kod içerisinde bu bilgiyi göremeyebilir.

Benzer şekilde CORS davranışı veya session cookie attribute'u runtime seviyesinde oluşabilir.

DAST bunu daha iyi tespit edebilir.

Bu nedenle iki yöntem farklı güvenlik katmanlarını görür.

13. SCA Nedir?

SCA, Software Composition Analysis yaklaşımıdır.

SCA'nın temel sorusu şudur:

“Uygulamamız hangi üçüncü taraf bileşenleri kullanıyor ve bunlarda bilinen güvenlik açıkları var mı?”

Modern uygulamalarda çok sayıda open source package kullanıldığı için bu soru kritik hale gelmiştir.

SCA:

• dependency'leri,
• package versiyonlarını,
• bilinen CVE'leri,
• license bilgilerini

analiz edebilir.

14. SCA SAST'tan Neden Farklıdır?

SAST çoğunlukla first-party code'u analiz eder.

Yani kurum geliştiricilerinin yazdığı kod.

SCA ise third-party code'a odaklanır.

Yani kurumun yazmadığı ancak kullandığı kütüphaneler.

Örneğin:

SAST sizin yazdığınız SQL sorgusundaki Injection riskini bulabilir.

SCA kullandığınız JSON parser library'deki bilinen CVE'yi bulabilir.

Bu iki risk tamamen farklıdır.

15. SCA Neden Modern Yazılımlarda Zorunlu Hale Geliyor?

Çünkü yazılım geliştirme artık açık kaynak ekosisteminden bağımsız düşünülemez.

Bir uygulama yüzlerce dependency içerebilir.

Transitive dependency'lerle bu sayı çok daha fazla olabilir.

Kurum geliştiricisi yalnızca 10 farklı paket eklemiş olabilir.

Ancak gerçek uygulamada yüzlerce paket bulunabilir.

Bu nedenle dependency inventory manuel olarak yönetilemez.

SCA bu görünürlüğü otomatik hale getirir.

16. SCA Hangi Riskleri Görür?

SCA özellikle şu alanlarda güçlüdür:

• bilinen CVE'ler,
• vulnerable package version,
• transitive dependency,
• EOL dependency,
• license risk,
• dependency inventory.

Daha gelişmiş sistemler:

• reachability,
• exploit intelligence,
• remediation guidance

gibi bilgiler de sağlayabilir.

17. SCA'nın Sınırları

SCA yalnızca dependency güvenliğini görür.

Uygulamanın kendi kodundaki Injection problemini değerlendirmez.

Business logic açığını bulmaz.

Authentication tasarımını analiz etmez.

Dolayısıyla SCA:

“Dependency güvenliği”

alanına odaklanır.

Bu nedenle SCA'nın SAST ile birlikte kullanılması önemlidir.

18. Pentest Nedir?

Pentest, yani Penetration Testing, bir sistemin güvenliğinin gerçek saldırgan perspektifine mümkün olduğunca yakın şekilde değerlendirilmesidir.

Pentest sırasında güvenlik uzmanı uygulamanın saldırı yüzeyini analiz eder.

Otomatik araçlar kullanabilir.

Ancak karar ve saldırı mantığı insan uzman tarafından yürütülür.

Amaç yalnızca bilinen zafiyetleri taramak değildir.

Uygulamanın nasıl kötüye kullanılabileceğini anlamaktır.

19. Pentest Neden Otomatik Tarama Değildir?

Pentest sırasında otomatik vulnerability scanner kullanılabilir.

Ancak pentest bundan ibaret değildir.

Güvenlik uzmanı;

• uygulamayı keşfeder,
• roller arasında farkları analiz eder,
• endpoint'leri karşılaştırır,
• parametre manipülasyonu yapar,
• saldırı zincirleri kurar,
• business logic'i anlamaya çalışır.

Bu nedenle pentest insan yaratıcılığı gerektirir.

20. Pentest Hangi Alanlarda Güçlüdür?

Pentest özellikle şu alanlarda güçlüdür:

• Broken Access Control
• IDOR / BOLA
• Business Logic
• Authentication bypass
• Authorization bypass
• Session problemleri
• Race Condition
• API abuse
• Attack Chaining
• kompleks runtime zafiyetleri

Bunlar otomatik araçların daha fazla zorlandığı alanlardır.

21. Pentestin Sınırları

Pentest çok değerlidir ancak belirli bir zaman diliminde yapılır.

Örneğin beş günlük testte güvenlik uzmanı uygulamanın tamamını sınırsız derinlikte inceleyemez.

Ayrıca kod değişmeye devam edebilir.

Pentest tamamlandıktan bir hafta sonra yeni güvenlik açığı eklenebilir.

Bu nedenle pentest sürekli AppSec kontrollerinin yerine geçmez.

Pentest:

periyodik veya kritik değişiklik sonrası derin doğrulama katmanı

olarak düşünülmelidir.

22. SAST ile Pentest Arasındaki Fark

SAST kaynak kodu sistematik şekilde tarar.

Pentest çalışan uygulamanın saldırı yüzeyini değerlendirir.

SAST çok geniş kod kapsamı sağlayabilir.

Pentest ise daha derin saldırgan mantığı sağlar.

Örneğin SAST:

“Bu endpoint'te authorization kontrolü yok.”

diyebilir.

Pentester ise bu eksikliği kullanarak:

“Standart kullanıcı admin işlemi gerçekleştirebiliyor.”

şeklinde gerçek etkiyi gösterebilir.

23. DAST ile Pentest Aynı Şey midir?

Hayır.

Bu iki yöntem özellikle sık karıştırılır.

Her ikisi de çalışan uygulamayı test edebilir.

Ancak DAST otomatik bir güvenlik testidir.

Pentest ise insan uzman tarafından yürütülen saldırı simülasyonudur.

DAST yüzlerce endpoint'i hızlı tarayabilir.

Pentester ise farklı endpoint'ler arasındaki ilişkiyi anlayabilir.

Bu nedenle:

DAST = Otomatik dinamik test

Pentest = İnsan odaklı saldırı testi

şeklinde özetlenebilir.

24. DAST Pentestin Yerini Alabilir mi?

Hayır.

DAST pentester'ın iş yükünü azaltabilir.

Bilinen güvenlik problemlerini hızlı şekilde tespit edebilir.

Ancak business logic ve attack chaining gibi alanlarda sınırlıdır.

En güçlü model:

DAST + Manuel Pentest

birlikte kullanmaktır.

DAST geniş otomatik tarama sağlar.

Pentester kritik alanlarda derinleşir.

25. SAST Pentestin Yerini Alabilir mi?

Hayır.

SAST kaynak kodda çok derin görünürlük sağlar.

Ancak çalışan uygulamanın gerçek davranışını görmez.

Örneğin kodda authentication kontrolü doğru görünebilir.

Ancak reverse proxy veya deployment configuration nedeniyle bir endpoint public kalmış olabilir.

Pentest bu problemi görebilir.

Aynı şekilde business logic açıklarını insan daha iyi anlayabilir.

26. SCA Pentestin Yerini Alabilir mi?

Hayır.

SCA bilinen dependency risklerini analiz eder.

Pentest uygulamanın gerçek saldırı yüzeyini değerlendirir.

Ancak pentester'ın da yüzlerce dependency'yi manuel olarak CVE açısından incelemesi verimli değildir.

Bu nedenle SCA otomasyonu gereklidir.

27. Hangi Test Ne Zaman Yapılmalıdır?

Pratik bir yazılım yaşam döngüsünde testler farklı aşamalara yerleştirilebilir.

Kod Yazılırken

Secure Coding

IDE Security

Commit / Pull Request

Secret Scanning

SAST

SCA

Build

SAST

SCA

Container Scanning

Test Ortamı

DAST

API Security Testing

Release Öncesi

Pentest

Manuel Security Review

Production

Continuous Monitoring

Periodic Pentest

Bu yapı güvenliği yaşam döngüsünün tamamına yayar.

28. Shift Left İçin En Uygun Yöntem Hangisidir?

SAST ve SCA Shift Left Security açısından oldukça uygundur.

Çünkü uygulamanın çalışmasına gerek olmadan erken aşamada güvenlik kontrolü yapılabilir.

Geliştirici Pull Request oluşturduğunda:

• SAST,
• SCA,
• Secret Scanning

otomatik çalıştırılabilir.

Bu sayede güvenlik problemi production'a yaklaşmadan tespit edilir.

29. Shift Right Nedir?

Shift Left güvenliği erken aşamaya taşırken Shift Right production ve runtime güvenliğine odaklanır.

Örneğin:

• runtime security,
• WAF,
• application monitoring,
• SIEM,
• RASP,
• production pentest

Shift Right perspektifine daha yakındır.

Güçlü güvenlik programı yalnızca Shift Left yapmaz.

Shift Left + Shift Right

birlikte uygulanır.

30. API Güvenliğinde Hangi Yöntem Daha Etkilidir?

API güvenliği için tek bir yöntem yeterli değildir.

SAST:

API'nin kaynak kodundaki problemleri görebilir.

DAST:

API endpoint'lerini otomatik test edebilir.

SCA:

API servisinin kullandığı kütüphaneleri analiz eder.

Pentest:

BOLA, BFLA ve business logic saldırılarını daha derin test eder.

Dolayısıyla API Security için de katmanlı yaklaşım gerekir.

31. Business Logic İçin Hangi Yöntem Daha Güçlüdür?

Business Logic güvenlik problemlerinde manuel pentest ve manuel code review daha güçlüdür.

Çünkü bu açıkları bulmak için uygulamanın iş modelini anlamak gerekir.

Örneğin:

“Bu kupon neden sadece bir kez kullanılmalı?”

veya:

“Bu kullanıcı neden bu işlemi yapamamalı?”

gibi sorular bağlamsaldır.

Otomatik araç bu iş kuralını bilmeyebilir.

32. SQL Injection İçin Hangisi Daha İyidir?

SQL Injection farklı katmanlarda tespit edilebilir.

SAST riskli veri akışını kaynak kod içerisinde görebilir.

DAST çalışan uygulamaya payload göndererek açığı test edebilir.

Pentester manuel olarak daha karmaşık bypass tekniklerini deneyebilir.

Bu nedenle tek bir “en iyi” yöntem yoktur.

En güçlü model:

SAST + DAST + Pentest

kombinasyonudur.

33. Hard-Coded Secret İçin Hangisi Daha İyidir?

Bu problem runtime testinden çok kod ve repository seviyesindedir.

En uygun yöntem:

Secret Scanning

ve ikinci olarak SAST'tır.

DAST veya pentest kod içerisinde bırakılmış ancak runtime'da görünmeyen secret'ı göremeyebilir.

Bu örnek her güvenlik probleminin farklı araç gerektirdiğini açıkça gösterir.

34. Vulnerable Open Source Library İçin Hangisi Kullanılır?

Doğru cevap:

SCA

SAST bazı durumlarda dependency içerisindeki kodu analiz edebilir ama üçüncü taraf component inventory ve CVE yönetimi SCA'nın alanıdır.

Pentest bilinen dependency açığını istismar edebilir.

Ancak hangi yüzlerce library'nin riskli olduğunu sistematik olarak SCA daha iyi yönetir.

35. Authentication Problemleri İçin Hangisi Daha Güçlü?

Authentication çok katmanlı olduğu için farklı yöntemler birlikte kullanılabilir.

SAST:

authentication kodundaki hataları görebilir.

DAST:

login ve session davranışını otomatik test edebilir.

Pentest:

MFA bypass, password reset abuse ve karmaşık session saldırılarını değerlendirebilir.

Manuel analiz genellikle kritik önem taşır.

36. Authorization Problemleri İçin Hangisi Daha Güçlü?

Authorization özellikle business context gerektirir.

Bu nedenle:

Manuel Pentest + Manuel Code Review

en güçlü kombinasyonlardan biridir.

SAST bazı eksik security annotation veya authorization check problemlerini bulabilir.

DAST bazı object access problemlerini tespit edebilir.

Ancak bütün role matrix'i anlamak için insan analizi gerekir.

37. Zero-Day İçin SCA Yeterli midir?

SCA bilinen vulnerability veritabanlarına dayanıyorsa henüz açıklanmamış zero-day'i göremeyebilir.

Aynı problem diğer otomatik teknolojiler için de geçerli olabilir.

Bu nedenle güvenlik yalnızca bilinen CVE'lere dayanmamalıdır.

Pentest,

manual code review,

behavior monitoring

gibi yöntemler bilinmeyen riskleri ortaya çıkarabilir.

38. False Positive Hangi Yöntemde Daha Fazladır?

Bu araç ve yapılandırmaya göre değişir.

Ancak otomatik teknolojiler genel olarak False Positive üretebilir.

SAST'ta veri akışının yanlış yorumlanması,

DAST'ta response davranışının yanlış değerlendirilmesi,

SCA'da package CVE'sinin uygulama açısından reachable olmaması

örnek olabilir.

Bu nedenle bütün otomasyonlarda triage önemlidir.

39. False Negative Riski

Hiçbir araç bütün güvenlik açıklarını bulamaz.

SAST belirli business logic'i kaçırabilir.

DAST keşfedemediği endpoint'i test edemez.

SCA henüz bilinmeyen CVE'yi bilemez.

Pentester zaman sınırlaması nedeniyle bazı alanları kaçırabilir.

Dolayısıyla güvenlikte temel prensip:

Tek kontrol noktasına güvenmemek

olmalıdır.

40. Defence in Depth Application Security'de Ne Anlama Gelir?

Defence in Depth, bir güvenlik kontrolü başarısız olduğunda başka kontrolün riski azaltmasını hedefleyen katmanlı güvenlik yaklaşımıdır.

Application Security'de örnek:

SAST problemi kod yazılırken bulmaya çalışır.

DAST test ortamında bulmaya çalışır.

Pentest release öncesi saldırı simülasyonu yapar.

WAF production'da exploit girişimini engellemeye çalışır.

SOC şüpheli davranışı izler.

Bir katman problemi kaçırsa bile sonraki katman yakalayabilir.

41. Security Testing Pyramid Nasıl Olmalıdır?

Uygulama güvenlik testleri bir piramit şeklinde düşünülebilir.

En altta sık ve otomatik testler bulunur.

Örneğin:

SAST + SCA + Secret Scanning

her commit veya build'de çalışabilir.

Orta katmanda:

DAST + API Security

bulunabilir.

Üst katmanda ise daha az sıklıkla ancak daha derin:

Manual Code Review + Pentest

uygulanabilir.

Bu yapı hem ölçek hem derinlik sağlar.

42. Neden Her Commit'te Pentest Yapılamaz?

Pentest insan uzmanlığı gerektirir.

Her commit için manuel pentest ekonomik ve operasyonel olarak mümkün değildir.

Bu nedenle erken aşamalarda otomasyon kullanılır.

Pentest ise:

• major release,
• kritik değişiklik,
• yeni uygulama,
• authentication değişikliği,
• önemli API değişikliği

gibi durumlarda uygulanabilir.

43. Neden Yılda Bir Pentest Yetmez?

Sürekli geliştirilen bir uygulamada yılda bir kez pentest yapmak ciddi boşluk oluşturabilir.

Ocak ayında pentest yapılmış olabilir.

Şubat ayında yeni API eklenir.

Mart ayında authentication değişir.

Nisan ayında yeni ödeme modülü çıkar.

Bütün bu değişiklikler sonraki penteste kadar test edilmemiş kalabilir.

Bu nedenle pentest sürekli AppSec kontrolleriyle desteklenmelidir.

44. CI/CD İçerisinde Hangi Güvenlik Kontrolleri Otomatik Olmalı?

Genellikle şu kontroller otomasyona uygundur:

• SAST
• SCA
• Secret Scanning
• Container Image Scanning
• IaC Scanning

DAST da test environment'a deployment sonrasında otomatik çalışabilir.

Pentest ise insan odaklı ayrı bir güvenlik faaliyeti olarak devam eder.

45. Security Quality Gate Nasıl Kurulmalı?

Quality Gate her bulguda build'i durdurmamalıdır.

Risk bazlı politika gereklidir.

Örneğin:

SAST

Yeni Critical Injection → Block

SCA

Reachable Critical CVE → Block

Secret

Active Production Secret → Block

DAST

Confirmed Critical Vulnerability → Release Block

Bu politika kurumun risk iştahına göre özelleştirilmelidir.

46. Yeni Kod ile Legacy Kod Aynı Şekilde mi Yönetilmelidir?

Her zaman mümkün olmayabilir.

Legacy uygulamalarda binlerce geçmiş bulgu bulunabilir.

Hepsinin bir anda çözülmesi gerçekçi olmayabilir.

Bu durumda:

New Code Policy

uygulanabilir.

Yeni kodun yeni Critical ve High güvenlik borcu üretmesine izin verilmez.

Eski Security Debt ise risk bazlı backlog olarak yönetilir.

47. SAST + SCA + Secret Scanning Neden Temel Üçlüdür?

Çünkü bu üç teknoloji üç farklı kod riskini kapsar.

SAST

Bizim yazdığımız kod güvenli mi?

SCA

Kullandığımız kod güvenli mi?

Secret Scanning

Kod içerisinde erişim anahtarı bıraktık mı?

Bu nedenle modern DevSecOps pipeline'larında bu üçlü güçlü bir başlangıç noktasıdır.

48. DAST Bu Üçlüye Ne Ekler?

DAST şu soruyu ekler:

“Kod production benzeri ortamda çalışırken gerçekten nasıl davranıyor?”

Bu runtime perspektifi önemlidir.

Çünkü güvenlik koddan deployment'a geçerken değişebilir.

Configuration,

proxy,

server,

environment

davranışı güvenliği etkileyebilir.

49. Pentest Ne Ekler?

Pentest bütün bu katmanlara şu soruyu ekler:

“Gerçek bir saldırgan bu sistemi nasıl kötüye kullanır?”

Bu nedenle pentester tek tek bulgular yerine saldırı senaryoları oluşturabilir.

Örneğin:

Low bilgi ifşası

Medium IDOR

zayıf reset flow

birleşerek kritik account takeover oluşturabilir.

Bu yaratıcılık insan uzmanlığının önemli avantajıdır.

50. Manual Code Review Bu Modelde Nereye Oturur?

Manual Code Review SAST ile pentest arasında kritik köprü görevi görebilir.

SAST riskli kod bölgelerini gösterir.

Uzman kaynak kodu manuel inceler.

Pentest çalışan uygulamada etkisini doğrular.

Bu model özellikle kritik uygulamalar için güçlüdür:

SAST → Manual Code Review → Pentest

51. White Box Pentest Nedir?

White Box Pentest sırasında güvenlik uzmanının kaynak kod, mimari doküman veya kullanıcı hesapları gibi daha fazla bilgiye erişimi olabilir.

Bu yaklaşım test derinliğini artırabilir.

Özellikle kısa sürede maksimum güvenlik kapsamı hedefleniyorsa kaynak kod erişimi faydalı olabilir.

Pentester hem uygulama davranışını hem kod yapısını birlikte değerlendirebilir.

52. Black Box Pentest Nedir?

Black Box Pentest'te uzman sisteme dış saldırgan perspektifinden yaklaşır.

Kaynak kod bilgisi bulunmaz.

Bu yaklaşım dış saldırganın görebileceği saldırı yüzeyini anlamak açısından değerlidir.

Ancak kod seviyesindeki bazı problemler görünmeyebilir.

Bu nedenle kritik uygulamalarda farklı test yaklaşımları birlikte kullanılabilir.

53. Gray Box Pentest Nedir?

Gray Box yaklaşımında pentester sınırlı iç bilgiye sahiptir.

Örneğin:

• standart kullanıcı hesabı,
• API dokümantasyonu,
• belirli mimari bilgiler

verilebilir.

Bu yaklaşım gerçekçi saldırı senaryosu ile test verimliliği arasında denge sağlayabilir.

54. Bir Kurum Hangisinden Başlamalı?

Bu kurumun yazılım olgunluğuna bağlıdır.

Henüz hiçbir AppSec kontrolü olmayan bir kurum için başlangıç şöyle olabilir:

1. Pentest

Mevcut gerçek riskleri görünür hale getir.

2. SAST

Kod güvenliğini erken aşamaya taşı.

3. SCA

Dependency görünürlüğü oluştur.

4. Secret Scanning

Credential riskini azalt.

5. DAST

Runtime otomasyonu ekle.

6. DevSecOps

Bütün kontrolleri pipeline'a entegre et.

Bu sıralama kurumun ihtiyaçlarına göre değişebilir.

55. Küçük Yazılım Ekibi İçin Önerilen Model

Küçük bir ekipte bütün enterprise güvenlik teknolojilerini bir anda uygulamak gerekmeyebilir.

Başlangıç için:

• Secure Coding
• SAST
• SCA
• Secret Scanning
• periyodik pentest

oldukça güçlü temel oluşturabilir.

Uygulama büyüdükçe DAST ve daha ileri AppSec kontrolleri eklenebilir.

56. Büyük Kurum İçin Önerilen Model

Çok sayıda uygulama ve geliştirici bulunan büyük kurumlarda daha merkezi yapı gerekir.

Örneğin:

• AppSec Platform
• SAST
• SCA
• Secret Scanning
• DAST
• API Security
• SBOM
• Central Vulnerability Management
• Security Champions
• Pentest Program
• Secure Coding Training

birlikte kullanılabilir.

Burada en önemli konu araç sayısı değil süreç entegrasyonudur.

57. Finans ve Kritik Sistemlerde Model Nasıl Olmalı?

Finansal ve kritik sistemlerde risk daha yüksek olduğu için ek manuel kontroller önerilebilir.

Örneğin:

SAST

SCA

Secret Scanning

Manual Code Review

DAST

API Pentest

Web Pentest

Threat Modeling

birlikte kullanılabilir.

Özellikle authentication, authorization ve finansal transaction logic manuel olarak derin incelenmelidir.

58. Araç Sayısını Artırmak Güvenliği Artırır mı?

Her zaman değil.

On farklı güvenlik aracı kullanmak otomatik olarak iyi AppSec programı oluşturmaz.

Eğer:

• bulgular yönetilmiyor,
• aynı bulgular tekrar ediyor,
• geliştiricilere ulaşmıyor,
• SLA takip edilmiyor,
• False Positive temizlenmiyor

ise araç sayısı sadece operasyonel gürültüyü artırabilir.

Başarılı AppSec:

Tool + Process + People

dengesidir.

59. Tek Bir AppSec Platformu Kullanılmalı mı?

Unified AppSec platformları:

• SAST,
• SCA,
• Secret Scanning,
• IaC scanning

gibi farklı kontrolleri tek yerde sunabilir.

Bu merkezi görünürlük avantajı sağlayabilir.

Ancak ürün seçerken her modülün gerçek teknik kabiliyeti değerlendirilmelidir.

Tek platform kullanmak operasyonel kolaylık sağlar ancak sırf tek platform olduğu için teknik yeterlilik varsayılmamalıdır.

60. Bulgular Tek Merkezde Toplanmalı mı?

Evet, özellikle büyük organizasyonlarda faydalıdır.

Farklı araçlardan gelen bulgular:

• duplicate olabilir,
• farklı severity kullanabilir,
• aynı açığı farklı şekilde raporlayabilir.

Centralized Vulnerability Management bu sonuçları normalize edebilir.

Böylece uygulama bazında toplam risk görülebilir.

61. Bir Güvenlik Bulgusu Nasıl Önceliklendirilmelidir?

Kaynağı ne olursa olsun gerçek risk değerlendirmesinde şu faktörler birlikte kullanılabilir:

• Severity
• Exploitability
• Reachability
• Internet Exposure
• Data Sensitivity
• Business Criticality
• Known Exploitation
• Existing Controls

Böylece sadece araç skoruna bağlı karar verilmez.

62. SAST Critical ile Pentest Critical Aynı Şey midir?

Her zaman değil.

Farklı araç ve metodolojiler severity belirlerken farklı kriterler kullanabilir.

SAST teorik Critical üretebilir ancak kod reachable olmayabilir.

Pentest ise istismarı doğrulanmış Critical bulgu raporlayabilir.

Bu nedenle severity normalization önemlidir.

63. CVSS Nerede Kullanılır?

CVSS teknik zafiyet severity'sini değerlendirmede yararlı olabilir.

Ancak kurumsal risk modeli CVSS'in üzerine iş kritikliği ve varlık bağlamı eklemelidir.

Örneğin:

CVSS + Asset Criticality + Exposure + Exploit Intelligence

daha gerçekçi öncelik sağlayabilir.

64. AppSec Bulguları Developer Backlog'a Nasıl Girer?

Güvenlik sistemleri Jira, Azure DevOps veya benzeri iş takip sistemleriyle entegre edilebilir.

Doğrulanmış bulgu otomatik olarak ilgili repository owner'a atanabilir.

Ticket içerisinde:

• risk,
• affected code,
• remediation,
• SLA,
• evidence

bulunabilir.

Bu yaklaşım security report'un PDF içinde unutulmasını engeller.

65. Retest Kim Tarafından Yapılmalı?

Düzeltme sonrası bulgunun gerçekten kapanıp kapanmadığı doğrulanmalıdır.

SAST bulgusunda otomatik re-scan yeterli olabilir.

Ancak pentest tarafından bulunan business logic açığında manuel retest gerekir.

Bu nedenle retest yöntemi bulgu türüne göre seçilmelidir.

66. Security Regression Nedir?

Daha önce düzeltilen güvenlik açığının tekrar ortaya çıkmasına Security Regression denebilir.

Örneğin geliştirici SQL Injection'ı düzeltmiştir.

Aylar sonra başka developer benzer güvensiz pattern'i tekrar ekler.

Bu nedenle düzeltme sonrası mümkün olduğunca automated test rule oluşturulmalıdır.

Böylece problem tekrar ortaya çıktığında CI/CD yakalayabilir.

67. Pentest Bulgusu SAST Kuralına Dönüştürülebilir mi?

Bazı durumlarda evet.

Bu çok değerli bir AppSec olgunluk göstergesidir.

Örneğin pentest sırasında kurumun kendi framework'üne özgü güvensiz fonksiyon kullanımı tespit edilir.

AppSec ekibi custom SAST rule oluşturur.

Bundan sonra aynı pattern başka repository'de oluştuğunda otomatik tespit edilir.

Bu model:

Manuel bulguyu otomatik kontrole dönüştürme

yaklaşımıdır.

68. Pentest Sonrası Secure Coding Eğitimi

Pentest raporlarında aynı zafiyet türleri tekrar ediyorsa geliştirici eğitimleri bu gerçek bulgulara göre tasarlanabilir.

Örneğin kurum sürekli BOLA problemi üretiyorsa API authorization konusunda özel Secure Coding eğitimi verilebilir.

Böylece pentest yalnızca açık bulmaz.

Organizasyonun gelişimine veri sağlar.

69. AppSec Maturity Nasıl Gelişir?

Başlangıç seviyesi kurum:

Yılda bir pentest yapar.

Bir sonraki seviyede:

SAST ekler.

Sonra:

SCA + Secret Scanning

eklenir.

Daha sonra:

DAST + DevSecOps

oluşturulur.

Olgun yapıda ise:

Threat Modeling + Security Champions + Metrics + Continuous AppSec

devreye girer.

Yani güvenlik testten programa dönüşür.

70. SAST, DAST, SCA ve Pentest Karşılaştırması

Özet olarak:

SAST

Neye bakar?

Kaynak kod.

Ne zaman?

Geliştirme aşamasında.

Avantajı?

Erken tespit ve kod satırı görünürlüğü.

Sınırlaması?

Runtime ve business logic.

DAST

Neye bakar?

Çalışan uygulama.

Ne zaman?

Test/staging ortamında.

Avantajı?

Gerçek runtime davranışı.

Sınırlaması?

Kaynak kodu göremez.

SCA

Neye bakar?

Açık kaynak ve third-party dependency.

Ne zaman?

Build ve dependency yönetiminde.

Avantajı?

CVE ve bileşen görünürlüğü.

Sınırlaması?

Uygulamanın kendi kodunu ve business logic'i analiz etmez.

Pentest

Neye bakar?

Gerçek saldırı yüzeyi.

Ne zaman?

Release öncesi veya periyodik.

Avantajı?

İnsan yaratıcılığı, business logic ve attack chaining.

Sınırlaması?

Zaman ve kapsam sınırlıdır.

71. İdeal Application Security Akışı

Modern kurum için örnek akış şu şekilde olabilir:

Developer

↓

Secure Coding

↓

Commit

↓

Secret Scanning

↓

SAST

↓

SCA

↓

Build

↓

Security Quality Gate

↓

Test Environment

↓

DAST

↓

Manual Pentest

↓

Production

↓

Continuous Monitoring

Bu model güvenliği son kontrol olmaktan çıkarır.

Yazılım yaşam döngüsünün tamamına dağıtır.

SecureSys Application Security Yaklaşımı

SecureSys olarak SAST, DAST, SCA ve Pentest yaklaşımlarını birbirinin alternatifi olarak değerlendirmiyoruz.

Her biri farklı saldırı yüzeyini ve farklı güvenlik riskini görünür hale getirir.

Proje ve uygulama kritikliği doğrultusunda;

SAST, SCA, Secret Scanning, DAST, API Security Testing, Manuel Kaynak Kod Analizi ve Pentest

katmanları birlikte değerlendirilebilir.

Özellikle kritik uygulamalarda hedef yalnızca otomatik tarama yapmak değil;

kod, dependency, runtime ve saldırgan perspektifini tek bir güvenlik resmi içerisinde birleştirmektir.

Bir uygulamada SAST temiz olabilir.

Ancak business logic açığı bulunabilir.

Pentest başarılı olabilir.

Ancak kaynak kod repository'sinde active production secret bulunabilir.

DAST kritik bulgu üretmeyebilir.

Ancak dependency içerisinde aktif istismar edilen bir CVE bulunabilir.

Bu nedenle doğru soru:

“Hangi güvenlik ürününü kullanıyoruz?”

değildir.

Asıl soru:

“Hangi güvenlik risklerini gerçekten görebiliyoruz?”

olmalıdır.

Modern Application Security yaklaşımının amacı bütün güvenliği tek araca yüklemek değil;

farklı kontroller arasındaki kör noktaları birbirleriyle kapatmaktır.

Sık Sorulan Sorular

SAST nedir?

SAST, uygulamanın kaynak kodunu çalıştırmadan güvenlik açısından analiz eden Static Application Security Testing yöntemidir.

DAST nedir?

DAST, çalışan uygulamayı dışarıdan dinamik olarak test eden Dynamic Application Security Testing yöntemidir.

SCA nedir?

SCA, uygulamada kullanılan açık kaynak ve üçüncü taraf dependency'leri güvenlik açıkları ve lisans riskleri açısından analiz eden Software Composition Analysis yöntemidir.

Pentest nedir?

Pentest, sistemin güvenliğinin gerçek saldırgan davranışlarına mümkün olduğunca yakın senaryolarla uzmanlar tarafından değerlendirilmesidir.

SAST ile DAST arasındaki fark nedir?

SAST kaynak kodu analiz ederken DAST çalışan uygulamayı dışarıdan test eder.

DAST ile pentest aynı şey midir?

Hayır. DAST otomatik dinamik taramadır. Pentest ise güvenlik uzmanının uygulamanın iş mantığını ve saldırı yüzeyini manuel olarak değerlendirdiği daha kapsamlı bir testtir.

SAST pentestin yerine geçer mi?

Hayır. SAST kaynak kod perspektifi sağlar, pentest ise çalışan sistem üzerinde gerçek saldırgan perspektifi sağlar.

SCA neden gereklidir?

Modern uygulamalar çok sayıda üçüncü taraf dependency kullandığı için kurumun yazmadığı kodların güvenlik risklerinin de görünür hale getirilmesi gerekir.

Hangisi daha iyi: SAST mı DAST mı?

Birbirlerinin alternatifi değildir. SAST kod seviyesinde, DAST runtime seviyesinde güvenlik görünürlüğü sağlar.

En güçlü Application Security yaklaşımı nedir?

Uygulama riskine göre SAST, SCA, Secret Scanning, DAST, manuel kaynak kod analizi ve pentestin birlikte kullanıldığı katmanlı modeldir.

Sonuç: En İyi Güvenlik Testi Tek Bir Test Değildir

Application Security dünyasında sık yapılan hatalardan biri tek bir teknolojiye fazla anlam yüklemektir.

SAST alındığında kodun tamamen güvenli olduğu düşünülebilir.

DAST çalıştırıldığında uygulamanın tüm saldırı yüzeyinin kontrol edildiği varsayılabilir.

SCA kullanıldığında dependency risklerinin tamamen çözüldüğü düşünülebilir.

Pentest yapıldığında ise bir sonraki teste kadar uygulamanın güvenli kalacağı varsayılabilir.

Gerçekte bunların hiçbiri tek başına yeterli değildir.

Çünkü modern uygulamalar tek katmandan oluşmaz.

Kendi yazdığımız kod vardır.

Kullandığımız üçüncü taraf kodlar vardır.

Runtime ortamı vardır.

API'ler vardır.

Kullanıcı rolleri vardır.

Business Logic vardır.

CI/CD süreci vardır.

Ve bütün bunları kötüye kullanmaya çalışan saldırgan vardır.

Bu nedenle:

SAST kodu görür.

SCA bağımlılıkları görür.

DAST çalışan uygulamayı görür.

Pentest saldırganın ne yapabileceğini görmeye çalışır.

Bu dört perspektif bir araya geldiğinde güvenlik görünürlüğü çok daha güçlü hale gelir.

Modern Application Security'nin amacı da tam olarak budur:

Tek bir araçla her şeyi görmek değil, hiçbir kritik alanın görünmez kalmamasını sağlamak.