SAST Nedir, Hangi Açıkları Bulur, Hangilerini Kaçırır?

Bir CI/CD pipeline’ında SAST sonucunun yeşil olması rahatlatıcıdır. Fakat bu sonuç çoğu zaman yanlış yorumlanır. “Kod tarandı ve kritik bulgu çıkmadı” cümlesi, uygulamanın güvenli olduğunu değil, ilgili aracın etkin rule set’i ve analiz edebildiği kod yolları içinde kritik bir pattern tespit etmediğini gösterir. Aradaki fark küçümsendiğinde SAST bir güvenlik kontrolü olmaktan çıkıp yanlış güven üreten bir onay kutusuna dönüşebilir.

Peki SAST nedir? SAST, Static Application Security Testing ifadesinin kısaltmasıdır. Uygulama çalıştırılmadan source code, bytecode veya bazı araçlarda binary üzerinde analiz yapar. Amaç, güvenlik açığına dönüşebilecek weakness pattern’leri ve riskli data flow’ları geliştirme sürecinin mümkün olduğunca erken aşamasında bulmaktır.

SAST özellikle user-controlled input’un SQL query, operating system command, file path veya HTML output gibi riskli bir sink’e güvenli işlemden geçmeden ulaştığı durumlarda etkilidir. Buna karşılık bir kullanıcının başka bir müşteriye ait kaydı görüp göremeyeceği, indirim kuponunun art arda sınırsız kullanılabilmesi veya iki ayrı düşük yetkili fonksiyonun birlikte kritik bir işlemi tamamlaması gibi context gerektiren riskleri çoğu zaman anlayamaz.

SAST nedir?

SAST, uygulamanın çalışan hâline saldırmak yerine kodun kendisini inceler. Bu yüzden white-box security testing yaklaşımının bir parçası olarak değerlendirilir. Analiz için aracın türüne göre source repository, build artifact, bytecode, intermediate representation veya binary kullanılabilir.

Basit bir linter yalnızca belirli syntax ve pattern hatalarını ararken gelişmiş bir SAST engine fonksiyonlar arası veri hareketini, call graph’i, branching yapılarını ve güvenlik açısından kritik API kullanımını modelleyebilir. User input’un nereden alındığını, hangi metotlardan geçtiğini, validation veya sanitization uygulanıp uygulanmadığını ve sonunda hangi hassas işleme ulaştığını takip etmeye çalışır.

SAST’ın en önemli avantajı uygulamanın production’a çıkmasını beklememesidir. Developer kodu yazarken IDE üzerinde, pull request açıldığında veya build sırasında analiz çalıştırılabilir. Böylece sorun henüz ilgili kod değişikliği küçükken ve developer’ın zihnindeki context tazeyken ele alınır.

Ancak “static” kelimesi önemli bir sınırı da anlatır. SAST, çalışan sistemin gerçek configuration değerlerini, kullanıcı davranışını, WAF etkisini, cloud IAM ilişkilerini veya bir saldırganın uygulama üzerindeki adım adım etkileşimini doğal olarak gözlemlemez. Koddan çıkarım yapar. Çıkarımın doğruluğu ise aracın analiz gücüne, framework bilgisinin kalitesine, tarama kapsamına ve uygulamanın nasıl yazıldığına bağlıdır.

SAST nasıl çalışır?

Her SAST ürünü aynı engine’i kullanmaz. Bazıları ağırlıklı olarak pattern matching yaparken bazıları interprocedural ve context-sensitive data flow analysis uygular. Modern araçlarda farklı teknikler birlikte kullanılabilir.

Lexical analysis ve parsing

Araç önce source code’u token’lara ayırır ve kullanılan programming language’in syntax yapısını anlamaya çalışır. Değişkenler, fonksiyonlar, class’lar, method call’lar ve expression’lar ayrıştırılır. Bu aşama, metin içinde kelime aramaktan çok daha anlamlı bir code model oluşturur.

Abstract Syntax Tree

Kod çoğu araçta Abstract Syntax Tree, yani AST biçiminde temsil edilir. AST, bir satırın yalnızca nasıl yazıldığını değil programlama dili açısından ne anlama geldiğini gösterir. Bu sayede araç farklı yazım biçimlerine rağmen aynı riskli işlemi tanıyabilir.

Control Flow Analysis

