GitLab ile DevSecOps Yaşam Döngüsünde Uygulama Güvenliği
Modern yazılım geliştirme dünyasında, uygulama güvenliği artık “sonradan eklenen” bir unsur değildir. Kesinlikle, yazılım yaşam döngüsünün (SDLC) ayrılmaz bir parçası olmalıdır. DevSecOps yaklaşımı tam olarak neyi hedefler? Elbette, güvenliği, geliştirme ve operasyon süreçlerine en baştan, sistematik ve otomatik şekilde yerleştirmeyi amaçlar.
GitLab, bu yaklaşımı hayata geçirmek için zengin güvenlik tarayıcıları (security scanners) ekosistemi sunar. Bu makalede, GitLab’in sunduğu statik ve dinamik analiz araçlarını, CI/CD pipeline’lara nasıl entegre edilebileceğini açıklayacağız. Ek olarak, gerçek hayatta ne tür problemleri çözdüklerini de inceleyeceğiz.
DevSecOps Yaşam Döngüsünde Güvenliğin Önemi
DevSecOps yaşam döngüsü genel olarak iki ana faza ayrılabilir: Development (Geliştirme) ve Operations (Operasyon).
GitLab’in güvenlik aşaması bu iki fazın tümüne yayılan yatay bir katman gibi düşünülebilir. Amaç, yalnızca kodu çalışır hale getirmek değildir. Aynı zamanda her aşamada güvenlik duruşunu (security posture) sürekli ölçmek ve iyileştirmektir.
Bu kapsamda GitLab şu iki temel tarama türünü sunar: Statik Analiz (SAST – Static Application Security Testing) ve Dinamik Analiz (DAST – Dynamic Application Security Testing)
Statik analiz, kod çalışmıyorken kaynak kodu tarar. Dinamik analiz ise uygulama ayakta ve çalışır durumdayken, gerçek bir saldırgan gibi davranarak güvenliği test eder. İkisini birlikte kullanmak, mümkün olan en geniş güvenlik kapsamını sağlar.
GitLab Güvenlik Tarayıcılarının CI/CD’ye Entegrasyonu
GitLab güvenlik tarayıcıları, CI/CD pipeline üzerinden çalışır ve *.gitlab-ci.yml dosyası ile tanımlanır. Burada, stages ile pipeline aşamaları (test, security, dast vb.), include ile GitLab’in sağladığı hazır template veya component’ler, inputs ve variables ile tarayıcıların davranışı tanımlanır.
Örneğin SAST için minimal bir tanım şu biçimdedir:
stages:
– test
include:
– component: gitlab.com/components/sast/sast@main
Aynı yaklaşım, Secret Detection, Dependency Scanning, Container Scanning, IaC ve DAST/API Security için de geçerlidir. Böylece tek bir YAML dosyası üzerinden hem fonksiyonel testleri, hem de güvenlik testlerini orkestre etmek mümkündür.
SAST (Static Application Security Testing)
SAST Ne Yapar?
SAST’in amacı, kaynak kodu tarayarak güvenlik zafiyetlerine işaret eden kalıpları otomatik olarak tespit etmektir. Özellikle, büyük kod tabanlarında manuel inceleme yükünü azaltmak, yeni commit’lerde güvenlik sorunlarını erken aşamada yakalamak (“shift left” yaklaşımı), zafiyetleri önem derecesine göre sıralamak ve issue’lara dönüştürmeyi kolaylaştırmak için çok uygundur.
GitLab SAST Mimarisi
GitLab SAST, birden fazla analyzer kullanır. Örneğin, gitlab-advanced-sast – çapraz fonksiyon / dosya taint analysis yapan gelişmiş tarayıcı, kubesec – Kubernetes manifest ve Helm chart’ları için, semgrep – pek çok dili destekleyen genel amaçlı statik analiz aracı ve spotbugs, sobelow, pmd-apex gibi.
Proje türüne göre uygun analizörler otomatik seçilir. Örneğin depo içinde AndroidManifest.xml varsa ilgili spotbugs analizörü devreye girer. Aynı repoda birden fazla dil/dosya türü varsa, birden çok analizör paralel çalışabilir.
Yapılandırma ve Özelleştirme
SAST’i bir component olarak dahil ettiğinizde, davranışını inputs ile aşağıdaki gibi değiştirebilirsiniz:
stage: Tarayıcının hangi pipeline aşamasında çalışacağını belirler (örneğin security gibi).
excluded_paths: Tarama dışında bırakılacak klasör/dosyalar (örneğin, docs, tests, samples gibi).
Bu sayede, test, dokümantasyon veya örnek kod (samples) gibi üretim dışı içerikleri taramanın dışına çıkarabilir ve güvenlik taramalarını fonksiyonel testlerden ayrı, izole bir güvenlik aşamasında çalıştırabilirsiniz.
Advanced SAST
Gelişmiş SAST tarayıcısı, fonksiyonlar ve dosyalar arasındaki veri akışını takip ederek daha karmaşık güvenlik sorunlarını tespit edebilir. C#, Go, Java/JSP, JavaScript/TypeScript, Python ve Ruby için destek sunar.
Aktifleştirmek için, SAST component’ine aşağıdaki değer girilir.
inputs:
run_advanced_sast: true
Bu durumda pipeline’da gitlab-advanced-sast isimli ek bir job görülür.
Secret Detection (Gizli Bilgilerin Tespiti)
Neden Önemli?
Modern projelerde sıkça, API anahtarları, parolalar, SSH anahtarları, OAuth token’ları gibi sırlar kullanılır. Bunların yanlışlıkla repoya commit’lenmesi, tüm sistemi tehlikeye atabilecek kritik bir güvenlik açığıdır. Secret Detection’ın hedefi, bu tür ”hardcoded secret” vakalarını otomatik tespit etmek ve sızıntı oluşmasını engellemektir.
Üç Katmanlı Koruma Modeli
GitLab üç farklı seviyede secret tespiti sağlar: Secret Push Protection, commit push edilirken tarama yapılır. Secret bulunursa push engellenir. Amaç, sırrın repoya hiç ulaşmamasını sağlamaktır.
Pipeline Secret Detection, repository’de halihazırda commit’lenmiş sırları tarar. Geçmişteki hataları ortaya çıkarır. Client-side Secret Detection, Issue ve Merge Request açıklamaları gibi metin içeriklerini kaydedilmeden önce tarar. Sırların yalnızca kaynak kodda değil, GitLab arayüzünde de görünmesini engellemeye yardım eder.
Konfigürasyon
Secret Detection, diğer tarayıcılar gibi CI/CD component’i olarak eklenir ve inputs / variables ile özelleştirilir. Örneğin:
SECRET_DETECTION_HISTORIC_SCAN – git geçmişinin tamamını taramak için,
SECRET_DETECTION_EXCLUDED_PATHS – kimi dizinleri hariç bırakmak için kullanılır.
Daha ileri ihtiyaçlar için .gitlab/secret-detection-ruleset.toml içinde özgün regex kuralları tanımlanabilir. Bu sayede, kuruma özel gizli veri formatları da yakalanabilir.
Dependency Scanning ve SBOM
Kütüphane ve Bağımlılık Riskleri
Güncel uygulamaların neredeyse tamamı üçüncü parti kütüphaneler ve paketler kullanır. Log4j örneğinde olduğu gibi, tek bir popüler paketteki zafiyet, yüzlerce projeyi, birçok kurumu ve kritik sistemleri aynı anda etkileyebilir.
Dependency Scanning’in amacı, projede kullanılan paketleri ve sürümlerini tespit etmek, bunları GitLab Advisory Database gibi güvenlik veri tabanlarıyla karşılaştırmak, bulunan zafiyetleri CVE, CVSS, CWE bilgileriyle birlikte raporlamak ve aynı zamanda bir SBOM (Software Bill of Materials) üretmektir.
Çalışma Prensibi
Tarayıcı, kullanılan paket yöneticisinin lock dosyalarını inceler:
JavaScript için: package-lock.json, yarn.lock, pnpm-lock.yaml gibi,
Diğer ekosistemler için ilgili dosyalar. Bu bilgiler sayesinde bağımlılık ağacı çıkarılır ve zafiyetli paketler işaretlenir.
SBOM ve Continuous Vulnerability Scanning
Dependency Scanning etkinleştirildiğinde: proje için bir SBOM oluşturulur (Secure > Dependency list ekranı), bu SBOM, Continuous Vulnerability Scanning (CVS) için de temel oluşturur.
CVS, CI pipeline’ından bağımsız arka plan işleriyle, SBOM’daki bağımlılıkları sürekli yeni güvenlik tavsiyeleriyle karşılaştırır ve yeni zafiyetleri otomatik olarak Vulnerability Report’a işler.
Container Scanning
Uygulamalar artık genellikle container imajları üzerinden dağıtılıyor. Bu imajların içinde, işletim sistemi paketleri, uygulama bağımlılıkları, ara katman yazılımları bulunur ve hepsi ayrı birer risk kaynağıdır.
Container Scanning:
CI pipeline’ında build edilen son container imajını, GitLab Container Registry’den çekerek GitLab Advisory Database’e göre tarar. Sonuçlar Container Scanning job’ı aracılığıyla Vulnerability Report’ta görünür. Böylece hem kod bağımlılıkları (Dependency Scanning), hem de imaj içindeki OS ve paketler (Container Scanning) güvence altına alınır.
Infrastructure as Code (IaC) Scanning
Altyapının kodla tanımlanması (Terraform, Ansible, Kubernetes manifest’leri, CloudFormation gibi) büyük kolaylık sağlarken, yanlış yazılmış bir konfigürasyon da ciddi güvenlik açıklarına yol açabilir (açık güvenlik grupları, public S3 bucket’lar, zayıf şifre politikaları gibi).
GitLab IaC Scanning:
Depodaki IaC dosyalarını, KICS adlı açık kaynak statik analiz aracıyla tarar. Desteklediği formatlar arasında Ansible, Terraform, Kubernetes, Dockerfile, CloudFormation, ARM, GCP Deployment Manager, OpenAPI gibi birçok yapı bulunur. Kurallar sast-ruleset.toml dosyasıyla özelleştirilebilir veya bazı kurallar devre dışı bırakılabilir. Böylece, altyapı seviyesindeki yanlış yapılandırmalar daha uygulanmadan tespit edilebilir.
DAST (Dynamic Application Security Testing)
SAST kodu “durağan” durumda tararken, DAST kodu çalışırken test eder. Uygulama çalıştırılmış, HTTP üzerinden erişilebilir durumdadır ve DAST bu çalışan uygulamaya gerçek bir saldırgan gibi yaklaşır.
Pasif ve Aktif Tarama
Pasif Tarama (Passive Scan)
Uygulamayı bir kullanıcı gibi gezer, HTTP mesajlarını, cookie’leri, DOM ve tarayıcı olaylarını inceler. Etkileşim saldırgan davranışı içermez, daha “zararsız” bir taramadır.
Aktif Tarama (Active Scan)
SQL injection, XSS gibi saldırı payload’larını isteklere enjekte ederek gerçekten açığı tetiklemeye çalışır. Yanıt içeriği (match response) ve yanıt süresi (timing attacks) gibi tekniklerle exploit’in başarılı olup olmadığı değerlendirilir. Bu mod, yalnızca test ortamlarında kullanılmalıdır.
DAST Konfigürasyonu
DAST, DAST.gitlab-ci.yml template’i ile devreye alınır. En temel değişken: DAST_TARGET_URL: Taranacak uygulamanın URL’sidir.
Ek olarak, kimlik doğrulama için: DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD kullanılır.
Form alanları için CSS seçicileri (DAST_AUTH_USERNAME_FIELD gibi) kullanılır. Böylece oturum açma gerektiren sayfalar da taranabilir.
API Security Scanning
Modern web uygulamaları büyük ölçüde API’ler üzerinden çalışır. GitLab API Security Scanning, bu API uç noktalarının yetkisiz erişim, kötü niyetli girişler ve yaygın API zafiyetlerine karşı taranmasını sağlar.
Desteklenen API Tanım Formatları
API güvenlik tarayıcıyı beslemek için aşağıdaki dört tanımlama biçiminden biri kullanılır:
OpenAPI spesifikasyonu,
GraphQL şeması,
HTTP Archive (HAR),
Postman koleksiyonu.
Tarayıcı bu tanımları kullanarak API’yi gezmek ve saldırı senaryolarını çalıştırmak için gerekli istekleri oluşturur. Dil bağımsızdır ve sadece HTTP istek tanımlarına ihtiyaç duyar.
Pasif / Aktif Mod ve Kimlik Doğrulama
API Security de DAST gibi pasif ve aktif modda çalışabilir:
Pasif mod: Standart isteklerle API’yi çağırır, yanıtları inceler.
Aktif mod: SQL injection gibi spesifik saldırı payload’ları dener.
Sağlıklı bir tarama için kimlik doğrulamanın doğru ayarlanması önemlidir:
HTTP Basic için: APISEC_HTTP_USERNAME, APISEC_HTTP_PASSWORD_BASE64,
Bearer token’lar için: APISEC_OVERRIDES_ENV veya APISEC_OVERRIDES_FILE,
Kısa ömürlü token’lar için: APISEC_OVERRIDES_CMD ve APISEC_OVERRIDES_INTERVAL ile token yenileme script’i kullanılır.
Bu sayede, token süreleri dolmadan uzun süren taramalar gerçekleştirilebilir ve tüm yetkili endpoint’ler kapsam altına alınır.
Bütüncül Bir Güvenlik Ekosistemi
GitLab’in sunduğu güvenlik tarayıcıları, DevSecOps yaklaşımını pratikte hayata geçirmek için güçlü bir araç birleşimi sunar:
SAST ile kaynak kod seviyesi zafiyetler,
Secret Detection ile gizli bilgilerin sızıntısı,
Dependency Scanning + SBOM + CVS ile üçüncü parti bağımlılık riskleri,
Container Scanning ile imaj ve OS katmanındaki zafiyetler,
IaC Scanning ile altyapı konfigürasyon hataları,
DAST ve API Security ile çalışma zamanındaki uygulama ve API zafiyetleri, tek bir CI/CD pipeline’da, aynı ekosistem altında yönetilebilir.
Kurumsal ölçekte bakıldığında, hedef yalnızca elbette tarayıcıyı çalıştırmak değildir. Çıkan sonuçları
önceliklendirmek (severity, CVSS, EPSS, KEV gibi metriklerle), issue’lara dönüştürmek, takip etmek ve kapatıldığını doğrulamak şeklinde sürdürülebilir bir güvenlik sürecine dönüştürmektir.
Doğru kurgulanmış bir GitLab DevSecOps yapısıyla, ekipler hem teslimat hızını düşürmeden çalışabilir hem de güvenlik risklerini sistematik olarak azaltabilir. Açıktır ki, bu da modern yazılım geliştirme dünyasında rekabetçi kalmanın temel şartlarından biridir.
Sarav Asiye Yiğit * 13 Kasım 2025
Kaynakça:
GitLab dokümantasyon.