# SAST Nedir? Static Application Security Testing Nasıl Çalışır?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kaynak-kod-analizi/sast-nedir-nasil-calisir

![SAST Nedir? Static Application Security Testing Nasıl Çalışır?](/images/bilgi-merkezi/covers/cover-kod-03.webp)

Modern yazılım geliştirme süreçlerinde hız her geçen gün artıyor.

Yeni özellikler daha kısa sürede geliştiriliyor.

Kodlar gün içerisinde defalarca repository sistemlerine gönderiliyor.

CI/CD pipeline'ları sayesinde uygulamalar saatler hatta dakikalar içerisinde test edilip canlı ortama alınabiliyor.

Bu hız yazılım ekiplerine önemli avantajlar sağlıyor.

Ancak aynı zamanda kritik bir soruyu da beraberinde getiriyor:

#### Güvenlik kontrolleri bu hıza nasıl yetişecek?

Her kod değişikliğinden sonra manuel kaynak kod analizi yapmak mümkün değildir.

Her commit sonrasında kapsamlı bir sızma testi gerçekleştirmek de gerçekçi değildir.

Dolayısıyla güvenlik kontrollerinin otomatik hale getirilmesi gerekir.

İşte bu noktada **SAST – Static Application Security Testing** devreye girer.

SAST, uygulama çalıştırılmadan kaynak kodun veya yazılım bileşenlerinin güvenlik açısından analiz edilmesini sağlayan bir yöntemdir.

Temel amaç geliştiricinin yazdığı kod içerisindeki güvenlik problemlerini mümkün olduğunca erken aşamada tespit etmektir.

Ancak SAST yalnızca belirli kelimeleri veya kod satırlarını arayan basit bir tarama sistemi değildir.

Modern SAST çözümleri;

#### Data Flow Analysis, Taint Analysis, Control Flow Analysis, Source-Sink Analysis ve Semantic Code Analysis

gibi teknikleri kullanarak uygulamanın kaynak kodunu anlamaya çalışır.

Bu nedenle SAST, modern Application Security ve DevSecOps programlarının temel güvenlik katmanlarından biri haline gelmiştir.

### \1. SAST Nedir?

SAST, **Static Application Security Testing** ifadesinin kısaltmasıdır.

Türkçede genel olarak:

#### Statik Uygulama Güvenlik Testi

veya

#### Statik Kod Güvenlik Analizi

olarak ifade edilebilir.

SAST'ın temel özelliği uygulamanın çalıştırılmasına ihtiyaç duymadan analiz yapılabilmesidir.

Bir SAST aracı kaynak kodu, derlenmiş kodu veya bytecode gibi yazılım bileşenlerini inceleyerek potansiyel güvenlik problemlerini tespit etmeye çalışır.

Örneğin bir web uygulamasında kullanıcıdan alınan bir parametrenin herhangi bir doğrulama yapılmadan SQL sorgusuna aktarıldığını düşünelim.

SAST sistemi bu veri akışını takip ederek şu ilişkiyi tespit etmeye çalışabilir:

**Kullanıcı Girdisi → Uygulama Fonksiyonu → SQL Sorgusu**

Eğer arada güvenli bir doğrulama veya parameterized query mekanizması bulunmuyorsa sistem potansiyel SQL Injection bulgusu oluşturabilir.

Bu yaklaşım sayesinde güvenlik açığı uygulama production ortamına ulaşmadan önce tespit edilebilir.

### \2. SAST Neden “Static” Olarak Adlandırılır?

SAST'ın ismindeki “Static” kelimesi analiz sırasında uygulamanın çalıştırılmamasını ifade eder.

Başka bir ifadeyle sistem uygulamaya dışarıdan saldırı göndermez.

HTTP request oluşturmaz.

API endpoint'ini aktif olarak çağırmaz.

Tarayıcı üzerinden uygulamayı kullanmaz.

Bunun yerine kodun kendisini inceler.

Bu nedenle SAST, DAST yani Dynamic Application Security Testing yaklaşımından farklıdır.

DAST çalışan uygulamayı dışarıdan değerlendirirken SAST uygulamanın iç yapısını analiz eder.

Bu ayrım önemlidir.

Çünkü SAST, dışarıdan görülmesi oldukça zor olan bazı güvenlik problemlerini kod seviyesinde tespit edebilir.

Örneğin;

- hard-coded credential,
- güvensiz kriptografik kullanım,
- riskli fonksiyon çağrısı,
- kontrol edilmeyen veri akışı,
- kod içerisinde bulunan API key,
- exception handling problemleri

kaynak kod seviyesinde daha kolay görülebilir.

### \3. SAST Kaynak Kodu Nasıl Analiz Eder?

SAST sistemlerinin çalışma mantığı kullanılan teknolojiye göre farklılık gösterebilir.

Ancak genel olarak birkaç temel analiz yöntemi bulunur.

Bunların başında:

- Lexical Analysis
- Syntax Analysis
- Abstract Syntax Tree
- Control Flow Analysis
- Data Flow Analysis
- Taint Analysis
- Semantic Analysis

