# SAST Tek Başına Yeterli mi? Otomatik Tarama ve Manuel Kaynak Kod Analizi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/sast-yeterli-mi-otomatik-manuel-kod-analizi

![SAST Tek Başına Yeterli mi? Otomatik Tarama ve Manuel Kaynak Kod Analizi](/images/bilgi-merkezi/covers/cover-kod-04.webp)

SAST, modern yazılım güvenliği programlarının en önemli araçlarından biridir.

Kaynak kod içerisindeki veri akışlarını analiz edebilir.

SQL Injection, Cross-Site Scripting, Command Injection, Path Traversal ve benzeri birçok güvenlik problemini daha yazılım production ortamına ulaşmadan tespit edebilir.

CI/CD pipeline'larına entegre edilebilir.

Her commit sonrasında otomatik çalışabilir.

Geliştiricilere kod yazarken güvenlik geri bildirimi verebilir.

Bütün bunlar SAST'ı son derece güçlü bir teknoloji haline getirir.

Ancak burada kritik bir soru vardır:

**Bir kurum güçlü bir SAST ürünü satın aldığında ve bütün kaynak kodunu taradığında artık uygulamanın güvenli olduğunu söyleyebilir mi?**

Cevap:

**Hayır.**

Çünkü SAST kaynak kod güvenliğinin çok önemli bir parçasıdır ancak bütün güvenlik problemlerini tek başına göremez.

Bir otomatik analiz motoru kaynak kod içerisindeki pattern'leri, fonksiyonları, veri akışlarını ve potansiyel güvenlik risklerini analiz edebilir.

Fakat uygulamanın gerçek iş mantığını her zaman anlayamaz.

Bir bankacılık uygulamasında belirli kullanıcının hangi işlemleri yapması gerektiğini bilemez.

Bir e-ticaret platformunda indirim kodunun hangi şartlarda kullanılabileceğini anlayamayabilir.

Bir insan kaynakları sisteminde hangi yöneticinin hangi personel dosyasına erişmesi gerektiğini kurumun iş kurallarını bilmeden değerlendiremez.

Bu nedenle uygulama güvenliğinde en güçlü yaklaşım:

#### Otomasyon + İnsan Uzmanlığı

kombinasyonudur.

Modern Application Security programlarında SAST önemli bir ilk savunma katmanı olarak kullanılmalı ancak manuel kaynak kod analizi, business logic değerlendirmesi ve sızma testi gibi yöntemlerle desteklenmelidir.

### \1. SAST'ın Güçlü Olduğu Alanlar

Öncelikle SAST'ın neden bu kadar önemli olduğunu doğru anlamak gerekir.

SAST sistemlerinin en büyük avantajlarından biri çok büyük kod tabanlarını kısa süre içerisinde analiz edebilmesidir.

Bir uygulamada milyonlarca satır kaynak kod bulunabilir.

Bütün bu kodun insan tarafından satır satır incelenmesi hem çok uzun sürer hem de ekonomik olarak sürdürülebilir değildir.

SAST otomasyon sayesinde bu yükün önemli bölümünü üstlenir.

Özellikle belirli güvenlik problemlerinde oldukça başarılı olabilir.

Örneğin:

- SQL Injection
- Command Injection
- Path Traversal
- Cross-Site Scripting
- Güvensiz kriptografi kullanımı
- Riskli fonksiyon çağrıları
- Hard-coded credential
- Hata yönetimi problemleri
- Güvensiz veri akışları

gibi birçok alan otomatik analiz için uygundur.

SAST ayrıca tekrar eden güvenlik problemlerinin sistematik şekilde tespit edilmesini sağlar.

Örneğin bir kurumun 200 farklı repository'si bulunuyorsa her repository üzerinde aynı güvenlik kuralları otomatik olarak uygulanabilir.

Bu, manuel analiz ile sağlanması zor olan önemli bir standardizasyon avantajıdır.

### \2. Otomatik Güvenlik Analizinin Temel Sınırı

SAST sistemlerinin temel problemi teknolojinin kötü olması değildir.

Asıl problem kaynak kod güvenliğinin yalnızca teknik pattern'lerden oluşmamasıdır.

Bir güvenlik açığı bazen bir fonksiyon çağrısından veya yanlış API kullanımından kaynaklanır.

Böyle durumlarda otomatik sistem oldukça başarılı olabilir.

Ancak bazı açıklar uygulamanın işleyişinden kaynaklanır.

Bu tür güvenlik açıklarını anlamak için yalnızca kodun syntax'ını değil, uygulamanın ne yapmak istediğini de bilmek gerekir.

Örneğin uygulamada şu kod olabilir:

if user.isAuthenticated():

transferMoney()

Kodda authentication kontrolü vardır.

SAST sistemi bunun güvenli olduğunu düşünebilir.

Ancak gerçek iş kuralı şu olabilir:

**Bir kullanıcının yalnızca kendi hesabından para transferi yapabilmesi gerekir.**

