SAST mi, LLM Güvenlik Taraması mı? Pipeline'ında Hangisi Nerede Çalışmalı

Ekibinizde birileri muhtemelen şunu deniyor: güçlü bir dil modeline bir merge request gösterip “burada açık var mı” diye sormak. Tek bir merge request üzerinde sonuç şaşırtıcı derecede iyi gelir; model kodu okur, ne yapması gerektiğini çıkarır, pattern tabanlı bir tarayıcının kaçırdığı sorunları bile yakalar. Sorun, bu deneyimi tüm pipeline’a genellemeye kalktığınızda başlıyor.

LLM’in tek MR’da iyi çalışması tüm pipeline’a neden taşınamıyor

Bir merge request üzerinde iyi çalışan model, her commit’te aynı davranışı göstermek zorunda değil. Commit sayısı arttıkça her biri için ayrı bir inference çağrısı yapmak, maliyeti ve davranış tutarlılığını öngörülemez hale getiriyor. Yani soru “SAST mi LLM mi” değil; hangisinin pipeline’ın hangi noktasında çalışacağı. Bu ayrımı doğru yapmak üç şeyi aynı anda korumanızı sağlar: her commit’te deterministik kapsama, gerektiği yerde akıl yürütme kapasitesi, öngörülemez bir inference faturasından kaçınma. Ekip küçükken bile bu ayrımı erken kurmak, kod tabanı büyüdükçe pipeline’ı yeniden kurmaktan çok daha ucuza gelir.

Maliyet ve öngörülebilirlik nerede kırılıyor

SAST taraması commit başına bir sentin çok küçük bir kesri kadar, sabit ve öngörülebilir bir maliyetle çalışır — her seferinde aynı şekilde. LLM tabanlı bir tarama ise ücretli bir inference çağrısı; maliyet taranan kod hacmiyle birlikte ölçeklenir ve önceden kestirmesi zor. Küçük bir takım için bu fark önemsiz görünebilir, ama her commit’i, her gün, tüm kod tabanında taramaya başladığınızda kümülatif etki büyür. SAST’ı her commit’te çalıştırmak güvenlik kapsamını bütçeyle rekabete sokmuyor; LLM’i aynı role koymak sokuyor. LLM taramasını sabit maliyetli bir taban katman değil, ihtiyaç duyulan noktada devreye giren, değişken maliyetli bir ek katman olarak planlamak gerekiyor.

Tutarlılık ve denetim kanıtı neden SAST’ta daha güçlü

Aynı kodu bir LLM’den iki kez geçirdiğinizde tespit edilen açıklar farklılaşabilir. Bu bir hata değil, örnekleme tabanlı akıl yürütmenin doğal sonucu. Ama bir taramanın gerçekten yapıldığını ve sonuçlarına güvenilebileceğini kanıtlamanız gerektiğinde bu değişkenlik ciddi bir sorun haline geliyor. Tekrarlanabilirlik, denetim kanıtının güvenilirliğini doğrudan etkiler: aynı taramayı yeniden çalıştırdığınızda aynı sonucu almanız, o sonucun bağımsızca doğrulanabilir olduğu anlamına gelir. Kural tabanlı bir SAST aracı bunu tasarımı gereği sağlıyor; her çalıştırmada aynı bulguyu, aynı CWE eşlemesiyle üretiyor. Probabilistik bir model bu garantiyi vermiyor — çıktı çalıştırmadan çalıştırmaya değişebiliyor ve tek başına denetim kanıtı olarak kullanılması zorlaşıyor.

SOC 2, PCI DSS gibi çerçeveler ve AB’nin Siber Dayanıklılık Yasası (Cyber Resilience Act), tekrarlanabilir ve denetlenebilir kanıt istiyor. Denetim dosyanıza “model böyle söyledi” yazmak, “bu tarayıcı bu kuralla bu sonucu üretti, tekrar çalıştırdık aynı sonucu aldık” yazmaktan çok daha zayıf bir konum. Denetim döneminde bu fark, saatlerce ek açıklama yazmakla dakikalar içinde kanıt sunmak arasındaki farka denk geliyor.