gelir.

Modern SAST sistemleri bu yöntemlerin bir bölümünü veya tamamını kullanarak kaynak kodun güvenlik açısından anlamını çıkarmaya çalışır.

Buradaki temel amaç yalnızca belirli bir kod satırını bulmak değildir.

Asıl amaç:

**Verinin uygulama içerisinde nasıl hareket ettiğini anlamaktır.**

### \4. Abstract Syntax Tree – AST Nedir?

Bir SAST sisteminin kaynak kodu analiz ederken kullanabileceği temel yapılardan biri **Abstract Syntax Tree – AST** yapısıdır.

AST, kaynak kodun programlama dilindeki yapısal anlamını ağaç biçiminde temsil eder.

Örneğin geliştirici şu kodu yazmış olabilir:

result = userInput + 10

Bir insan bu satıra baktığında;

bir değişkenin kullanıcı girdisi ile toplandığını anlayabilir.

Ancak analiz motorunun kodu sistematik şekilde değerlendirebilmesi için kodun parçalarına ayrılması gerekir.

AST sayesinde sistem;

- değişkenleri,
- fonksiyonları,
- operatörleri,
- method çağrılarını,
- koşulları,
- döngüleri

yapısal olarak anlayabilir.

Bu yapı daha ileri güvenlik analizlerinin temelini oluşturur.

### \5. Control Flow Analysis Nedir?

Control Flow Analysis, uygulamanın hangi koşullarda hangi kod bloklarını çalıştırabileceğini analiz eder.

Örneğin bir uygulamada şu mantık bulunduğunu düşünelim:

Eğer kullanıcı admin ise yönetim paneline eriş.

Değilse erişimi reddet.

SAST sistemi yalnızca satırları bağımsız şekilde değerlendirmek yerine programın olası çalışma yollarını analiz eder.

Bu yapı genellikle **Control Flow Graph – CFG** üzerinden modellenebilir.

Control Flow Graph, program içerisinde bir kod bloğundan diğerine hangi yollarla geçilebileceğini gösterir.

Bu sayede güvenlik sistemi şu sorulara cevap arayabilir:

- Güvenlik kontrolü her kod yolunda uygulanıyor mu?
- Belirli bir koşul atlanabilir mi?
- Riskli fonksiyon güvenlik kontrolünden geçmeden çağrılabiliyor mu?

Özellikle karmaşık uygulamalarda bu analiz oldukça değerlidir.

### \6. Data Flow Analysis Nedir?

SAST teknolojisinin en önemli bileşenlerinden biri **Data Flow Analysis** yöntemidir.

Data Flow Analysis, bir verinin uygulama içerisinde nereden geldiğini ve nereye gittiğini takip eder.

Örneğin bir kullanıcı web formuna kullanıcı adı yazıyor olabilir.

Bu veri;

HTTP request içerisinden alınır.

Bir değişkene atanır.

Başka bir fonksiyona gönderilir.

Daha sonra SQL sorgusunda kullanılabilir.

SAST sistemi bu zinciri anlamaya çalışır.

Örneğin:

**HTTP Parameter → Variable → Function → SQL Query**

şeklinde bir veri akışı bulunabilir.

Eğer kullanıcı girdisi kritik noktaya güvenli bir kontrolden geçmeden ulaşıyorsa güvenlik problemi oluşabilir.

Bu nedenle SAST'ın gücü tek tek kod satırlarını incelemekten değil, kod içerisindeki veri akışlarını değerlendirebilmesinden gelir.

### \7. Source Nedir?

SAST dünyasında sık kullanılan kavramlardan biri **Source** kavramıdır.

Source, güvenilmeyen veya dışarıdan kontrol edilebilen verinin uygulamaya giriş yaptığı noktayı ifade eder.

Örneğin source olarak değerlendirilebilecek alanlardan bazıları şunlardır:

- HTTP GET parametreleri
- HTTP POST verileri
- API request body
- HTTP header
- Cookie
- URL parametreleri
- Dosya yüklemeleri
- Harici servislerden gelen veriler
- Message queue üzerinden gelen içerikler

Bunların ortak özelliği verinin uygulamanın tamamen kontrolü dışında bir kaynaktan gelebilmesidir.

Bu nedenle güvenlik analizinde Source noktaları özellikle önemlidir.

### \8. Sink Nedir?

**Sink**, verinin ulaştığı güvenlik açısından kritik fonksiyonu ifade eder.

Örneğin kullanıcı kontrollü veri aşağıdaki işlemlerde kullanılıyorsa güvenlik riski oluşabilir:

- SQL sorgusu
- İşletim sistemi komutu
- Dosya sistemi işlemi
- HTML çıktısı
- JavaScript çıktısı
- LDAP sorgusu
- Network isteği
- Template engine
- XML parser

Bu fonksiyonlar her zaman güvensiz değildir.

Risk, kullanıcı kontrollü verinin uygun güvenlik kontrollerinden geçmeden bu fonksiyonlara ulaşması durumunda ortaya çıkar.

Dolayısıyla SAST analizinin temel sorularından biri şudur:

#### Bir Source içerisinden gelen veri güvenli hale getirilmeden bir Sink noktasına ulaşabiliyor mu?

### \9. Source-to-Sink Analysis Nasıl Çalışır?

Source-to-Sink Analysis modern SAST sistemlerinin temel yaklaşımıdır.

Örneğin web uygulamasında kullanıcıdan gelen filename parametresi olduğunu düşünelim.

Uygulama bu parametreyi şu mantıkla kullanıyor olabilir:

**Kullanıcı parametresi → Dosya yolu oluştur → Dosyayı oku**

Burada;

kullanıcı parametresi **Source**,

dosya okuma fonksiyonu ise **Sink** olarak değerlendirilebilir.

Eğer kullanıcı /etc/passwd veya benzeri farklı bir dosya yolunu uygulamaya iletebiliyorsa Path Traversal problemi oluşabilir.

SAST sistemi kodu takip ederek kullanıcı girdisinin dosya okuma fonksiyonuna nasıl ulaştığını belirlemeye çalışır.

Bu analiz bazen tek dosya içerisinde gerçekleşmez.

Veri birden fazla fonksiyondan geçebilir.

Başka sınıfa aktarılabilir.

Farklı modüllerde işlenebilir.

Bu nedenle gelişmiş SAST çözümleri **interprocedural analysis**, yani fonksiyonlar arası analiz yapabilmelidir.

### \10. Taint Analysis Nedir?

Taint Analysis, kullanıcı kontrollü veya güvenilmeyen verinin uygulama içerisinde takip edilmesini sağlayan analiz yöntemidir.

Bu yaklaşımda dışarıdan gelen veri “tainted”, yani güvenilmeyen olarak işaretlenir.

Örneğin:

userInput = request.getParameter("search")

satırında userInput değişkeni kullanıcı tarafından kontrol edilebildiği için tainted olarak değerlendirilebilir.

Bu veri başka bir değişkene atanabilir:

searchText = userInput

Bu durumda searchText de tainted hale gelir.

Daha sonra bu veri SQL sorgusuna aktarılıyorsa sistem risk tespit edebilir.

SAST motoru temelde şunu takip eder:

#### Güvenilmeyen veri uygulama içerisinde nasıl yayılıyor?

Bu yaklaşım özellikle Injection türü güvenlik açıklarının tespit edilmesinde etkilidir.

### \11. Sanitizer Nedir?

Source ve Sink arasındaki üçüncü önemli kavram **Sanitizer** veya güvenlik kontrolüdür.

Sanitizer, kullanıcı girdisinin güvenli hale getirilmesini sağlayan işlem veya fonksiyonları ifade eder.

Ancak burada dikkat edilmesi gereken önemli bir nokta vardır.

Her güvenlik problemi için aynı sanitizer kullanılmaz.

Örneğin SQL Injection için doğru yöntem parameterized query olabilir.

XSS için context-aware output encoding kullanılabilir.

Dosya işlemleri için güvenli path validation uygulanabilir.

Dolayısıyla bir SAST sisteminin yalnızca Source ve Sink noktalarını bilmesi yeterli değildir.

Aynı zamanda aradaki güvenlik kontrollerini de anlaması gerekir.

Örneğin veri:

**Source → Validation → Parameterized Query → SQL**

şeklinde ilerliyorsa güvenli olabilir.

Ancak:

**Source → String Concatenation → SQL**

şeklinde ilerliyorsa potansiyel SQL Injection problemi oluşabilir.

### \12. SAST SQL Injection'ı Nasıl Tespit Eder?

Bir kullanıcıdan gelen username parametresinin doğrudan SQL sorgusuna eklendiğini düşünelim.

Örneğin uygulama şu mantığı kullanıyor olabilir:

query = "SELECT * FROM users WHERE username='" + username + "'"

Burada username kullanıcı tarafından kontrol edilmektedir.

SAST sistemi:

request parameter

noktasını Source olarak,

SQL execute fonksiyonunu ise Sink olarak tanımlayabilir.

Aradaki veri akışında güvenli parameterization bulunmadığını tespit ederse SQL Injection uyarısı oluşturabilir.

Ancak kod şu şekilde uygulanmışsa:

SELECT * FROM users WHERE username = ?

ve kullanıcı girdisi parameterized query üzerinden aktarılıyorsa risk önemli ölçüde azalır.

Gelişmiş SAST sistemleri bu ayrımı yapmaya çalışır.

### \13. SAST XSS Açığını Nasıl Tespit Eder?

Cross-Site Scripting analizinde kullanıcı girdisinin web çıktısına nasıl aktarıldığı önemlidir.

Örneğin kullanıcıdan gelen name parametresi doğrudan HTML içerisine ekleniyorsa sistem potansiyel XSS riski oluşturabilir.

Veri akışı şu şekilde olabilir:

**HTTP Parameter → Application Variable → HTML Response**

Burada güvenli output encoding uygulanmamışsa SAST sistemi güvenlik problemi tespit edebilir.