Kod kullanıcının login olduğunu doğruluyor ancak transfer yapılan hesabın gerçekten kullanıcıya ait olup olmadığını kontrol etmiyorsa ciddi Broken Access Control problemi bulunmaktadır.

Buradaki açık syntax hatası değildir.

**İş mantığı hatasıdır.**

### \3. Business Logic Açığı Nedir?

Business Logic Vulnerability, uygulamanın iş kurallarının yanlış veya eksik uygulanması sonucunda ortaya çıkan güvenlik problemidir.

Bu tür açıklar klasik güvenlik açıklarından farklı olabilir.

Bir SQL Injection saldırısında saldırgan zararlı SQL payload gönderir.

Business Logic saldırısında ise saldırgan uygulamanın normal fonksiyonlarını kötüye kullanabilir.

Örneğin bir e-ticaret uygulamasında indirim kodunun yalnızca bir kez kullanılması gerekiyor olabilir.

Ancak backend indirim kodunun kullanım sayısını kontrol etmiyorsa saldırgan aynı kodu tekrar tekrar kullanabilir.

Burada saldırgan zararlı kod çalıştırmamıştır.

SQL Injection yapmamıştır.

XSS payload göndermemiştir.

Sadece sistemin normal fonksiyonunu beklenmeyen şekilde kullanmıştır.

Bu nedenle Business Logic açıkları otomatik güvenlik araçlarının en zorlandığı alanlardan biridir.

### \4. Business Logic Açıklarına Örnekler

Business Logic güvenlik problemleri sektör ve uygulamaya göre değişebilir.

Örneğin bir finans uygulamasında:

- transfer limitinin aşılması,
- negatif tutarla işlem yapılması,
- farklı müşterinin hesabından işlem başlatılması,
- onay sürecinin atlanması

gibi problemler oluşabilir.

Bir e-ticaret uygulamasında:

- indirim kodunun sınırsız kullanılması,
- ürün fiyatının client tarafından değiştirilmesi,
- negatif ürün adedi gönderilmesi,
- ödeme tamamlanmadan sipariş oluşturulması

gibi açıklar bulunabilir.

Bir rezervasyon sisteminde:

- başka kullanıcının rezervasyonunun iptal edilmesi,
- ücretsiz rezervasyon oluşturulması,
- tarih kısıtlamalarının atlanması

gibi güvenlik problemleri ortaya çıkabilir.

Bu açıkların ortak özelliği uygulamanın iş kurallarına bağlı olmalarıdır.

Dolayısıyla otomatik SAST motorunun bunları anlaması her zaman mümkün değildir.

### \5. Manuel Kaynak Kod Analizi Nedir?

Manuel kaynak kod analizi, güvenlik uzmanının uygulamanın kaynak kodunu güvenlik perspektifinden incelemesidir.

Bu süreç yalnızca satır satır kod okumak değildir.

Uzman öncelikle uygulamanın mimarisini anlamaya çalışır.

Örneğin:

- uygulamanın hangi modüllerden oluştuğu,
- authentication mekanizmasının nasıl çalıştığı,
- authorization yapısının nasıl uygulandığı,
- kullanıcı rollerinin nasıl tanımlandığı,
- verilerin hangi sistemlerde tutulduğu,
- kritik iş fonksiyonlarının neler olduğu,
- dış servis entegrasyonlarının nasıl gerçekleştiği

analiz edilir.

Ardından güvenlik açısından kritik kod bölgelerine odaklanılır.

Bu yaklaşım SAST'ın ürettiği genel görünürlüğü insan uzmanlığıyla derinleştirir.

### \6. Manuel Kod Analizinin Avantajı Nedir?

Manuel kaynak kod analizinin en büyük avantajı **context**, yani bağlamı anlayabilmesidir.

Bir güvenlik uzmanı kodu yalnızca programlama dili açısından değerlendirmez.

Şu soruları da sorabilir:

#### Bu fonksiyon ne yapıyor?

#### Kimler bu fonksiyonu çağırabilir?

#### Bu veri neden burada kullanılıyor?

#### Yetkilendirme gerçekten doğru kullanıcıya uygulanıyor mu?

#### Bir saldırgan bu akışı farklı sırada çalıştırabilir mi?

#### Birden fazla fonksiyon bir araya geldiğinde güvenlik problemi oluşuyor mu?

Bu tür değerlendirmeler otomatik sistemlerin sınırlı olduğu alanlardır.

### \7. SAST ve Manuel Analiz Birbirinin Alternatifi midir?

Hayır.

Bu iki yöntem birbirinin alternatifi değil tamamlayıcısıdır.

SAST çok büyük miktarda kodu hızlı şekilde analiz eder.

Manuel analiz ise kritik noktaları daha derin değerlendirir.

En güçlü model şu şekilde çalışır:

**SAST → Otomatik Bulgular → Triaging → Manuel Analiz → Risk Doğrulama**

Bu yaklaşım güvenlik ekibinin verimliliğini önemli ölçüde artırabilir.