Hangi açık türünde hangisi kazanıyor

Burada net bir kazanan yok; ikisi de farklı sınıflarda güçlü. SAST, injection açıkları, hardcoded secret kullanımı ve zayıf kriptografi çağrıları gibi pattern tabanlı, sabit kurallarla tanımlanabilen açıklarda güçlü — sabit kurallara dayandığı için her çalıştırmada aynı sorunu işaretliyor. (Secret taraması pratikte ayrı bir job olarak, SAST’tan bağımsız da yürütülebilir; tespit mantığı her iki durumda da deterministiktir.)

Bir LLM taraması ise kodun etrafındaki bağlamı — epic’leri, issue’ları, dokümantasyonu, sistemin ne yapması gerektiğini anlatan metinleri — okuyabiliyor. Bu bağlam sayesinde eksik yetkilendirme kontrolü ya da bozuk sahiplik (ownership) mantığı gibi iş mantığı sorunlarını, henüz bir CVE veya CWE’ye eşlenmemiş yeni açık türlerini işaretleyebiliyor. Bir tarayıcının yapısal olarak asla yakalayamayacağı sınıf bu; kural yazarak bu tür açıkları kapsama almak pratikte mümkün değil, çünkü her biri projeye özgü bir mantık hatası.

Bulgu doğrulama: LLM’in öne çıktığı nokta

SAST bir aday bulguyu işaretler ama o bulgunun gerçekten sömürülebilir olup olmadığını söyleyemez. LLM burada bir adım öteye gidebiliyor: bulguyu tetikleyen çalışır bir exploit üreterek, bulgunun kuyruğunuza ulaşmadan önce gerçek olup olmadığını gösterebiliyor. Bu, ekibin false-positive araştırmakla vakit kaybetmesini azaltıyor ve geliştiricinin bulgulara duyduğu güveni artırıyor. Sürekli yanlış alarm üreten bir tarayıcı zamanla ciddiye alınmaz hale gelir — yalancı çoban etkisi budur; doğrulama adımı tam olarak bunu engelliyor.

Pipeline’da iki katmanı nasıl konumlandırırsınız

Pratik ayrım şöyle işliyor: deterministik tarama her commit’te çalışan, tavizsiz taban katman olarak kalıyor. LLM tabanlı tarama ise genellikle her commit’te değil, merge request seviyesinde devreye giriyor — akıl yürütme gerektiren, bağlama dayalı kontroller için.

Katman	Ne zaman çalışır	Neyi yakalar	Maliyet profili
SAST (deterministik)	Her commit, her push	Injection, hardcoded secret, zayıf kripto	Sabit, çok düşük
LLM tabanlı inceleme	Merge request seviyesinde	Eksik yetkilendirme, bozuk ownership mantığı, iş mantığı hataları	Değişken, kod hacmine bağlı

Gerçek bir pipeline’da bu ayrımı kurarken CI aracınızın kendi şablon ve tetikleme mekanizmasını kullanmanız gerekiyor; hangi pipeline kaynağının (push, merge request event, zamanlanmış çalıştırma) hangi job’ı tetikleyeceğini CI aracınızın dokümantasyonuna göre netleştirin, çünkü bu davranış araçtan araca ve sürümden sürüme değişiyor.

Böylece her commit’te ucuz ve öngörülebilir kapsama korunuyor; her merge request’te ise bağlamı okuyabilen ama pahalı ve değişken olan katman devreye giriyor. İkisini birbirinin yerine değil, birbirini tamamlayan katmanlar olarak kurgulamak hem güvenlik kapsamını hem bütçeyi kontrol altında tutuyor.

Supply chain güvenliği tarafında imaj taraması ve SBOM üretimi de benzer bir mantıkla çalışıyor: deterministik, tekrarlanabilir kontroller sürekli katmanda kalmalı; bağlama dayalı analiz ise nokta atışı bir katmanda çalışmalı. Cluster’ınızdaki CI/CD pipeline’ında bu ayrımı henüz netleştirmediyseniz, 30 dakikalık ücretsiz teknik değerlendirme için bize yazın.