Ancak XSS analizinin karmaşık olmasının nedeni farklı output context'lerinin bulunmasıdır.

Bir veri;

HTML body içerisinde,

HTML attribute içerisinde,

JavaScript içerisinde,

CSS içerisinde,

URL içerisinde

kullanılabilir.

Bu nedenle modern SAST sistemlerinin context-aware analiz yapabilmesi önemlidir.

### \14. SAST Command Injection'ı Nasıl Bulur?

Command Injection, kullanıcı kontrollü verilerin işletim sistemi komutlarında kullanılması sonucunda ortaya çıkabilir.

Örneğin uygulama kullanıcıdan IP adresi alıyor ve ping komutu çalıştırıyor olabilir.

Mantık şu şekilde olabilir:

ping + userInput

Eğer kullanıcı girdisi doğrudan işletim sistemi komutuna ekleniyorsa saldırgan komut yapısını manipüle etmeye çalışabilir.

SAST sistemi;

kullanıcı girdisini Source,

işletim sistemi komut fonksiyonunu Sink

olarak tanımlayabilir.

Arada uygun güvenlik kontrolü bulunmuyorsa Command Injection bulgusu oluşturulabilir.

Bu tür problemler genellikle kritik güvenlik riski olarak değerlendirilir.

### \15. SAST SSRF Tespit Edebilir mi?

Belirli durumlarda evet.

Server-Side Request Forgery yani SSRF, saldırganın sunucunun başka sistemlere istek göndermesini sağlaması sonucunda oluşur.

Örneğin uygulamada şöyle bir özellik bulunabilir:

**“Kullanıcı URL girsin ve sistem ilgili içeriği indirsin.”**

Kullanıcıdan gelen URL doğrudan backend tarafından çağrılıyorsa saldırgan;

- localhost,
- internal IP adresleri,
- cloud metadata servisleri,
- kurum içi servisler

gibi hedeflere erişmeye çalışabilir.

SAST sistemi kullanıcı girdisinin HTTP client fonksiyonuna ulaştığını belirleyerek potansiyel SSRF riski oluşturabilir.

Ancak gerçek istismar koşulları uygulamanın network yapısına bağlı olabileceği için bulgunun manuel olarak doğrulanması gerekebilir.

### \16. SAST Broken Access Control Bulabilir mi?

Bu soru oldukça önemlidir.

Cevap:

**Bazı durumlarda evet, ancak her zaman değil.**

Broken Access Control çoğunlukla uygulamanın iş mantığıyla ilgilidir.

Örneğin bir API endpoint'inde authentication kontrolünün tamamen unutulması SAST tarafından tespit edilebilir.

Ancak daha karmaşık senaryolarda problem yalnızca uygulamanın iş kuralını anlayarak görülebilir.

Örneğin:

Bir kullanıcının yalnızca kendi departmanındaki belgeleri görüntülemesi gerekiyor olabilir.

Kodda authorization kontrolü bulunabilir.

Ancak kontrol yanlış business rule üzerinden uygulanıyor olabilir.

SAST sistemi teknik olarak bir authorization kontrolünün bulunduğunu görür.

Fakat gerçek iş kuralının yanlış uygulandığını anlamayabilir.

Bu nedenle SAST, manuel kaynak kod analizinin veya pentestin tamamen yerine geçmez.

### \17. SAST Hard-Coded Credential Bulabilir mi?

Evet.

Birçok SAST ve Secret Scanning çözümü kaynak kod içerisindeki hassas bilgileri tespit etmeye çalışabilir.

Örneğin:

- password,
- API key,
- secret token,
- private key,
- cloud credential

gibi bilgiler belirli pattern'ler üzerinden analiz edilebilir.

Ancak Secret Scanning çoğu zaman SAST'tan ayrı bir güvenlik katmanı olarak değerlendirilir.

Çünkü secret detection sistemleri yalnızca mevcut kodu değil, repository geçmişini de analiz edebilir.

Bu oldukça önemlidir.

Bir geliştirici API key'i koddan silmiş olabilir.

Ancak key eski Git commit'inde bulunmaya devam ediyor olabilir.

### \18. Interprocedural Analysis Nedir?

Basit güvenlik analizinde veri aynı fonksiyon içerisinde takip edilebilir.

Ancak modern uygulamalarda veri genellikle birçok farklı fonksiyondan geçer.

Örneğin kullanıcı girdisi:

Controller içerisinde alınabilir.

Service katmanına gönderilebilir.

Utility fonksiyonundan geçebilir.

Repository katmanında SQL sorgusuna aktarılabilir.

Dolayısıyla veri akışı şu şekilde olabilir:

**Controller → Service → Helper → Repository → Database**

SAST sisteminin güvenlik problemini tespit edebilmesi için fonksiyonlar arasında veri akışını takip etmesi gerekir.

Bu yöntem **Interprocedural Analysis** olarak adlandırılır.

Gelişmiş SAST motorlarının başarısı büyük ölçüde bu tür karmaşık veri akışlarını ne kadar doğru analiz edebildiğine bağlıdır.

### \19. Cross-File Analysis Nedir?