SAST binlerce kod satırı içerisindeki potansiyel risk noktalarını belirler.

Güvenlik uzmanı ise bu noktalarda gerçek güvenlik riskinin bulunup bulunmadığını değerlendirir.

### \8. False Positive Problemi

SAST sistemlerinde en çok karşılaşılan problemlerden biri **False Positive** yani yanlış pozitif sonuçlardır.

False Positive, aracın güvenlik açığı olduğunu düşündüğü ancak gerçekte istismar edilebilir olmayan durumları ifade eder.

Örneğin SAST sistemi kullanıcı girdisinin SQL sorgusuna ulaştığını görebilir.

Ancak uygulama framework seviyesinde otomatik parameterization kullanıyor olabilir.

Araç framework davranışını doğru anlayamazsa SQL Injection bulgusu oluşturabilir.

Bu durumda raporda güvenlik açığı görünür ancak gerçekte sistem güvenlidir.

False Positive sayısı arttıkça güvenlik operasyonu zorlaşır.

Çünkü ekip zamanını gerçek olmayan bulguları araştırmak için harcamaya başlar.

### \9. False Positive Neden Tehlikelidir?

İlk bakışta False Positive yalnızca zaman kaybı gibi görünebilir.

Ancak uzun vadede daha ciddi bir problem oluşturabilir.

Eğer geliştiriciler sürekli yanlış güvenlik uyarıları alırsa araçlara olan güven azalır.

Bu duruma bazen **Alert Fatigue** denir.

Geliştirici her gün onlarca önemsiz uyarı görüyorsa zamanla uyarıları dikkate almamaya başlayabilir.

Sonuçta gerçek kritik güvenlik açığı da aynı liste içerisinde kaybolabilir.

Bu nedenle başarılı bir SAST programının amacı maksimum sayıda bulgu üretmek değildir.

Amaç:

**yüksek doğrulukta ve uygulanabilir güvenlik bulguları üretmektir.**

### \10. False Negative Problemi

False Negative, gerçek bir güvenlik açığının SAST tarafından tespit edilememesidir.

Bu durum False Positive'den daha kritik olabilir.

Çünkü sistem herhangi bir uyarı üretmez.

Ekip kodun güvenli olduğunu düşünebilir.

Ancak gerçek güvenlik problemi production ortamına ulaşmış olabilir.

Örneğin karmaşık bir authorization problemi SAST tarafından görülemeyebilir.

Business Logic açığı tespit edilmeyebilir.

Framework'e özgü özel bir güvenlik problemi analiz motorunun kurallarında bulunmayabilir.

Bu nedenle SAST raporunda kritik bulgu bulunmaması:

**“Uygulama güvenlidir.”**

anlamına gelmez.

### \11. Neden Hiçbir Araç %100 Güvenlik Sağlayamaz?

Yazılım güvenliği deterministik bir problem değildir.

Bir uygulamanın güvenliği yalnızca kullanılan fonksiyonların listesiyle belirlenemez.

Uygulama mimarisi,

iş kuralları,

kullanıcı rolleri,

deployment ortamı,

veri akışları,

harici entegrasyonlar,

network erişimleri

birlikte değerlendirilmelidir.

Bu nedenle SAST dahil hiçbir otomatik güvenlik aracı %100 güvenlik garantisi veremez.

Amaç zaten bütün güvenliği tek bir ürüne yüklemek değildir.

Modern güvenlik mimarisinde farklı güvenlik katmanları birlikte çalışır.

### \12. Security Triaging Nedir?

SAST tarafından bulunan bulguların güvenlik uzmanları tarafından incelenerek gerçek risklerin belirlenmesi sürecine genellikle **Security Triaging** denir.

Triaging sırasında güvenlik uzmanı bulguyu değerlendirir.

Örneğin:

- Kod gerçekten erişilebilir mi?
- Kullanıcı girdisi gerçekten kontrol edilebilir mi?
- Güvenlik kontrolü başka katmanda uygulanıyor mu?
- Bulgu production ortamında geçerli mi?
- Saldırgan hangi şartlarda istismar edebilir?
- Gerçek iş etkisi ne olabilir?

Bu değerlendirme sonucunda bulgu;

- True Positive
- False Positive
- Accepted Risk
- Not Exploitable
- Needs Investigation

gibi kategorilere ayrılabilir.

Bu süreç SAST operasyonlarının en önemli aşamalarından biridir.

### \13. True Positive Nedir?

True Positive, SAST aracının tespit ettiği bulgunun gerçekten güvenlik açığı olmasıdır.

Ancak burada da önemli bir ayrım vardır.

Her True Positive aynı risk seviyesine sahip değildir.

Örneğin iki farklı SQL Injection bulgusu olabilir.

Birincisi internet üzerinden erişilebilen kritik ödeme sisteminde bulunabilir.

İkincisi yalnızca lokal test ortamında kullanılan bir araçta olabilir.

Teknik zafiyet aynı olsa bile iş riski tamamen farklıdır.