Control Flow Analysis, uygulamanın olası çalışma yollarını modellemeye çalışır. Bir if koşulu, exception, loop veya early return sonrasında hangi code block’un çalışabileceği incelenir. Bu analiz, riskli bir satırın gerçekten reachable olup olmadığını değerlendirmeye yardımcı olur.

Data Flow Analysis

Data Flow Analysis, verinin değişkenler, fonksiyonlar ve objeler arasında nasıl taşındığını izler. Örneğin HTTP request’ten gelen bir parametre önce service katmanına, oradan repository fonksiyonuna ve son olarak SQL query’ye aktarılıyorsa aracın bu yolu görebilmesi gerekir.

Taint Analysis

Taint Analysis, SAST’ın en bilinen tekniklerinden biridir. Dışarıdan kontrol edilebilen veri bir source olarak işaretlenir. SQL execution, command execution, file access veya HTML rendering gibi güvenlik açısından hassas fonksiyonlar sink olarak tanımlanır. Veri source’tan sink’e güvenilir bir sanitization adımı olmadan ulaşıyorsa potansiyel zafiyet raporlanır.

Basitleştirilmiş bir akış şu şekildedir:

HTTP request parameter → application variable → service method → SQL query

Arada doğru parameterization yoksa SAST SQL injection ihtimali bildirebilir. Fakat uygulamanın kullandığı custom validation wrapper araca tanıtılmamışsa güvenli bir akışı da riskli sanabilir. Tersi durumda, güvenli zannedilen fakat etkisiz bir sanitizer yanlış biçimde trusted kabul edilirse gerçek zafiyet kaçırılabilir.

Interprocedural analysis ve call graph

Gerçek uygulamalarda source ve sink çoğu zaman aynı fonksiyon içinde değildir. Veri farklı class’lardan, module’lerden ve servis katmanlarından geçer. Interprocedural analysis bu fonksiyonlar arası yolu izlemeye çalışır. Call graph ise hangi fonksiyonun hangi fonksiyonu çağırabileceğini gösterir.

Analiz derinliği arttıkça doğruluk potansiyeli yükselir, fakat scan süresi ve kaynak ihtiyacı da artar. Büyük monorepo’larda, yoğun reflection kullanan uygulamalarda veya çok sayıda dynamic call bulunan yapılarda bütün olası yolları kesin biçimde hesaplamak pratik olarak zorlaşır.

Rule-based ve semantic analysis

SAST araçları yalnızca data flow izlemez. Güvensiz API kullanımları, zayıf cryptographic algorithm, hardcoded credential, debug özelliği, hatalı random number generation veya tehlikeli deserialization fonksiyonları rule set üzerinden de aranabilir. Bazı araçlar framework ve library davranışını semantic model’lerle yorumlar.

Bu nedenle iki farklı SAST aracının aynı repository üzerinde farklı sonuç üretmesi normaldir. Rule coverage, framework modelling, analysis depth ve default configuration değerleri aynı değildir.

SAST hangi açıkları bulur?

SAST’ın başarısı programming language, framework, kullanılan araç ve kodun yapısına göre değişir. Aşağıdaki kategoriler SAST’ın genellikle güçlü veya en azından faydalı sinyal üretebildiği alanlardır.

1. SQL injection ve diğer injection türleri

User-controlled input’un query içine string concatenation ile eklendiği akışlar SAST için uygun hedeflerdir. Araç source ile database execution sink’i arasındaki veri yolunu görebiliyorsa SQL injection riskini production’a çıkmadan bulabilir.

Benzer yaklaşım aşağıdaki injection sınıflarında da kullanılabilir:

• OS command injection
• Code injection
• LDAP injection
• XPath injection
• Expression Language injection
• Template injection
• NoSQL injection

Burada “SAST injection bulur” ifadesi koşulsuz değildir. Query farklı servislerde oluşturuluyorsa, dynamic string yoğun biçimde parçalanıyorsa, stored procedure içinde devam ediyorsa veya custom database wrapper araca tanıtılmamışsa veri yolu kaybolabilir.

2. Cross-Site Scripting

Reflected XSS için request parametresinden HTML response’a giden doğrudan data flow çoğu gelişmiş araç tarafından tespit edilebilir. Output encoding uygulanmayan template kullanımları veya riskli DOM sink’leri de rule coverage içinde olabilir.

Stored XSS daha zordur. Veri bir request sırasında database’e yazılıp günler sonra başka bir endpoint üzerinden okunarak farklı template içinde gösteriliyorsa source ve sink aynı scan context’inde ilişkilendirilemeyebilir. DOM-based XSS tarafında ise client-side framework, bundler, runtime DOM değişiklikleri ve dynamic JavaScript kullanımı doğruluğu etkiler.