Modern uygulamalar tek bir dosyadan oluşmaz.

Binlerce kaynak kod dosyası olabilir.

Bir değişken bir dosyada oluşturulabilir.

Başka bir dosyada işlenebilir.

Üçüncü bir dosyada kritik fonksiyona aktarılabilir.

Bu nedenle SAST sistemlerinin yalnızca tek dosyayı bağımsız şekilde incelemesi yeterli değildir.

**Cross-File Analysis**, güvenlik motorunun birden fazla kaynak kod dosyası arasındaki ilişkileri analiz etmesini sağlar.

Bu özellik özellikle enterprise uygulamalarda önemlidir.

### \20. SAST Hangi Aşamada Çalıştırılmalıdır?

SAST'ın en önemli avantajlarından biri yazılım geliştirme sürecinin birçok farklı noktasında çalıştırılabilmesidir.

Örneğin:

#### IDE Seviyesi

Geliştirici kod yazarken güvenlik uyarısı alabilir.

Bu en erken geri bildirim noktalarından biridir.

#### Commit Seviyesi

Repository'ye kod gönderilirken analiz yapılabilir.

#### Merge Request / Pull Request

Kod ana branch'e alınmadan önce güvenlik kontrolü gerçekleştirilebilir.

#### Build Aşaması

CI/CD pipeline içerisinde otomatik SAST çalıştırılabilir.

#### Release Öncesi

Daha kapsamlı güvenlik analizi uygulanabilir.

Modern DevSecOps yaklaşımında mümkün olduğunca hızlı feedback tercih edilir.

Çünkü geliştirici ilgili kod üzerinde çalışmaya devam ederken verilen güvenlik uyarısının düzeltilmesi daha kolaydır.

### \21. CI/CD İçerisinde SAST Nasıl Kullanılır?

Modern yazılım geliştirme ortamlarında SAST çoğunlukla CI/CD pipeline içerisinde otomatikleştirilir.

Örneğin süreç şu şekilde olabilir:

#### Developer Commit

↓

#### Secret Scanning

↓

#### SAST

↓

#### SCA

↓

#### Unit Test

↓

#### Build

↓

#### Security Quality Gate

↓

#### Deployment

SAST analizi sırasında kritik güvenlik problemi bulunursa pipeline durdurulabilir.

Böylece güvenli olmayan kod production ortamına ulaşmadan engellenmiş olur.

Bu yaklaşım DevSecOps'un temel prensiplerinden biridir.

Ancak burada Quality Gate politikasının doğru tasarlanması gerekir.

Her düşük seviye uyarı nedeniyle pipeline'ın durması geliştirme ekiplerinin güvenlik kontrollerini devre dışı bırakmak istemesine neden olabilir.

Bu nedenle risk bazlı politikalar uygulanmalıdır.

### \22. Incremental Scan Nedir?

Büyük yazılım projelerinde bütün kaynak kodun her commit sonrasında tekrar analiz edilmesi uzun sürebilir.

Bu nedenle modern SAST sistemlerinde **Incremental Scan** yaklaşımı kullanılabilir.

Incremental Scan yalnızca değişen kod bölümlerini veya değişiklikten etkilenen alanları analiz etmeye çalışır.

Bu yaklaşım geliştiriciye daha hızlı geri bildirim verir.

Örneğin milyonlarca satır kod içeren bir projede full scan uzun sürebilir.

Ancak geliştirici yalnızca 50 satır kod değiştirmişse hızlı incremental scan gerçekleştirilebilir.

Daha kapsamlı full scan ise gece veya belirli zamanlarda çalıştırılabilir.

Bu model performans ve güvenlik arasında daha dengeli bir yaklaşım sağlar.

### \23. False Positive Nedir?

SAST teknolojilerinde en önemli konulardan biri **False Positive** problemidir.

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

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

Ancak arada framework tarafından otomatik parameterization uygulanıyor olabilir.

Sistem bunu doğru anlayamazsa SQL Injection bulgusu oluşturabilir.

Ancak gerçek güvenlik açığı bulunmayabilir.

Bu durum False Positive olarak değerlendirilir.

Çok fazla False Positive üreten SAST sistemleri geliştiriciler açısından ciddi sorun oluşturabilir.

Çünkü yüzlerce yanlış alarm arasında gerçek kritik güvenlik açıklarını bulmak zorlaşır.

### \24. False Negative Nedir?

False Negative daha tehlikeli bir durumdur.

Sistem gerçek güvenlik açığını tespit edemez.

Örneğin uygulamada ciddi bir authorization problemi bulunabilir.

Ancak SAST motoru bu güvenlik açığını görmeyebilir.

Bu durumda araç raporunda herhangi bir problem görünmez.

Fakat uygulama gerçekte güvensizdir.

Bu nedenle hiçbir SAST çözümü şu şekilde değerlendirilmemelidir:

**“Araç temiz rapor verdi, uygulama tamamen güvenlidir.”**

SAST önemli bir güvenlik katmanıdır.

Ancak bütün Application Security programının kendisi değildir.