Bu nedenle profesyonel güvenlik değerlendirmesinde yalnızca teknik severity yeterli değildir.

### \14. Risk = Teknik Açık Değildir

Application Security programlarında sık yapılan hatalardan biri teknik severity ile gerçek riski aynı kabul etmektir.

Gerçek risk değerlendirmesinde farklı faktörler birlikte ele alınmalıdır.

Örneğin:

**Risk = Teknik Etki × İstismar Edilebilirlik × Erişilebilirlik × İş Kritikliği**

şeklinde düşünülebilir.

Bir güvenlik açığı teknik olarak kritik olabilir.

Ancak ilgili kod production ortamında kullanılmıyorsa gerçek risk daha düşük olabilir.

Buna karşılık teknik olarak Medium görünen bir authorization problemi çok hassas müşteri verilerine erişim sağlıyorsa iş etkisi kritik olabilir.

Bu nedenle SAST skorları kör şekilde kabul edilmemelidir.

### \15. Reachability Analysis Neden Önemlidir?

Bir kod tabanında güvenlik açısından riskli kütüphane veya fonksiyon bulunması her zaman o zafiyetin istismar edilebilir olduğu anlamına gelmez.

Örneğin riskli fonksiyon hiç çağrılmıyor olabilir.

Sadece eski test kodunda bulunabilir.

Uygulamanın dışarıdan erişilemeyen bir bölümünde olabilir.

Bu nedenle modern güvenlik programlarında **Reachability Analysis** giderek daha önemli hale gelmektedir.

Temel soru şudur:

#### Saldırgan bu güvenlik problemine gerçekten ulaşabilir mi?

Reachability değerlendirmesi hem False Positive sayısını azaltır hem de gerçek risklerin daha doğru önceliklendirilmesini sağlar.

### \16. Kodun Çalışma Ortamı Neden Önemlidir?

Statik analiz kaynak kodu inceler.

Ancak gerçek güvenlik riski bazen çalışma ortamına bağlıdır.

Örneğin bir fonksiyon teorik olarak SSRF açığı içeriyor olabilir.

Ancak production ortamındaki network policy nedeniyle sunucu hiçbir internal sisteme erişemiyor olabilir.

Risk hâlâ vardır ancak etkisi farklı olabilir.

Tersi de mümkündür.

Kodda küçük görünen SSRF problemi cloud ortamında metadata servislerine erişim sağlayabiliyorsa çok kritik hale gelebilir.

Dolayısıyla kod güvenliğini değerlendirirken deployment context önemlidir.

### \17. Runtime Güvenlik Problemleri

Bazı güvenlik problemleri uygulama çalışmadan tam olarak değerlendirilemez.

Örneğin:

- Session yönetimi
- Cache davranışı
- HTTP güvenlik header'ları
- CORS yapılandırması
- TLS ayarları
- Reverse proxy davranışı
- WAF etkisi
- Authentication token yaşam döngüsü

runtime ortamında daha iyi değerlendirilebilir.

Bu nedenle SAST'ın yanında DAST ve manuel pentest gibi dinamik test yöntemleri önemlidir.

### \18. SAST ve DAST Arasındaki Tamamlayıcı İlişki

SAST uygulamanın içini görür.

DAST ise uygulamaya dışarıdan bakar.

Bu iki perspektif birbirini tamamlar.

Örneğin SAST kaynak kod içerisinde potansiyel XSS bulabilir.

DAST çalışan uygulamada bu XSS'nin gerçekten tetiklenip tetiklenmediğini test edebilir.

SAST SQL sorgusuna ulaşan riskli veri akışını gösterebilir.

DAST gerçek HTTP request üzerinden saldırı davranışını değerlendirebilir.

Dolayısıyla güvenlik programında:

#### SAST + DAST

kombinasyonu güçlü bir temel oluşturur.

Ancak business logic ve ileri seviye saldırı senaryoları için yine manuel pentest gerekir.

### \19. Manuel Pentest Neden Hâlâ Gereklidir?

Otomasyonun hızla gelişmesine rağmen manuel sızma testi önemini korumaktadır.

Çünkü saldırganlar yalnızca bilinen pattern'leri kullanmaz.

Birden fazla fonksiyonu zincirleyebilir.

Uygulamanın iş mantığını manipüle edebilir.

Kullanıcı rollerini karşılaştırabilir.

API çağrı sırasını değiştirebilir.

Bir düşük seviye açığı başka bir açıkla birleştirerek kritik saldırı oluşturabilir.

Bu tür senaryolara **Attack Chaining** denebilir.

SAST tek bir kod bölgesindeki güvenlik problemini görebilir.

Pentest uzmanı ise farklı zafiyetleri bir araya getirerek gerçek saldırı etkisini değerlendirebilir.

### \20. Attack Chaining Nedir?

Attack Chaining, birden fazla güvenlik probleminin birlikte kullanılmasıyla daha ciddi saldırı oluşturulmasıdır.

Örneğin tek başına düşük riskli bilgi ifşası bulunabilir.