3. Path traversal ve güvensiz file operation

Kullanıcı girdisinin dosya adı veya dizin yolu olarak kullanılması, yeterli canonicalization yapılmaması ve kontrolsüz file read veya file write işlemleri SAST tarafından yakalanabilir. File upload sonrasında path’in nasıl oluşturulduğu da analiz edilebilir.

Ancak gerçek filesystem permission’ları, container mount yapısı, symbolic link davranışı ve production path configuration değerleri kod dışında kaldığında etkinin tamamı anlaşılamayabilir.

4. Server-Side Request Forgery

URL, hostname veya network destination bilgisinin kullanıcıdan alınarak HTTP client, URL fetcher veya socket fonksiyonuna gönderildiği akışlar SSRF adayı olarak işaretlenebilir. SAST özellikle doğrudan data flow varsa değerlidir.

Gerçek exploitability ise runtime network erişimine bağlıdır. Uygulamanın metadata endpoint’e, internal service’lere veya internet üzerindeki adreslere erişip erişemediğini source code tek başına her zaman göstermez. Allowlist’in başka bir policy katmanında uygulanması da sonucu değiştirebilir.

5. Güvensiz deserialization

Untrusted data’nın riskli deserialization API’lerine gönderilmesi, tür kısıtlamasının olmaması veya tehlikeli configuration kullanılması SAST rule’larıyla tespit edilebilir. Araç ilgili framework’ün serializer davranışını biliyorsa daha doğru sonuç verir.

Gadget chain’in gerçekten classpath içinde bulunması, library version’ı ve runtime configuration ise ayrı doğrulama gerektirebilir. Bu noktada SAST ile SCA ve manuel analiz birlikte düşünülmelidir.

6. XXE ve güvensiz parser configuration

XML parser üzerinde external entity kullanımının kapatılmaması, güvenli factory option’larının uygulanmaması veya doğrudan untrusted XML işlenmesi rule-based olarak bulunabilir. Benzer şekilde YAML, archive, image veya document parser kullanımlarındaki bilinen riskli API pattern’leri raporlanabilir.

7. Zayıf cryptography ve random number kullanımı

Deprecated hashing algorithm, hardcoded encryption key, static IV, güvensiz cipher mode, tahmin edilebilir random generator ve certificate validation bypass gibi code-level problemler SAST’ın güçlü olabileceği alanlardır.

Yine de cryptography konusunda yalnızca algorithm adına bakmak yeterli değildir. Key lifecycle, rotation, secret storage, protocol tasarımı ve business requirement gibi konular manuel inceleme gerektirir. Güçlü bir algorithm yanlış protocol içinde kullanıldığında SAST bunu anlamayabilir.

8. Hardcoded secret ve hassas veri kullanımı

API key, password, private key, token veya connection string’in source code içinde yer alması birçok SAST platformu ya da entegre secrets scanner tarafından tespit edilebilir. Burada önemli bir ayrım vardır. Secrets scanning her zaman SAST’ın doğal parçası değildir. Bazı platformlar iki capability’yi tek ürün altında sunar.

Bulunan değerin gerçek ve aktif olup olmadığı ayrı bir sorudur. Buna karşılık “test credential” etiketi taşıyan bir secret’ın production’da kullanılması da mümkündür. Bu nedenle secret finding’leri yalnızca dosya adına göre otomatik kapatılmamalıdır.

9. Güvensiz API ve security control kullanımları

SAST aşağıdaki code pattern’lerinde faydalı olabilir:

• TLS certificate validation’ın devre dışı bırakılması
• Güvenli olmayan redirect kullanımı
• Cookie üzerinde Secure, HttpOnly veya uygun SameSite seçeneklerinin eksikliği
• Debug veya verbose error davranışının kod içinde açılması
• Hassas verinin log’a yazılması
• Geçici dosyaların güvensiz oluşturulması
• Güvensiz process execution fonksiyonları
• Riskli regular expression ve potansiyel ReDoS pattern’leri
• Exception mesajlarında gereksiz teknik detay döndürülmesi

Bu bulguların bazıları doğrudan zafiyet, bazıları ise security hotspot niteliğindedir. İnsan incelemesi olmadan ikisini aynı severity ile raporlamak gereksiz gürültü üretir.

10. Memory safety problemleri