### \25. Neden Manuel Doğrulama Gereklidir?

Otomatik SAST araçları büyük kod tabanlarını çok hızlı şekilde analiz edebilir.

Bu önemli bir avantajdır.

Ancak aracın tespit ettiği bulguların bağlam içerisinde değerlendirilmesi gerekir.

Güvenlik uzmanı örneğin şu soruları sorabilir:

- Veri gerçekten kullanıcı tarafından kontrol edilebiliyor mu?
- Fonksiyon dışarıdan erişilebilir mi?
- Arada güvenlik kontrolü bulunuyor mu?
- Bulgu gerçek ortamda istismar edilebilir mi?
- Yetkilendirme farklı bir katmanda uygulanıyor mu?
- Güvenlik açığının gerçek iş etkisi nedir?

Bu nedenle profesyonel kaynak kod güvenlik analizinde:

**SAST çıktısı = Nihai güvenlik raporu**

olarak değerlendirilmemelidir.

Doğru model:

**SAST → Triaging → Manuel Doğrulama → Risk Değerlendirmesi → Remediation**

şeklinde olmalıdır.

### \26. SAST Bulguları Nasıl Önceliklendirilmelidir?

Bir SAST taraması yüzlerce hatta binlerce bulgu üretebilir.

Hepsinin aynı anda düzeltilmesi gerçekçi değildir.

Bu nedenle bulgular risk bazlı önceliklendirilmelidir.

Örneğin aşağıdaki faktörler değerlendirilebilir:

#### Severity

Bulgunun teknik önem seviyesi.

#### Exploitability

Güvenlik açığının istismar edilme kolaylığı.

#### Reachability

İlgili kod gerçekten erişilebilir mi?

#### Data Sensitivity

Bulgu hassas verilere erişim sağlıyor mu?

#### Internet Exposure

Uygulama internet üzerinden erişilebilir mi?

#### Business Criticality

Uygulama kurum açısından ne kadar kritik?

Bu kriterler birlikte kullanıldığında güvenlik ekipleri gerçek risklere öncelik verebilir.

### \27. Reachability Analysis Nedir?

Modern Application Security sistemlerinde giderek önem kazanan kavramlardan biri **Reachability Analysis** yaklaşımıdır.

Örneğin kod içerisinde riskli bir fonksiyon bulunabilir.

Ancak ilgili fonksiyon hiçbir zaman kullanıcı tarafından erişilebilir olmayabilir.

Bu durumda teorik güvenlik riski gerçek saldırı yüzeyinde bulunmayabilir.

Reachability Analysis şu soruyu cevaplamaya çalışır:

#### Bu güvenlik açığına saldırgan gerçekten ulaşabilir mi?

Bu yaklaşım özellikle False Positive sayısını azaltmada önemlidir.

### \28. SAST Raporunda Neler Olmalıdır?

Profesyonel SAST raporu yalnızca araç çıktılarının export edilmiş hali olmamalıdır.

Her güvenlik bulgusu geliştirici açısından anlaşılabilir olmalıdır.

İdeal bir bulgu aşağıdaki bilgileri içerebilir:

- Bulgu adı
- Severity
- Etkilenen dosya
- Etkilenen kod satırı
- Source noktası
- Sink noktası
- Veri akışı
- CWE kategorisi
- OWASP ilişkisi
- Risk açıklaması
- İstismar senaryosu
- Remediation önerisi
- Güvenli kod örneği
- Doğrulama durumu

Bu yapı geliştiricinin sorunu daha hızlı anlamasını sağlar.

### \29. SAST ve CWE İlişkisi

SAST bulgularının ortak bir güvenlik dili içerisinde sınıflandırılması önemlidir.

Bu nedenle bulgular çoğunlukla **CWE – Common Weakness Enumeration** kategorileriyle eşleştirilir.

Örneğin:

SQL Injection,

Cross-Site Scripting,

Command Injection,

Path Traversal,

Improper Authorization

gibi zayıflıkların CWE karşılıkları bulunur.

Bu eşleştirme kurumların uzun vadeli güvenlik metrikleri oluşturmasını kolaylaştırır.

Örneğin bir kurum yıl sonunda şu analizi yapabilir:

**“En fazla hangi CWE kategorisiyle karşılaşıyoruz?”**

Eğer aynı güvenlik hataları tekrar tekrar görülüyorsa geliştirici eğitimleri ve Secure Coding standartları bu alana göre güncellenebilir.

### \30. SAST ve OWASP İlişkisi

OWASP Top 10 uygulama güvenliğinin en bilinen risk sınıflandırmalarından biridir.

SAST araçları tarafından tespit edilen birçok güvenlik problemi OWASP kategorileriyle ilişkilendirilebilir.

Ancak SAST kapsamını yalnızca OWASP Top 10 ile sınırlandırmak doğru değildir.

Kaynak kod içerisinde yüzlerce farklı güvenlik zayıflığı bulunabilir.

Bu nedenle kapsamlı Application Security programlarında:

**CWE + OWASP + Secure Coding Standard + Kurumsal Risk Modeli**