Başka bir noktada zayıf authorization problemi olabilir.

Üçüncü noktada tahmin edilebilir identifier yapısı bulunabilir.

Bu üç problem birlikte kullanıldığında saldırgan hassas verilere erişebilir.

Otomatik araçlar bu bulguları ayrı ayrı raporlayabilir.

Ancak insan uzman saldırı zincirini görebilir.

Bu nedenle manuel güvenlik testinin değeri yalnızca yeni bulgu bulmak değildir.

**Bulgular arasındaki ilişkiyi anlamaktır.**

### \21. Code Review ile Security Code Review Aynı Şey midir?

Hayır.

Normal Code Review genellikle;

- kod kalitesi,
- okunabilirlik,
- performans,
- naming convention,
- mimari standartlar

üzerine odaklanabilir.

Security Code Review ise saldırgan perspektifinden değerlendirme yapar.

Örneğin:

- kullanıcı kontrollü veri nereden geliyor?
- authorization atlanabilir mi?
- hassas bilgi loglanıyor mu?
- güvenli olmayan kriptografi var mı?
- yarış durumu oluşabilir mi?
- dosya işlemi manipüle edilebilir mi?

gibi sorular sorulur.

Dolayısıyla klasik Code Review süreçlerine güvenlik kontrol listelerinin eklenmesi önemlidir.

### \22. Peer Review Güvenlik İçin Yeterli midir?

Peer Review oldukça faydalıdır.

Bir geliştiricinin yazdığı kodun başka geliştirici tarafından incelenmesi birçok hatanın erken yakalanmasını sağlar.

Ancak güvenlik uzmanlığı ayrı bir yetkinliktir.

Geliştiriciler uygulamanın fonksiyonel ve mimari yapısını çok iyi bilir.

Güvenlik uzmanları ise saldırgan davranışları ve güvenlik zafiyetleri konusunda uzmanlaşır.

En güçlü model bu iki bakış açısını birleştirir.

Bu nedenle kritik uygulamalarda:

**Developer Peer Review + SAST + Security Code Review**

birlikte kullanılabilir.

### \23. Güvenlik Uzmanı Kaynak Kodda Nereye Bakar?

Manuel kaynak kod analizi bütün kodu eşit derinlikte incelemek anlamına gelmez.

Risk bazlı yaklaşım kullanılır.

Özellikle aşağıdaki bölgeler daha kritik olabilir:

- Authentication modülleri
- Authorization kontrolleri
- Payment işlemleri
- Dosya yükleme fonksiyonları
- SQL ve database erişimi
- Cryptography kullanımı
- API endpoint'leri
- Admin fonksiyonları
- Password reset akışları
- Token üretimi
- External service çağrıları
- Serialization işlemleri

Bu alanlar saldırgan açısından daha yüksek değer taşıdığı için daha detaylı analiz edilebilir.

### \24. Authentication Kodunun Manuel İncelenmesi

Authentication güvenlik sisteminin en kritik bölümlerinden biridir.

Manuel analiz sırasında örneğin şu kontroller yapılabilir:

- Parolalar nasıl saklanıyor?
- Password hashing güvenli mi?
- Brute force koruması var mı?
- MFA bypass mümkün mü?
- Session ID güvenli üretiliyor mu?
- Password reset tokenları tahmin edilebilir mi?
- Token süresi doğru mu?
- Logout gerçekten session'ı geçersiz kılıyor mu?

Bu kontrollerin bazıları SAST tarafından sınırlı ölçüde analiz edilebilir.

Ancak bütün authentication yaşam döngüsünün değerlendirilmesi insan analizi gerektirebilir.

### \25. Authorization Kodunun Manuel İncelenmesi

Authorization, manuel analiz açısından en kritik alanlardan biridir.

Güvenlik uzmanı farklı kullanıcı rollerini anlamaya çalışır.

Örneğin:

- User
- Manager
- Administrator
- Auditor
- API Service Account

gibi roller olabilir.

Ardından kritik endpoint ve fonksiyonların hangi rollere açık olduğu değerlendirilir.

Özellikle Object Level Authorization kontrolleri incelenir.

Şu soru önemlidir:

#### Kullanıcının sisteme giriş yapmış olması dışında, ilgili nesneye erişim hakkı gerçekten doğrulanıyor mu?

Bu kontrol BOLA ve IDOR gibi güvenlik problemlerinin tespitinde kritik rol oynar.

### \26. Race Condition ve İşlem Sırası Problemleri

Bazı business logic açıkları eşzamanlı işlemlerden kaynaklanır.

Örneğin bir kullanıcının kuponu yalnızca bir kez kullanması gerekiyor olabilir.

Ancak aynı anda iki HTTP request gönderildiğinde her iki işlem de kuponu kullanılmamış olarak görebilir.

Sonuçta kupon iki kez kullanılır.

Bu tür durumlara **Race Condition** denir.

SAST bazı teknik yarış durumlarını tespit edebilir.

Ancak gerçek iş etkisinin anlaşılması çoğu zaman dinamik test gerektirir.