C ve C++ gibi memory-safe olmayan dillerde gelişmiş static analyzer’lar buffer overflow, out-of-bounds access, integer overflow, null pointer dereference, double free, use-after-free ve uninitialized memory use gibi problemlere ilişkin bulgular üretebilir.

Bu analizler basit web application rule’larından farklı teknikler kullanabilir. Pointer aliasing, concurrency, compiler davranışı ve platform özellikleri sonuçları etkiler. Dolayısıyla “C/C++ destekliyor” ifadesi aracın bütün memory corruption sınıflarında aynı derinliğe sahip olduğu anlamına gelmez.

SAST’ın güçlü olduğu alanlar nasıl özetlenebilir?

Bu tablo “bulur” ve “bulamaz” arasında kesin bir sınır çizmez. Aynı CWE için bir araç güçlü sinyal üretirken başka bir araç hiç sonuç vermeyebilir. Custom rule, framework support ve application architecture sonucu önemli ölçüde değiştirir.

SAST hangi açıkları kaçırır?

SAST’ın asıl sınırı syntax değil context’tir. Bir güvenlik problemi kod içinde bulunabilir fakat aracın zafiyeti anlayabilmesi için gereken iş anlamı ve runtime state koddan otomatik çıkarılamayabilir.

1. Business logic zafiyetleri

Bir e-ticaret uygulamasında aynı kuponun yalnızca bir kez kullanılması gerektiğini SAST kendiliğinden bilemez. İade tutarının satın alma tutarını geçmemesi, bir onay akışında aynı kişinin hem talep açıp hem onay verememesi veya belirli işlemlerin doğru sırayla yapılması gerektiği business requirement’tır.

Kod syntactically güvenli ve bütün input’lar validate edilmiş olabilir. Buna rağmen saldırgan işlemleri beklenmeyen sırada çağırarak maddi avantaj elde edebilir. Bu tür riskler business logic testing, threat modeling, manuel code review ve pentest ile değerlendirilir.

2. IDOR ve object-level authorization

SAST bir endpoint’in authentication annotation’ına sahip olduğunu görebilir. Fakat giriş yapmış kullanıcının URL’deki orderId değerine ait siparişi gerçekten görme yetkisi olup olmadığını anlamak çok daha zordur.

Authorization kararı farklı microservice’lerde, policy engine’de veya database katmanında veriliyorsa analiz daha da karmaşıklaşır. Horizontal privilege escalation ve tenant isolation problemleri çoğu zaman farklı kullanıcı hesaplarıyla çalışan sistem üzerinde test edilmelidir.

3. Authentication flow kusurları

Hardcoded password veya güvensiz hash kullanımı bulunabilir. Ancak account enumeration, MFA bypass, password reset token’ının yanlış bağlanması, SSO account linking hatası veya bir OAuth flow’daki business-level trust problemi runtime interaction gerektirir.

OWASP da authentication ve access control problemlerinin otomatik static analysis için zor alanlar olduğunu belirtir. Bunun nedeni güvenlik kararının çoğu zaman tek bir riskli fonksiyondan değil, birçok state ve rol ilişkisinden doğmasıdır.

4. Runtime configuration ve deployment problemleri

Source repository güvenli görünürken production ortamında aşağıdaki riskler bulunabilir:

• Public erişime açık cloud storage
• Hatalı security group veya firewall rule
• Gereksiz açık management interface
• Default credential ile çalışan servis
• Yanlış CORS veya reverse proxy configuration
• WAF bypass oluşturan routing farkı
• Kubernetes RBAC ve network policy hatası
• Production’da açık debug endpoint’i
• Eski TLS protocol veya zayıf cipher suite

Configuration dosyaları repository içindeyse bazı kontroller yapılabilir. Fakat bu, gerçek deployment state’inin aynı olduğunu kanıtlamaz. IaC scanning, cloud security assessment, configuration review ve active testing ayrı kontrol katmanlarıdır.

5. Vulnerable dependency ve supply chain riskleri

SAST first-party code içindeki weakness pattern’lere odaklanır. Kullanılan open-source package’in belirli version’ında bilinen bir CVE bulunması esas olarak Software Composition Analysis, yani SCA alanıdır. License riski, transitive dependency, package provenance ve SBOM yönetimi de SAST’tan farklıdır.

Bazı ürünler SAST ve SCA sonuçlarını aynı dashboard’da gösterir. Bu, iki yöntemin aynı olduğu anlamına gelmez. “SAST aracımız dependency tarıyor” ifadesinde hangi engine’in hangi veriyi ürettiği ayrıştırılmalıdır.