birlikte değerlendirilebilir.

### \31. SAST Hangi Programlama Dillerini Destekler?

Desteklenen diller kullanılan SAST çözümüne göre değişir.

Modern SAST ürünleri genellikle birçok programlama dili ve framework'ü destekleyebilir.

Örneğin:

- Java
- C#
- JavaScript
- TypeScript
- Python
- PHP
- C
- C++
- Go
- Kotlin
- Swift
- Ruby

gibi teknolojiler desteklenebilir.

Ancak yalnızca programlama dilinin desteklenmesi yeterli değildir.

Framework bilgisi de önemlidir.

Örneğin Java için:

Spring,

Spring Boot,

Jakarta EE

gibi framework yapılarının doğru analiz edilmesi gerekir.

Benzer durum .NET, PHP, JavaScript ve diğer ekosistemler için de geçerlidir.

### \32. SAST Araç Seçiminde Nelere Dikkat Edilmelidir?

SAST ürünü seçilirken yalnızca kaç programlama dili desteklediğine bakılmamalıdır.

Değerlendirilmesi gereken başlıca kriterler şunlardır:

- Programlama dili desteği
- Framework desteği
- False Positive oranı
- Scan performansı
- CI/CD entegrasyonu
- IDE entegrasyonu
- Git platformu entegrasyonu
- Incremental Scan desteği
- API desteği
- Reporting özellikleri
- CWE ve OWASP mapping
- Custom rule yazabilme
- On-premise veya cloud deployment seçenekleri
- Veri gizliliği gereksinimleri

Özellikle kritik veya regüle sektörlerde kaynak kodun kurum dışına çıkıp çıkmadığı da değerlendirilmelidir.

### \33. SAST Kaynak Kodu Dışarı Gönderir mi?

Bu durum kullanılan ürüne ve deployment modeline bağlıdır.

Cloud tabanlı bazı çözümlerde kaynak kod analiz amacıyla sağlayıcının altyapısına gönderilebilir.

On-premise çözümlerde ise analiz tamamen kurumun kendi ortamında gerçekleştirilebilir.

Kritik kaynak kodlar, savunma sanayi projeleri, finans uygulamaları veya fikri mülkiyet açısından hassas yazılımlar için bu konu özellikle önemlidir.

Bu nedenle SAST çözümü seçilirken şu sorular mutlaka değerlendirilmelidir:

#### Kaynak kod nerede analiz ediliyor?

#### Kod saklanıyor mu?

#### Hangi veriler sağlayıcıya gönderiliyor?

#### Veri hangi ülkede tutuluyor?

Bu sorular yalnızca teknik değil, GRC ve veri güvenliği açısından da önemlidir.

### \34. SAST Geliştiricinin İşini Yavaşlatır mı?

Yanlış yapılandırılırsa evet.

Doğru yapılandırılırsa tam tersine güvenlik sorunlarının daha hızlı çözülmesini sağlayabilir.

Örneğin her commit sonrasında 45 dakika süren tarama çalıştırılırsa geliştirici deneyimi ciddi şekilde bozulabilir.

Bunun yerine:

IDE seviyesinde hızlı kontrol,

Pull Request aşamasında Incremental Scan,

gece Full Scan

gibi farklı analiz seviyeleri kullanılabilir.

Aynı şekilde her Low severity bulgu nedeniyle pipeline durdurulmamalıdır.

Quality Gate yalnızca gerçek risk oluşturan güvenlik problemlerine göre yapılandırılmalıdır.

DevSecOps yaklaşımında güvenliğin amacı geliştirmeyi durdurmak değil;

**geliştirmenin güvenli şekilde hızlanmasını sağlamaktır.**

### \35. SAST Tek Başına Yeterli midir?

Hayır.

SAST güçlü bir güvenlik kontrolüdür ancak yalnızca kaynak kod perspektifinden görünürlük sağlar.

Modern Application Security programında farklı test yöntemleri birlikte kullanılmalıdır.

Örneğin:

**SAST** → Kaynak kodu analiz eder.

**SCA** → Üçüncü taraf kütüphaneleri analiz eder.

**Secret Scanning** → Hassas bilgileri tespit eder.

**DAST** → Çalışan uygulamayı dışarıdan analiz eder.

**API Security Testing** → API saldırı yüzeyini değerlendirir.

**Pentest** → Gerçek saldırgan davranışını simüle eder.

**Manuel Code Review** → İş mantığı ve karmaşık kod problemlerini inceler.

Bu kontroller birlikte kullanıldığında çok daha güçlü bir güvenlik görünürlüğü elde edilir.

### \36. SAST'ın Asıl Değeri Nerede Ortaya Çıkar?

SAST'ın gerçek değeri tek seferlik bir güvenlik taramasında değil, yazılım geliştirme sürecine entegre edildiğinde ortaya çıkar.

Bir kurum yılda bir kez kaynak kod taraması yapabilir.

Bu faydalıdır.

Ancak geliştirici her yeni kod gönderdiğinde SAST otomatik çalışıyorsa güvenlik çok daha erken aşamada devreye girmiş olur.