Bu örnek SAST + manuel pentest kombinasyonunun neden güçlü olduğunu gösterir.

### \27. Mass Assignment Problemleri

Modern API uygulamalarında kullanıcı tarafından gönderilen JSON verisinin doğrudan model nesnesine bağlanması yaygındır.

Örneğin kullanıcı profil güncellemesi için şu veri gönderilebilir:

{"name":"Ali","surname":"Yılmaz"}

Ancak backend bütün alanları otomatik olarak kabul ediyorsa saldırgan şu alanı eklemeyi deneyebilir:

{"name":"Ali","role":"admin"}

Eğer uygulama role alanını da model içerisine bind ediyorsa ciddi authorization problemi oluşabilir.

Bu tür açıklar framework davranışına ve business logic'e bağlı olduğundan otomatik analiz sistemleri tarafından her zaman doğru tespit edilemeyebilir.

### \28. Second-Order Vulnerability Nedir?

Bazı güvenlik açıklarında zararlı veri sisteme girdiği anda saldırı gerçekleşmez.

Veri önce veritabanına kaydedilir.

Daha sonra farklı bir fonksiyon tarafından kullanıldığında güvenlik açığı tetiklenir.

Buna **Second-Order Vulnerability** denebilir.

Örneğin kullanıcı girdisi veritabanına kaydedilir.

Aylar sonra admin panelinde bu veri güvenli olmayan şekilde SQL sorgusunda veya HTML çıktısında kullanılır.

Bu tür uzun veri akışlarını otomatik analiz etmek oldukça zordur.

Gelişmiş SAST sistemleri bazı durumlarda tespit edebilir ancak manuel analiz hâlâ değerli olabilir.

### \29. Framework Güvenlik Özellikleri SAST'ı Yanıltabilir mi?

Evet.

Modern framework'ler birçok güvenlik özelliğini otomatik uygular.

Örneğin:

- otomatik output encoding,
- CSRF protection,
- parameterized ORM query,
- authentication middleware

gibi kontroller bulunabilir.

SAST motoru framework davranışını doğru modellemiyorsa False Positive oluşturabilir.

Tersi de mümkündür.

Framework varsayılan olarak güvenli olabilir ancak geliştirici güvenlik kontrolünü manuel olarak devre dışı bırakmış olabilir.

Bu nedenle teknoloji stack'ini anlayan güvenlik uzmanının analizi önemlidir.

### \30. Custom Framework ve Internal Library Problemi

Büyük kurumlar çoğu zaman kendi geliştirdikleri framework ve internal library sistemlerini kullanır.

SAST ürünü bu özel kütüphanelerin güvenlik davranışlarını bilmeyebilir.

Örneğin kurumun kendi sanitization fonksiyonu bulunabilir.

Araç bunu tanımadığı için binlerce False Positive üretebilir.

Bu durumda SAST çözümünde custom rule veya custom sanitizer tanımları oluşturulması gerekir.

Bu ayarlar profesyonel SAST operasyonunun önemli parçalarındandır.

### \31. SAST Tuning Nedir?

SAST aracı kurulduktan sonra doğrudan binlerce repository üzerinde çalıştırmak ideal yaklaşım değildir.

Sistem kurumun teknoloji yapısına göre optimize edilmelidir.

Bu sürece **SAST Tuning** denebilir.

Tuning kapsamında:

- False Positive kuralları,
- custom source tanımları,
- custom sink tanımları,
- sanitizer fonksiyonları,
- framework davranışları,
- severity mapping,
- exclusion listeleri

gibi ayarlar yapılabilir.

Amaç aracın kurumun gerçek yazılım yapısını daha iyi anlamasını sağlamaktır.

### \32. SAST Politikaları Nasıl Oluşturulmalıdır?

SAST bulgularının nasıl yönetileceği açık politikalarla belirlenmelidir.

Örneğin kurum şöyle bir politika oluşturabilir:

**Critical:** Release engellenir.

**High:** Release öncesi remediation gerekir.

**Medium:** Belirlenen SLA içerisinde düzeltilir.

**Low:** Backlog'a alınır.

Ancak bu politika yalnızca araç severity değerine bağlı olmamalıdır.

İş kritikliği ve gerçek istismar koşulları da dikkate alınmalıdır.

### \33. Security Quality Gate Her Bulguda Pipeline'ı Durdurmalı mı?

Hayır.

Bu sık yapılan DevSecOps hatalarından biridir.

Eğer her düşük seviyeli SAST uyarısı build'i durdurursa geliştiriciler güvenlik sistemini bir engel olarak görmeye başlar.

Bu durum zamanla kontrollerin bypass edilmesine yol açabilir.

Quality Gate risk bazlı olmalıdır.

Örneğin:

- yeni Critical bulgu,
- doğrulanmış High severity güvenlik açığı,
- hard-coded production credential,
- internet-facing uygulamada kritik Injection

gibi durumlarda pipeline durdurulabilir.