6. Gerçek exploitability ve security control etkisi

SAST potansiyel command injection raporlayabilir fakat ilgili fonksiyon hiçbir route’tan reachable olmayabilir. Tersi durumda riskli görünen veri, production’da güçlü bir allowlist’ten geçiyor olabilir. Araç koddan olasılık üretir. Zafiyetin gerçek saldırı yüzeyinde exploit edilip edilemediği DAST, IAST veya manuel pentest ile doğrulanır.

WAF, runtime protection, container permission, operating system hardening ve network segmentation gibi compensating control’ler de source code dışında olabilir. Bunlar root cause’u ortadan kaldırmasa bile gerçek etkiyi değiştirir.

7. Multi-step ve chained attack path’ler

Bir düşük riskli information disclosure bulgusunun başka bir endpoint’teki SSRF ile birleştirilmesi, elde edilen credential’ın cloud API üzerinde kullanılması ve sonrasında privilege escalation yapılması tek bir code path değildir. Farklı sistem, identity ve zaman adımlarından oluşur.

SAST bulguların bazı parçalarını ayrı ayrı gösterebilir. Fakat saldırı zincirinin tamamını kurması beklenmemelidir. Bu alan manuel sızma testi ve Red Team çalışmasının güçlü olduğu noktadır.

8. Race condition ve zamanlama problemleri

Bazı static analyzer’lar concurrency riskleri veya belirli data race pattern’leri için sonuç üretebilir. Ancak ödeme, stok, kupon, limit veya para transferi gibi business transaction’larda ortaya çıkan race condition’lar gerçek paralel request davranışı gerektirebilir. Database isolation level ve distributed lock yapısı da production context’ine bağlıdır.

9. Second-order data flow

Bir input bugün database’e güvenli biçimde kaydedilip daha sonra başka bir servis tarafından command, query veya HTML output içinde kullanılabilir. İlk yazma noktası ile sonraki sink farklı repository, programming language veya application sınırındaysa klasik SAST ilişkiyi kuramayabilir.

Microservice mimarisinde message queue, event bus, cache ve third-party API gibi sınırlar data flow analysis’i kesebilir. Her repository’nin ayrı taranması, sistem genelindeki trust boundary’leri otomatik olarak birleştirmez.

10. Dynamic language ve framework magic

Reflection, metaprogramming, runtime code generation, dependency injection, dynamic query builder ve framework tarafından üretilen route’lar static analysis’i zorlaştırır. Araç code path’i oluşturamazsa false negative üretebilir. Aşırı ihtiyatlı davranıp bütün olasılıkları riskli kabul ederse bu kez false positive sayısı artar.

SAST neden false positive üretir?

False positive, aracın güvenlik açığı olarak raporladığı fakat gerçek uygulama context’inde exploit edilemeyen veya doğru kontrolle korunan bulgudur. SAST’ın hiç false positive üretmemesi gerçekçi bir beklenti değildir. Önemli olan oranı yönetmek ve gerçek bulguların gürültü içinde kaybolmasını önlemektir.

Sık karşılaşılan nedenler şunlardır:

• Custom sanitizer veya validation fonksiyonunun araca tanıtılmaması
• Closed-source library içindeki kontrolün görülememesi
• Riskli fonksiyonun unreachable code içinde bulunması
• Test, sample veya migration code’un production kapsamı gibi taranması
• Framework’ün otomatik output encoding davranışının anlaşılmaması
• Environment-specific güvenlik kontrolünün source code dışında kalması
• Aynı root cause’un çok sayıda code location için ayrı bulgu üretilmesi
• Aracın yüksek recall için belirsiz bütün akışları raporlaması

False positive’leri tamamen bastırmak için rule’ları aşırı daraltmak da doğru değildir. Bu kez false negative oranı yükselir. İyi bir program precision ve recall arasında uygulamanın riskine uygun denge kurar.

SAST neden false negative üretir?

False negative, gerçek güvenlik açığının tarama sonucunda görünmemesidir. “Sıfır bulgu” raporunun neden güvenlik kanıtı olmadığını açıklayan asıl risk budur.

Başlıca nedenler şunlardır:

• Aracın ilgili programming language veya framework’ü yüzeysel desteklemesi
• İlgili weakness için rule bulunmaması
• Scan kapsamına kritik repository, branch veya generated code’un alınmaması
• Build’in tamamlanamaması ve analizin eksik model üzerinde çalışması
• Scan timeout veya memory limiti nedeniyle analysis depth’in düşmesi
• Source-to-sink akışının microservice ya da external component sınırında kesilmesi
• Reflection, dynamic code veya runtime binding nedeniyle call graph’in kurulamaması
• Custom wrapper, sanitizer veya sink’in yanlış modellenmesi
• Incremental scan’in etkilenmiş bütün code path’leri kapsamaması
• Runtime configuration veya gerçek deployment state’inin bilinmemesi

Bu nedenle SAST raporunda yalnızca bulgular değil, scan coverage, build durumu, atlanan dosyalar, kullanılan rule pack, tool version ve analysis warning’leri de incelenmelidir.

SAST ile DAST, SCA, manuel Code Review ve pentest farkı

Olgun bir Application Security programı bunlardan yalnızca birini seçmez. Kontrolleri SDLC içindeki doğru aşamalara yerleştirir ve sonuçları ortak risk context’i içinde değerlendirir.

SAST ne zaman çalıştırılmalı?

SAST’ın değeri yalnızca release öncesi toplu taramada değildir. Geri bildirim code change’e ne kadar yakınsa düzeltme o kadar kolay olur.

Developer kod yazarken

IDE integration, riskli API veya pattern kullanıldığında hızlı feedback sağlayabilir. Her rule’ın IDE üzerinde aktif olması gürültü yaratabilir. Bu katmanda kesinliği yüksek ve geliştiricinin doğrudan aksiyon alabileceği kontroller tercih edilmelidir.

Pull request aşamasında

Değişen kod için incremental veya differential scan çalıştırılabilir. Yeni kritik ve yüksek riskli finding’ler merge gate olarak kullanılabilir. Eski teknik borcun tamamını her pull request’te developer’ın önüne koymak, yeni risklerin gözden kaçmasına neden olur.

Main branch ve nightly build üzerinde

Deep interprocedural analysis daha uzun sürebileceği için nightly scan olarak planlanabilir. Böylece pull request üzerinde hızlı sonuç veren rule set ile repository genelinde daha derin analiz birbirinden ayrılır.

Major release öncesinde

Full scan sonucu manuel triage edilmeli, kritik code flow’lar ayrıca gözden geçirilmeli ve gerekli bulgular remediation sonrasında tekrar doğrulanmalıdır. Build warning’leri veya scan failure varsa rapor temiz kabul edilmemelidir.

Kritik zafiyet sonrasında

Pentest, bug bounty veya incident sırasında bulunan bir code-level root cause için benzer pattern’in bütün codebase içinde aranması gerekir. Custom SAST rule bu noktada tek bir bulguyu kurumsal ölçekte regression kontrolüne dönüştürebilir.

SAST CI/CD pipeline’a nasıl doğru entegre edilir?

SAST kurulumunda en sık yapılan hata bütün rule’ları ilk günden açıp binlerce mevcut bulgu nedeniyle build’i durdurmaktır. Ekip kısa sürede bypass arar, suppression sayısı yükselir ve araç güvenilirliğini kaybeder.

Daha sağlıklı bir uygulama modeli şu adımlardan oluşur:

1. Uygulama envanteri ve teknoloji kapsamını çıkarın

Hangi repository hangi programming language, framework ve build system’i kullanıyor? Generated code, test code, migration script ve third-party code nasıl ayrılacak? Araç seçimi gerçek teknoloji envanterine göre yapılmalıdır.

2. Temsil gücü yüksek pilot uygulamalar seçin

Yalnızca küçük ve temiz bir demo repository ile seçim yapmak yanıltıcıdır. Authentication, database access, messaging, API ve legacy code içeren gerçekçi uygulamalar üzerinde pilot yapılmalıdır.

3. Baseline oluşturun

Mevcut codebase’deki eski finding’ler kayıt altına alınabilir. Pipeline başlangıçta yalnızca yeni veya değiştirilen kodda oluşan kritik riskleri engeller. Baseline içindeki borç ise ayrı remediation planıyla azaltılır.

4. Rule set’i kuruma göre ayarlayın

Kullanılan custom framework, validation helper, authentication wrapper, source ve sink’ler tanımlanmalıdır. Kuruma özgü güvenli ve güvensiz pattern’ler custom rule hâline getirilebilir.

5. Finding sahipliğini belirleyin

