Kod Analizi (SAST/DAST) & Güvenli Geliştirme

Kamu ve özel sektör yazılım ihalelerinde giderek daha sık bir madde görülüyor: teslim edilen yazılımın kaynak kod düzeyinde güvenlik denetiminden geçmesi. Bu sayfa, uygulama güvenliğini (AppSec) bir ürün alımı ya da tedarikçi şartnamesi olarak planlayan bilgi işlem, geliştirme ve güvenlik ekipleri için yöntemleri, kıyas tablosunu ve şartname maddelerini açıklar.

Çözüm neyi kapsar?

Uygulama güvenliği tek bir araçla değil, birbirini tamamlayan tarama yöntemleriyle kurulur. Kod yazılırken, uygulama çalışırken ve üçüncü parti bileşenler eklenirken farklı açık sınıfları ortaya çıkar; her birini farklı bir yöntem yakalar:

• SAST (Statik Uygulama Güvenlik Testi): Kaynak kodu veya byte kodu çalıştırmadan analiz eder; SQL enjeksiyonu, XSS, sabit kodlanmış parola (hardcoded secret) ve güvensiz kriptografi gibi kod kaynaklı zafiyetleri erken yakalar.
• DAST (Dinamik Uygulama Güvenlik Testi): Çalışan uygulamaya dışarıdan saldırı simüle eder; kimlik doğrulama zafiyetleri, oturum yönetimi ve konfigürasyon hatalarını gerçek çalışma koşullarında bulur.
• SCA (Yazılım Bileşen Analizi): Açık kaynak bağımlılıkları CVE ve lisans veritabanlarıyla eşleştirir; Log4Shell benzeri bilinen açıkları ve lisans uyum riskini raporlar.
• IAST ve secret tarama: Uygulama içine yerleşen ajanla test sırasında doğrulanmış (exploitable) açıkları izler; ayrıca depoya sızan API anahtarı ve parolaları yakalar.

Bu yöntemler bir DevSecOps hattında birleşir: bulgular tek panelde toplanır, geliştiriciye IDE ve pull request içinde geri bildirim olarak döner, kalite kapısı (quality gate) eşiği aşıldığında derleme durdurulur.

SAST, DAST, SCA ve IAST: yöntem karşılaştırması

OWASP, CWE ve standart çerçeveler

Nesnel bir şartname tanınmış zafiyet taksonomilerine dayanmalıdır. OWASP Top 10 en yaygın web uygulama risklerini; OWASP ASVS (Application Security Verification Standard) doğrulanabilir güvenlik gereksinimlerini tanımlar. CWE (Common Weakness Enumeration) ve CWE/SANS Top 25zafiyet türlerini standart bir sözlükle numaralandırır — bir SAST aracının hangi CWE sınıflarını kapsadığını sormak, ürünleri objektif kıyaslamanın en pratik yoludur. Süreç tarafında NIST SSDF (SP 800-218 Güvenli Yazılım Geliştirme Çerçevesi), ISO/IEC 27001 ve kart verisi işleyen kurumlar için PCI DSS kaynak kod denetimini bir kontrol maddesi olarak zorunlu kılar.

CI/CD entegrasyonu ve false-positive yönetimi

Güvenlik testinin değeri, ne kadar erken çalıştığıyla doğru orantılıdır (shift-left). Bir açığın üretimde giderme maliyeti, geliştirme aşamasında giderme maliyetinin çok üzerindedir — sektör çalışmalarına göre yaklaşık 10–100 kat (örnek değer). Bu yüzden SAST ve SCA taramaları her commit/pull request'te, kapsamlı DAST taraması ise gecelik veya sürüm öncesi çalıştırılır.

Statik analizin en büyük operasyonel riski yanlış pozitif (false-positive) selidir; gürültülü bir araç geliştiricinin güvenini hızla kaybeder. Bulgu kalitesini basit bir oranla ölçebilirsiniz:

Sinyal / Gürültü = Doğrulanmış bulgu (TP) ÷ Toplam uyarı (TP + FP)

Pratik önlemler: mevcut açıkları baseline alıp yalnızca yeni eklenen kodu bloklamak (artımlı / diff-aware tarama), kural setini dile ve çerçeveye göre özelleştirmek, IAST ile bulguları çalışma zamanında doğrulamak. Kalite kapısını yalnızca yeni ve yüksek önem dereceli bulgularda bloklayıcı yapmak, hattı yavaşlatmadan riski kontrol eder:

Teknik şartnamede dikkat edilecekler

• Ürün adı yerine yetenek + standart: kapsanan diller/çerçeveler, OWASP Top 10 ve CWE Top 25 karşılığı, desteklenen tarama türleri (SAST + DAST + SCA).
• Veri sahipliği ve dışa aktarım: bulguların standart SARIF formatında dışa aktarılabilmesi şart koşulmalı — araç değiştirildiğinde geçmiş verinin taşınabilmesi vendor lock-in'i önler.
• Kaynak kod gizliliği: kaynak kodun buluta çıkması hassas kurumlarda risklidir; on-prem / self-hosted seçenek, KVKK ve gerekli yerlerde 5651 uyumu (kod ve log'un yurt içinde tutulması) aranmalı.
• Entegrasyon: CI/CD (Jenkins, GitLab, GitHub Actions, Azure DevOps), IDE eklentileri ve issue takip (Jira) entegrasyonu; REST API açıklığı.
• SLA / metrikler: yanlış pozitif oranı, tarama süresi, kural/imza güncelleme sıklığı ve zafiyet giderme süresi (MTTR) raporlanabilmeli.

Seçim kriterleri

• Dil ve çerçeve kapsamı: yığınınızdaki tüm diller (ör. Java, C#, JavaScript/TypeScript, Python, Go) desteklenmeli.
• Doğruluk: düşük yanlış pozitif, yüksek gerçek pozitif; mümkünse bir pilot repoda kıyas taraması yapın.
• Geliştirici deneyimi: IDE ve PR içi geri bildirim, otomatik düzeltme önerileri; aracı güvenlik ekibi değil geliştirici tüketir.
• Raporlama ve uyum: OWASP / PCI / ISO haritalı yönetici raporları ve denetim izi.
• Dağıtım ve ölçek: on-prem / bulut seçeneği, artımlı tarama, çok sayıda repo için ölçeklenme.
• Açık kaynak mı, ticari mi: SonarQube, Semgrep, OWASP ZAP, Trivy ve OWASP Dependency-Check güçlü başlangıç noktalarıdır; ticari ürünler genelde daha geniş dil kapsamı, düşük gürültü ve kurumsal destekle ayrışır.

Mevcut geliştirme hattınızı ve teknoloji yığınınızı birlikte değerlendirip, önceliklendirilmiş bir AppSec yol haritası ve şartname taslağı çıkaralım. İhtiyacınızı aşağıdaki formdan iletmeniz yeterli.