Daha düşük riskli bulgular ticket sistemine aktarılabilir.

### \34. Legacy Kodlarda SAST Nasıl Uygulanmalıdır?

Yıllardır geliştirilen büyük bir uygulamada SAST ilk kez çalıştırıldığında binlerce bulgu çıkabilir.

Bu durumda bütün açıkları bir anda düzeltmeye çalışmak gerçekçi olmayabilir.

Daha uygulanabilir yaklaşım **New Code Policy** kullanmaktır.

Mevcut teknik borç backlog olarak yönetilir.

Ancak yeni yazılan kodun güvenlik standardını düşürmesine izin verilmez.

Temel prensip:

**Yeni güvenlik açığı üretme.**

Ardından eski güvenlik borcu risk bazlı şekilde azaltılır.

### \35. Security Debt Nedir?

Security Debt, geçmişten gelen ve henüz giderilmemiş güvenlik problemlerini ifade eder.

Technical Debt kavramına benzer.

Örneğin eski uygulamada yüzlerce düşük ve orta seviyeli güvenlik problemi bulunabilir.

Bunların tamamını aynı anda düzeltmek mümkün olmayabilir.

Bu nedenle Security Debt ölçülmeli ve yönetilmelidir.

Kritik riskler önceliklendirilmeli,

tekrar eden güvenlik hatalarının kök nedeni belirlenmeli

ve zaman içerisinde borç azaltılmalıdır.

### \36. SAST Bulguları Geliştiriciye Nasıl Sunulmalıdır?

Güvenlik ekibinin başarısı yalnızca güvenlik açığını bulmasına bağlı değildir.

Bulgunun geliştirici tarafından anlaşılması da gerekir.

Kötü bir bulgu:

**“CWE-89 bulundu. Düzeltin.”**

şeklinde olabilir.

İyi bir bulgu ise:

- riskli kod satırını,
- Source noktasını,
- Sink noktasını,
- saldırı senaryosunu,
- güvenli alternatif kodu

gösterir.

Geliştiricinin problemi birkaç dakika içerisinde anlayabilmesi remediation süresini önemli ölçüde azaltır.

### \37. Developer Experience Neden Önemlidir?

DevSecOps programlarının başarısında geliştirici deneyimi kritik öneme sahiptir.

Güvenlik sistemi sürekli yanlış alarm üretirse,

tarama çok uzun sürerse,

raporlar anlaşılmazsa,

geliştirici güvenlik ekibine sürekli ticket açmak zorunda kalırsa

sistem sürdürülebilir olmaz.

İyi AppSec programı güvenliği geliştirici workflow'una entegre eder.

Örneğin bulgu doğrudan Pull Request içerisinde gösterilebilir.

Güvenli kod önerisi aynı ekranda sunulabilir.

Geliştirici başka bir platforma geçmeden problemi çözebilir.

### \38. İnsan Uzmanlığı Nerede En Değerlidir?

Otomasyon özellikle ölçek ve hız konusunda güçlüdür.

İnsan uzmanlığı ise bağlam ve yaratıcılık konusunda güçlüdür.

Manuel güvenlik uzmanının en fazla değer sağladığı alanlar genellikle şunlardır:

- Business Logic
- Authorization
- Authentication
- Attack Chaining
- Complex Data Flow
- Race Condition
- Custom Cryptography
- Kritik mimari kararlar
- Uygulamaya özgü güvenlik modeli

Bu nedenle en iyi güvenlik programı otomasyon ile insanı karşı karşıya getirmez.

İkisini birlikte kullanır.

### \39. İdeal Kaynak Kod Güvenliği Modeli

Modern kurumsal kaynak kod güvenliği modeli şu şekilde kurgulanabilir:

#### Katman 1 – Developer Controls

Secure Coding

IDE Security Plugin

Peer Review

#### Katman 2 – Automated Security

SAST

SCA

Secret Scanning

#### Katman 3 – Security Review

SAST Triaging

Manual Code Review

Architecture Review

#### Katman 4 – Runtime Testing

DAST

API Security Testing

Pentest

#### Katman 5 – Continuous Improvement

Retest

Metrics

Secure Coding Training

Security Champion

Bu yaklaşım güvenliği tek bir üründen çıkararak bütün yazılım yaşam döngüsüne yayar.

**\40. SAST + Manuel Kod Analizi + Pentest Modeli**

Pratik açıdan en güçlü yaklaşımlardan biri üç farklı bakış açısını birleştirmektir.

#### SAST

Kodun tamamında geniş ölçekli otomatik analiz sağlar.

#### Manuel Kaynak Kod Analizi

Kritik kod bölgelerinde bağlamsal ve derin analiz gerçekleştirir.

#### Pentest

Çalışan uygulamayı gerçek saldırgan perspektifinden değerlendirir.

Bu üç yöntem bir araya geldiğinde farklı güvenlik kör noktaları önemli ölçüde azalır.

SAST kodu görür.

Pentest uygulamanın davranışını görür.