Her bulgunun developer, security champion veya AppSec ekibi arasında nasıl ele alınacağı açık olmalıdır. “Security kuyruğuna düştü” durumu ownership değildir. Severity, SLA ve escalation modeli tanımlanmalıdır.

6. Suppression sürecini yönetin

Bir finding false positive veya accepted risk olarak kapatılıyorsa gerekçe, onaylayan kişi, tarih ve yeniden değerlendirme koşulu kaydedilmelidir. Süresiz ve açıklamasız suppression güvenlik açığını görünmez kılar.

7. Remediation sonrasında verification yapın

Finding’in kaybolması tek başına doğru düzeltme yapıldığını göstermeyebilir. Rule’ı susturacak yüzeysel değişiklik yerine root cause’un giderildiği code review ile kontrol edilmelidir. Kritik bulgularda test veya PoC doğrulaması da gerekebilir.

SAST aracı seçerken hangi sorular sorulmalı?

Desteklenen programming language sayısı tek başına yeterli seçim kriteri değildir. “Destekliyor” ifadesinin derinliği ürünler arasında ciddi ölçüde değişir.

Aşağıdaki sorular daha anlamlı sonuç verir:

• Kullandığımız framework ve library’ler için hazır semantic model bulunuyor mu?
• Interprocedural ve cross-file data flow analysis ne kadar derin?
• Buildable source code gerekiyor mu?
• Bytecode veya binary analysis destekleniyor mu?
• Custom source, sink ve sanitizer tanımlanabiliyor mu?
• Custom rule yazma ve kurum genelinde dağıtma imkânı var mı?
• Monorepo ve çoklu programming language yapısı nasıl ele alınıyor?
• Incremental scan ile full scan arasındaki coverage farkı nedir?
• Scan failure ve kısmi analiz görünür biçimde raporlanıyor mu?
• IDE, pull request ve CI/CD integration seçenekleri neler?
• SARIF gibi standart output formatları destekleniyor mu?
• False positive ve accepted risk kayıtlarının audit trail’i tutuluyor mu?
• Source code SaaS ortamına gönderiliyor mu, yoksa on-premises veya air-gapped deployment mümkün mü?
• SAST, SCA, secrets ve IaC sonuçları birbirinden açık biçimde ayrılıyor mu?
• Kendi uygulamalarımızdan alınan doğrulanmış test setinde precision ve recall oranı nedir?

OWASP Benchmark gibi test setleri ürünlerin true positive ve false positive davranışını karşılaştırmak için yararlıdır. Fakat tek başına satın alma kararı vermemelidir. Synthetic test case başarısı, kurumun custom framework ve gerçek architecture yapısındaki performansı garanti etmez.

SAST başarısı nasıl ölçülmeli?

Toplam finding sayısı iyi bir başarı metriği değildir. Rule sayısı artırıldığında bulgu sayısı yükselir fakat gerçek risk görünürlüğü aynı kalabilir. Benzer biçimde bütün gürültülü rule’ları kapatmak dashboard’u yeşile çevirir fakat false negative riskini büyütür.

Daha sağlıklı metrikler şunlardır:

• SAST kapsamına alınmış aktif repository oranı
• Başarıyla tamamlanan full ve incremental scan oranı
• Manuel doğrulama sonrası true positive oranı
• False positive oranı ve en çok gürültü üreten rule’lar
• Yeni kritik bulgular için mean time to triage
• Doğrulanmış bulgular için mean time to remediate
• SLA dışında kalan finding sayısı ve yaşı
• Tekrarlayan weakness sınıfları ve regression oranı
• Suppression sayısı, yaşı ve yeniden değerlendirme durumu
• Pentest veya incident sırasında bulunup SAST tarafından kaçırılan code-level zafiyetler
• Custom rule ile kurumsal kontrole dönüştürülen gerçek bulgu sayısı

Özellikle son iki metrik önemlidir. SAST dışında bulunan her code-level zafiyet, aracın ve rule set’in geliştirilmesi için feedback üretmelidir. Böylece pentest yalnızca tek bir açığı kapatmaz, aynı weakness’in yeniden yazılmasını engelleyen regression kontrolü oluşturur.

SAST raporu nasıl yorumlanmalı?

Bir SAST bulgusu değerlendirilirken yalnızca tool severity’ye bakılmamalıdır. Aşağıdaki context birlikte incelenmelidir:

• Input gerçekten attacker-controlled mı?
• Code path production’da reachable mı?
• Sink güvenlik açısından etkili bir işlem gerçekleştiriyor mu?
• Arada validation, encoding veya parameterization var mı?
• Kontrol doğru context için uygulanmış mı?
• Etkilenen data hassas mı?
• İlgili fonksiyon hangi identity ve privilege ile çalışıyor?
• Başarılı exploitation durumunda blast radius nedir?
• Aynı root cause başka code location’larda tekrar ediyor mu?
• Runtime üzerinde compensating control var mı?

Bu değerlendirme sonunda finding true positive, false positive, security hotspot veya accepted risk olarak sınıflandırılabilir. Tool output’un doğrudan vulnerability report olarak müşteriye veya yönetime iletilmesi doğru değildir. Teknik doğrulama ve business impact analizi gerekir.

SAST konusunda sık yapılan hatalar

“OWASP Top 10’u tarıyor, demek ki uygulama güvende” demek

OWASP Top 10 bir tool checklist’i değildir. Access control, authentication, design ve business logic gibi kategoriler yalnızca static rule’larla tam olarak doğrulanamaz.

SAST ile SCA’yı aynı kabul etmek

Source code içindeki SQL injection pattern’i ile dependency version’ındaki bilinen CVE farklı analiz problemleridir. Dashboard aynı olsa bile engine, veri kaynağı ve remediation yöntemi ayrıdır.

Scan başarısızken sonucu temiz saymak

Build tamamlanmamış, kritik module atlanmış veya analysis timeout oluşmuşsa sıfır bulgu iyi haber değildir. Coverage eksikliğidir.

Bütün finding’leri aynı anda pipeline gate yapmak

Bu yaklaşım developer’ı güvenlik düzeltmeye değil pipeline’ı geçmeye yöneltir. Yeni kritik riskler, doğruluğu yüksek rule’lar ve risk bazlı policy ile başlanmalıdır.

False positive’leri gerekçesiz kapatmak

Bugün false positive olan finding, framework veya configuration değişikliğinden sonra gerçek riske dönüşebilir. Suppression kaydı neden ve süre bilgisi taşımalıdır.

Manuel doğrulamayı kaldırmak

SAST, analyst için güçlü bir hızlandırıcıdır. Özellikle complex codebase’de security-relevant bölgelere odaklanmayı sağlar. Fakat aracın ürettiği olasılığı gerçek zafiyet ve iş etkisine dönüştürmek uzman incelemesi gerektirir.

Sonuç: SAST güçlü bir başlangıçtır, güvenlik kararı değildir

SAST, güvenlik hatasını developer’a yakın noktada bulabildiği için modern SDLC’nin en değerli kontrollerinden biridir. Tekrarlanabilir, ölçeklenebilir ve doğru kurulduğunda binlerce code change içinde riskli data flow’ları erken gösterebilir. Özellikle injection, path traversal, güvensiz parser ve API kullanımı, hardcoded secret ve bazı memory safety problemlerinde ciddi görünürlük sağlar.

Fakat SAST’ın bakış açısı source code ve oluşturabildiği static model ile sınırlıdır. Uygulamanın gerçek authorization davranışını, business logic kurallarını, production configuration’ı ve saldırganın farklı sistemler arasında kurduğu attack chain’i tek başına göremez. Bu nedenle “SAST temiz” ile “uygulama güvenli” aynı cümle değildir.

En güvenilir yaklaşım SAST’ı SCA, secrets scanning, IaC scanning, threat modeling, manuel Kaynak Kod Analizi ve sızma testiyle birlikte kullanmaktır. Otomasyon genişlik ve hız sağlar. Uzman incelemesi ise context, gerçek exploitability ve iş etkisini ortaya koyar.

Secnodex, SAST çıktısını doğrudan zafiyet raporu olarak kabul etmek yerine manuel code review, data flow analizi, business logic incelemesi ve gerektiğinde çalışan sistem üzerindeki doğrulama adımlarıyla birlikte değerlendirir. Kaynak Kod Analizi ve sızma testi hizmetlerimizi inceleyebilir, kurumunuza uygun SAST kapsamı ve güvenlik test modeli için Secnodex ile iletişime geçebilirsiniz.

Metodoloji ve referanslar

• OWASP Static Code Analysis
• OWASP Source Code Analysis Tools
• OWASP Code Review Guide
• OWASP Application Security Verification Standard
• OWASP Benchmark
• NIST SP 800-218: Secure Software Development Framework
• NIST Source Code Security Analysis
• NIST SAMATE