İdeal modelde geliştirici güvenlik hatasını aylar sonra pentest raporunda değil;

**kodu yazdığı gün öğrenir.**

Bu durum güvenli yazılım geliştirme kültürünün oluşması açısından büyük önem taşır.

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

SecureSys olarak SAST'ı yalnızca otomatik bir güvenlik tarama aracı olarak değerlendirmiyoruz.

Kaynak kod güvenliğinde temel hedefimiz aracın ürettiği mümkün olan en yüksek sayıda bulguyu raporlamak değil;

**gerçek güvenlik risklerini doğru şekilde ortaya çıkarmaktır.**

Bu nedenle proje kapsamına göre;

#### SAST, manuel kaynak kod analizi, SCA, Secret Scanning, API güvenlik testleri, DAST ve sızma testi

yaklaşımları birlikte değerlendirilebilir.

SAST bulgularının;

- Source-Sink ilişkileri,
- veri akışları,
- CWE kategorileri,
- gerçek erişilebilirlik,
- istismar edilebilirlik,
- uygulamanın iş kritikliği

açısından değerlendirilmesi önemlidir.

Aynı zamanda güvenlik bulgularının geliştirici ekiplerine uygulanabilir remediation önerileriyle aktarılması gerekir.

Çünkü iyi bir Application Security süreci yalnızca güvenlik açığını göstermez.

**Geliştiriciye o açığın neden oluştuğunu ve bir daha nasıl oluşmayacağını da anlatır.**

### Sık Sorulan Sorular

#### SAST nedir?

SAST, Static Application Security Testing ifadesinin kısaltmasıdır. Uygulama çalıştırılmadan kaynak kod veya ilgili yazılım bileşenlerinin güvenlik açısından analiz edilmesini sağlar.

#### SAST nasıl çalışır?

SAST araçları kaynak kod içerisindeki fonksiyonları, değişkenleri, kontrol akışlarını ve veri akışlarını analiz eder. Kullanıcı kontrollü bir verinin güvenlik açısından kritik fonksiyonlara ulaşıp ulaşmadığını belirlemeye çalışır.

#### Source ve Sink nedir?

Source, kullanıcı veya dış sistem tarafından kontrol edilebilen verinin uygulamaya giriş yaptığı noktadır. Sink ise bu verinin ulaştığı SQL sorgusu, işletim sistemi komutu veya HTML çıktısı gibi güvenlik açısından kritik fonksiyonlardır.

#### Taint Analysis nedir?

Taint Analysis, güvenilmeyen verinin uygulama içerisinde nasıl hareket ettiğini takip eden statik analiz yöntemidir.

#### SAST SQL Injection bulabilir mi?

Evet. Kullanıcı kontrollü verinin güvenli olmayan şekilde SQL sorgularına aktarıldığı veri akışlarını tespit ederek potansiyel SQL Injection bulguları oluşturabilir.

#### SAST tüm güvenlik açıklarını bulabilir mi?

Hayır. Business Logic, karmaşık authorization problemleri ve runtime ortamına özgü bazı güvenlik açıkları SAST tarafından tespit edilemeyebilir.

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

SAST kaynak kodu statik olarak analiz eder. Pentest ise çalışan uygulamayı gerçek saldırgan perspektifinden test eder. Birbirlerinin alternatifi değil tamamlayıcısıdır.

#### SAST CI/CD pipeline'a entegre edilebilir mi?

Evet. SAST commit, Pull Request, build ve release süreçlerinde otomatik çalıştırılabilir.

#### False Positive nedir?

SAST sisteminin 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 analiz sistemi tarafından tespit edilememesidir.

### Sonuç: SAST Kod ile Güvenlik Arasındaki İlk Otomatik Kontrol Noktasıdır

Modern yazılım ekiplerinin her gün ürettiği kod miktarı düşünüldüğünde bütün güvenlik analizlerinin manuel gerçekleştirilmesi mümkün değildir.

Güvenlik de yazılım geliştirme hızıyla aynı tempoda ilerlemek zorundadır.

SAST bu ihtiyaca cevap veren en önemli Application Security teknolojilerinden biridir.

Kaynak kodu uygulama çalıştırılmadan analiz eder.

Verinin nereden geldiğini ve nereye ulaştığını anlamaya çalışır.

Source, Sink ve Sanitizer ilişkilerini değerlendirir.

Control Flow ve Data Flow analizleri gerçekleştirir.

Potansiyel güvenlik problemlerini geliştiriciye production ortamından çok daha önce gösterebilir.

Ancak burada unutulmaması gereken kritik nokta şudur:

**SAST bir güvenlik programının tamamı değildir.**

SAST'ın gerçek değeri;

Secure Coding,

SCA,

Secret Scanning,

manuel kaynak kod analizi,

DAST,

Pentest

ve DevSecOps süreçleriyle birlikte kullanıldığında ortaya çıkar.

Çünkü güvenli yazılım geliştirme tek bir araçla değil;

**birbirini tamamlayan güvenlik katmanlarıyla sağlanır.**