Manuel uzman ise ikisi arasındaki ilişkiyi yorumlayabilir.

### SecureSys SAST ve Manuel Kaynak Kod Analizi Yaklaşımı

SecureSys olarak kaynak kod güvenliği çalışmalarında yalnızca otomatik tarama çıktılarının raporlanmasını yeterli bir güvenlik yaklaşımı olarak değerlendirmiyoruz.

SAST büyük kod tabanlarında görünürlük sağlamak ve güvenlik problemlerini erken aşamada belirlemek açısından kritik öneme sahiptir.

Ancak gerçek güvenlik riskinin ortaya çıkarılması için bulguların uygulama bağlamında değerlendirilmesi gerekir.

Bu nedenle proje kapsamına göre;

**SAST + Security Triaging + Manuel Kaynak Kod Analizi + SCA + Secret Scanning + DAST + Pentest**

katmanları birlikte kullanılabilir.

Özellikle;

- kritik authentication fonksiyonları,
- authorization mekanizmaları,
- finansal işlem akışları,
- hassas veri işlemleri,
- API servisleri,
- dosya işlemleri,
- admin fonksiyonları

gibi yüksek riskli alanlar daha derin manuel değerlendirmeye alınabilir.

Temel hedefimiz mümkün olan en fazla güvenlik bulgusunu üretmek değildir.

**Gerçek, istismar edilebilir ve iş açısından önemli güvenlik risklerini ortaya çıkarmaktır.**

Çünkü güvenlik raporunun değeri sayfa sayısıyla veya bulgu sayısıyla ölçülmez.

Gerçek değer;

**kurumun hangi riskleri önce çözmesi gerektiğini doğru gösterebilmesidir.**

### Sık Sorulan Sorular

#### SAST tek başına yeterli midir?

Hayır. SAST güçlü bir otomatik güvenlik kontrolüdür ancak Business Logic, karmaşık authorization problemleri ve runtime güvenlik problemleri gibi bazı açıkları tespit edemeyebilir.

#### Manuel kaynak kod analizi gerekli midir?

Özellikle kritik uygulamalarda önerilir. Manuel analiz uygulamanın iş mantığı, authentication, authorization ve karmaşık veri akışlarının güvenlik uzmanı tarafından değerlendirilmesini sağlar.

#### False Positive nedir?

SAST aracının gerçekte istismar edilebilir olmayan bir durumu güvenlik açığı olarak raporlamasıdır.

#### False Negative nedir?

Gerçek bir güvenlik açığının SAST tarafından tespit edilememesidir.

#### SAST ile pentest arasındaki fark nedir?

SAST kaynak kodu analiz eder. Pentest çalışan uygulamaya saldırgan perspektifinden yaklaşır. İki yöntem birbirini tamamlar.

#### Business Logic açığı nedir?

Uygulamanın iş kurallarının yanlış veya eksik uygulanması sonucunda ortaya çıkan güvenlik açığıdır. Otomatik güvenlik sistemleri tarafından tespit edilmesi zor olabilir.

#### SAST bulgularının manuel doğrulanması gerekir mi?

Özellikle kritik bulgularda önerilir. Böylece False Positive sonuçlar ayıklanabilir ve gerçek risk seviyesi daha doğru belirlenebilir.

#### SAST bütün kaynak kodu manuel analiz etmenin yerine geçebilir mi?

SAST manuel analizin ihtiyaç duyduğu kod miktarını önemli ölçüde azaltabilir ancak kritik iş fonksiyonlarında insan uzmanlığının tamamen yerini alamaz.

### Sonuç: Otomasyon Hızı Sağlar, İnsan Bağlamı Anlar

SAST modern Application Security programlarının vazgeçilmez teknolojilerinden biridir.

Milyonlarca satır kaynak kodu analiz edebilir.

Güvenlik kontrollerini CI/CD pipeline'ına taşıyabilir.

Geliştiricilere kod yazarken geri bildirim verebilir.

Bilinen güvenlik problemlerini sistematik şekilde tespit edebilir.

Ancak bir uygulamanın gerçekten güvenli olup olmadığını anlamak yalnızca pattern matching veya data flow analizi ile mümkün değildir.

Çünkü yazılım güvenliği aynı zamanda;

**iş mantığıdır.**

**kullanıcı yetkisidir.**

**mimaridir.**

**veri akışıdır.**

**saldırgan davranışıdır.**

Bu nedenle güçlü güvenlik yaklaşımı:

#### İnsan mı, otomasyon mu?

sorusunu sormaz.

Doğru soru şudur:

#### İnsan uzmanlığı ve otomasyon birlikte nasıl en verimli şekilde kullanılabilir?

Modern Application Security'nin cevabı da burada yatmaktadır:

**Otomasyon ölçek sağlar.**

**Manuel analiz bağlam sağlar.**

**Pentest saldırgan perspektifi sağlar.**

Bu üç yaklaşım birlikte kullanıldığında güvenli yazılım geliştirme yolculuğu çok daha güçlü hale gelir.