GitLab SAST, uygulama kodunu çalıştırmadan inceleyen bir güvenlik taramasıdır. Tarama pipeline içinde bir job olarak çalışır; sonuçlar merge request üzerinde görünür ve geliştirici kodu birleştirmeden önce riski görür.
Pratikte iki karar önemlidir: hangi plan gerçekten gerekiyor ve bulgularla kim ne yapacak. Bu iki soru cevaplanmadan kurulan tarama, kısa sürede kimsenin okumadığı bir rapora dönüşür.
Ne zaman değer üretir?
- Merge request incelemesi zaten yerleşmişse; SAST bu akışa ek bir kontrol katar.
- Aynı hata tipi (girdi doğrulama, komut çalıştırma, zayıf şifreleme kullanımı) tekrar ediyorsa.
- Denetim veya müşteri sözleşmesi, geliştirme sürecinde güvenlik kontrolü kanıtı istiyorsa.
- Dış geliştirici veya çok sayıda ekip aynı depoya katkı veriyorsa.
Ne zaman beklentiyi karşılamaz?
- Kod tabanı çok küçükse ya da uygulama büyük ölçüde hazır bileşenlerden oluşuyorsa.
- Ekipte bulguları değerlendirecek zaman ve sahiplik yoksa.
- Asıl risk bağımlılıklarda veya çalışan sistemin yapılandırmasındaysa; bu durumda Dependency Scanning, Container Scanning veya DAST daha doğru başlangıç olabilir.
- SAST’tan “tüm güvenlik açıklarını bulma” bekleniyorsa. Statik analiz, mantıksal iş kuralı hatalarını ve çalışma zamanına özgü sorunları göremez.
Bizim kurduğumuz pipeline
GitLab’ın kendi SAST job’ını kullanıyoruz; ayrı bir tarayıcı kurmuyoruz. Şablon hazır geldiği için iş, aracı kurmak değil eşikleri ve kapsamı doğru tanımlamaktır.
Aynı pipeline’a Secret Detection‘ı da ekliyoruz. Depoya girmiş parola, API anahtarı veya token, statik analiz bulgularının çoğundan daha acil bir risktir; bu yüzden ikisi birlikte çalışır.
Kurgu şöyle işler:
- SAST job’ı her merge request’te kodu tarar.
- Secret Detection deponun tamamını kontrol eder.
- Kritik bulgular pipeline’ı durdurur; kalanlar merge request üzerinden değerlendirilir.
- Tekrarlayan yanlış alarmlar gerekçesiyle işaretlenir.
Bu kurgu ücretsiz planda çalışır; Ultimate lisansı almadan işleyen bir güvenlik zemini kurar. Eksik kalan tek şey merkezî güvenlik panosudur, onun yerine bulguları merge request akışında yönetiriz.
Maliyet nasıl düşünülmeli?
Plan lisansı tek kalem değildir. Hesaba katılması gerekenler:
- Tarama job’larının tükettiği CI kapasitesi ve süresi (runner tarafındaki maliyet)
- Yanlış alarm ayıklamak için harcanan geliştirici zamanı
- Kural setinin projeye göre ayarlanması
- Bulguların takip edileceği sürecin kurulması
Sıralı bir kurulum yaklaşımı
- Taramayı tek bir depoda, pipeline’ı kırmayacak biçimde çalıştırın.
- Kritik ve yüksek seviyeli bulguları ayırın; önce onları ele alın.
- Yanlış alarmları gerekçesiyle kayıt altına alın.
- Kabul edilebilir eşiği belirledikten sonra kuralı zorunlu hâle getirin.
- Aynı kurguyu diğer depolara yayın.
Resmi kaynaklar
Mono ne zaman yardımcı olur?
- Plan ihtiyacının belirlenmesi: temel SAST yeterli mi, Ultimate gerçekten gerekli mi
- Tarama job’larının pipeline’a eklenmesi ve kural setinin projeye göre ayarlanması
- Bulgu değerlendirme sürecinin ve sahipliğinin tanımlanması
- SAST, Dependency Scanning ve DAST arasındaki iş bölümünün kurulması
