CI/CD Ortamında Otomatik Güvenlik Taramaları (SAST/DAST)

Bir yazılım ekibinde güvenlik kontrolünün yalnızca sürümden hemen önce yapılması, hataların en pahalı zamanda fark edilmesine neden olabilir. CI/CD Ortamında Otomatik Güvenlik Taramaları (SAST/DAST), güvenlik kontrolünü geliştirmenin doğal bir parçası haline getirerek bu sorunu önemli ölçüde azaltır. Yaklaşık on yıldır yazılım geliştirme, otomasyon ve güvenli teslim süreçleri üzerinde çalışan ekiplerde gördüğüm en net sonuç şudur: geliştiriciye doğru anda verilen kısa ve anlaşılır güvenlik geri bildirimi, haftalar sonra hazırlanan uzun bir rapordan çok daha kullanışlıdır. Bu rehberde SAST, DAST, SCA, secret scanning, container taraması, SBOM, güvenlik kapıları ve vulnerability yönetimini gerçek CI/CD akışı içinde nasıl konumlandırabileceğinizi ele alacağız. Ayrıca CI/CD pipeline içinde SAST ve DAST güvenlik taraması nasıl yapılır, DevSecOps süreçlerinde otomatik SAST DAST entegrasyonu nasıl kurulur ve güvenlik kontrolleri geliştiricilerin çalışma hızını bozmadan nasıl yönetilir gibi pratik sorulara yanıt vereceğiz.

CI/CD Ortamında Otomatik Güvenlik Taraması Nedir?

CI/CD ortamında otomatik güvenlik taraması, kaynak koddan çalışan uygulamaya kadar farklı varlıkların pipeline adımları sırasında güvenlik kontrollerinden geçirilmesidir. Amaç geliştiricilerin ayrı bir güvenlik sürecini beklemesi değil, güvenlik geri bildirimini zaten kullandıkları geliştirme akışı içinde görmesidir. İyi tasarlanmış bir yapı kod değişikliğini, bağımlılıkları, yapılandırmaları, container image'larını ve çalışan uygulamayı farklı araçlarla kontrol eder. Buradaki önemli nokta her aracı her commit'te ağır biçimde çalıştırmak yerine kontrolleri doğru pipeline aşamasına yerleştirmektir. Böylece güvenlik, teslimat sürecini yavaşlatan harici bir kontrol olmaktan çıkar ve yazılım kalitesinin sürekli ölçülen bir parçası haline gelir.

CI/CD Pipeline Nedir?

CI/CD pipeline, geliştiricinin yaptığı kod değişikliğinin test edilmesinden paketlenmesine ve uygun ortama dağıtılmasına kadar uzanan otomatik işlem zinciridir. Continuous Integration tarafı değişikliklerin sık birleştirilmesini, otomatik testlerden geçirilmesini ve sorunların erken fark edilmesini hedefler. Continuous Delivery veya Continuous Deployment tarafında ise doğrulanmış build'lerin staging ya da production ortamlarına kontrollü biçimde taşınması sağlanır. Güvenlik kontrollerinin bu zincire eklenmesi, yalnızca kod kalitesinin değil risk seviyesinin de her değişiklikte ölçülebilmesini sağlar. Benim tercih ettiğim yaklaşım, hızlı kontrolleri pull request seviyesinde çalıştırmak, daha kapsamlı analizleri ise build, staging veya zamanlanmış pipeline adımlarına dağıtmaktır.

DevSecOps Nedir?

DevSecOps, yazılım geliştirme, operasyon ve güvenlik sorumluluklarını aynı teslimat döngüsünde bir araya getiren çalışma yaklaşımıdır. Burada güvenlik ekibi yalnızca yayın öncesinde onay veren bir birim olarak değil, geliştiricilerin kullanabileceği politikalar, otomasyonlar ve geri bildirim mekanizmaları sağlayan bir ortak olarak konumlanır. DevSecOps süreçlerinde otomatik SAST DAST entegrasyonu nasıl kurulur sorusunun cevabı da yalnızca scanner eklemekten ibaret değildir. Başarılı bir yapı için araç seçimi, vulnerability triage, istisna yönetimi, risk kabul süreci ve ölçüm modeli birlikte tasarlanmalıdır. Böyle bir sistem kurulduğunda geliştirici güvenlik sonucunu kendi pull request'i içinde görür ve çoğu problem üretim ortamına ulaşmadan çözülebilir.

Security Testing Neden Pipeline'a Taşınmalıdır?

Security testing pipeline dışında tutulduğunda güvenlik ekibi genellikle büyük değişiklik paketlerini son aşamada incelemek zorunda kalır. Bu durumda bulunan bir zafiyetin düzeltilmesi kodun yeni yazıldığı ana göre daha fazla zaman ve koordinasyon gerektirir. Pipeline entegrasyonu ise aynı problemi geliştiricinin değişikliği yaptığı dakikalarda veya saatlerde görünür hale getirir. Ayrıca otomatik kontrol sayesinde güvenlik standardı yalnızca belirli projelere değil, uygun template kullanılarak onlarca repository'ye tutarlı biçimde uygulanabilir. Pratikte en büyük kazanım yalnızca daha fazla zafiyet bulmak değil, güvenlik geri bildirim süresini kısaltmaktır.

Shift Left Security Nedir?

Shift Left Security, güvenlik kontrollerini yazılım yaşam döngüsünün mümkün olduğunca erken aşamalarına taşımayı ifade eder. IDE eklentileri, pre-commit secret kontrolü, pull request SAST taraması ve dependency analizi bu yaklaşımın yaygın örnekleridir. Erken geri bildirim geliştiricinin hatanın bağlamını henüz hatırladığı bir anda düzeltme yapmasını kolaylaştırır. Bununla birlikte her güvenlik testini sola taşımak mümkün değildir, çünkü bazı riskler yalnızca çalışan uygulamada veya gerçek deployment yapılandırması içinde görülebilir. Bu nedenle shift left yaklaşımını DAST, runtime gözlemleme ve production güvenlik kontrolleriyle birlikte değerlendirmek gerekir.

Shift Right Security Nedir?

Shift Right Security, güvenlik gözlemlerinin staging ve production gibi çalışan ortamlarda devam etmesini ifade eder. Uygulamanın gerçek servis iletişimi, HTTP davranışı, kimlik doğrulama akışı veya deployment ayarları statik analiz sırasında tam olarak görülemeyebilir. DAST, runtime monitoring, güvenlik logları ve belirli kontrollü production testleri bu nedenle önemlidir. Shift right, shift left yaklaşımının alternatifi değil tamamlayıcısıdır. Sağlıklı bir DevSecOps programında geliştiriciye erken geri bildirim verilirken üretim ortamından gelen bulgular da yeniden geliştirme sürecine taşınır.

Continuous Security Testing Nedir?

Continuous Security Testing, güvenlik testlerinin tek seferlik denetim yerine yazılımın değişim hızına uyumlu biçimde sürekli çalıştırılmasıdır. Kod değiştiğinde SAST, dependency değiştiğinde SCA, image üretildiğinde container scan ve staging güncellendiğinde DAST devreye girebilir. Böylece güvenlik durumu birkaç ay önce hazırlanmış bir rapora değil mevcut build'e göre değerlendirilebilir. Sürekli test yaklaşımı özellikle hızlı sürüm yapan ekiplerde güvenlik görünürlüğünü belirgin biçimde artırır. Buradaki başarı ölçütü mümkün olan en fazla scanner'ı çalıştırmak değil, doğru sinyali doğru kişiye zamanında ulaştırmaktır.

CI/CD Pipeline'ında Hangi Güvenlik Taramaları Yapılmalıdır?

Tek bir güvenlik tarayıcısı bütün saldırı yüzeyini göremez. Kaynak kod, üçüncü taraf paketler, container image, altyapı tanımları, API uçları ve çalışan web uygulaması farklı risk türlerine sahiptir. Bu nedenle iyi bir pipeline birden fazla kontrol katmanını bir araya getirir ve her kontrolü en uygun aşamada çalıştırır. SAST ve DAST araçları CI/CD pipeline karşılaştırması ve kullanım senaryoları incelendiğinde iki yaklaşımın birbirini tamamladığı açıkça görülür. Kurumsal ortamlarda buna SCA, secret scanning, IaC taraması, SBOM üretimi ve supply chain kontrollerinin eklenmesi daha dengeli bir güvenlik modeli oluşturur.

SAST

SAST, uygulama çalıştırılmadan kaynak kodu veya derlenmiş kodu analiz ederek güvenlik açısından riskli kalıpları arar. Pull request aşamasında kullanıldığında geliştiriciye değişiklikle ilgili doğrudan geri bildirim sağlayabilir. Özellikle veri akışı, tehlikeli fonksiyon kullanımı ve güvenli olmayan API çağrıları açısından değerlidir. SAST sonuçlarının verimli olması için kullanılan programlama diline ve framework'e uygun kurallar seçilmelidir. Çok genel bir kural seti kullanıldığında gereksiz uyarılar artabileceği için zamanla rule tuning yapılması gerekir.

DAST

DAST, çalışan uygulamaya ağ üzerinden istek göndererek gözlemlenebilir güvenlik problemlerini tespit etmeye çalışır. Kaynak kodu görmek zorunda olmadığı için saldırganın dışarıdan görebileceği davranışları test etme açısından değerlidir. Staging veya preview environment üzerinde çalıştırılması genellikle production taramasından daha güvenli ve daha kontrol edilebilirdir. Authentication gerektiren uygulamalarda oturum açmış tarama desteği kapsamı ciddi biçimde artırır. DAST'ın pipeline içindeki amacı yalnızca zafiyet aramak değil, build sonucunda ortaya çıkan gerçek HTTP davranışının beklenen güvenlik seviyesinde olup olmadığını kontrol etmektir.

SCA

Software Composition Analysis, uygulamanın kullandığı açık kaynak veya üçüncü taraf bağımlılıkları güvenlik veritabanlarıyla karşılaştırır. Modern uygulamalarda kaynak kodun önemli bölümü harici paketlerden geldiği için bu kontrol zorunlu hale gelmiştir. SCA yalnızca doğrudan eklenen paketleri değil mümkün olduğunda transitive dependency olarak gelen alt bağımlılıkları da değerlendirmelidir. Tarama sonucunun package lock dosyaları ve gerçek build çıktısıyla ilişkilendirilmesi daha doğru sonuç verir. Yeni bir CVE yayınlandığında kod değişmemiş olsa bile mevcut bağımlılıkların yeniden değerlendirilmesi gerekir.

Secret Scanning

Secret scanning, repository veya commit içine yanlışlıkla eklenen API anahtarı, parola, token ve private key gibi hassas değerleri arar. Bu kontrolün pre-commit seviyesinde çalışması geliştiriciye en hızlı geri bildirimi verir. Ancak yerel kontrol atlanabileceği için CI/CD aşamasında ikinci bir tarama yapılması da önemlidir. Bir secret bulunduğunda yalnızca dosyadan silmek yeterli değildir, çünkü değer commit history içinde kalmış olabilir. Böyle bir durumda credential'ın geçersiz kılınması ve yenisinin üretilmesi güvenlik açısından temel adımdır.

IaC Scanning

Infrastructure as Code taraması Terraform, CloudFormation, Kubernetes YAML, Helm ve benzeri tanımlardaki riskli yapılandırmaları build veya deployment öncesinde kontrol eder. Açık storage alanları, geniş network izinleri ve ayrıcalıklı container tanımları bu kontrollerle erken fark edilebilir. IaC taramasının en büyük avantajı riskli altyapı ayarını canlı ortama ulaşmadan önce gösterebilmesidir. Kurallar kurumun kendi cloud ve ağ politikalarıyla desteklendiğinde sonuçların değeri yükselir. Ağ güvenliği ve erişim denetiminin daha geniş bağlamı için https://www.diyarbakiryazilim.com.tr/posts/ag-guvenlik-duvari-kurallari-ve-erisim-denetimi içeriği de yararlı bir tamamlayıcı olabilir.

Container Scanning

Container scanning, üretilen image içindeki işletim sistemi paketlerini, uygulama bağımlılıklarını ve bazı durumlarda secret izlerini analiz eder. Tarama build tamamlandıktan sonra gerçek image üzerinde yapılırsa production'a taşınacak artifact hakkında daha doğru sonuç elde edilir. Base image güncellendiğinde veya vulnerability veritabanına yeni CVE eklendiğinde eski image'ların yeniden taranması gerekir. Registry seviyesinde continuous rescanning bu ihtiyacı karşılayabilir. Deployment öncesi gate ise kritik seviyedeki yeni bulguların production ortamına ulaşmasını önlemek için kullanılabilir.

API Security Testing

API güvenlik testleri REST, GraphQL veya başka servis arayüzlerinde authentication, authorization ve input validation sorunlarını kontrol etmeye odaklanır. OpenAPI tanımı bulunan projelerde endpoint kapsamı otomatik oluşturulabilir. Yalnızca endpoint'in cevap verip vermediğini kontrol etmek güvenlik testi için yeterli değildir. Farklı kullanıcı rolleri, object-level authorization ve beklenmeyen parametre kombinasyonları da değerlendirilmelidir. API taramalarını integration test ve DAST süreçleriyle birleştirmek daha iyi bir güvenlik görünümü sağlar.

IAST

Interactive Application Security Testing, çalışan uygulama içindeki gözlemleri test trafiğiyle birleştirerek güvenlik problemi arar. Bu yaklaşım kaynak kod bağlamı ile runtime davranışını aynı değerlendirmede buluşturabilir. IAST özellikle kapsamlı integration testleri bulunan uygulamalarda değerli sonuçlar üretebilir. Ancak aracın uygulamaya eklenmesi, performans etkisi ve framework desteği dikkatle değerlendirilmelidir. IAST çoğu ekip için SAST ve DAST'ın yerine değil onların verdiği sinyalleri zenginleştiren ek bir katman olarak düşünülmelidir.

Fuzz Testing

Fuzz testing, uygulamaya beklenmeyen, bozuk veya sınır durumlarını zorlayan girdiler göndererek hatalı davranışları ortaya çıkarmaya çalışır. Parser, protokol, native library ve yoğun input işleyen servisler için özellikle değerlidir. CI/CD içinde kısa fuzz oturumları sık çalıştırılabilir, daha uzun kampanyalar ise scheduled job olarak planlanabilir. Fuzz sonucunda bulunan crash veya timeout durumları otomatik olarak tekrar üretilebilir testlere dönüştürülebilir. Güvenlik açısından yalnızca crash sayısını değil, memory corruption veya yetkisiz davranış gibi etkileri de incelemek gerekir.

SBOM ve Supply Chain Kontrolleri

SBOM, bir build içinde hangi yazılım bileşenlerinin bulunduğunu görünür hale getirir ve supply chain yönetimi için temel veri sağlar. Build sırasında üretilen SBOM'un aynı artifact veya container digest'i ile ilişkilendirilmesi güvenilir izlenebilirlik oluşturur. Yeni bir vulnerability yayınlandığında hangi uygulamaların etkilendiğini hızlı belirlemek için bu envanter kullanılabilir. Supply chain kontrolleri yalnızca dependency taramasıyla sınırlı kalmamalı, artifact provenance ve signing gibi adımları da kapsamalıdır. Böylece yalnızca kullanılan bileşenin güvenliği değil, build'in nerede ve nasıl üretildiği de doğrulanabilir.

SAST Nedir?

SAST, uygulamanın çalıştırılmasına gerek kalmadan kod tabanını güvenlik açısından değerlendiren statik analiz yaklaşımıdır. Araç, kaynak kodda riskli fonksiyon çağrılarını, kontrolsüz veri akışlarını veya güvenli olmayan yapılandırmaları tespit etmeye çalışır. CI/CD içinde en güçlü kullanım alanı pull request veya merge öncesi kontroldür. Çünkü geliştirici bulguyu kendi değişikliğiyle ilişkilendirerek daha hızlı değerlendirebilir. SAST'ın değeri yalnızca bulduğu zafiyet sayısıyla değil, geliştiriciye sunduğu açıklama ve düzeltme bağlamıyla ölçülmelidir.

Static Application Security Testing Nasıl Çalışır?

Static Application Security Testing kaynak dosyalarını, bytecode'u veya oluşturulan ara temsilleri analiz ederek riskli kod yollarını arar. Basit araçlar belirli pattern'leri eşleştirirken daha gelişmiş analizler değişkenlerin kaynak ve hedef arasındaki veri akışını takip edebilir. Örneğin kullanıcıdan gelen bir değerin doğrulanmadan SQL sorgusuna ulaşıp ulaşmadığı incelenebilir. Analizin doğruluğu kullanılan dil parser'ına, framework bilgisinin kalitesine ve rule set'e bağlıdır. Bu nedenle aynı projede farklı scanner'ların birbirinden farklı bulgular üretmesi olağandır.

SAST Hangi Zafiyetleri Bulabilir?

SAST özellikle kaynak kodda gözlemlenebilen input validation, injection, credential ve güvenli olmayan API kullanımı problemlerinde etkilidir. Ancak scanner'ın bir zafiyeti bulabilmesi o dil ve framework için ilgili veri akışını anlayabilmesine bağlıdır. Kod tabanındaki özel helper fonksiyonları veya yoğun metaprogramming bazı analizlerin bağlamı kaçırmasına yol açabilir. Bu nedenle kritik bulgular insan incelemesiyle doğrulanmalıdır. Aşağıdaki kategoriler SAST araçlarının sıklıkla hedeflediği örneklerdir.

SQL Injection

SQL Injection, kullanıcı kontrollü verinin güvenli parametreleme yapılmadan sorguya dahil edilmesiyle oluşabilir. SAST scanner'ı input kaynağından veritabanı sorgusuna uzanan veri akışını takip ederek bu riski gösterebilir. Özellikle string birleştirme ile oluşturulan sorgular güçlü bir uyarı işaretidir. Prepared statement kullanılması ve parametrelerin ayrı aktarılması riski önemli ölçüde azaltır. Scanner bulgusu değerlendirilirken framework'ün otomatik escaping veya parameter binding davranışı da dikkate alınmalıdır.

Cross-Site Scripting

Cross-Site Scripting riski kullanıcıdan gelen içeriğin uygun output encoding yapılmadan HTML veya JavaScript bağlamında gösterilmesiyle ortaya çıkabilir. SAST araçları source-to-sink analiziyle kontrolsüz verinin HTML üretim fonksiyonlarına ulaştığını tespit etmeye çalışır. Modern framework'lerin varsayılan escaping mekanizmaları bazı senaryoları otomatik koruyabilir. Buna rağmen raw HTML özellikleri veya manuel template üretimi korumayı devre dışı bırakabilir. Bulguyu doğrularken verinin hangi output context içinde kullanıldığı mutlaka incelenmelidir.

Command Injection

Command Injection, kullanıcı kontrollü input'un işletim sistemi komutuna dahil edilmesi halinde ciddi sonuçlara yol açabilir. SAST scanner'ları shell execution fonksiyonlarına ulaşan değişkenleri takip ederek bu tür akışları işaretleyebilir. En güvenli yaklaşım mümkün olduğunda shell çağrısını tamamen kaldırmak veya güvenli kütüphane fonksiyonlarını kullanmaktır. Komut çalıştırmak zorunluysa allowlist tabanlı parametre doğrulaması uygulanmalıdır. Yalnızca özel karakterleri filtrelemek çoğu zaman yeterli ve dayanıklı bir savunma değildir.

Path Traversal

Path Traversal, kullanıcı tarafından kontrol edilen dosya yolu değerlerinin uygulamanın izin verilen dizininin dışına erişmesine neden olabilir. Statik analiz path oluşturma fonksiyonlarıyla kullanıcı girdisi arasındaki veri akışını işaretleyebilir. Canonical path kontrolü, sabit base directory ve allowlist yaklaşımı riski azaltmak için kullanılabilir. Dosya indirme veya yükleme endpoint'leri bu açıdan özellikle kontrol edilmelidir. Scanner sonucunda görülen her dosya yolu kullanımı zafiyet değildir, bu nedenle uygulanan doğrulama mekanizması ayrıca incelenmelidir.

Insecure Cryptography

Güvenli olmayan kriptografi kullanımı eski algoritmalar, zayıf key boyutları veya yanlış random number üretimi gibi farklı biçimlerde görülebilir. SAST scanner'ları bilinen riskli API ve algoritma çağrılarını kod üzerinden tespit edebilir. Ancak kriptografik güvenlik yalnızca algoritma adına bağlı değildir, key management ve kullanım modu da önem taşır. Güvenlik kuralı kurumun desteklediği algoritmalar ve platform standartlarıyla uyumlu olmalıdır. Scanner çıktısı böylece yalnızca genel bir uyarı değil uygulanabilir bir kod standardına dönüşür.

Hard-Coded Credentials

Kaynak kod içine gömülen parola, token veya API key hem repository erişimi hem de log ve artifact sızıntıları açısından risk oluşturur. SAST bazı sabit değerleri algılayabilir, ancak bu görev için özel secret scanning araçları genellikle daha geniş pattern ve entropy kontrolleri sunar. Bulunan credential'ın gerçek olup olmadığı kontrol edilmelidir. Gerçek değer kullanılmışsa dosyadan kaldırmanın yanında credential rotation yapılmalıdır. Yeni secret'ların CI/CD secret store veya güvenli vault üzerinden runtime sırasında sağlanması daha doğru bir tasarımdır.

White-Box Testing Nedir?

White-box testing, test yapan tarafın uygulamanın iç yapısına, kaynak koduna veya tasarım bilgisine erişebildiği yaklaşımı ifade eder. SAST bu kategori içinde değerlendirilir çünkü kodun içindeki veri akışlarını doğrudan analiz eder. Bu görünürlük çalışmayan kod yollarının bile incelenebilmesini sağlar. Buna karşılık gerçek deployment davranışı veya dış sistemlerin etkisi statik analizde tam olarak görülemeyebilir. Bu nedenle white-box yaklaşımını black-box testlerle desteklemek daha dengeli sonuç verir.

SAST Kaynak Koda İhtiyaç Duyar mı?

Birçok SAST aracı doğrudan kaynak kod üzerinde çalışır, ancak bazı ürünler bytecode veya derleme çıktısını da analiz edebilir. Temel ihtiyaç uygulamanın iç yapısını değerlendirebilecek statik bir temsilin bulunmasıdır. Kaynak kod erişimi olduğunda scanner'ın geliştiriciye dosya ve satır seviyesinde geri bildirim vermesi kolaylaşır. Kapalı kaynak üçüncü taraf bileşenlerde ise SAST yerine SCA, binary analysis veya runtime test yaklaşımları gerekebilir. Pipeline tasarımında aracın hangi artifact'e ihtiyaç duyduğu önceden belirlenmelidir.

SAST'ın Avantajları

SAST'ın en önemli avantajı geliştiriciye çok erken aşamada geri bildirim verebilmesidir. Uygulama deploy edilmeden çalışabildiği için pull request üzerinde hızlı kontrol yapılabilir. Bazı scanner'lar doğrudan riskli kod satırını, veri akışını ve önerilen düzeltme biçimini gösterebilir. Bu özellik kod review sürecini güvenlik açısından daha verimli hale getirir. Ayrıca aynı rule set'in çok sayıda repository'de otomatik uygulanması kurumsal güvenli kodlama standardının yaygınlaştırılmasını kolaylaştırır.

SAST'ın Sınırlamaları

SAST gerçek çalışma ortamını görmediği için yalnızca runtime sırasında ortaya çıkan problemleri kaçırabilir. Authentication akışları, gerçek HTTP header'ları, reverse proxy ayarları veya deployment kaynaklı sorunlar buna örnektir. Dinamik framework davranışları ve karmaşık veri akışları bazı scanner'ların doğruluğunu düşürebilir. Ayrıca geniş rule set'ler çok sayıda false positive üreterek geliştiricilerin uyarılara duyarsızlaşmasına yol açabilir. Bu nedenle SAST sonuçları DAST ve diğer güvenlik kontrolleriyle birlikte değerlendirilmelidir.

SAST False Positive Problemi

False positive, scanner'ın riskli olduğunu düşündüğü kod yolunun gerçek uygulama bağlamında zafiyet oluşturmaması durumudur. Çok fazla false positive geliştiricilerin güvenlik sonuçlarına güvenini azaltır ve gerçek risklerin fark edilmesini zorlaştırır. Rule tuning, framework-aware analiz ve doğrulanmış suppression kayıtları bu sorunu azaltabilir. Suppression yapılırken neden, onaylayan kişi ve sona erme tarihi kaydedilmelidir. Zaman içinde scanner bazında false positive oranını ölçmek de araç kalitesini ve rule set performansını değerlendirmek açısından önemlidir.

SAST CI/CD Pipeline'ın Hangi Aşamasında Çalıştırılmalıdır?

SAST tek bir pipeline aşamasına sıkıştırılmak yerine farklı hız ve derinlik seviyeleriyle birden fazla noktada kullanılabilir. Geliştiricinin yazdığı anda hızlı feedback alması için IDE veya pre-commit kontrolü, ortak kalite kapısı için pull request taraması ve geniş güvence için nightly full scan uygulanabilir. Her aşamadaki scanner kapsamı aynı olmak zorunda değildir. Hızlı pipeline adımlarında değişen dosyalara veya kritik rule set'lere odaklanmak daha uygundur. Full repository analizi ise zamanlanmış job veya release öncesi kontrol olarak çalıştırılabilir.

IDE Aşaması

IDE entegrasyonu geliştirici kodu yazarken güvenlik uyarısı gösterebildiği için en hızlı geri bildirim kanallarından biridir. Bu aşamada amaç geliştiricinin birkaç saniye içinde düzeltebileceği açık problemleri göstermek olmalıdır. Çok fazla veya düşük güvenilirlikte uyarı IDE deneyimini olumsuz etkileyebilir. Bu nedenle yalnızca yüksek sinyal üreten kuralların etkinleştirilmesi daha yararlıdır. Merkezi pipeline taraması yine de korunmalıdır çünkü yerel eklenti kullanımı her geliştiricide aynı olmayabilir.

Pre-Commit

Pre-commit aşaması kod henüz merkezi repository'ye gönderilmeden hızlı güvenlik kontrolleri çalıştırmak için uygundur. Secret scanning, basit pattern kontrolleri ve changed-file SAST burada kullanılabilir. Kontroller saniyeler içinde sonuç vermelidir, aksi halde geliştiriciler hook mekanizmasını devre dışı bırakmaya yönelebilir. Pre-commit sonuçları yardımcı kontrol olarak görülmeli ve merkezi pipeline'ın yerini almamalıdır. Böylece hem hızlı geri bildirim sağlanır hem de kurumsal doğrulama korunur.

Push

Push sonrasında çalışan CI job'ları geliştiricinin branch'i üzerinde otomatik güvenlik taraması yapabilir. Bu aşama pull request oluşturulmadan önce önemli problemleri fark etmek için kullanışlıdır. Ancak her push'ta tam repository taramak pipeline kaynaklarını gereksiz tüketebilir. Incremental veya changed-file scanning bu noktada daha uygun bir seçenek olabilir. Bulguların geliştiriciye branch veya commit ile ilişkilendirilmiş biçimde sunulması düzeltme süresini kısaltır.

Pull Request

Pull request aşaması SAST için en değerli kontrol noktalarından biridir çünkü değişiklik henüz ana branch'e birleşmemiştir. Scanner yalnızca yeni veya değişen kodu önceliklendirdiğinde sonuçlar review süreciyle doğrudan ilişkilendirilebilir. Yeni critical veya high bulgular merge gate oluşturmak için kullanılabilir. Mevcut security debt'in her pull request'i engellemesi yerine baseline yaklaşımı tercih edilebilir. Bu sayede ekip eski sorunları ayrı backlog'da yönetirken yeni kodun güvenlik seviyesini düşürmesini önleyebilir.

Merge Öncesi

Merge öncesi kontrol, branch protection kuralıyla birlikte uygulanarak belirli güvenlik job'larının başarılı olmasını zorunlu hale getirebilir. Bu aşamada hızlı SAST, SCA, secret ve IaC taramalarının sonuçları birlikte değerlendirilebilir. Gate politikası scanner'ın yalnızca severity değerine değil exploitability ve asset context gibi ek sinyallere de dayanabilir. Risk kabul edilen bulgular için kayıtlı istisna mekanizması bulunmalıdır. Böylece ekip hem otomasyonu korur hem de gerçek iş ihtiyaçlarında kontrollü karar verebilir.

Default Branch

Default branch üzerinde yapılan tarama birleşmiş kod tabanının güncel güvenlik durumunu ölçmek için önemlidir. Pull request taraması bazı build koşullarını veya birleşme sonrası etkileşimleri tam olarak göremeyebilir. Default branch job'ı daha geniş rule set kullanarak bu boşluğu azaltabilir. Sonuçlar merkezi vulnerability dashboard'una aktarılabilir ve repository bazında trend takibi yapılabilir. Bu tarama deployment pipeline'ının başlangıcındaki güvenlik kontrolü olarak da kullanılabilir.

Nightly Full Scan

Nightly full scan, hızlı pull request taramalarında kapsam dışı bırakılan pahalı analizleri çalıştırmak için uygundur. Scanner bütün repository'yi, daha geniş veri akışlarını ve ek kuralları değerlendirebilir. Kod değişmemiş olsa bile scanner engine veya rule database güncellendiğinde yeni bulgular ortaya çıkabilir. Sonuçların geliştirici backlog'una otomatik işlenmesi güvenlik borcunun görünürlüğünü artırır. Nightly tarama pipeline hızını etkilemeden daha derin güvenlik kapsamı sağlar.

Release Öncesi SAST

Release öncesi SAST, yayınlanacak commit veya tag üzerinde son bir doğrulama katmanı oluşturabilir. Burada amaç geliştiricinin her değişikliğini yeniden taramak değil, yayın artifact'inin onaylanan kaynak kodla ilişkilendirildiğini doğrulamaktır. Kritik projelerde full scan sonucu release gate'e dahil edilebilir. Ancak tarama sonucu ilk kez release aşamasında görülmemelidir çünkü düzeltme maliyeti bu noktada daha yüksektir. Release taraması daha önce çalışan kontrollerin tamamlayıcı doğrulaması olarak düşünülmelidir.

Incremental SAST Nedir?

Incremental SAST, her pipeline çalışmasında repository'nin tamamını analiz etmek yerine değişikliğin etkilediği kod alanlarına odaklanan yaklaşımdır. Özellikle büyük monorepo veya uzun full-scan süresine sahip projelerde önemli zaman kazancı sağlayabilir. Bu yaklaşım pull request'teki yeni güvenlik sorunlarını daha hızlı göstermeyi amaçlar. Ancak yalnızca değişen satırlara bakmak bazı çapraz dosya veri akışlarını kaçırabileceği için kullanılan scanner'ın analiz yöntemi önemlidir. Bu nedenle incremental scanning ile periyodik full scanning birlikte kullanılmalıdır.

Tüm Repository Yerine Değişen Kodun Taranması

Değişen kodun taranması, hızlı feedback hedeflenen pull request pipeline'larında oldukça kullanışlıdır. Scanner diff bilgisine göre yeni dosyaları veya değiştirilen fonksiyonları önceliklendirebilir. Böylece geliştirici mevcut binlerce bulgu yerine kendi değişikliğine ait birkaç sonucu görür. Bu yöntem security debt ile yeni risklerin ayrılmasına da yardımcı olur. Bununla birlikte kritik refactor işlemlerinde full scan çalıştırmak daha güvenli olabilir.

Baseline Commit Kullanımı

Baseline commit, scanner'ın hangi noktadan sonra oluşan değişiklikleri yeni bulgu olarak değerlendireceğini belirler. Genellikle pull request branch'i ile hedef branch'in ortak atası referans alınır. Doğru baseline seçilmezse eski bulgular yeniymiş gibi görünebilir veya gerçek yeni bulgular gözden kaçabilir. CI sisteminin merge stratejisi bu nedenle scanner yapılandırmasıyla uyumlu olmalıdır. Baseline yaklaşımı security gate'in yalnızca geliştiricinin değiştirebildiği riskleri engellemesi açısından oldukça etkilidir.

PR Diff Taraması

PR diff taraması güvenlik analizini pull request'teki değişen satırlar ve ilgili kod yollarıyla ilişkilendirir. Sonuçların doğrudan code review ekranında gösterilmesi geliştiricinin bağlamı anlamasını kolaylaştırır. Diff dışındaki eski bulgular ayrı dashboard'da tutulabilir. Böyle bir ayrım, her pull request'te aynı eski güvenlik uyarılarının tekrar görünmesini önler. Security gate yalnızca yeni ve doğrulanmış risklere odaklandığında geliştirici deneyimi belirgin biçimde iyileşir.

Incremental Scan'in Pipeline Süresine Etkisi

Incremental scanning özellikle büyük codebase'lerde analiz süresini dakikalardan saniyelere veya daha kısa dakikalara indirebilir. Ancak gerçek kazanç scanner mimarisine ve değişikliğin büyüklüğüne bağlıdır. Cache kullanımı, worker paralelliği ve dependency graph bilgisinin yeniden kullanılması süreyi daha da azaltabilir. Pipeline metriğinde yalnızca toplam scanner süresi değil geliştiricinin feedback beklediği kritik yol ölçülmelidir. Tarama hızlı ama sonuç üretimi çok geç ise kullanıcı deneyimi yine zayıf kalabilir.

Full Scan Ne Zaman Çalıştırılmalıdır?

Full scan scheduled pipeline, default branch veya release öncesi doğrulama sırasında çalıştırılabilir. Büyük framework güncellemesi, scanner rule değişikliği veya geniş refactor sonrası tam tarama yapmak özellikle değerlidir. Çünkü bu değişiklikler daha önce görünmeyen veri akışlarını veya yeni kural eşleşmelerini ortaya çıkarabilir. Full scan sonucu baseline güvenlik durumunu güncellemek için kullanılabilir. Böylece hızlı incremental taramalar güncel bir referans noktasıyla çalışmaya devam eder.

DAST Nedir?

DAST, çalışan uygulamayı dışarıdan test ederek gözlemlenebilir güvenlik problemlerini bulmaya çalışan dinamik analiz yaklaşımıdır. Scanner HTTP veya API istekleri gönderir, uygulamanın cevaplarını inceler ve belirli saldırı payload'larına karşı davranışını değerlendirir. Kaynak kod gerektirmediği için deployment sırasında oluşan güvenlik hatalarını görebilir. CI/CD içinde en uygun çalışma alanı çoğu zaman staging veya kısa ömürlü preview environment'tır. CI/CD Ortamında Otomatik Güvenlik Taramaları (SAST/DAST) tasarlanırken DAST'ın çalışan bir hedef gerektirdiği mutlaka hesaba katılmalıdır.

Dynamic Application Security Testing Nasıl Çalışır?

DAST scanner hedef uygulamanın URL'lerini keşfeder ve farklı parametrelerle HTTP istekleri üretir. Cevap kodları, response body, header'lar, gecikme davranışı ve hata mesajları analiz edilir. Bazı araçlar aktif saldırı testleri yaparken bazıları yalnızca pasif gözlem modunda çalışabilir. Authentication yapılandırıldığında login arkasındaki endpoint'ler de tarama kapsamına alınabilir. CI/CD ortamında scanner'ın exit code ve machine-readable report üretmesi otomatik gate oluşturmak açısından önemlidir.

Black-Box Testing Nedir?

Black-box testing, uygulamanın iç kod yapısını bilmeden dışarıdan görülebilen davranışlara göre test yapılmasıdır. DAST bu yaklaşımın yaygın bir örneğidir. Bir saldırganın internet üzerinden uygulamayla kurabileceği etkileşimlere benzer testler yapılabilir. Ancak scanner kodun erişemediği dallarını veya hiç çağrılmayan fonksiyonları göremez. Bu nedenle black-box testler kaynak kod analizinin alternatifi değil tamamlayıcısıdır.

DAST Hangi Zafiyetleri Bulabilir?

DAST çalışan sistemde authentication, authorization, injection ve HTTP yapılandırmasıyla ilişkili birçok problemi tespit edebilir. Bulgular uygulamanın gerçek response davranışından geldiği için geliştirici açısından doğrulaması kolay olabilir. Ancak coverage yalnızca scanner'ın erişebildiği endpoint ve kullanıcı rollerine bağlıdır. Login arkasındaki alanlar taranmıyorsa önemli işlevler tamamen kapsam dışında kalabilir. DAST konfigürasyonunda endpoint keşfi ve authentication bu nedenle taramanın kendisi kadar önemlidir.

Authentication problemleri

Authentication problemleri zayıf session yönetimi, beklenmeyen login davranışı veya korumasız endpoint biçiminde görülebilir. DAST scanner farklı kimlik doğrulama durumlarında endpoint cevaplarını karşılaştırabilir. Login sayfası bulunması tek başına bütün uygulamanın korunduğu anlamına gelmez. Özellikle doğrudan URL erişimi ve session sona erme davranışı kontrol edilmelidir. Otomatik testlerde ayrı bir test hesabı kullanmak güvenli ve tekrarlanabilir sonuç sağlar.

Authorization problemleri

Authorization problemi kullanıcı giriş yapmış olsa bile yetkisi olmayan veriye veya işleme erişebilmesi anlamına gelebilir. DAST farklı rol veya kullanıcı hesaplarıyla aynı endpoint'e istek göndererek davranış farklarını inceleyebilir. Object-level authorization testleri özellikle kullanıcıya ait kaynak kimliklerinin URL veya JSON body içinde taşındığı API'lerde önemlidir. Yalnızca 401 veya 403 durum kodu kontrol etmek her zaman yeterli değildir. Response body ve veri bütünlüğü de değerlendirilmelidir.

SQL injection

DAST SQL injection testinde query, form veya API parametrelerine kontrollü payload'lar gönderir ve uygulamanın cevabını analiz eder. Hata mesajı, gecikme veya response farkı backend sorgusunun input'tan etkilenebildiğini gösterebilir. Bu yaklaşım gerçek çalışan uygulama üzerinde kanıt üretmesi açısından güçlüdür. Tarama staging ortamında kontrollü test verileriyle yapılmalıdır. Üretim verisine zarar verebilecek payload'lar production ortamında kullanılmamalıdır.

XSS

DAST XSS ararken uygulamaya gönderilen işaretleyici payload'ın response içinde nasıl işlendiğini kontrol eder. Reflected ve bazı stored XSS senaryoları otomatik testlerle tespit edilebilir. JavaScript ağırlıklı uygulamalarda browser tabanlı scanner desteği coverage açısından önemlidir. Tarayıcı davranışı olmadan yalnızca ham HTTP response kontrol etmek bazı DOM tabanlı sorunları kaçırabilir. Otomatik bulgu yine de manuel doğrulama veya güvenlik regression testiyle desteklenmelidir.

Güvensiz HTTP header'ları

DAST veya pasif web scanner'ları response header'larını analiz ederek eksik güvenlik politikalarını gösterebilir. Content Security Policy, HSTS ve diğer browser güvenlik header'ları bu kapsamda değerlendirilebilir. Ancak eksik bir header her uygulamada aynı risk seviyesine sahip değildir. Uygulamanın internet erişimi, kullanılan içerik modeli ve diğer kontroller birlikte incelenmelidir. Pipeline sonucunu doğrudan kritik kabul etmek yerine kuruma uygun bir baseline policy tanımlamak daha doğrudur.

TLS ve deployment hataları

Çalışan ortam üzerinde TLS protokolü, sertifika yapılandırması ve yönlendirme davranışları kontrol edilebilir. Bu tür problemler kaynak kodda hiç bulunmayabilir çünkü yük dengeleyici veya reverse proxy seviyesinde oluşabilir. DAST ve ek network testleri bu nedenle deployment güvenliğini değerlendirmede yararlıdır. Staging ortamının production ile benzer TLS ve proxy yapılandırmasına sahip olması testin değerini artırır. Tamamen farklı altyapılar kullanılıyorsa staging sonucu production davranışını temsil etmeyebilir.

Runtime configuration problemleri

Debug modu, ayrıntılı hata mesajları ve yanlış güvenlik header'ları gibi runtime problemleri DAST sırasında fark edilebilir. Bu ayarlar kod repository'sinde güvenli görünse bile deployment değişkenleri nedeniyle canlı ortamda farklılaşabilir. Scanner'ın gerçek staging endpoint'ine bağlanması bu nedenle önemlidir. Bulgular environment configuration repository'si veya deployment manifest'iyle ilişkilendirildiğinde düzeltme daha hızlı yapılabilir. Aynı problemin tekrarını önlemek için uygun IaC veya policy-as-code kuralı da eklenebilir.

DAST'ın Avantajları

DAST'ın önemli avantajı gerçek çalışan uygulamanın dışarıdan gözlemlenebilir güvenlik davranışını test etmesidir. Kaynak kod erişimine ihtiyaç duymadığı için farklı teknoloji yığınlarında ortak kontrol olarak kullanılabilir. Deployment veya reverse proxy kaynaklı problemleri görebilmesi SAST'a göre farklı bir görünürlük sağlar. Doğrulanmış bulgular çoğu zaman geliştiriciye net HTTP request ve response kanıtı sunabilir. Ayrıca staging ortamında tekrarlanan testler güvenlik regression kontrolü olarak değerlendirilebilir.

DAST'ın Sınırlamaları

DAST yalnızca ulaşabildiği sayfaları ve endpoint'leri test edebilir. Authentication yanlış yapılandırıldığında uygulamanın önemli bölümü tarama dışında kalabilir. Derin aktif taramalar uzun sürebilir ve test ortamında yük oluşturabilir. Scanner kaynak kodu görmediği için bulgunun hangi kod satırından kaynaklandığını doğrudan söylemeyebilir. Bu sınırlamalar SAST, API testleri ve manuel güvenlik değerlendirmeleriyle tamamlanmalıdır.

DAST Pipeline'ın Hangi Aşamasında Çalıştırılmalıdır?

DAST için çalışan bir uygulama gerektiğinden pipeline sıralaması SAST'a göre farklıdır. Uygulama build edildikten ve test edilebilir ortama deploy edildikten sonra tarama başlatılmalıdır. Preview environment veya staging bu amaç için en sık kullanılan hedeflerdir. Kısa passive scan pull request akışında çalıştırılabilirken deep scan nightly job olarak planlanabilir. Release gate yalnızca gerçek risk üreten ve doğruluğu yüksek DAST bulgularına dayanmalıdır.

Build Sonrası mı?

Build tamamlanması DAST için tek başına yeterli değildir çünkü scanner'ın erişebileceği çalışan bir servis gerekir. Container veya artifact oluşturulduktan sonra uygulama geçici bir ortama deploy edilmelidir. Bu ortamda network, database ve authentication gibi temel bağımlılıkların çalışması gerekir. Build sonrası doğrudan local container başlatıp tarama yapmak küçük servislerde pratik bir yöntem olabilir. Daha karmaşık sistemlerde staging veya preview environment daha gerçekçi sonuç sağlar.

Staging Deployment Sonrası

Staging deployment sonrası DAST birçok ekip için en dengeli uygulamadır. Ortam production'a benzer davranış sunarken test verisi ve güvenli kullanıcı hesaplarıyla çalıştırılabilir. Aktif scanner'ın veri değiştiren request'leri bu ortamda daha rahat kontrol edilebilir. Tarama başarısız olduğunda deployment production'a ilerlemeden durdurulabilir. Staging yapısının production'dan çok farklı olmaması sonuçların güvenilirliği açısından önemlidir.

Preview Environment Üzerinde DAST

Her pull request için oluşturulan preview environment, değişiklik özelinde DAST çalıştırmak için güçlü bir yöntemdir. Scanner yalnızca ilgili branch'in çalışan sürümünü test eder. Tarama tamamlandıktan sonra ortam otomatik silinebilir ve böylece kalıcı altyapı maliyeti azaltılabilir. Preview URL'sinin scanner job'ına güvenli biçimde aktarılması gerekir. Authentication ve test data hazırlığı otomatikleştirildiğinde bu yaklaşım geliştiriciye oldukça hızlı dinamik güvenlik geri bildirimi sağlar.

Pre-Production DAST

Pre-production DAST release candidate build'in production'a en yakın yapılandırmada değerlendirilmesini sağlar. Bu aşamada daha geniş endpoint kapsamı ve daha derin aktif test profili kullanılabilir. Kritik authentication ve authorization senaryoları özel test hesaplarıyla tekrar doğrulanmalıdır. Tarama raporu release approval sürecine girdi sağlayabilir. Ancak güvenlik testlerinin ilk kez burada çalışması yerine daha erken pipeline aşamalarında da feedback verilmesi gerekir.

Release Gate

DAST bulguları release gate oluşturmak için kullanılabilir ancak her uyarı deployment'ı durdurmamalıdır. Yüksek güvenilirlikteki kritik injection veya authorization bulguları engelleyici kural için iyi adaylardır. Scanner'ın düşük güvenilirlikli bilgi seviyesindeki uyarıları ise advisory olarak gösterilebilir. İstisna verilen bulguların süresi ve gerekçesi kaydedilmelidir. Gate politikası zamanla false positive ve incident verilerine göre güncellenmelidir.

Nightly DAST

Nightly DAST günlük pipeline'ın süre sınırına sığmayan geniş testleri çalıştırmak için uygundur. Scanner daha fazla endpoint keşfedebilir ve daha kapsamlı aktif payload seti kullanabilir. Sonuçlar doğrudan merge'i engellemek yerine vulnerability management sistemine aktarılabilir. Yeni critical bulgu bulunduğunda ilgili ekip otomatik olarak bilgilendirilebilir. Böylece hızlı delivery pipeline korunurken derin dinamik test kapsamı da sürdürülebilir.

Production DAST Ne Zaman Uygundur?

Production DAST yalnızca tarama profili güvenli, kontrollü ve operasyon ekibi tarafından onaylı olduğunda uygulanmalıdır. Veri değiştiren veya yoğun yük oluşturan aktif payload'lar production ortamında risklidir. Pasif kontrol, güvenli endpoint doğrulaması veya özel safe-scan policy daha uygun seçeneklerdir. Test hesabının yetkileri sınırlı olmalı ve gerçek kullanıcı verisine erişmemelidir. Production taraması staging testinin yerine değil, runtime güvenlik görünürlüğünü tamamlayan sınırlı bir kontrol olarak düşünülmelidir.

Staging ve Production DAST Arasındaki Fark

Staging ve production DAST arasındaki temel fark operasyonel risk seviyesidir. Staging ortamında test verisi kullanılabildiği için aktif taramalar daha rahat çalıştırılabilir. Production ortamında ise yanlış bir request gerçek veriyi değiştirebilir veya servisi etkileyebilir. Bu nedenle aynı scanner profili iki ortama doğrudan uygulanmamalıdır. Production için daha dar kapsamlı ve güvenli request politikası oluşturulması gerekir.

Staging Neden Tercih Edilir?

Staging ortamı DAST için production'a benzer uygulama davranışını daha düşük iş riskiyle test etme fırsatı sunar. Test hesapları, sentetik veriler ve kontrollü reset işlemleri burada daha kolay uygulanabilir. Aktif scanner payload'ları veri değiştirse bile ortam yeniden oluşturulabilir. Ayrıca güvenlik ekibi scanner ayarlarını production etkisi oluşturmadan deneyebilir. Staging'in değeri production'a teknik olarak benzediği ölçüde artar.

Production Tarama Riskleri

Production taraması gerçek kullanıcı trafiği ve verisiyle aynı ortamda çalıştığı için dikkatli planlanmalıdır. Otomatik scanner bir formu doldurabilir, kayıt oluşturabilir veya beklenmeyen sayıda request gönderebilir. Uygulama bu trafiği gerçek kullanıcı davranışı olarak işleyebilir. Bu nedenle production taramasında passive veya safe mode seçenekleri önceliklendirilmelidir. Operasyon ekibinin gözlemleme ve gerektiğinde taramayı durdurma imkanı bulunmalıdır.

Veri değiştiren request'ler

POST, PUT, PATCH ve DELETE gibi request'ler production verisini değiştirebilir. Scanner'ın form keşfi sırasında oluşturduğu değerler gerçek kayıtlarla karışabilir. Güvenli production profilinde mümkün olduğunda yalnızca read-only endpoint'ler taranmalıdır. Veri değiştiren test zorunluysa özel tenant veya izole test hesabı kullanılabilir. Tarama sonrasında oluşan test verisinin temizlenmesi de otomatik sürecin parçası olmalıdır.

Servis kesintisi

Yoğun aktif DAST taraması kısa sürede yüksek miktarda request üretebilir. Uygulamanın kapasitesi düşükse bu trafik performans sorununa veya kesintiye yol açabilir. Concurrency ve request rate production için sınırlanmalıdır. Monitoring sistemi scanner trafiğinin etkisini ayrı biçimde izleyebilmelidir. Herhangi bir hata oranı artışı görüldüğünde taramayı durduracak operasyon prosedürü bulunması yararlıdır.

Rate limit

Production endpoint'lerinde rate limit kuralları scanner'ın kısa sürede engellenmesine neden olabilir. Bu durum tarama kapsamının yanlışlıkla düşük görünmesine yol açabilir. Scanner için ayrı ve kontrollü bir test kimliği kullanılabilir ancak bu kimliğe sınırsız erişim vermek doğru değildir. Gerçek rate limit davranışı ayrıca güvenlik testinin bir parçası olarak değerlendirilmelidir. Tarama hızının uygulama kapasitesi ve operasyon politikasıyla uyumlu olması gerekir.

Gerçek kullanıcı verileri

Production DAST gerçek kullanıcı verilerine istemeden erişme riski taşıyabilir. Scanner raporları response body veya request detaylarını kaydediyorsa hassas bilgiler güvenlik aracına taşınabilir. Log ve rapor sanitization politikası bu nedenle önemlidir. Test hesabının gerçek müşteri kayıtlarına erişimi mümkün olduğunca kapatılmalıdır. Veri koruma gereksinimleri scanner konfigürasyonunun ayrılmaz bir parçası olarak ele alınmalıdır.

Production İçin Safe Scan Policy

Safe scan policy production ortamında hangi endpoint, HTTP method ve payload türlerinin kullanılabileceğini açıkça tanımlar. Read-only request'ler varsayılan seçim olabilir. Destructive test kategorileri devre dışı bırakılmalı ve request rate sınırlanmalıdır. Policy scanner konfigürasyonuyla kod olarak yönetilirse değişiklikler review sürecinden geçirilebilir. Bu yaklaşım production güvenlik testlerini daha öngörülebilir hale getirir.

Read-Only Test Account Kullanımı

Read-only test account production DAST sırasında yanlışlıkla veri değiştirme riskini azaltabilir. Hesap yalnızca taranması gereken sayfa ve endpoint'lere minimum izinle erişmelidir. Gerçek kullanıcı rolünü tam olarak temsil etmese bile güvenli baseline taraması için yararlıdır. Authorization testleri gerekiyorsa ayrı roller için kontrollü hesap setleri kullanılabilir. Hesap credential'ları secret store içinde tutulmalı ve düzenli olarak yenilenmelidir.

Maintenance Window

Maintenance window daha riskli veya daha yoğun güvenlik testlerini düşük trafik döneminde çalıştırmak için kullanılabilir. Ancak düşük trafik zamanı testin otomatik olarak güvenli olduğu anlamına gelmez. Rate limit, monitoring ve rollback prosedürleri yine korunmalıdır. Operasyon ekibi tarama zamanını ve beklenen trafiği önceden bilmelidir. Sonuçlar gerçek kullanıcı etkisiyle birlikte değerlendirilerek gelecekteki tarama profili ayarlanabilir.

Authenticated DAST Nasıl Yapılır?

Authenticated DAST, login arkasındaki uygulama alanlarını tarayarak anonymous taramaya göre çok daha geniş kapsam sağlar. Scanner'ın oturum açabilmesi için form login, API token, cookie veya OAuth/OIDC akışlarından uygun olanı desteklemesi gerekir. Oturum süresi dolduğunda scanner'ın yeniden authentication yapabilmesi önemlidir. Test hesabı gerçek kullanıcı verisine minimum erişime sahip olmalıdır. Farklı rollerin davranışını değerlendirmek için birden fazla kimlik kullanılması authorization testlerinin kalitesini yükseltir.

Login Gerektiren Sayfaların Taranması

Login gerektiren sayfalar anonymous scanner tarafından çoğu zaman keşfedilemez. Scanner'a geçerli authentication akışı öğretildiğinde uygulama içi navigasyon genişler. Başarılı login durumunu belirlemek için belirli cookie, response code veya sayfa elementi kontrol edilebilir. Yanlış yapılandırılmış login script'i taramanın çalışıyor görünmesine rağmen gerçekte login ekranını tekrar tekrar taramasına yol açabilir. Bu nedenle authenticated coverage ayrıca ölçülmelidir.

Session Cookie

Session cookie scanner'a hazır oturum sağlamak için basit bir yöntem olabilir. Ancak cookie kısa sürede sona eriyorsa uzun tarama ortasında authentication kaybolabilir. Pipeline başlangıcında programatik login yaparak güncel cookie üretmek daha dayanıklı bir yaklaşımdır. Cookie değeri loglara yazılmamalı ve job secret olarak işlenmelidir. Scanner sona erdiğinde oturumun geçersiz kılınması da iyi bir güvenlik uygulamasıdır.

API Token

API token özellikle servis odaklı DAST veya API security testing işlemlerinde kolay authentication sağlar. Token yalnızca gerekli endpoint ve yetkilere erişebilecek şekilde sınırlandırılmalıdır. Uzun ömürlü ortak token yerine pipeline sırasında kısa süreli token üretmek tercih edilir. Scanner raporlarında Authorization header'ın maskelenmesi gerekir. Token yenileme ve iptal mekanizması otomatikleştirildiğinde credential yönetimi daha güvenli hale gelir.

OAuth/OIDC

OAuth/OIDC kullanılan sistemlerde scanner'ın token alma ve yenileme akışını desteklemesi gerekir. Client credential, authorization code veya test kullanıcı akışı uygulamanın mimarisine göre seçilebilir. Pipeline için insan etkileşimine ihtiyaç duymayan kontrollü flow tercih edilmelidir. Token scope değerleri yalnızca test için gereken izinlerle sınırlandırılmalıdır. Kimlik sağlayıcı logları da test sırasında beklenmeyen authentication davranışlarını incelemek için kullanılabilir.

Test Service Account

Test service account otomatik scanner'ın kimliğini gerçek kullanıcı hesaplarından ayırır. Bu hesap yalnızca güvenlik testinin gerektirdiği minimum kaynaklara erişmelidir. Ortam bazında ayrı hesap kullanılması staging ve production sınırlarını netleştirir. Credential rotation düzenli yapılmalı ve account activity merkezi log sisteminde izlenmelidir. Güvenlik ekibi scanner'ın yaptığı işlemleri bu kimlik üzerinden kolayca ayırt edebilir.

Session Renewal

Uzun DAST taramalarında session süresinin dolması coverage kaybına neden olabilir. Scanner'ın login akışını tekrar çalıştırması veya refresh token kullanması gerekebilir. Session renewal başarısız olduğunda job'ın sessizce devam etmesi yerine uyarı vermesi daha doğrudur. Aksi halde rapor tarama tamamlanmış gibi görünürken endpoint'lerin büyük bölümü gerçekte test edilmemiş olabilir. Coverage metriği authentication durumuyla birlikte takip edilmelidir.

MFA Gerektiren Sistemler

MFA güvenliği artırır ancak otomatik DAST authentication akışını zorlaştırabilir. Pipeline için MFA'yı tamamen kapatmak genellikle doğru çözüm değildir. Bunun yerine kontrollü service account, workload identity veya test ortamına özel authentication politikası kullanılabilir. İnsan hesabının kalıcı credential'ını scanner'a vermek yerine otomasyon için tasarlanmış kimlik modeli tercih edilmelidir. Production taraması yapılıyorsa kimlik sağlayıcı ve güvenlik ekibi bu modeli birlikte onaylamalıdır.

Yetkili ve Yetkisiz Kullanıcı Senaryoları

Authorization testinin etkili olması için yalnızca tek bir admin hesabıyla tarama yapmak yeterli değildir. Normal kullanıcı, sınırlı rol ve yetkisiz oturum gibi farklı kimliklerle aynı kaynaklara erişim denenmelidir. Response code yanında dönen veri ve uygulanan işlem de karşılaştırılmalıdır. Özellikle API'lerde kullanıcıya ait object ID değerlerinin değiştirilmesi önemli test senaryolarından biridir. Bu kontroller otomatik regression testine dönüştürüldüğünde erişim kontrolü hatalarının tekrar ortaya çıkması zorlaşır.

API Güvenlik Taramaları CI/CD'ye Nasıl Eklenir?

API güvenlik taraması CI/CD'ye eklenirken endpoint keşfi, authentication ve test data hazırlığı birlikte otomatikleştirilmelidir. OpenAPI veya Swagger belgesi varsa scanner endpoint listesini doğrudan bu tanımdan oluşturabilir. GraphQL tarafında schema bilgisi benzer bir başlangıç noktası sağlar. API testleri yalnızca injection payload'larıyla sınırlı kalmamalı, authorization ve object-level access senaryolarını da içermelidir. Integration testlerinden sonra staging deployment üzerinde çalışan güvenlik job'ı bu kontroller için uygun bir konumdur.

REST API DAST

REST API DAST endpoint'lere farklı HTTP method ve parametre kombinasyonlarıyla request gönderir. Scanner status code, response body ve timing değişikliklerini güvenlik sinyali olarak kullanabilir. Authentication header'ları pipeline secret store üzerinden güvenli biçimde sağlanmalıdır. Test sırasında oluşturulan kayıtlar ayrı tenant veya test data alanında tutulmalıdır. Machine-readable rapor çıktısı vulnerability management sistemine aktarılarak sonuçların zaman içinde izlenmesi sağlanabilir.

OpenAPI/Swagger Spesifikasyonundan Tarama

OpenAPI tanımı scanner'a endpoint, parametre tipi ve request body yapısı hakkında güçlü bir başlangıç bilgisi verir. Bu sayede crawler'ın bulamadığı API uçları da doğrudan test edilebilir. Spec'in gerçek deployment ile uyumlu tutulması coverage açısından önemlidir. Pipeline içinde önce spec validation ardından API security scan çalıştırmak iyi bir sıralamadır. Yeni endpoint eklendiğinde güvenlik taraması otomatik olarak kapsamını genişletebilir.

GraphQL Security Testing

GraphQL güvenlik testi klasik REST endpoint taramasından farklı ihtiyaçlara sahiptir. Query depth, field authorization, introspection ve resolver davranışları ayrıca değerlendirilmelidir. Tek endpoint bulunması uygulamanın küçük bir saldırı yüzeyine sahip olduğu anlamına gelmez. Scanner schema üzerinden farklı query kombinasyonları üretebilir. Yetki kontrolleri field ve object seviyesinde tekrar eden güvenlik regression testleriyle desteklenmelidir.

Authentication ve Authorization Testleri

API güvenliğinde authentication kullanıcının kim olduğunu, authorization ise hangi işlemleri yapabileceğini belirler. CI/CD testinde geçerli token, süresi dolmuş token, eksik token ve farklı role sahip token senaryoları birlikte çalıştırılabilir. Yalnızca endpoint'in 200 veya 403 döndürmesine bakmak yeterli olmayabilir. Response içinde hassas veri sızıntısı olup olmadığı da kontrol edilmelidir. Bu senaryolar otomatik test paketine dönüştürüldüğünde her release öncesi tekrar doğrulanabilir.

Object-Level Authorization

Object-level authorization, kullanıcının belirli bir kayda gerçekten erişim hakkı olup olmadığını kontrol eder. API'de müşteri, sipariş, belge veya proje kimliği gibi değerler değiştirildiğinde başka kullanıcıya ait veri dönmemelidir. Test için en az iki farklı kullanıcıya ait kontrollü veri seti oluşturulabilir. Scanner veya custom integration testi kullanıcı A'nın token'ıyla kullanıcı B'nin object ID'sine erişmeyi deneyebilir. Beklenmeyen başarı durumu yüksek öncelikli güvenlik bulgusu olarak ele alınmalıdır.

Rate-Limit Testleri

Rate-limit testleri authentication, password reset ve maliyetli API işlemlerinde abuse riskini değerlendirmek için önemlidir. CI/CD ortamında bu test kontrollü request sayısıyla yapılmalıdır. Amaç sistemi yük altında bırakmak değil beklenen limit politikasının uygulandığını doğrulamaktır. Farklı token veya IP davranışlarının nasıl ele alındığı da test senaryosuna dahil edilebilir. Production yerine staging ortamında çalıştırmak operasyonel riski azaltır.

API Security Regression Testing

Bulunan ve düzeltilen API zafiyetleri tekrar oluşmaması için otomatik regression testine dönüştürülmelidir. Örneğin başka kullanıcıya ait kayda erişim veren endpoint düzeltildiyse bu davranışı tekrar deneyen integration testi yazılabilir. Test her pull request'te çalıştığında aynı hata gelecekte yeniden eklenirse pipeline hızlı biçimde uyarı verir. Bu yöntem scanner'a tamamen bağımlı kalmadan bilinen riskleri koruma altına alır. Güvenlik ekibinin bulguyu kapatırken regression test varlığını kontrol etmesi yararlı bir süreçtir.

SAST ve DAST Arasındaki Fark Nedir?

SAST ve DAST aynı güvenlik problemini farklı gözlem noktalarından ele alır. SAST kaynak kodu analiz ederken DAST çalışan uygulamanın dışarıdan verdiği cevaplara bakar. Bu nedenle ikisinin bulduğu zafiyet türleri ve pipeline içindeki çalışma zamanı farklıdır. SAST daha erken ve hızlı feedback sağlayabilir, DAST ise deployment kaynaklı riskleri gösterebilir. Güçlü bir DevSecOps yaklaşımı bu iki kontrolü birbirinin alternatifi olarak değil tamamlayıcısı olarak kullanır.

White Box vs Black Box

SAST white-box yaklaşımına yakındır çünkü uygulamanın iç kod yapısını analiz eder. DAST ise black-box yaklaşımıyla dışarıdan gözlemlenebilen davranışı test eder. White-box analiz çalışmayan kod yollarını görebilirken runtime yapılandırmasını tam temsil etmeyebilir. Black-box test gerçek response davranışını görür ancak kodun erişilemeyen bölümleri hakkında bilgi sağlayamaz. İki görünümü birleştirmek daha geniş güvenlik kapsamı oluşturur.

Source Code vs Running Application

SAST'ın temel girdisi kaynak kod veya statik build temsilidir. DAST'ın girdisi ise erişilebilir ve çalışan uygulamadır. Bu fark pipeline sıralamasını doğrudan belirler. SAST compile veya deploy öncesinde çalışabilirken DAST genellikle staging deployment sonrasında başlar. Aynı zafiyet iki scanner'da görünse bile verdikleri kanıt ve düzeltme bağlamı farklı olabilir.

Pipeline Aşaması

SAST çoğu zaman pull request, merge ve default branch aşamalarında çalıştırılır. DAST ise çalışan ortam gerektiği için build ve deployment sonrasında konumlandırılır. Hızlı SAST her commit'te çalışabilirken deep DAST nightly job olarak daha uygun olabilir. Release gate iki tarama sonucunu ortak risk politikasında birleştirebilir. Böylece erken kod kontrolü ve geç runtime kontrolü aynı teslimat sürecine bağlanır.

Tarama Hızı

SAST tarama hızı codebase boyutu ve analiz derinliğine bağlı olarak saniyelerden uzun dakikalara değişebilir. Incremental yöntemler pull request taramasını belirgin biçimde hızlandırabilir. DAST ise endpoint sayısı, request sayısı ve authentication akışları nedeniyle daha uzun sürebilir. Tarama süresini yönetmek için kısa smoke security scan ile scheduled deep scan ayrımı yapılabilir. Pipeline kritik yoluna yalnızca hızlı ve yüksek sinyal üreten kontroller eklemek geliştirici deneyimini korur.

False Positive

Hem SAST hem DAST false positive üretebilir ancak nedenleri farklı olabilir. SAST framework sanitization davranışını anlamadığında risk olmayan veri akışını işaretleyebilir. DAST ise response içindeki belirli metni yanlış yorumlayabilir veya test ortamının özel davranışını zafiyet sanabilir. Bulguların doğrulanması ve scanner rule tuning bu nedenle gereklidir. False positive oranını araç ve rule bazında ölçmek uzun vadeli kalite iyileştirmesi sağlar.

Runtime Context

Runtime context açısından DAST daha güçlüdür çünkü gerçek çalışan servis, HTTP header ve deployment davranışını gözlemleyebilir. SAST kodun çalıştırıldığı reverse proxy veya cloud policy gibi dış yapılandırmaları genellikle göremez. Buna karşılık SAST uygulama içinde henüz tetiklenmemiş tehlikeli kod yollarını analiz edebilir. Bu iki perspektif farklı güvenlik sorularına yanıt verir. Pipeline tasarımı da bu farklılığı avantaj olarak kullanmalıdır.

Zafiyet Kapsamı

SAST injection, güvensiz API kullanımı, hard-coded credential ve kod akışı problemlerinde güçlü olabilir. DAST authentication, runtime configuration, HTTP header ve çalışan endpoint üzerindeki injection davranışını görebilir. İki scanner'ın coverage alanları kısmen çakışsa da tamamen aynı değildir. SCA, IaC ve container scan gibi ek kontroller yine gereklidir. Güvenlik kapsamı scanner sayısıyla değil varlık ve risk kategorilerinin ne kadarının ölçüldüğüyle değerlendirilmelidir.

SAST mı DAST mı Kullanılmalı?

Pratik cevap ikisinin de kullanılması gerektiğidir. SAST kodun iç yapısını erken aşamada değerlendirirken DAST çalışan uygulamadaki davranışı kontrol eder. Yalnızca birini seçmek saldırı yüzeyinin önemli bölümünü görünmez bırakabilir. Küçük ekipler önce hızlı SAST ve staging DAST ile başlayıp zaman içinde kapsamı genişletebilir. Buradaki hedef araç sayısını artırmak değil riskleri farklı katmanlarda yakalayan dengeli bir kontrol sistemi kurmaktır.

Neden Tek Bir Scanner Yeterli Değildir?

Her scanner belirli veri kaynaklarına ve analiz yöntemine bağlıdır. Kaynak kodu gören araç deployment sorununu, web endpoint'ini tarayan araç repository history içindeki secret'ı göremeyebilir. Dependency CVE'si için SCA, cloud yapılandırması için IaC taraması gerekir. Bu nedenle tek scanner kullanmak güvenliğin yalnızca bir bölümünü ölçer. Defense-in-depth yaklaşımı farklı kontrol noktalarının birbirinin boşluğunu tamamlamasını sağlar.

SAST'ın Bulduğu, DAST'ın Bulamadığı Problemler

SAST henüz çalıştırılmayan kod yollarındaki tehlikeli API kullanımını görebilir. Hard-coded secret, riskli kriptografi çağrısı veya belirli command execution path'leri buna örnektir. DAST endpoint'ten erişemediği bir kodu doğal olarak test edemez. Ayrıca SAST geliştiriciye doğrudan dosya ve satır bağlamı verebilir. Bu özellik hızlı remediation açısından önemli bir avantajdır.

DAST'ın Bulduğu, SAST'ın Bulamadığı Problemler

DAST reverse proxy, deployment ve runtime config nedeniyle oluşan problemleri gösterebilir. Eksik güvenlik header'ı, yanlış TLS davranışı veya staging ortamında devre dışı kalmış authentication buna örnek olabilir. Kaynak kod doğru olsa bile environment variable veya ingress ayarı canlı davranışı değiştirebilir. DAST gerçek endpoint'e istek gönderdiği için bu sonucu doğrudan gözlemleyebilir. Bu nedenle release öncesi dinamik kontrol güçlü bir tamamlayıcıdır.

Defense-in-Depth Yaklaşımı

Defense-in-depth güvenliği tek bir önleme bağlamak yerine birden fazla kontrol katmanı oluşturmaktır. Geliştirici seviyesinde secure coding ve IDE kontrolü, pipeline'da SAST ve SCA, build sonrasında container taraması, staging'de DAST uygulanabilir. Production tarafında monitoring ve yeniden tarama süreci bu zinciri devam ettirir. Bir kontrol belirli riski kaçırsa bile başka bir katmanın yakalama olasılığı yükselir. CI/CD güvenlik mimarisi de bu mantıkla tasarlanmalıdır.

SCA Nedir?

SCA, uygulamada kullanılan üçüncü taraf paketlerin güvenlik ve lisans durumunu değerlendiren analiz yaklaşımıdır. Modern uygulamalarda yüzlerce doğrudan ve dolaylı dependency bulunabildiği için bu kontrol büyük önem taşır. Scanner package manifest ve lock dosyalarını analiz ederek kullanılan sürümleri vulnerability kaynaklarıyla karşılaştırır. İdeal durumda yalnızca CVE göstermekle kalmaz, düzeltme sürümünü ve dependency path bilgisini de sunar. SCA kod değişikliğinin yanında sürekli monitoring süreciyle de desteklenmelidir.

Software Composition Analysis Nasıl Çalışır?

SCA aracı package manifest, lock file veya build artifact içindeki bileşenleri belirler. Bulunan paket adı ve sürümü bilinen vulnerability kayıtlarıyla eşleştirilir. Bazı araçlar dependency'nin uygulamada gerçekten kullanılıp kullanılmadığına dair ek sinyaller sağlayabilir. Lisans bilgisi ve package provenance gibi supply chain verileri de rapora eklenebilir. Pipeline gate için yalnızca CVE sayısı yerine exploitability ve kullanılan sürüm bağlamı değerlendirilmelidir.

Direct Dependency

Direct dependency geliştiricinin proje manifest'ine doğrudan eklediği kütüphanedir. Bu paketlerin sürüm yönetimi ekip tarafından daha kolay kontrol edilir. Scanner bulgusu geldiğinde package version artırılarak düzeltme yapılabilir. Ancak major version değişiklikleri uygulama uyumluluğunu etkileyebileceği için otomatik update her zaman yeterli değildir. Dependency sahipliği ve upgrade süreci ekip içinde açık biçimde tanımlanmalıdır.

Transitive Dependency

Transitive dependency, doğrudan kullanılan bir paketin kendi bağımlılığı olarak projeye gelir. Geliştirici bu paketi manifest'e açıkça eklememiş olabilir. Buna rağmen runtime artifact içinde bulunduğu için güvenlik riski oluşturabilir. Scanner dependency tree üzerinden hangi üst paketin sorunlu bileşeni getirdiğini göstermelidir. Düzeltme bazen üst dependency'yi güncellemek veya override mekanizması kullanmakla mümkün olur.

CVE Taraması

CVE taraması kullanılan paket sürümünü bilinen güvenlik kayıtlarıyla karşılaştırır. CVSS skoru önemli bir sinyal olsa da risk kararını tek başına vermemelidir. Paket uygulamada yalnızca build-time kullanılıyor olabilir veya vulnerable fonksiyona hiç erişilmiyor olabilir. Buna karşılık internet-facing bir servis içinde aktif exploit bulunan orta skorlu bir CVE daha acil olabilir. Bu nedenle vulnerability bilgisi uygulama bağlamıyla birlikte değerlendirilmelidir.

Dependency License Kontrolü

SCA araçları güvenlik zafiyetlerinin yanında dependency lisanslarını da envantere ekleyebilir. Kurumun kabul ettiği veya kısıtladığı lisans türleri policy olarak tanımlanabilir. Yeni package eklendiğinde pipeline bu policy'ye göre uyarı verebilir. Lisans kararı hukuki değerlendirme gerektirebileceği için scanner sonucu tek başına nihai karar değildir. Ancak otomatik envanter ekiplerin sonradan sürpriz yaşamamasına yardımcı olur.

SCA Pipeline'ın Neresinde Çalıştırılmalıdır?

SCA pull request aşamasında dependency değişikliğini hızlı kontrol etmek için çalıştırılabilir. Build aşamasında gerçek resolved dependency listesi üzerinden ikinci bir kontrol yapılması daha doğru sonuç verebilir. Container üretildiyse image içindeki application dependency'leri ayrıca taranmalıdır. Release gate yeni critical veya bilinen exploit bulunan dependency sorunlarını engelleyebilir. Scheduled taramalar ise kod değişmeden ortaya çıkan yeni CVE'leri yakalamak için gereklidir.

Sürekli Dependency Monitoring

Dependency riski yalnızca package eklendiği anda oluşmaz. Bugün güvenli görünen bir sürüm için haftalar sonra yeni vulnerability yayınlanabilir. Bu nedenle eski build ve aktif production sürümleri düzenli olarak yeniden değerlendirilmelidir. SBOM ve deployment envanteri hangi uygulamanın hangi paketi kullandığını belirlemeyi kolaylaştırır. Monitoring sonucu kritik yeni CVE bulunduğunda ilgili repository ve servis sahibi otomatik bilgilendirilebilir.

SAST ile SCA Arasındaki Fark

SAST uygulamanın ekip tarafından yazılan kodunu analiz ederken SCA üçüncü taraf bileşenlerin bilinen güvenlik durumuna odaklanır. Bir uygulama kendi kodunda güvenli olabilir ancak vulnerable dependency kullanabilir. Tersi durumda bütün paketler güncel olsa bile uygulama kodunda SQL injection bulunabilir. Bu nedenle iki yaklaşım farklı risk kaynaklarını ele alır. CI/CD pipeline içinde ikisinin de erken aşamada çalıştırılması daha dengeli sonuç verir.

Uygulama Kodu

SAST kaynak kodun iş mantığını, veri akışını ve tehlikeli API kullanımını analiz eder. Geliştiricinin yazdığı yeni fonksiyon veya endpoint doğrudan tarama kapsamına girebilir. Scanner riskli satırı ve code path'i gösterebilir. SCA ise bu özel iş mantığını anlamaya çalışmaz. Bu ayrım araçların neden birlikte gerekli olduğunu açıkça gösterir.

Üçüncü Taraf Kütüphaneler

SCA package ecosystem üzerinden gelen bileşenleri envantere alır. Bu bileşenler uygulamanın kod tabanında kaynak olarak görünmeyebilir. Buna rağmen build çıktısında veya container image içinde bulunabilirler. Bilinen CVE ve lisans sorunları SCA verisi üzerinden daha doğru izlenir. SAST ise dependency'nin kendi iç kodunu çoğu projede kapsamlı biçimde analiz etmez.

Bilinen CVE vs Kod Akışı Zafiyeti

SCA çoğunlukla bilinen package sürümü ile CVE eşleştirmesi yapar. SAST ise uygulamaya özgü kod akışı problemlerini bulmaya çalışır. CVE bulunmaması uygulama kodunun güvenli olduğu anlamına gelmez. Benzer biçimde temiz bir SAST sonucu vulnerable dependency bulunmadığını kanıtlamaz. Güvenlik gate'i bu farklı sinyalleri ayrı kategoriler halinde değerlendirmelidir.

Neden İkisi Birlikte Kullanılmalıdır?

Modern uygulama hem özel koddan hem de büyük miktarda üçüncü taraf bileşenden oluşur. Yalnızca bir tarafı kontrol etmek eksik güvenlik görünümü oluşturur. SAST geliştiricinin yazdığı kodu, SCA ise dependency zincirini değerlendirir. İki tarama aynı pull request içinde paralel çalıştırılarak pipeline süresi düşük tutulabilir. Sonuçlar ortak vulnerability dashboard'unda normalize edildiğinde ekip tek yerden risk yönetebilir.

SBOM Nedir?

SBOM, bir yazılım artifact'inin içinde bulunan bileşenleri ve sürümleri kayıt altına alan Software Bill of Materials belgesidir. Bu envanter güvenlik olaylarında hangi sistemlerin belirli bir dependency'den etkilendiğini hızlı belirlemek için çok değerlidir. SBOM build sırasında oluşturulduğunda gerçek artifact ile daha güvenilir biçimde eşleştirilebilir. Format olarak CycloneDX ve SPDX yaygın seçeneklerdir. SBOM tek başına güvenlik sağlamaz ancak vulnerability monitoring ve supply chain görünürlüğü için güçlü bir temel oluşturur.

Software Bill of Materials Neden Gereklidir?

Bir güvenlik açığı yayınlandığında ilk soru genellikle hangi uygulamaların ilgili bileşeni kullandığıdır. Güncel bileşen envanteri yoksa bu sorunun cevabı repository'leri tek tek incelemeyi gerektirebilir. SBOM merkezi ve sorgulanabilir bir yazılım içeriği kaydı sağlar. Artifact digest ile ilişkilendirildiğinde hangi production build'in hangi dependency'leri içerdiği görülebilir. Incident response ve vulnerability management bu sayede daha hızlı ilerler.

CycloneDX

CycloneDX özellikle application security ve supply chain kullanım senaryoları için yaygın bir SBOM formatıdır. Paket, sürüm, ilişki ve ek güvenlik metadata'sı taşıyabilir. Birçok scanner ve dependency aracı CycloneDX çıktısı üretebilir veya okuyabilir. CI/CD içinde JSON formatında üretilip artifact olarak saklanması pratik bir yöntemdir. Merkezi dependency platformu bu dosyaları ingestion ederek sürekli risk değerlendirmesi yapabilir.

SPDX

SPDX yazılım bileşenleri, lisans bilgileri ve ilişkileri ifade etmek için kullanılan standart formatlardan biridir. Supply chain envanteri oluştururken farklı araçlar arasında veri alışverişini kolaylaştırabilir. Build pipeline SPDX çıktısını release artifact'iyle birlikte saklayabilir. Format seçimi kurumun kullandığı security tooling ve compliance gereksinimlerine göre yapılmalıdır. Asıl önemli nokta SBOM'un güncel build'i doğru temsil etmesidir.

Build Aşamasında SBOM Üretme

SBOM build aşamasında üretilirse gerçek resolved dependency ve image içeriğine daha yakın veri elde edilir. Yalnızca repository manifest'inden SBOM oluşturmak bazı runtime bileşenleri kaçırabilir. Container build sonrasında image üzerinden ek SBOM üretmek bu farkı azaltabilir. Pipeline çıktı dosyasını build ID ve commit SHA ile etiketlemelidir. Böylece daha sonra belirli release'in bileşen içeriği kolayca doğrulanabilir.

SBOM'u Artifact ile Eşleştirme

SBOM'un değeri hangi artifact'i temsil ettiğinin kesin olarak bilinmesine bağlıdır. Container digest, package hash veya release ID bu ilişkiyi kurmak için kullanılabilir. Aynı commit farklı build ortamlarında farklı dependency çözümleyebileceği için yalnızca commit SHA her zaman yeterli değildir. SBOM build sonucuyla birlikte imzalanabilir veya provenance kaydına eklenebilir. Bu yaklaşım supply chain audit sırasında daha güvenilir kanıt sağlar.

Yeni CVE Çıktığında Eski Build'leri Yeniden Değerlendirme

Yeni CVE yayınlandığında repository kodunda hiçbir değişiklik olmayabilir. Buna rağmen production'da çalışan eski build ilgili vulnerable bileşeni içerebilir. Merkezi SBOM envanteri hangi artifact'lerin etkilendiğini sorgulamayı kolaylaştırır. Güvenlik ekibi böylece bütün repository'leri yeniden build etmek yerine aktif deployment'ları önceliklendirebilir. Bu model vulnerability response süresini belirgin biçimde kısaltır.

Secret Scanning Nedir?

Secret scanning kod, commit history ve pipeline çıktıları içinde credential olabilecek değerleri tespit etmeye çalışır. API key, parola, cloud credential, private key ve database connection string yaygın örneklerdir. Kontrol pre-commit seviyesinde başladığında geliştiricinin hatayı repository'ye göndermeden fark etmesini sağlar. Merkezi CI taraması ise yerel kontrolü atlayan durumları yakalar. Gerçek secret tespit edildiğinde rotation ve incident değerlendirmesi sürecin ayrılmaz parçasıdır.

API Key

API key uygulamaların harici servislerle iletişiminde sık kullanılır ve yanlışlıkla kaynak koda eklenebilir. Scanner bilinen key prefix'lerini veya yüksek entropy değerlerini kontrol edebilir. Bulgu gerçekse key derhal iptal edilmeli veya yenilenmelidir. Repository'den silmek erişim geçmişini ortadan kaldırmaz. Yeni değer CI secret store üzerinden job sırasında sağlanmalıdır.

Password

Hard-coded password kaynak kod, test fixture veya configuration dosyasında bulunabilir. Bazı test parolaları gerçek credential olmadığı için scanner false positive üretebilir. Buna rağmen production credential ile benzer değerler ayrı ve güvenli secret store içinde tutulmalıdır. Suppression yapılacaksa dosyanın gerçekten test amaçlı olduğu doğrulanmalıdır. Ortak parola pattern'leri zamanla özel kurallarla geliştirilebilir.

Cloud Credential

Cloud access key veya service account credential sızıntısı geniş altyapı erişimine neden olabilir. Bu tür secret'lar bulunduğunda rotation işlemi yüksek öncelikle yapılmalıdır. Uzun ömürlü credential kullanımını azaltmak için workload identity veya OIDC federation tercih edilebilir. Scanner vendor-specific key formatlarını tanıyabilmelidir. Cloud audit logları sızan credential'ın kullanılıp kullanılmadığını değerlendirmek için incelenebilir.

Private Key

Private key dosyaları belirgin PEM başlıkları sayesinde secret scanner tarafından kolayca tespit edilebilir. Ancak key'in test, development veya gerçek production amacıyla kullanıldığı ayrıca doğrulanmalıdır. Gerçek private key repository'ye girdiyse yalnızca dosyayı kaldırmak yeterli değildir. İlgili sertifika veya kimlik doğrulama ilişkisi yeniden oluşturulmalıdır. Yeni key güvenli secret management sistemi üzerinden sağlanmalıdır.

Database Connection String

Database connection string çoğu zaman kullanıcı adı, parola, host ve database adını tek satırda içerir. Bu nedenle repository'de bulunması hem credential hem altyapı bilgisi sızıntısı yaratabilir. Scanner bilinen URI pattern'lerini kontrol ederek bu değerleri yakalayabilir. Connection string environment variable veya secret store üzerinden uygulamaya aktarılmalıdır. Leak yaşandıysa database credential rotation ve erişim log kontrolü yapılmalıdır.

Pre-Commit Secret Scanning

Pre-commit secret scanning geliştiricinin hatalı credential'ı commit etmesini daha ilk aşamada engelleyebilir. Tarama çok hızlı çalışmalıdır ve yalnızca staged dosyalara odaklanabilir. Local hook merkezi policy'nin tek uygulama noktası olmamalıdır çünkü kullanıcı hook'u devre dışı bırakabilir. Aynı kontrol CI pipeline içinde tekrar çalıştırılmalıdır. İyi hata mesajı geliştiriciye hangi dosyada ne bulunduğunu ve nasıl düzeltileceğini açıkça göstermelidir.

Repository History Scanning

Repository history taraması mevcut dosyalarda görünmeyen ancak eski commit'lerde kalan secret'ları bulur. Özellikle uzun ömürlü projelerde yalnızca working tree taramak yeterli olmayabilir. İlk DevSecOps geçişinde full history scan yapmak faydalıdır. Sonrasında yeni commit'ler incremental biçimde kontrol edilebilir. Bulgu gerçekse credential rotation history rewrite işleminden daha öncelikli olmalıdır.

CI/CD Secret Scanning

CI/CD secret scanning her push veya pull request'te merkezi güvenlik kontrolü sağlar. Scanner sonucu branch protection veya security gate'e bağlanabilir. Yeni doğrulanmış secret bulunduğunda merge engellenmesi çoğu ekip için mantıklı bir politikadır. Scanner'ın kendi token ve credential'ları rapor veya log içinde görünmemelidir. Secret masking ve minimum job permission bu nedenle birlikte uygulanmalıdır.

Bir Secret Git'e Commit Edildiyse Silmek Yeterli midir?

Hayır, secret'ın son commit'ten silinmesi tek başına yeterli değildir. Değer eski commit, branch, fork veya CI loglarında kalmış olabilir. En önemli ilk adım credential'ı geçersiz kılmak ve yenisini oluşturmaktır. Daha sonra repository history temizliği ve olay incelemesi yapılabilir. Bu yaklaşım olası erişim riskini en hızlı biçimde sınırlar.

Git History Problemi

Git değişiklik geçmişini sakladığı için dosyadan kaldırılan bir değer önceki commit'lerde bulunmaya devam edebilir. Repository erişimi olan biri eski commit'i görüntüleyerek credential'a ulaşabilir. Public repository durumunda risk daha da yüksektir. History rewrite eski referansları azaltabilir ancak daha önce clone edilmiş kopyaları geri alamaz. Bu yüzden credential rotation her zaman temel güvenlik adımıdır.

Credential Rotation

Credential rotation sızdığı düşünülen secret'ın yenisiyle değiştirilmesidir. Yeni değer üretildikten sonra eski credential derhal devre dışı bırakılmalıdır. Uygulama ve pipeline yeni secret'ı güvenli store üzerinden alacak şekilde güncellenmelidir. Değişikliğin bütün environment'lara yayıldığı kontrol edilmelidir. Rotation prosedürünün önceden otomatikleştirilmiş olması incident sırasında önemli zaman kazandırır.

Secret Revocation

Secret revocation eski credential'ın artık kullanılamamasını sağlar. API provider veya identity sistemi üzerinden token iptal edilebilir. Revocation sonrasında eski token ile test request'i yapılarak gerçekten devre dışı kaldığı doğrulanmalıdır. Audit loglarda eski credential'ın şüpheli kullanımı araştırılabilir. Olay kapanmadan önce bağlı bütün sistemlerde credential referansının kaldırıldığı kontrol edilmelidir.

History Rewrite

History rewrite hassas değeri repository'nin geçmişinden çıkarmaya yardımcı olabilir. Ancak paylaşılan repository'lerde commit hash'leri değişeceği için geliştirici koordinasyonu gerekir. Fork ve clone kopyaları otomatik temizlenmez. Bu nedenle history rewrite güvenlik olayının tek çözümü olarak görülmemelidir. Asıl güvenlik kontrolü sızan credential'ın artık geçerli olmamasıdır.

Incident Investigation

Secret sızıntısı potansiyel güvenlik olayı olarak değerlendirilmelidir. Credential'ın ne zaman commit edildiği, repository'nin kimlere açık olduğu ve herhangi bir kullanım kaydı bulunup bulunmadığı araştırılmalıdır. Cloud veya API audit logları bu incelemede önemli veri sağlar. Etki alanı belirlendikten sonra gerekli credential ve yetkiler yenilenebilir. Olay sonucunda pre-commit ve CI secret scanning kuralları güncellenmelidir.

Infrastructure as Code Security Scanning

Infrastructure as Code security scanning altyapı değişikliklerini deployment öncesinde güvenlik politikalarıyla karşılaştırır. Terraform, CloudFormation, Kubernetes, Helm ve Dockerfile gibi dosyalar statik olarak değerlendirilebilir. Bu kontrol public erişim, geniş network permission ve ayrıcalıklı runtime ayarları gibi riskleri erken gösterir. Pull request içinde çalıştırıldığında geliştirici riskli değişikliği cloud ortamına uygulamadan önce düzeltebilir. Kuruma özel policy'ler zamanla default scanner kurallarının üzerine eklenebilir.

Terraform

Terraform taraması cloud resource tanımlarını deployment öncesinde analiz eder. Public bucket, açık security group veya encryption eksikliği gibi ayarlar policy üzerinden tespit edilebilir. Scanner plan çıktısını da analiz edebiliyorsa gerçek oluşturulacak resource durumuna daha yakın sonuç elde edilir. Pull request annotation geliştiricinin hangi satırın sorunlu olduğunu görmesini kolaylaştırır. Kritik IaC bulguları production deployment gate'ine bağlanabilir.

CloudFormation

CloudFormation template'leri kaynak kod gibi version control altında tutulduğu için otomatik güvenlik taramasına uygundur. IAM permission, storage exposure ve encryption ayarları rule set ile kontrol edilebilir. Template değişikliği merge edilmeden scanner sonucu review ekranına eklenebilir. Kurumun cloud standardına uygun custom policy'ler hazırlanabilir. Böylece yanlış yapılandırma canlı ortama ulaşmadan önce engellenebilir.

Kubernetes YAML

Kubernetes YAML taraması privileged container, hostPath, root user ve eksik securityContext gibi riskleri kontrol edebilir. Resource limit ve network policy gibi operasyonel güvenlik ayarları da policy kapsamına alınabilir. Manifest Helm veya başka template sisteminden üretiliyorsa rendered çıktı üzerinde tarama yapmak daha gerçekçi sonuç sağlar. Deployment öncesi admission policy ile aynı kuralların runtime tarafında tekrar uygulanması güçlü bir modeldir. Pipeline ve cluster politikalarının uyumlu olması beklenmeyen farkları azaltır.

Helm

Helm chart güvenlik taramasında yalnızca template dosyalarına bakmak bazı dinamik değerleri kaçırabilir. Bu nedenle mümkün olduğunda gerçek environment values ile render edilmiş manifest analiz edilmelidir. Production ve staging değerleri farklı riskler üretebilir. Scanner sonucunda bulunan problemi chart template veya values policy seviyesinde düzeltmek daha kalıcıdır. Ortak chart repository'si kullanan ekipler güvenlik kurallarını merkezi template içinde uygulayabilir.

Dockerfile

Dockerfile taraması root user kullanımı, gereksiz package kurulumu ve güvensiz base image tercihleri gibi sorunları gösterebilir. Secret değerlerin ARG veya ENV ile image layer'a yazılması özellikle kontrol edilmelidir. Build sırasında güvenli secret mount mekanizması kullanılabilir. Dockerfile taraması image scan'in yerine geçmez çünkü gerçek image içindeki paket sürümlerini tam olarak temsil etmeyebilir. İki kontrolün birlikte uygulanması daha doğru sonuç verir.

Misconfiguration Detection

Misconfiguration detection altyapı kodundaki güvenli olmayan ayarları policy karşılaştırmasıyla belirler. Scanner'ın default kuralları iyi başlangıç sağlar ancak her kurumun network ve data policy'si farklı olabilir. Bu nedenle gerçek incident ve audit bulgularından yeni kurallar türetmek değerlidir. Bulguların severity seviyesi uygulamanın environment ve asset criticality bilgisiyle zenginleştirilebilir. Böylece development ortamındaki küçük bir ayarla internet-facing production kaynağındaki aynı ayar farklı öncelik alabilir.

Public storage

Public storage yanlış yapılandırıldığında dosyalar internet üzerinden yetkisiz erişime açılabilir. IaC scanner bucket veya storage permission tanımlarını kontrol ederek bu riski deployment öncesi gösterebilir. Public erişim gerçekten iş gereği ise açık risk kabul kaydı oluşturulmalıdır. Sensitive data barındıran kaynaklarda public access varsayılan olarak engellenmelidir. Cloud organization policy ile pipeline kontrolünü birlikte kullanmak daha güçlü koruma sağlar.

Açık security group

Security group veya firewall rule'larında geniş IP aralığına açık yönetim portları ciddi risk oluşturabilir. IaC scanner 0.0.0.0/0 gibi kaynakları belirli portlarla birlikte değerlendirebilir. İnternete açık servis gerekiyorsa yalnızca gerekli application portları izinli olmalıdır. Yönetim erişimi özel ağ veya kimlik tabanlı güvenli mekanizmalar üzerinden sınırlandırılabilir. Pipeline kontrolü yanlış network değişikliğinin uygulanmadan önce fark edilmesini sağlar.

Privileged container

Privileged container host seviyesinde geniş yetkilere erişebildiği için saldırı etkisini büyütebilir. Kubernetes veya container manifest taraması bu ayarı kolayca tespit edebilir. Uygulamanın gerçekten privileged çalışmaya ihtiyacı olup olmadığı sorgulanmalıdır. Çoğu servis minimum capability ve non-root user ile çalışabilir. Gerekli istisna varsa neden ve süre bilgisi policy kaydında tutulmalıdır.

Hard-coded secret

IaC dosyasına yazılan secret repository history içinde kalıcı hale gelebilir. Scanner password, token veya private key pattern'lerini deployment öncesinde işaretleyebilir. Secret değer yerine secret manager reference kullanılması tercih edilmelidir. Gerçek credential commit edilmişse rotation uygulanmalıdır. IaC taraması ile özel secret scanning kontrolünü birlikte çalıştırmak daha geniş coverage sağlar.

Eksik encryption

Storage, database veya message queue kaynaklarında encryption ayarının eksik olması veri koruma politikasını ihlal edebilir. IaC scanner resource configuration üzerinden encryption flag ve key seçimini kontrol edebilir. Sensitive data işleyen sistemlerde müşteri yönetimli key politikaları ayrıca değerlendirilebilir. Encryption sadece at-rest ayarıyla sınırlı değildir, transport security de ayrı kontrol edilmelidir. Kurum standardı policy-as-code biçiminde tanımlandığında bütün repository'lerde tutarlı uygulanabilir.

Container Image Security Scanning

Container image security scanning, build sonucunda oluşan gerçek image içeriğini güvenlik açısından analiz eder. Base image paketleri, işletim sistemi bileşenleri ve uygulama dependency'leri bu kapsamda değerlendirilebilir. Build sırasında secret'ın layer içine yazılıp yazılmadığı da bazı scanner'larla kontrol edilebilir. Image digest sonuçla ilişkilendirildiğinde hangi artifact'in tarandığı açık biçimde görülebilir. Registry tarafında yeniden tarama yapılması yeni CVE'lerin eski image'ları etkilemesini yakalamak için önemlidir.

Base Image Vulnerabilities

Base image uygulamanın container güvenlik seviyesini doğrudan etkiler. Eski veya destek dışı dağıtımlar çok sayıda bilinen CVE içerebilir. Minimal ve düzenli güncellenen base image kullanmak risk ve image boyutunu azaltabilir. Scanner hangi vulnerability'nin base image katmanından geldiğini gösterebilmelidir. Ortak base image platform ekibi tarafından merkezi olarak güncellenirse remediation daha kolay yönetilir.

OS Package CVE'leri

Container içindeki operating system paketleri CVE veritabanlarıyla karşılaştırılabilir. Paket sürümü distribution backport politikaları nedeniyle upstream sürüm numarasından farklı yorumlanabilir. Bu nedenle scanner'ın kullanılan Linux dağıtımını doğru tanıması önemlidir. Fix available bilgisi remediation önceliğini belirlemede yararlı olur. Gereksiz package'ların image'dan çıkarılması saldırı yüzeyini azaltır.

Application Dependency'leri

Container scanner application dependency'lerini de tespit edebiliyorsa build çıktısı üzerinde ikinci SCA katmanı sağlar. Repository manifest'i ile final image içeriği bazen farklı olabilir. Multi-stage build bazı dependency'leri final image'a taşımayabilir. Bu nedenle image taraması production artifact'ini doğrulamak açısından değerlidir. Sonuçlar repository SCA verisiyle deduplicate edilmelidir.

Image Layers

Container image layer'ları silinmiş görünen dosyaların önceki katmanlarda kalmasına neden olabilir. Örneğin build sırasında kopyalanan secret sonraki layer'da silinse bile image history içinde bulunabilir. Scanner layer bazında secret veya hassas dosya kontrolü yapabilir. Multi-stage build bu riski azaltmak için etkili bir yöntemdir. Final image yalnızca runtime için gereken dosyaları içermelidir.

Container Secret Detection

Container secret detection final image içinde yanlışlıkla bırakılmış credential veya key dosyalarını arar. Build argümanı olarak kullanılan secret'ın layer'a yazılması yaygın hatalardan biridir. Güvenli build secret mekanizması değerin filesystem layer'ına kalıcı yazılmasını engeller. Bulgu bulunduğunda image kullanılmamalı ve credential yenilenmelidir. Yeni image temiz build environment içinde tekrar üretilmelidir.

Build Sonrası Image Scan

Image scan build tamamlandıktan hemen sonra çalıştırılırsa production'a gidecek artifact erken değerlendirilir. Scanner digest üzerinden çalışmalı ve sonuç aynı digest ile kayıt altına alınmalıdır. Critical yeni bulgu varsa image registry promotion işlemi durdurulabilir. Tarama job'ı build job'ından paralel downstream adım olarak tasarlanabilir. Sonuçların SBOM ile birlikte saklanması incident response sırasında yararlı olur.

Registry'de Continuous Rescanning

Container image build edildikten sonra vulnerability durumu zaman içinde değişebilir. Yeni CVE çıktığında haftalar önce oluşturulmuş image artık riskli hale gelebilir. Registry veya merkezi scanner düzenli rescanning yaparak bu durumu görünür hale getirir. Aktif deployment'larda kullanılan digest'ler daha yüksek öncelikle değerlendirilmelidir. Kullanılmayan eski image'ların retention policy ile temizlenmesi yönetim yükünü azaltır.

Deploy Öncesi Container Gate

Deployment gate production'a taşınacak container digest'inin kabul edilebilir risk seviyesinde olduğunu kontrol eder. Policy yalnızca CVSS skoruna değil exploit availability ve environment exposure gibi faktörlere de dayanabilir. İstisna verilen image için süre ve owner kaydı bulunmalıdır. Gate image tag yerine immutable digest kullanırsa doğrulanan artifact'in değişmesi önlenir. Signature verification ile birlikte kullanıldığında supply chain güvenliği güçlenir.

CI/CD İçin Örnek Güvenlik Tarama Sırası

Güvenlik kontrollerinin sırası geliştiriciye hızlı feedback verme ve pahalı testleri uygun zamanda çalıştırma hedefiyle oluşturulmalıdır. İlk aşamalarda secret scan, hızlı SAST ve SCA gibi düşük gecikmeli kontroller tercih edilebilir. Build sonrasında SBOM, container scan ve artifact signing devreye girer. Çalışan ortam oluştuğunda DAST ve API security testleri başlatılır. Son adımda risk bazlı gate deployment kararını verir ve production monitoring döngüyü devam ettirir.

1. Developer IDE Kontrolleri

IDE kontrolleri geliştiriciye kod yazarken güvenlik geri bildirimi sağlar. Basit ve yüksek güvenilirlikteki SAST kuralları bu aşamada etkilidir. Amaç geliştiricinin birkaç saniyede düzeltebileceği sorunları erken göstermektir. IDE sonucu merkezi policy'nin yerini almaz. Aynı kontroller pull request pipeline'ında tekrar doğrulanmalıdır.

2. Pre-Commit Secret Scan

Pre-commit secret scan credential'ın merkezi repository'ye ulaşmasını engellemeyi hedefler. Staged dosyalar üzerinde hızlı pattern ve entropy analizi yapılabilir. Bulgu bulunduğunda commit işlemi açıklayıcı mesajla durdurulabilir. Geliştirici gerçek secret ise değeri güvenli store'a taşır. Merkezi CI taraması yine de ikinci güvenlik katmanı olarak korunmalıdır.

3. Pull Request SAST

Pull request SAST değişen kodu güvenlik açısından inceler. Incremental analiz pipeline süresini düşük tutabilir. Sonuçlar doğrudan review ekranına annotation olarak eklenebilir. Yeni critical veya high bulgular merge'i engelleyebilir. Eski security debt baseline dışında ayrı backlog'da yönetilebilir.

4. SCA

SCA dependency değişikliklerini ve bilinen vulnerability durumunu kontrol eder. Pull request içinde manifest ve lock file taraması hızlı sonuç sağlar. Build sonrasında gerçek resolved dependency üzerinde tekrar kontrol yapılabilir. Yeni exploitable critical dependency riski security gate'e dahil edilebilir. Lisans politikaları da aynı süreçte değerlendirilebilir.

5. IaC Scan

IaC scan cloud ve deployment manifest değişikliklerini production'a uygulanmadan önce kontrol eder. Açık network rule, public storage veya privileged container gibi sorunlar tespit edilebilir. Scanner sonucu ilgili satırla birlikte pull request'e eklenebilir. Kurumsal policy'ler kod olarak version control altında yönetilebilir. Riskli infrastructure değişikliği merge edilmeden düzeltilebilir.

6. Unit ve Integration Tests

Unit ve integration testleri temel kalite kontrolünün yanında güvenlik regression testlerini de içerebilir. Daha önce düzeltilen authorization veya validation problemi için test yazılması faydalıdır. Bu testler scanner'dan daha hızlı ve deterministik sonuç verebilir. Güvenlik testleri ayrı klasör veya tag ile yönetilebilir. Pipeline güvenlik kontrolleri uygulama testlerinin yerine değil yanına eklenmelidir.

7. Build

Build aşaması doğrulanmış kaynak koddan dağıtılabilir artifact üretir. Build environment'ın güvenliği supply chain açısından kritik öneme sahiptir. Dependency kaynakları, build runner ve secret erişimleri sınırlandırılmalıdır. Reproducible veya kontrollü build yaklaşımı artifact güvenilirliğini artırır. Çıktı digest veya hash değeriyle tanımlanmalıdır.

8. SBOM Oluşturma

SBOM build sırasında kullanılan bileşenlerin envanterini çıkarır. Dosya artifact digest'i ile ilişkilendirilmelidir. CycloneDX veya SPDX formatı downstream araçlarla uyum için kullanılabilir. SBOM vulnerability monitoring sistemine aktarılabilir. Böylece yeni CVE çıktığında aktif build'ler tekrar değerlendirilebilir.

9. Container Scan

Container scan final image içindeki işletim sistemi ve uygulama bileşenlerini analiz eder. Base image riskleri ve secret kalıntıları da kontrol edilebilir. Tarama sonucu image digest ile eşleştirilmelidir. Kritik yeni vulnerability varsa promotion veya deployment durdurulabilir. Registry rescanning süreci daha sonra aynı image'ı takip etmeye devam eder.

10. Artifact Signing

Artifact signing build çıktısının kimliğini ve bütünlüğünü doğrulamak için kullanılır. İmza güvenilir build süreci tarafından oluşturulmalıdır. Deployment sistemi yalnızca doğrulanmış signature taşıyan artifact'lere izin verebilir. Bu yaklaşım artifact değiştirilmesi riskini azaltır. Provenance kaydıyla birlikte kullanıldığında supply chain izlenebilirliği güçlenir.

11. Staging Deployment

Staging deployment DAST ve integration security testleri için çalışan hedef oluşturur. Ortam production mimarisine mümkün olduğunca yakın olmalıdır. Test verisi ve özel scanner hesapları kullanılabilir. Deployment tamamlandığında health check sonrası security job başlatılabilir. Başarısız staging güvenlik kontrolü production'a geçişi engelleyebilir.

12. DAST

DAST çalışan staging uygulamasına HTTP veya API request'leri gönderir. Authentication yapılandırıldığında login arkasındaki endpoint'ler de kapsama girer. Kısa active scan release pipeline içinde çalıştırılabilir. Daha derin testler scheduled olarak devam edebilir. Sonuçların evidence ve endpoint bilgisiyle vulnerability sistemine aktarılması triage sürecini hızlandırır.

13. Security Gate

Security gate farklı scanner sonuçlarını ortak risk politikasıyla değerlendirir. Her bulgunun build'i durdurması yerine severity, exploitability ve business context birlikte kullanılmalıdır. Yeni critical bulgular genellikle blocking kural için uygun adaylardır. Onaylı exception kayıtları belirli süreyle gate'i geçebilir. Kararın otomatik ve açıklanabilir olması geliştiricinin güvenini artırır.

14. Production Deployment

Production deployment yalnızca onaylanmış ve doğrulanmış artifact'i kullanmalıdır. Image digest veya immutable release ID staging'de test edilen çıktıyla aynı olmalıdır. Deployment sırasında signature ve policy kontrolü tekrar yapılabilir. Environment secret'ları yalnızca production scope ile sınırlandırılmalıdır. Deployment sonucu audit loglara açık biçimde kaydedilmelidir.

15. Continuous Monitoring

Production'a çıktıktan sonra güvenlik süreci sona ermez. Yeni vulnerability, runtime anomalisi veya configuration drift ortaya çıkabilir. Container ve dependency'ler düzenli yeniden taranmalıdır. Incident bulguları yeni SAST, DAST veya regression test kuralına dönüştürülebilir. Böylece production deneyimi yeniden geliştirme pipeline'ını güçlendiren geri bildirim haline gelir.

Security Gate Nedir?

Security gate, pipeline'ın belirli güvenlik koşulları sağlanmadan bir sonraki aşamaya ilerlemesini engelleyen karar mekanizmasıdır. Etkili bir gate yalnızca scanner severity alanına bakmaz. Bulgunun yeni olup olmadığı, internet exposure, exploitability, asset criticality ve veri hassasiyeti birlikte değerlendirilebilir. Çok sert gate geliştiricilerin sistemi atlamasına, çok gevşek gate ise gerçek risklerin production'a ulaşmasına neden olabilir. En iyi yaklaşım önce görünürlük sağlayıp sonra baseline ve risk tabanlı enforcement modeline geçmektir.

Pipeline'ı Hangi Bulgular Durdurmalıdır?

Yeni ve doğrulanmış critical bulgular çoğu sistemde güçlü blocking adayıdır. Authentication bypass, remote code execution veya internet-facing ciddi injection problemleri buna örnek olabilir. High seviyedeki bulgular asset context'e göre değerlendirilmelidir. Mevcut legacy security debt'in her commit'i durdurması yerine new-findings policy uygulanabilir. Gate kriteri güvenlik ekibi ve geliştirme ekipleri tarafından anlaşılabilir şekilde belgelenmelidir.

Severity-Based Gate

Severity-based gate belirli severity seviyesinin üzerindeki bulguları engeller. Uygulaması kolaydır ve scanner'lar arasında ortak başlangıç noktası sağlar. Ancak yalnızca severity kullanmak gerçek iş riskini tam yansıtmayabilir. İnternete kapalı test aracındaki high bulgu ile müşteri verisi işleyen public API'deki aynı skor farklı öncelik taşıyabilir. Bu nedenle severity modeli zamanla risk-based modele genişletilmelidir.

Risk-Based Gate

Risk-based gate teknik severity ile uygulama bağlamını birleştirir. Exploitability, internet exposure, asset criticality, sensitive data ve known exploited vulnerability bilgisi kararın parçası olabilir. Böylece küçük ama kolay sömürülebilir bir risk bazen daha yüksek öncelik alabilir. Policy'nin otomatik hesaplanabilir olması pipeline kullanımını kolaylaştırır. Karar kriterleri geliştiriciye bulguyla birlikte gösterilmelidir.

Advisory Gate

Advisory gate pipeline'ı durdurmadan güvenlik sonucunu görünür hale getirir. DevSecOps programının ilk aşamasında scanner kalitesini ve baseline durumunu anlamak için çok yararlıdır. Ekip false positive'leri temizler ve gerçek risk dağılımını ölçer. Belirli süre sonra yüksek güvenilirlikteki rule'lar blocking moda alınabilir. Bu aşamalı geçiş geliştiricilerin güvenlik kontrollerini benimsemesini kolaylaştırır.

Blocking Gate

Blocking gate koşul sağlanmadığında merge veya deployment'ı durdurur. Yalnızca güvenilir ve iş açısından anlamlı kurallar için kullanılması gerekir. Çok fazla gereksiz blokaj ekiplerin scanner'ı bypass etmesine yol açabilir. Exception mekanizması kontrollü ve süreli olmalıdır. Gate başarısızlığının nedenini açıklayan mesaj düzeltme süresini önemli ölçüde kısaltır.

Manual Approval

Manual approval yüksek riskli veya belirsiz bulgularda insan değerlendirmesi sağlar. Güvenlik veya yetkili teknik ekip scanner evidence'ını, compensating control'leri ve release ihtiyacını inceleyebilir. Approval kaydı audit log içinde tutulmalıdır. Manuel süreç günlük her release için darboğaz haline gelmemelidir. Bu nedenle yalnızca otomatik policy'nin karar veremediği istisnai durumlarda kullanılmalıdır.

Automated Approval

Automated approval policy kurallarına göre release kararını insan müdahalesi olmadan verir. Yeni critical bulgu yoksa, signature geçerliyse ve gerekli scanner'lar tamamlandıysa deployment otomatik ilerleyebilir. Bu model hızlı teslimat yapan ekiplerde önemli operasyonel avantaj sağlar. Policy kod olarak version control altında tutulduğunda değişiklikler review edilebilir. Audit log hangi kuralın neden izin verdiğini göstermelidir.

CVSS Tek Başına Security Gate İçin Yeterli midir?

CVSS teknik severity hakkında yararlı bir standart sinyal sağlar ancak tek başına deployment kararı için yeterli değildir. Gerçek risk zafiyetin uygulanabilirliği, sistemin internet exposure seviyesi ve iş değeriyle değişir. Ayrıca exploit yayınlanmış bir vulnerability hızla daha kritik hale gelebilir. EPSS ve known exploited vulnerability bilgileri ek bağlam sağlayabilir. En iyi gate politikası teknik skorları uygulamanın gerçek iş ve saldırı yüzeyi bilgisiyle birleştirir.

Severity

Severity zafiyetin potansiyel teknik etkisini anlamak için başlangıç noktasıdır. Critical ve high bulgular daha hızlı değerlendirilmelidir. Ancak severity doğrudan gerçek saldırı olasılığını göstermez. Uygulamanın erişim modeli ve kullanılan fonksiyon ayrıca incelenmelidir. Gate politikası severity'yi diğer risk sinyalleriyle birlikte kullanmalıdır.

Exploitability

Exploitability bir zafiyetin pratikte ne kadar kolay kullanılabileceğini ifade eder. Public exploit bulunması risk önceliğini yükseltebilir. Buna karşılık yalnızca çok özel iç koşullarda tetiklenen bir bulgu daha düşük aciliyete sahip olabilir. Scanner'ın exploit maturity verisi varsa risk hesabına dahil edilebilir. İnsan doğrulaması özellikle yüksek etkili bulgularda önemini korur.

Internet Exposure

Internet-facing sistemler saldırganların doğrudan erişebildiği daha geniş bir tehdit yüzeyine sahiptir. Aynı vulnerability iç ağdaki yönetim aracında ve public API'de farklı öncelik alabilir. Asset inventory bu exposure bilgisini vulnerability sistemine sağlayabilir. Gate policy internet-facing servislerde daha sıkı threshold uygulayabilir. Bu yaklaşım sınırlı güvenlik kaynağını daha önemli risklere yönlendirir.

Asset Criticality

Asset criticality sistemin iş süreçleri açısından önem seviyesini ifade eder. Ödeme, kimlik veya müşteri verisi işleyen servisler daha yüksek kritik seviyeye sahip olabilir. Internal demo uygulamasındaki aynı bulgu farklı SLA ile yönetilebilir. Criticality bilgisinin merkezi asset inventory içinde tutulması otomatik risk değerlendirmesini kolaylaştırır. Security gate bu bilgiyi scanner sonucuyla birleştirebilir.

Sensitive Data

Hassas veri işleyen uygulamalarda confidentiality etkisi daha önemli hale gelir. Kişisel veri, finansal kayıt veya authentication secret barındıran sistemlerde belirli vulnerability kategorileri daha yüksek risk taşıyabilir. Data classification bilgisi pipeline veya asset metadata'sına eklenebilir. Gate policy veri sınıfına göre farklı threshold uygulayabilir. Bu sayede teknik bulgu iş etkisiyle daha doğru ilişkilendirilir.

Known Exploited Vulnerabilities

Gerçek dünyada aktif olarak kullanılan vulnerability'ler yalnızca teorik risk taşıyanlardan daha hızlı ele alınmalıdır. Bilinen exploit bilgisi SCA ve container sonuçlarını önceliklendirmede güçlü sinyaldir. Aktif deployment ilgili bileşeni içeriyorsa remediation SLA kısaltılabilir. Fix mevcutsa upgrade işlemi hızlandırılmalıdır. Gate politikası known exploited durumunu severity'den bağımsız ek yükseltici olarak kullanabilir.

EPSS

EPSS belirli CVE'nin yakın dönemde sömürülme olasılığına ilişkin ek risk sinyali sunabilir. Bu değer CVSS'nin yerine geçmez, farklı bir soruya cevap verir. Yüksek EPSS skoruna sahip vulnerability daha erken remediation için aday olabilir. Pipeline gate bu veriyi dependency ve container bulgularında kullanabilir. Ancak kurum kendi threat model ve exposure bilgisini yine hesaba katmalıdır.

Business Context

Business context teknik bulgunun gerçek operasyon ve müşteri etkisini anlamaya yardımcı olur. Aynı kod parçası development tool içinde veya kritik müşteri servisinde farklı risk oluşturabilir. Asset owner ve service tier bilgisi vulnerability sistemine bağlanabilir. Risk kabul kararlarında bu bağlam açıkça belirtilmelidir. Böylece güvenlik önceliği yalnızca scanner skoruna indirgenmez.

Risk-Based Prioritization

Risk-based prioritization severity, exploitability, exposure ve business context gibi sinyalleri bir araya getirir. Amaç en fazla bulguyu kapatmak değil en önemli riski en hızlı azaltmaktır. Otomatik scoring modeli triage ekibinin iş yükünü azaltabilir. Modelin sonuçları periyodik incident ve remediation verisiyle gözden geçirilmelidir. Geliştiricinin neden belirli bulgunun öncelikli olduğunu görebilmesi güvenlik sürecine güveni artırır.

Yeni Zafiyet ile Mevcut Security Debt Nasıl Ayrılır?

Eski codebase'e ilk kez scanner eklendiğinde yüzlerce mevcut bulgu ortaya çıkabilir. Bunların tamamını aynı anda blocking hale getirmek geliştirme akışını durdurabilir. Daha uygulanabilir yaklaşım mevcut durumu baseline olarak kabul edip yeni bulgular için sıkı gate uygulamaktır. Legacy vulnerability backlog ayrı SLA ve remediation planıyla azaltılır. Böylece ekip hem güvenlik borcunu görünür tutar hem de yeni kodun durumu daha kötü hale getirmesini önler.

Baseline Oluşturma

Baseline mevcut scanner sonuçlarının belirli tarihteki referans fotoğrafıdır. İlk taramada doğrulanan legacy bulgular bu kayıt altında tutulabilir. Daha sonra yalnızca baseline dışındaki yeni riskler pull request gate'ini etkiler. Baseline kalıcı af anlamına gelmemelidir. Eski bulgular ayrı remediation programında zamanla kapatılmalıdır.

New Findings Only Policy

New findings only policy geliştiricinin yaptığı değişiklikle gelen yeni güvenlik sorunlarına odaklanır. Bu yöntem eski codebase nedeniyle her pull request'in başarısız olmasını önler. Scanner diff veya first-seen bilgisiyle yeni bulguyu ayırabilir. Critical yeni riskler merge'i durdurabilir. Legacy bulgular dashboard ve SLA üzerinden izlenmeye devam eder.

Legacy Vulnerability Backlog

Legacy vulnerability backlog daha önce var olan güvenlik bulgularının planlı şekilde yönetildiği iş listesidir. Bulgular asset criticality ve exploitability bilgisine göre önceliklendirilebilir. En riskli alanlardan başlanarak sprint kapasitesi ayrılabilir. Backlog trendinin zamanla azalması güvenlik programının önemli metriğidir. Yeni güvenlik borcu eklenmesini engelleyen gate bu programın başarısını destekler.

Grandfathering

Grandfathering mevcut bulguların geçici olarak gate dışında tutulması yaklaşımıdır. Bu karar her bulgunun kabul edildiği anlamına gelmemelidir. Kapsama alınan risklerin owner ve remediation hedef tarihi bulunmalıdır. Yeni kod aynı vulnerable pattern'i tekrar eklediğinde grandfathering uygulanmamalıdır. Böylece eski sistem çalışmaya devam ederken güvenlik kalitesi kademeli olarak yükseltilebilir.

Yeni Kodun Eski Güvenlik Borcunu Artırmasını Önleme

En etkili kural yeni değişikliklerin mevcut vulnerability sayısını artırmasına izin vermemektir. Pull request SAST ve SCA scanner'ları diff bilgisiyle bu kontrolü sağlayabilir. Geliştirici yalnızca kendi eklediği yeni riski düzeltmekle sorumlu tutulduğunda süreç daha adil görünür. Eski borç planlı backlog çalışmasıyla azaltılır. Bu yöntem uzun süreli projelerde DevSecOps geçişini daha uygulanabilir hale getirir.

False Positive Yönetimi

False positive yönetimi scanner sonuçlarına güven duyulması için kritik öneme sahiptir. Geliştirici sürekli yanlış uyarı görürse zaman içinde gerçek güvenlik mesajlarını da görmezden gelmeye başlayabilir. Bu nedenle rule tuning, doğrulanmış suppression ve ölçüm süreci oluşturulmalıdır. Her suppression kalıcı olmak zorunda değildir ve sona erme tarihi içermesi yararlıdır. Scanner bazında false positive oranını takip etmek hangi aracın veya kural setinin iyileştirilmesi gerektiğini gösterir.

False Positive Neden Oluşur?

Scanner uygulamanın bütün business context'ini veya framework davranışını anlayamayabilir. Özel sanitization fonksiyonu veya wrapper kütüphanesi analiz motoru tarafından tanınmayabilir. DAST tarafında test ortamının özel response'u yanlış sinyal üretebilir. Yanlış rule config de gereksiz bulgulara yol açabilir. Bu nedenle false positive yalnızca scanner'ın hatası değil entegrasyon ve kural kalitesi problemi olarak da değerlendirilmelidir.

Scanner Rule Tuning

Rule tuning proje ve teknoloji yığınına uygun olmayan kuralları kapatmayı veya özelleştirmeyi içerir. Her rule'ın detection rate ve false positive oranı izlenebilir. Yüksek gürültü üreten düşük değerli kurallar advisory moda alınabilir. Güvenlik ekibi gerçek incident pattern'lerinden custom rule geliştirebilir. Rule değişiklikleri version control ve review süreciyle yönetilmelidir.

Suppression

Suppression doğrulanmış belirli bulgunun scanner sonucunda tekrar uyarı üretmemesini sağlar. Geliştiricinin tek başına sınırsız suppression yapabilmesi güvenlik kontrolünü zayıflatabilir. Kritik rule'lar için security review zorunlu tutulabilir. Suppression mümkün olduğunda finding identifier ve kod bağlamına özgü olmalıdır. Çok geniş pattern suppression gerçek yeni zafiyetleri gizleyebilir.

Suppression İçin Gerekçe Zorunluluğu

Her suppression kaydı neden bulgunun risk oluşturmadığını açıklamalıdır. Gerekçe daha sonra yapılacak security review için önemli bağlam sağlar. Yalnızca “false positive” yazmak yeterli değildir. Kullanılan sanitization, erişim kısıtı veya compensating control açıkça belirtilmelidir. Bu kayıt audit ve ekip değişikliği durumunda kararın anlaşılmasını kolaylaştırır.

Suppression Expiry Date

Suppression için expiry date belirlemek eski kararların sonsuza kadar geçerli kalmasını önler. Kod ve deployment koşulları zaman içinde değişebilir. Süre dolduğunda bulgu yeniden değerlendirilir. Hâlâ geçerli false positive ise yeni review ile süre uzatılabilir. Bu yaklaşım unutulmuş exception kayıtlarını azaltır.

Security Review

Security review özellikle high veya critical bulguların suppression işleminde ikinci kontrol sağlar. Reviewer scanner evidence'ını, kod akışını ve compensating control'leri değerlendirir. Karar merkezi vulnerability sisteminde kaydedilebilir. Düşük riskli ve sık tekrarlanan doğrulanmış pattern'ler zamanla otomatik rule tuning'e dönüştürülebilir. Böylece güvenlik ekibi manuel tekrar işlerinden kurtulur.

False Positive Oranı Nasıl Ölçülür?

False positive oranı doğrulanan yanlış bulguların toplam değerlendirilen bulgulara oranıyla takip edilebilir. Ölçüm scanner, rule, repository ve dil seviyesinde ayrıştırılabilir. Belirli rule sürekli yüksek false positive üretiyorsa iyileştirme adayıdır. Developer dismissal verisi tek başına doğru ölçüm olmayabilir çünkü yanlış suppression yapılabilir. Periyodik örnekleme ve security validation metriğin güvenilirliğini artırır.

Risk Acceptance Süreci Nasıl Tasarlanmalıdır?

Risk acceptance güvenlik bulgusunun belirli süre boyunca düzeltilmeden çalışmasına bilinçli onay verilmesidir. Bu karar geliştiricinin scanner uyarısını kapatmasıyla aynı şey değildir. Riskin iş gerekçesi, etkisi, compensating control'ü, owner'ı ve sona erme tarihi kayıt altına alınmalıdır. Yüksek riskler için daha yetkili onay seviyesi uygulanabilir. Süre dolduğunda risk yeniden değerlendirilerek düzeltme veya uzatma kararı verilmelidir.

Kim Risk Kabul Edebilir?

Risk kabul yetkisi bulgunun seviyesine ve sistemin önemine göre belirlenmelidir. Düşük risk için teknik owner yeterli olabilirken critical risk için güvenlik ve iş sahibi onayı gerekebilir. Yetki matrisi önceden tanımlandığında release sırasında belirsizlik azalır. Geliştirici kendi başına yüksek risk kabul edememelidir. Approval kaydı merkezi sistemde denetlenebilir biçimde tutulmalıdır.

Business Justification

Business justification neden bulgunun hemen düzeltilemediğini açıklar. Release tarihi, üçüncü taraf bağımlılığı veya büyük mimari değişiklik gereksinimi geçici nedenler olabilir. Gerekçe yalnızca takvim baskısı şeklinde yazılmamalı, risk ve alternatifler değerlendirilmelidir. Düzeltme planı mümkün olduğunca belirtilmelidir. Bu kayıt risk kararının bilinçli verildiğini göstermeye yardımcı olur.

Compensating Control

Compensating control vulnerability düzeltilene kadar riski azaltan ek önlemdir. Network restriction, feature disable, WAF kuralı veya yetki azaltma buna örnek olabilir. Kontrolün gerçekten riski azalttığı doğrulanmalıdır. Geçici önlem kalıcı remediation yerine geçmemelidir. Risk acceptance kaydında kontrolün owner ve doğrulama yöntemi belirtilmelidir.

Expiration Date

Her risk kabulünün bir expiration date'i bulunması unutulmuş istisnaları önler. Süre riske göre birkaç gün, hafta veya belirli release dönemi olabilir. Expiry yaklaşırken owner otomatik olarak bilgilendirilebilir. Süre dolduğunda pipeline exception'ı otomatik geçersiz hale gelebilir. Uzatma gerekiyorsa yeni değerlendirme ve onay yapılmalıdır.

Vulnerability Owner

Her kabul edilmiş riskin sorumlu bir owner'ı olmalıdır. Owner remediation planını ve gerekli koordinasyonu takip eder. Sadece ekip adı yerine mümkün olduğunda accountable rol veya servis sahipliği kullanılmalıdır. Ekip değiştiğinde ownership otomatik service catalog üzerinden güncellenebilir. Sahipsiz vulnerability'ler zamanla güvenlik borcuna dönüşür.

Yeniden Değerlendirme

Risk acceptance statik karar değildir çünkü threat ve application context zaman içinde değişir. Yeni exploit yayınlanması veya servisin internet-facing hale gelmesi risk seviyesini artırabilir. Periyodik reevaluation bu değişiklikleri yakalar. Expiry date doğal yeniden değerlendirme noktası oluşturur. Kritik dış gelişmelerde tarih beklenmeden risk kaydı tekrar açılmalıdır.

Vulnerability Triage Workflow

Vulnerability triage workflow scanner bulgusunun ilk görülmesinden kapanmasına kadar izlenen standart süreçtir. İyi tasarım duplicate uyarıları azaltır, gerçek riski doğrular ve doğru geliştiriciye atar. Severity yanında exploitability ve asset context değerlendirilir. Remediation sonrasında rescan veya regression test ile düzeltme doğrulanır. Bu akış otomatikleştirildiğinde güvenlik ekibi manuel rapor taşımak yerine risk analizi ve iyileştirmeye odaklanabilir.

Finding Oluşturma

Scanner yeni bulgu ürettiğinde benzersiz identifier, repository, commit ve evidence bilgisiyle merkezi kayda aktarılmalıdır. Bulguda scanner adı ve rule ID bulunması troubleshooting sürecini kolaylaştırır. Kod veya endpoint bilgisi geliştiriciye doğrudan bağlam sağlar. Sensitive request veya response verileri rapora aktarılmadan maskelenmelidir. Oluşturma zamanı remediation SLA başlangıcı olarak kullanılabilir.

Deduplication

Aynı vulnerability farklı scanner veya farklı pipeline çalışmasında tekrar görülebilir. Deduplication bu sonuçları tek kayıtta birleştirerek gereksiz ticket sayısını azaltır. Dosya, satır, rule, endpoint veya CVE bilgileri eşleştirme için kullanılabilir. Scanner değişikliklerinde identifier farklılaşabileceği için normalization önemlidir. Yanlış deduplication iki ayrı riski tek kayıt altında gizlememelidir.

Validation

Validation bulgunun gerçek güvenlik riski olup olmadığını doğrulama aşamasıdır. Yüksek güvenilirlikteki scanner sonuçları otomatik doğrulama sinyalleriyle desteklenebilir. Kritik bulgular gerektiğinde manuel review ile incelenir. False positive ise neden kaydedilir ve rule tuning fırsatı değerlendirilir. Doğrulanmış finding sonraki prioritization aşamasına geçer.

Prioritization

Prioritization hangi vulnerability'nin önce düzeltilmesi gerektiğini belirler. Severity, exploitability, exposure, asset criticality ve sensitive data gibi sinyaller birlikte kullanılabilir. Known exploited vulnerability bilgisi önceliği ciddi biçimde yükseltebilir. Risk skoru service owner'a anlaşılır biçimde gösterilmelidir. Bu sayede ekip yalnızca scanner sıralamasına göre değil gerçek iş riskine göre hareket eder.

Developer Assignment

Bulguyu doğru geliştirici veya servis ekibine atamak remediation süresini kısaltır. CODEOWNERS veya service catalog verisi otomatik assignment için kullanılabilir. Finding doğrudan ilgili repository ve dosya bilgisiyle gelirse sahiplik daha kolay belirlenir. Ticket açıklamasında düzeltme önerisi ve scanner evidence'ı bulunmalıdır. Sahipsiz kayıtlar merkezi triage ekibi tarafından düzenli kontrol edilmelidir.

SLA

Security SLA risk seviyesine göre bulgunun ne kadar sürede ele alınması gerektiğini tanımlar. Critical internet-facing vulnerability için süre daha kısa olabilir. Medium internal risk daha uzun remediation penceresine sahip olabilir. SLA başladığı ve durduğu olaylar açık biçimde tanımlanmalıdır. İstisna veya risk acceptance SLA'yı görünmez hale getirmemelidir.

Remediation

Remediation vulnerability'nin kod, dependency veya yapılandırma seviyesinde düzeltilmesidir. Geliştirici yalnızca scanner uyarısını susturmak yerine root cause'u çözmelidir. Dependency upgrade, input validation veya authorization kontrolü çözüm olabilir. Büyük değişikliklerde unit ve regression test eklenmesi önemlidir. Düzeltme pull request'i normal güvenlik pipeline'ından tekrar geçirilmelidir.

Rescan

Rescan yapılan düzeltmenin scanner tarafından artık bulunmadığını doğrular. Aynı commit veya yeni build üzerinde ilgili tarama tekrar çalıştırılmalıdır. DAST bulgularında staging environment'ın güncel sürümü test edilmelidir. Scanner bulgusunun kaybolması tek başına her zaman yeterli değildir, özellikle logic vulnerability için regression test gerekebilir. Başarılı doğrulama closure aşamasına geçiş sağlar.

Closure

Closure bulgunun düzeltildiği, geçersiz olduğu veya kabul edilen risk kapsamında kapatıldığı durumu ifade eder. Kapanış nedeni açık biçimde kaydedilmelidir. Remediation kanıtı commit, build veya test sonucu olabilir. Aynı vulnerability yeniden görülürse reopened metriği üzerinden takip edilebilir. Kapanan bulgulardan çıkarılan dersler yeni rule veya test geliştirmek için kullanılabilir.

Farklı Scanner Sonuçları Nasıl Birleştirilir?

Birden fazla güvenlik aracı kullanıldığında aynı vulnerability farklı formatlarda raporlanabilir. Merkezi vulnerability management katmanı bu sonuçları normalize ederek ortak görünüm oluşturur. SARIF, CWE ve CVE gibi standart alanlar entegrasyonu kolaylaştırır. Deduplication ve cross-tool correlation aynı problemin birçok ticket oluşturmasını önler. Sonuçların tek dashboard'da gösterilmesi ekiplerin scanner ekranları arasında dolaşma ihtiyacını azaltır.

Merkezi Vulnerability Management

Merkezi vulnerability management sistemi SAST, DAST, SCA, container ve IaC sonuçlarını tek yerde toplar. Finding'ler ortak severity ve status modeline dönüştürülebilir. Asset owner, SLA ve exception bilgileri aynı kayıtla ilişkilendirilebilir. Scanner yeniden çalıştığında mevcut finding güncellenir veya kapatılabilir. Bu yapı kurumsal güvenlik programında ölçüm ve audit için güçlü bir temel oluşturur.

SARIF

SARIF statik analiz sonuçlarını standart bir formatta taşımaya yardımcı olur. Tool adı, rule, location ve message gibi alanları ortak yapı altında ifade edebilir. Birden fazla SAST scanner sonucu aynı code scanning platformuna yüklenebilir. Pull request annotation üretmek için de kullanılabilir. Ancak bütün güvenlik araçları veya DAST sonuçları SARIF'i aynı kapsamda desteklemeyebilir.

CWE

CWE bulguları güvenlik zafiyeti kategorilerine göre sınıflandırmak için kullanılabilir. Farklı scanner'lar aynı problemi farklı rule adıyla raporlasa bile ortak CWE değeri correlation için yardımcı olabilir. Örneğin injection veya authorization kategorileri organizasyon seviyesinde trend analizine dönüştürülebilir. CWE mapping'in doğruluğu scanner'a bağlıdır. Merkezi sistem bu alanı normalize ederek raporlama kalitesini artırabilir.

CVE

CVE özellikle dependency, operating system package ve bilinen product vulnerability'lerini ortak identifier ile takip etmeyi sağlar. SCA ve container scanner aynı CVE'yi farklı artifact'lerde raporlayabilir. Merkezi sistem bu bilgiyi asset ve deployment envanteriyle ilişkilendirebilir. Yeni exploit bilgisi geldiğinde ilgili bütün CVE kayıtları tekrar önceliklendirilebilir. Kod seviyesindeki özel SAST bulgularının çoğunda CVE bulunmaz.

Finding Normalization

Normalization farklı scanner alanlarını ortak vulnerability veri modeline dönüştürür. Severity, confidence, location, asset ve identifier gibi bilgiler standartlaştırılabilir. Bu işlem gate policy'nin araç bağımsız çalışmasını kolaylaştırır. Scanner değiştirildiğinde bütün reporting yapısını yeniden yazmak gerekmez. Mapping kuralları version control altında tutulursa değişiklikler izlenebilir.

Deduplication

Deduplication benzer finding'lerin tek kayıt altında birleştirilmesini sağlar. Aynı dosya, endpoint, CVE veya CWE bilgisi eşleştirme sinyali olabilir. SAST ve DAST aynı riskin farklı kanıtlarını sunuyorsa correlation yapmak remediation bağlamını güçlendirebilir. Otomatik eşleştirme güven seviyesi düşük olduğunda insan review gerekebilir. Amaç bilgi kaybetmeden gereksiz tekrarları azaltmaktır.

Cross-Tool Correlation

Cross-tool correlation farklı scanner'ların aynı risk hakkında verdiği sinyalleri ilişkilendirir. SAST bir SQL injection code path'i bulurken DAST aynı endpoint'te çalışan exploit kanıtı gösterebilir. Bu durumda combined confidence ve priority yükseltilebilir. Benzer biçimde container CVE sonucu aktif deployment bilgisiyle eşleştirilebilir. Correlation risk önceliklendirmesini yalnızca tek scanner skorundan daha anlamlı hale getirir.

Tek Security Dashboard

Tek security dashboard geliştirici ve güvenlik ekiplerine ortak vulnerability görünümü sağlar. Repository, servis, ekip, severity ve SLA bazında filtreleme yapılabilir. Scanner başına farklı ekranları kontrol etme ihtiyacı azalır. Dashboard yalnızca açık bulgu sayısını değil remediation trendini ve coverage bilgisini de göstermelidir. İyi dashboard karar vermeyi kolaylaştırır, sadece daha fazla grafik göstermekle yetinmez.

SARIF Nedir?

SARIF, Static Analysis Results Interchange Format ifadesinin kısaltmasıdır ve statik analiz sonuçlarının ortak bir yapıda taşınmasını sağlar. Özellikle code scanning ve pull request annotation senaryolarında kullanışlıdır. Bir scanner'ın raporu farklı bir platform tarafından okunabilir hale gelir. Rule ID, severity, location ve message gibi bilgiler standart alanlarla ifade edilir. Kurumsal CI/CD ortamında birden fazla SAST aracını ortak workflow'a bağlamak için pratik bir entegrasyon katmanı oluşturabilir.

Static Analysis Results Interchange Format

SARIF JSON tabanlı standart bir sonuç formatıdır. Static analysis aracı bulgularını dosya konumu, rule bilgisi ve mesajla birlikte raporlayabilir. Platform bu veriyi geliştiriciye code annotation olarak gösterebilir. Format sayesinde scanner'a özel parser yazma ihtiyacı azalır. Bununla birlikte tool-specific metadata'nın tamamı her zaman ortak alanlara sığmayabilir.

Scanner Sonuçlarını Standartlaştırma

Scanner sonuçlarının ortak formatta tutulması vulnerability ingestion sürecini kolaylaştırır. Farklı araçların severity ve rule isimleri normalize edilebilir. SARIF özellikle kod konumu taşıyan bulgular için güçlüdür. Merkezi sistem ek enrichment yaparak asset owner veya SLA bilgisi ekleyebilir. Standart format araç değişikliklerinde entegrasyon maliyetini azaltır.

Pull Request Annotation

SARIF sonucu pull request içinde doğrudan riskli satıra annotation olarak eklenebilir. Geliştirici ayrı scanner dashboard'una gitmeden bulguyu code review sırasında görür. Mesaj kısa, açıklayıcı ve düzeltme yönlendirmesi içermelidir. Çok fazla düşük değerli annotation review ekranını gürültülü hale getirebilir. Bu nedenle yalnızca yeni ve güvenilir bulguların PR üzerinde gösterilmesi daha etkilidir.

Merkezi Code Scanning

Merkezi code scanning farklı repository'lerdeki statik analiz sonuçlarını ortak arayüzde toplar. SARIF yükleme bu entegrasyonu basitleştirebilir. Güvenlik ekibi rule ve repository bazında trend görebilir. Developer tarafında bulgular yine pull request bağlamında görünür kalabilir. Merkezi ve lokal görünümün birlikte kullanılması sahiplik ve program ölçümü açısından yararlıdır.

Birden Fazla Scanner'ı Tek Workflow'da Kullanma

Farklı diller veya risk kategorileri için birden fazla scanner gerekebilir. Her araç SARIF üretiyorsa sonuçlar aynı workflow sonunda ortak sisteme yüklenebilir. Job'lar paralel çalıştırılarak pipeline süresi azaltılabilir. Duplicate sonuçlar ingestion sonrasında normalize edilebilir. Gate policy scanner adına değil normalize edilmiş risk bilgisine dayanabilir.

GitHub Actions ile SAST/DAST Entegrasyonu

GitHub Actions içinde güvenlik taramaları pull request, push ve deployment event'lerine göre ayrı job'lar halinde tasarlanabilir. SAST ve dependency kontrolleri PR sırasında, DAST ise staging deployment sonrası çalıştırılabilir. SARIF destekleyen scanner sonuçları code scanning görünümüne aktarılabilir. Branch protection gerekli security job'larının başarılı olmasını merge koşulu haline getirebilir. GitHub Jenkins GitHub Actions pipeline güvenlik taraması ve vulnerability yönetimi kurulurken ortak policy ve finding normalization katmanı platformlar arasındaki farkı azaltır.

Pull Request Trigger

Pull request trigger değişiklik henüz default branch'e girmeden security job başlatır. Scanner changed file veya diff bilgisine erişebilir. Fork'tan gelen untrusted pull request'lerde secret kullanımına dikkat edilmelidir. Yüksek yetkili token'lar güvenilmeyen kodun çalıştığı job'a verilmemelidir. Bu ayrım runner ve supply chain güvenliği açısından çok önemlidir.

SAST Job

SAST job repository checkout sonrasında scanner'ı çalıştırır ve bulguları raporlar. Incremental mode mevcutsa pull request diff'i kullanılabilir. Scanner'ın minimum permission ile çalışması gerekir. Sonuç SARIF olarak yüklenebilir veya merkezi vulnerability platformuna gönderilebilir. Exit code policy yalnızca doğrulanmış risk seviyelerini blocking hale getirmelidir.

Staging Deployment

Staging deployment job build artifact'ini test edilebilir ortama taşır. Environment protection ve secret scope kullanılması production credential'larının yanlışlıkla erişilmesini önler. Deployment tamamlandıktan sonra health check ile servis hazır olduğu doğrulanabilir. DAST job hedef URL'yi bu adımdan alır. Preview environment kullanılıyorsa workflow sonunda otomatik cleanup yapılmalıdır.

DAST Job

DAST job staging URL'sine bağlanarak dinamik güvenlik taraması çalıştırır. Authentication için test service account veya kısa ömürlü token kullanılabilir. Scanner request rate staging kapasitesine uygun ayarlanmalıdır. Sonuç machine-readable formatta artifact veya merkezi sisteme aktarılabilir. Critical doğrulanmış bulgu release gate'i başarısız hale getirebilir.

SARIF Upload

SARIF upload statik analiz sonuçlarını merkezi code scanning görünümüne taşır. Workflow token permission değerleri yalnızca gerekli seviyede tutulmalıdır. Scanner'ın oluşturduğu path bilgileri repository ile doğru eşleşmelidir. Upload başarısız olursa security job'ın sessizce başarılı sayılması önlenmelidir. Sonuç review ekranında geliştiriciye anlaşılır annotation olarak görünmelidir.

Branch Protection

Branch protection default branch'e doğrudan kontrolsüz değişiklik yapılmasını azaltır. Required review ve required status check politikaları güvenlik job'larıyla birleştirilebilir. Admin bypass seçenekleri sınırlı tutulmalıdır. Koruma kuralları repository bazında değil organization policy ile merkezi yönetilebiliyorsa daha tutarlı uygulanır. Audit log değişikliklerin kim tarafından yapıldığını göstermelidir.

Merge Protection

Merge protection gerekli testler ve security gate tamamlanmadan kodun default branch'e girmesini engeller. Pull request'in son commit'i değiştiğinde eski approval'ın geçerli kalıp kalmayacağı policy ile belirlenebilir. Security result yeni commit'e ait olmalıdır. Force merge yetkileri minimum kullanıcı grubuyla sınırlandırılmalıdır. Bu kontroller scanner kadar önemli pipeline güvenlik bileşenleridir.

Security Gate

GitHub Actions security gate scanner job sonuçlarını ortak karar adımında değerlendirebilir. Severity, new finding ve exception bilgisi kullanılabilir. Policy-as-code yaklaşımı karar mantığını repository veya merkezi workflow içinde version control altında tutar. Gate başarısız olduğunda geliştirici nedeni kolayca görebilmelidir. Manuel override varsa audit ve expiry bilgisi zorunlu olmalıdır.

GitLab CI/CD ile SAST/DAST

GitLab CI/CD pipeline'ında güvenlik kontrolleri ayrı security stage veya mevcut test aşamaları içinde çalıştırılabilir. Merge request seviyesinde SAST ve dependency scanning, review app üzerinde ise DAST kullanılabilir. Pipeline policy kuralları belirli job'ların project tarafından devre dışı bırakılmasını önlemek için merkezi yaklaşım sunabilir. Sonuçların vulnerability workflow ile ilişkilendirilmesi triage sürecini kolaylaştırır. Büyük organizasyonlarda ortak CI template kullanmak repository'ler arasında tutarlı güvenlik kapsamı sağlar.

Security Stage

Security stage SAST, SCA, IaC veya secret taramalarını mantıksal olarak gruplayabilir. Ancak bütün scanner'ların sıralı çalışması pipeline süresini gereksiz uzatabilir. Bağımsız job'lar paralel çalıştırılmalıdır. Build sonrası gereken container scan daha sonraki stage'e taşınabilir. Stage tasarımı feedback hızını ve dependency ilişkilerini dikkate almalıdır.

Merge Request Scanning

Merge request scanning yeni kod değişikliğini default branch'e birleşmeden analiz eder. Incremental SAST ve dependency diff bu aşamada kullanışlıdır. Sonuçlar merge request içinde geliştiriciye gösterilebilir. Yeni high veya critical finding için approval policy uygulanabilir. Existing security debt ayrı backlog'da tutulmalıdır.

Dependency Scanning

Dependency scanning manifest ve lock file üzerinden bilinen vulnerability'leri kontrol eder. Pipeline'da package install sonrasında resolved dependency bilgisi daha doğru sonuç sağlayabilir. Yeni riskler merge request'e taşınabilir. Scheduled pipeline kod değişmeden ortaya çıkan yeni CVE'leri yakalayabilir. Sonuçlar SBOM envanteriyle ilişkilendirildiğinde aktif deployment etkisi daha hızlı belirlenir.

Review App

Review app her branch veya merge request için geçici çalışan ortam sağlayabilir. DAST scanner bu URL üzerinde değişiklik özelinde test yapabilir. Ortam production secret'larına erişmemelidir. Test account ve test data otomatik hazırlanmalıdır. Merge veya job tamamlandıktan sonra review environment temizlenmelidir.

DAST

DAST review app veya staging ortamında çalışan uygulamaya yönlendirilir. Authentication desteği coverage açısından özellikle önemlidir. Scanner profile kısa merge request taraması ve derin scheduled tarama olarak ayrılabilir. Rapor machine-readable formatta vulnerability sistemine aktarılmalıdır. Güvenilir kritik bulgular deployment policy için blocking sinyal olabilir.

Pipeline Policy

Pipeline policy güvenlik job'larının belirli kurallarla merkezi uygulanmasını kolaylaştırır. Geliştirici repository değiştirerek zorunlu scanner'ı kolayca devre dışı bırakamamalıdır. Policy değişiklikleri review ve audit sürecinden geçmelidir. İstisna gerekiyorsa süreli ve gerekçeli kayıt oluşturulmalıdır. Bu yaklaşım çok sayıda repository'nin güvenlik standardını yönetmeyi kolaylaştırır.

Jenkins ile Otomatik Güvenlik Taramaları

Jenkins esnek pipeline yapısı sayesinde SAST, SCA, container scan ve DAST araçlarını stage bazında çalıştırabilir. Güvenlik job'larının shared library üzerinden standartlaştırılması çok sayıda pipeline'da aynı kontrolü uygulamayı kolaylaştırır. Credential'lar Jenkins secret mekanizması veya harici vault üzerinden sağlanmalıdır. Self-hosted agent güvenliği özellikle untrusted branch'lerde dikkatle ele alınmalıdır. Jenkins pipeline sonucunun merkezi vulnerability management sistemine aktarılması farklı projelerin ortak güvenlik görünümünü sağlar.

SAST Stage

SAST stage source checkout sonrasında hızlı statik analiz çalıştırabilir. Pull request bilgisi mevcutsa incremental tarama tercih edilebilir. Scanner token'ı environment secret olarak verilmelidir. Rapor JSON veya SARIF formatında downstream sisteme aktarılabilir. Gate yalnızca belirlenen risk threshold'a göre stage'i başarısız yapmalıdır.

SCA Stage

SCA stage dependency manifest ve lock file'ları analiz eder. Build tool resolve işleminden sonra tarama yapmak gerçek dependency sürümlerini görmeyi kolaylaştırır. CVE sonuçları merkezi dashboard'a gönderilebilir. Known exploited vulnerability bilgisi varsa priority yükseltilebilir. Scheduled Jenkins job eski branch veya release'leri yeniden tarayabilir.

Docker Scan

Docker scan build edilen image'ın gerçek içeriğini kontrol eder. Image tag yanında immutable digest kaydedilmelidir. Scanner build agent üzerinde veya registry entegrasyonu üzerinden çalışabilir. Critical vulnerability bulunduğunda push veya promotion durdurulabilir. Result artifact signing adımından önce değerlendirilmelidir.

Staging Deployment

Jenkins staging deployment stage'inde doğrulanan artifact test ortamına taşınır. Credential scope yalnızca staging kaynaklarıyla sınırlandırılmalıdır. Health check tamamlanmadan DAST başlamamalıdır. Deployment bilgisi build ID ile ilişkilendirilmelidir. Böylece DAST sonucunun hangi artifact'e ait olduğu net biçimde takip edilir.

OWASP ZAP

OWASP ZAP Jenkins pipeline içinde headless mode ile web uygulaması taraması için kullanılabilir. Baseline scan hızlı passive kontrol sağlarken active scan daha derin test yapabilir. Authentication script'i uygulamanın login akışına göre hazırlanmalıdır. Rapor XML, JSON veya HTML formatında üretilebilir. Active scan production yerine kontrollü staging ortamında çalıştırılmalıdır.

Quality Gate

Quality gate scanner sonuçlarını pipeline kararına dönüştürür. Güvenlik bulguları kod kalitesi metriklerinden ayrı risk modeliyle değerlendirilmelidir. New findings policy Jenkins stage sonucunu daha uygulanabilir hale getirir. Manual override gerekiyorsa approval ve expiry kaydı tutulmalıdır. Pipeline logu gate kararının hangi kriterle verildiğini göstermelidir.

Security Report

Security report pipeline çalışmasının bütün scanner sonuçlarını ortak özet halinde gösterebilir. Ancak yalnızca statik HTML rapor saklamak uzun vadeli vulnerability tracking için yeterli değildir. Finding'ler merkezi sisteme aktarılmalıdır. Build link, commit ve artifact digest bilgisi rapora eklenmelidir. Sensitive request ve credential değerleri çıktıdan temizlenmelidir.

Azure DevOps Pipeline'larında SAST ve DAST

Azure DevOps pipeline'larında güvenlik kontrolleri pull request validation, build ve release stage'lerine dağıtılabilir. Static code scan ve dependency kontrolü erken aşamada, dynamic scan ise staging deployment sonrasında çalıştırılabilir. Secret değerler pipeline YAML içinde tutulmamalıdır. Environment approval ve protected variable mekanizmaları production erişimini sınırlandırmak için kullanılabilir. Ortak template ve policy yaklaşımı farklı projelerde aynı DevSecOps standardının uygulanmasını kolaylaştırır.

Static Code Scan

Static code scan source checkout sonrasında çalışan ayrı job olarak tasarlanabilir. Pull request diff bilgisi destekleniyorsa hızlı incremental tarama yapılabilir. Sonuç build summary veya merkezi security dashboard'a gönderilebilir. High-confidence yeni bulgular branch policy'ye bağlanabilir. Scanner credential'ları minimum permission ile kullanılmalıdır.

Dependency Scan

Dependency scan package manifest ve resolved dependency listesini kontrol eder. Build sırasında kullanılan gerçek version bilgisi tarama doğruluğunu artırır. Vulnerability sonucu risk context ile zenginleştirilebilir. Scheduled pipeline kod değişmeden çıkan yeni CVE'leri yakalar. SBOM üretimi dependency envanterini kalıcı hale getirir.

Secret Management

Pipeline secret'ları YAML içine düz metin olarak yazılmamalıdır. Secure variable veya harici secret manager kullanılması daha doğrudur. Production ve staging credential'ları ayrı tutulmalıdır. Job loglarında secret masking kontrol edilmelidir. Mümkün olduğunda uzun ömürlü secret yerine workload identity tercih edilmelidir.

Staging Environment

Staging environment DAST ve API security testleri için güvenli hedef sağlar. Deployment approval gerekiyorsa environment policy ile yönetilebilir. Test hesapları ve sentetik veri kullanılmalıdır. Ortam production topology'sine yakın olmalıdır. Scan tamamlandıktan sonra sonuç release gate'e aktarılabilir.

Dynamic Scan

Dynamic scan staging URL'sine istek göndererek çalışan uygulamanın güvenliğini değerlendirir. Authentication script veya API token secure variable üzerinden sağlanabilir. Scanner output pipeline artifact olarak saklanabilir. Merkezi vulnerability sistemine ingestion yapılması trend takibini kolaylaştırır. Blocking kararı yalnızca güvenilir ve yeni bulgulara göre verilmelidir.

Release Approval

Release approval güvenlik gate'i ve operasyonel kontroller tamamlandıktan sonra production'a geçişi yönetir. Düşük riskli sistemlerde tamamen otomatik approval kullanılabilir. Kritik sistemlerde belirli risk durumlarında manuel security review eklenebilir. Approval logu audit için korunmalıdır. Süresiz veya kişiye bağlı bypass mekanizmalarından kaçınılmalıdır.

Açık Kaynak SAST Araçları

Açık kaynak SAST araçları farklı diller ve kullanım amaçları için güçlü seçenekler sunar. Scanner seçerken yalnızca rule sayısına değil framework desteği, analiz hızı, CI uyumu ve çıktı formatına bakmak gerekir. Bazı araçlar pattern tabanlı hızlı taramada, bazıları daha derin veri akışı analizinde güçlüdür. Birden fazla scanner kullanmak mümkün olsa da gereksiz duplicate bulgu yönetim maliyetini artırabilir. En doğru seçim mevcut teknoloji yığını ve risk profili üzerinde küçük bir pilot yaparak belirlenir.

Semgrep

Semgrep pattern ve veri akışı tabanlı kurallar aracılığıyla çok sayıda dilde hızlı statik analiz yapabilir. Custom rule geliştirmek kurumun kendi güvenli kodlama standartlarını otomatikleştirmek açısından değerlidir. Pull request seviyesinde changed-file taraması hızlı feedback sağlar. Rule'lar version control altında tutulup test edilebilir. Scanner sonucu CI job'ı ve merkezi vulnerability ingestion akışıyla birleştirilebilir.

SonarQube Community

SonarQube Community kod kalitesi ve belirli statik analiz kontrollerini merkezi arayüzde sunabilir. Proje bazında quality profile ve rule yapılandırması yapılabilir. CI entegrasyonu sayesinde build sonucuyla ilişkilendirilmiş analiz üretilebilir. Kullanılacak güvenlik yeteneklerinin seçilen edition ve dil desteğiyle uyumu doğrulanmalıdır. Araç seçimi yapılırken yalnızca dashboard görünümüne değil gerçek security rule coverage'ına bakılmalıdır.

CodeQL

CodeQL kodu sorgulanabilir bir veritabanı modeline dönüştürerek belirli güvenlik veri akışlarını analiz eder. Özellikle desteklenen dillerde derin source-to-sink sorguları güçlü sonuçlar verebilir. Hazır query paketlerinin yanında özel query geliştirmek de mümkündür. Tarama süresi proje boyutuna göre diğer hızlı pattern scanner'lardan daha uzun olabilir. Bu nedenle pull request ve scheduled analysis profilleri ayrı tasarlanabilir.

Bandit

Bandit Python kodunda yaygın güvenlik problemlerini tespit etmeye odaklanır. Hızlı çalışması nedeniyle pull request veya pre-commit kullanımına uygundur. Rule kapsamı derin application security analizinin tamamını karşılamaz. Buna rağmen güvensiz fonksiyon kullanımı veya belirli configuration problemleri için yararlı erken feedback sağlar. Python projelerinde daha geniş SAST ve dependency kontrolleriyle birlikte kullanılabilir.

Brakeman

Brakeman Ruby on Rails uygulamalarına odaklanan statik güvenlik scanner'ıdır. Framework bilgisi sayesinde Rails'e özgü güvenlik pattern'lerini analiz edebilir. CI pipeline içinde hızlı çalıştırılarak pull request feedback'i üretilebilir. Bulgular uygulama routing ve view davranışıyla birlikte değerlendirilmelidir. Framework-specific araç kullanmak genel scanner'ın kaçırdığı bazı alanlarda ek görünürlük sağlayabilir.

SpotBugs

SpotBugs Java bytecode üzerinde statik analiz yaparak çeşitli hata pattern'lerini tespit eder. Güvenlik odaklı ek rule set'lerle uygulama security kontrolü genişletilebilir. Build sistemiyle entegrasyonu Java projelerinde kolaydır. Scanner sonucunun false positive oranı kullanılan rule set'e göre değişebilir. Güvenlik ve kalite bulgularını aynı severity modeliyle karıştırmamak raporlama açısından yararlıdır.

Dil ve Framework'e Göre Scanner Seçimi

SAST scanner seçiminin en önemli kriterlerinden biri gerçek proje dili ve framework desteğidir. Bir araç çok sayıda dili listelese bile kullandığınız framework'ün sanitization ve routing davranışını iyi anlayamayabilir. Pilot aşamada gerçek repository üzerinde bilinen test zafiyetleriyle detection performansı ölçülebilir. Scan süresi ve false positive oranı da değerlendirilmelidir. En iyi scanner teoride en çok kuralı olan değil ekibin düzenli olarak kullanabildiği ve doğru sinyal üreten araçtır.

Açık Kaynak DAST Araçları

Açık kaynak DAST araçları web ve API uygulamalarını CI/CD içinde dinamik olarak test etmek için kullanılabilir. Headless execution, CLI, authentication ve machine-readable report desteği otomasyon için temel gereksinimlerdir. Scanner'ın staging ortamında kolay başlatılabilmesi ve kontrollü exit code üretmesi gerekir. Browser tabanlı crawling modern JavaScript uygulamalarında coverage açısından önemlidir. Araç seçimi yapılırken tarama derinliği kadar pipeline süre ve güvenlik etkisi de değerlendirilmelidir.

OWASP ZAP

OWASP ZAP web uygulaması ve API taraması için yaygın kullanılan açık kaynak seçeneklerden biridir. Baseline scan passive kontroller için hızlı başlangıç sağlayabilir. Active scan daha fazla saldırı payload'ı gönderdiği için staging ortamında çalıştırılmalıdır. Authentication script ve context ayarları login arkasındaki uygulamalar için önemlidir. CI job sonucunun report ve exit code bilgisi security gate'e bağlanabilir.

Nuclei

Nuclei template tabanlı güvenlik kontrolü yaparak belirli web ve network pattern'lerini hızlı biçimde tarayabilir. CI kullanımında yalnızca güvenilir ve uygulamayla ilgili template kategorileri seçilmelidir. Çok geniş internet template setini kontrolsüz çalıştırmak gereksiz gürültü üretebilir. Production hedeflerinde destructive veya yüksek etkili testler dikkatle filtrelenmelidir. Sonuçlar diğer DAST bulgularıyla ortak vulnerability modelinde birleştirilebilir.

API ve Web Scanner Seçimi

Web ve API scanner seçimi uygulamanın gerçek attack surface yapısına göre yapılmalıdır. SPA uygulamalar browser crawling desteğine ihtiyaç duyabilir. API ağırlıklı sistemlerde OpenAPI import ve authentication header yönetimi daha önemli olabilir. GraphQL kullanan sistemlerde schema-aware test desteği değerlendirilmelidir. Pilot testte endpoint coverage ve false positive oranı birlikte ölçülmelidir.

CI/CD Uyumunda Aranması Gereken Özellikler

Bir DAST aracının iyi scanner olması tek başına CI/CD için yeterli değildir. Otomatik başlatılabilir, konfigüre edilebilir ve makine tarafından okunabilir sonuç üretebilir olması gerekir. Authentication ve session renewal desteği coverage açısından çok önemlidir. Exit code davranışı security gate entegrasyonunu kolaylaştırır. Container image olarak çalışabilmesi de runner ortamında bağımlılık yönetimini basitleştirir.

CLI

CLI desteği scanner'ın pipeline script içinden kolayca başlatılmasını sağlar. Parametreler config file veya environment variable üzerinden verilebilir. Non-interactive çalışması zorunludur. Exit code açık biçimde başarısızlık ve scanner hatasını ayırmalıdır. CLI version bilgisinin loglanması sonuçların yeniden üretilebilirliğini artırır.

API

API desteği scanner'ın merkezi servis olarak çalıştırılmasını sağlar. Pipeline scan başlatabilir ve sonucu daha sonra sorgulayabilir. Uzun süren DAST işlemlerinde asynchronous model yararlı olabilir. API token minimum yetkiyle sınırlandırılmalıdır. Job correlation ID ile sonuç doğru build'e bağlanmalıdır.

Headless execution

Headless execution scanner'ın kullanıcı arayüzü olmadan CI runner üzerinde çalışmasını sağlar. Container tabanlı scanner'larda bu özellik özellikle kullanışlıdır. Browser gerektiren testlerde headless browser desteği kullanılabilir. Job bütün dependency'leri reproducible image içinde taşıyabilir. Böylece farklı runner'larda aynı scanner davranışı elde edilir.

Authentication

Authentication desteği login arkasındaki endpoint coverage'ını belirler. Form login, cookie, token ve OAuth akışlarının projeye uygun biçimde desteklenmesi gerekir. Session renewal uzun taramalar için önemlidir. Credential'lar scanner config dosyasına düz metin yazılmamalıdır. Test service account minimum yetkiyle kullanılmalıdır.

Machine-readable report

Machine-readable report merkezi vulnerability ingestion ve otomatik gate için gereklidir. JSON, XML veya SARIF benzeri formatlar kullanılabilir. Finding identifier, endpoint, severity ve evidence alanları raporda bulunmalıdır. Sensitive response verileri gerektiğinde maskelenmelidir. Parser scanner version değişikliklerine karşı test edilmelidir.

Exit code desteği

Exit code pipeline'ın scanner sonucunu otomatik yorumlamasını sağlar. Scanner execution error ile vulnerability detected durumu birbirinden ayrılmalıdır. Her warning için non-zero exit code vermek pipeline'ı gereksiz durdurabilir. Risk threshold wrapper script veya policy engine üzerinden uygulanabilir. Log mesajı başarısızlık nedenini geliştiriciye açıkça göstermelidir.

Açık Kaynak SCA ve Supply Chain Araçları

Açık kaynak SCA ve supply chain araçları dependency envanteri, CVE taraması, SBOM üretimi ve merkezi risk takibi gibi farklı ihtiyaçlara cevap verir. Tek aracın bütün süreçleri kapsaması şart değildir. Scanner sonuçlarının standart formatta birleştirilmesi daha esnek mimari sağlar. Build pipeline hızlı taramayı, merkezi platform ise continuous monitoring görevini üstlenebilir. Araç seçiminde desteklenen package ecosystem, database update sıklığı ve CI entegrasyon kolaylığı değerlendirilmelidir.

OWASP Dependency-Check

OWASP Dependency-Check dependency bilgilerini bilinen vulnerability kayıtlarıyla eşleştirerek SCA kontrolü sağlar. Özellikle desteklediği ecosystem'lerde build pipeline'a entegre edilebilir. CVE eşleşmesinde package identification doğruluğu önemlidir. False positive durumlarında suppression mekanizması kontrollü kullanılmalıdır. Scheduled database update scanner sonucunun güncel kalmasını sağlar.

OSV-Scanner

OSV-Scanner farklı package ecosystem'lerde dependency vulnerability taraması için kullanılabilir. Lock file ve proje dependency bilgileri üzerinden bilinen kayıtlarla eşleştirme yapabilir. CI job içinde hızlı tarama amacıyla uygundur. Çıktı merkezi risk sistemine taşınabilir. Yeni vulnerability verisi geldiğinde scheduled rescan yapılması yine gereklidir.

Trivy

Trivy container, filesystem, dependency ve bazı IaC kontrollerini tek araç altında çalıştırabilir. Container image taramasında pipeline kullanımı oldukça pratiktir. Scanner database cache kullanılarak job süresi azaltılabilir. Farklı scan type sonuçları merkezi dashboard'a ayrı category olarak aktarılmalıdır. Tek araç birden fazla alanı tarasa bile coverage kalitesi her teknoloji için ayrıca değerlendirilmelidir.

Grype

Grype container image ve filesystem bileşenlerinde vulnerability taraması yapabilir. SBOM üzerinden tarama senaryosu supply chain workflow'ları için kullanışlıdır. Build sonrası image digest ile sonuç ilişkilendirilebilir. Risk gate fix available ve severity bilgisine göre ayarlanabilir. Registry rescanning ihtiyacı ayrı scheduled süreçle desteklenmelidir.

Syft

Syft container ve filesystem içeriklerinden SBOM üretmek için kullanılabilir. CycloneDX veya SPDX gibi formatlarda çıktı alınabilir. Build pipeline içinde image oluşturulduktan sonra çalıştırılması gerçek artifact içeriğini belgelemeye yardımcı olur. Üretilen SBOM digest ile ilişkilendirilmelidir. Daha sonra vulnerability scanner aynı SBOM'u input olarak kullanabilir.

Dependency-Track

Dependency-Track SBOM verisini merkezi olarak izleyerek dependency risk yönetimi sağlayabilir. CI pipeline CycloneDX dosyasını platforma gönderir. Sistem yeni vulnerability verileriyle mevcut projeleri tekrar değerlendirebilir. Böylece repository yeniden build edilmeden risk görünürlüğü güncellenir. Project ve version modelinin gerçek deployment envanteriyle uyumlu kurulması önemlidir.

Açık Kaynak Secret Scanning Araçları

Açık kaynak secret scanner'lar repository ve Git history içindeki credential pattern'lerini tespit etmek için kullanılabilir. Hızlı çalışmaları sayesinde pre-commit ve pull request seviyesinde güçlü koruma sağlarlar. Ancak scanner yalnızca sızıntıyı bulur, credential rotation sürecini otomatik olarak tamamlamaz. Sonuçlar gerçek secret olup olmadığı açısından doğrulanmalıdır. Kuruma özel key pattern'leri zamanla rule set'e eklenebilir.

Gitleaks

Gitleaks repository ve commit history üzerinde secret pattern'lerini tarayabilir. Pre-commit hook ve CI pipeline kullanımına uygundur. Custom allowlist ve rule tanımları false positive yönetiminde kullanılabilir. Yeni bulgu bulunduğunda commit veya merge durdurulabilir. Gerçek credential tespit edilirse rotation süreci hemen başlatılmalıdır.

TruffleHog

TruffleHog farklı secret pattern'leri ve bazı doğrulama yaklaşımlarıyla repository taraması için kullanılabilir. History scanning eski commit'lerde unutulan credential'ları bulmaya yardımcı olur. CI job yeni değişiklikleri kontrol etmek için daha dar kapsamda çalıştırılabilir. Doğrulama özelliği kullanılıyorsa dış servislere gönderilen request davranışı anlaşılmalıdır. Scanner raporunun secret değerini loglarda tam göstermemesi gerekir.

Pre-Commit Integration

Pre-commit integration geliştiricinin secret sızıntısını daha local aşamada görmesini sağlar. Hook staged dosyaları hızlı biçimde taramalıdır. Merkezi config repository ile rule set güncellenebilir. Local kontrol bypass edilebildiği için CI taraması yine zorunlu olmalıdır. İyi error mesajı geliştiriciye credential'ı nasıl güvenli biçimde sağlayacağını anlatmalıdır.

CI Integration

CI integration bütün push ve pull request'ler için ortak secret policy uygular. Scanner container veya binary olarak runner üzerinde çalıştırılabilir. Bulgu logunda secret değerin maskelenmesi önemlidir. Security gate yeni gerçek credential bulunduğunda pipeline'ı durdurabilir. Alert aynı zamanda incident veya rotation workflow'unu tetikleyebilir.

Security Scanner Seçerken Nelere Dikkat Edilmeli?

Security scanner seçimi yalnızca feature listesi karşılaştırmasıyla yapılmamalıdır. Gerçek repository üzerinde detection kalitesi, scan süresi, false positive oranı ve geliştirici deneyimi ölçülmelidir. CI/CD entegrasyonu, SARIF veya API desteği ve on-premise gereksinimleri de kararın parçasıdır. Lisans maliyetinin yanında bakım ve triage maliyeti hesaba katılmalıdır. Küçük bir pilot uygulama araç seçiminde teorik karşılaştırmadan daha güvenilir sonuç verir.

Dil ve Framework Desteği

Scanner uygulamanın kullandığı dili listelese bile framework özelliklerini anlamayabilir. Data flow, routing ve sanitization davranışı framework'e göre değişir. Pilot test bilinen örnek zafiyetlerle yapılmalıdır. Monorepo içinde birden fazla dil varsa her alan için farklı scanner gerekebilir. Coverage matrisi hangi repository'nin hangi araçla korunduğunu göstermelidir.

Scan Hızı

Scan hızı özellikle pull request feedback süresini doğrudan etkiler. On dakikalık scanner her commit'te çalıştırıldığında geliştirici akışını bozabilir. Incremental mode, cache ve parallelism önemli avantaj sağlar. Deep scan daha seyrek scheduled job'a taşınabilir. Ölçüm scanner'ın yalnızca CPU süresini değil feedback ready süresini dikkate almalıdır.

False Positive Oranı

Yüksek false positive oranı güvenlik programının en ciddi kullanım problemlerinden biridir. Geliştiriciler güvenmedikleri scanner sonucunu zamanla dikkate almamaya başlar. Pilot aşamada bulunan sonuçlar manuel doğrulanarak gerçek oran ölçülebilir. Rule bazında tuning yapılmalıdır. Düşük false positive ve güçlü evidence çoğu zaman daha fazla rule sayısından değerlidir.

Incremental Scan

Incremental scan büyük repository'lerde pull request analizini ciddi biçimde hızlandırabilir. Scanner'ın yalnızca changed line değil ilgili data flow'u da anlayabilmesi önemlidir. Baseline commit yönetimi merge modeline uygun olmalıdır. Full scan scheduled olarak devam etmelidir. Böylece hız ve coverage arasında dengeli bir yapı kurulabilir.

API ve CLI

API ve CLI scanner'ın CI/CD otomasyonuna kolay bağlanmasını sağlar. Non-interactive kullanım temel gereksinimdir. Config dosyalarının version control altında yönetilebilmesi tekrarlanabilirlik sağlar. API asynchronous scan ve merkezi scanner servis modeli için avantajlıdır. Authentication token'ları minimum yetkiyle sınırlandırılmalıdır.

SARIF Desteği

SARIF desteği static analysis sonuçlarını ortak code scanning platformuna taşımayı kolaylaştırır. Dosya ve satır konumu annotation üretmek için değerlidir. Ancak scanner'ın bütün metadata'sı SARIF'e tam aktarılmayabilir. Vendor-specific rapor gerekirse ayrıca saklanabilir. Standard format merkezi vulnerability normalization maliyetini azaltır.

IDE Entegrasyonu

IDE entegrasyonu geliştiriciye kod yazarken hızlı güvenlik feedback'i sunar. Aynı rule set'in CI tarafında da çalışması tutarlılık sağlar. IDE uyarıları çok fazla olduğunda geliştirici deneyimi olumsuz etkilenir. Yalnızca yüksek güvenilirlikteki kontroller burada gösterilebilir. Merkezi pipeline yine son doğrulama katmanı olarak kalmalıdır.

CI/CD Entegrasyonu

Scanner'ın hazır plugin'i olması yararlı olabilir ancak standart CLI çoğu zaman daha taşınabilir çözümdür. GitHub, GitLab, Jenkins ve Azure DevOps gibi farklı pipeline sistemlerinde aynı config kullanılabilmelidir. Exit code ve report formatı açık olmalıdır. Secret kullanım biçimi güvenli olmalıdır. Merkezi template ile entegrasyon repository bazında tekrar işi azaltır.

On-Premise Desteği

Bazı kurumlar kaynak kodun veya vulnerability verisinin dış servise gönderilmesini istemeyebilir. Bu durumda on-premise veya self-hosted scanner seçeneği önemli hale gelir. Deployment, database update ve version upgrade sorumluluğu kurumda olur. Network erişimi ve runner izolasyonu planlanmalıdır. Operasyon maliyeti lisans maliyetiyle birlikte değerlendirilmelidir.

Lisans ve Maliyet

Scanner maliyeti yalnızca yıllık lisans ücretinden oluşmaz. CI runner süresi, false positive triage ve bakım yükü de toplam maliyete dahildir. Ücretsiz araç doğru kullanıldığında çok değerli olabilir ancak kurum içinde rule ve entegrasyon bakımına ihtiyaç duyabilir. Ticari ürünlerde de otomatik olarak düşük operasyon yükü garanti değildir. Karar gerçek pilot verisi ve toplam sahip olma maliyeti üzerinden verilmelidir.

Pipeline Süresini Artırmadan Güvenlik Nasıl Eklenir?

Güvenlik kontrolü pipeline'a eklendiğinde bütün scanner'ları sırayla çalıştırmak en kolay ama çoğu zaman en verimsiz tasarımdır. Hızlı kontroller pull request kritik yolunda çalışırken derin taramalar scheduled veya asynchronous job'a taşınabilir. Incremental scanning, changed-file yaklaşımı, cache ve parallel jobs süreyi ciddi biçimde azaltır. Security gate yalnızca release kararını etkileyen sonuçları beklemelidir. Bu model fast feedback ve late enforcement yaklaşımıyla geliştirici hızını korurken güvenlik coverage'ını artırır.

Fast Feedback, Late Enforcement

Fast feedback geliştiriciye değişiklikten hemen sonra güvenlik sinyali vermeyi hedefler. Late enforcement ise daha pahalı kontrol ve kesin deployment kararını pipeline'ın uygun noktasına bırakır. Örneğin PR'da hızlı SAST çalışırken staging'de DAST gate uygulanabilir. Geliştirici riski erken görür ancak bütün deep scan'leri beklemek zorunda kalmaz. Bu yaklaşım hız ve güvenlik arasında pratik denge sağlar.

Incremental Scanning

Incremental scanning yalnızca değişen kod veya dependency alanlarını analiz ederek süreyi düşürür. Büyük repository'lerde en yüksek faydayı sağlar. Baseline ve diff bilgisi doğru yönetilmelidir. Scheduled full scan coverage boşluklarını tamamlar. Pipeline metriği bu iki tarama tipini ayrı izlemelidir.

Parallel Jobs

SAST, SCA ve IaC taramaları çoğu zaman birbirinden bağımsız çalışabilir. Aynı stage içinde paralel job tasarımı toplam bekleme süresini azaltır. Runner kapasitesi ve lisans concurrency sınırları dikkate alınmalıdır. Sonuçlar ortak security gate job'ında birleştirilebilir. Fail-fast yaklaşımı kritik erken bulgu varsa gereksiz sonraki işlemleri durdurabilir.

Scan Cache

Scanner database ve dependency cache tekrar indirme süresini azaltabilir. Cache güvenli ve version-aware tasarlanmalıdır. Çok eski vulnerability database cache'i güncel riskleri kaçırabilir. Cache key scanner version ve dependency lock bilgisi içerebilir. Shared runner ortamında cache poisoning riskine karşı erişim sınırları uygulanmalıdır.

Changed-File Scanning

Changed-file scanning pull request'te değişmeyen alanları atlayarak hızlı sonuç üretir. Secret scanning ve belirli SAST rule'ları için çok uygundur. Büyük refactor veya shared library değişikliği daha geniş scope gerektirebilir. Scanner impact analysis sunuyorsa bağlı modüller de taranabilir. Full scan periyodik güvence sağlamaya devam etmelidir.

Risk-Based Scan Scope

Risk-based scan scope her değişiklikte aynı derinliği kullanmak yerine risk sinyaline göre tarama kapsamını artırır. Authentication kodu, payment module veya public API değişikliği daha geniş security test tetikleyebilir. Dokümantasyon değişikliği ise deep DAST gerektirmeyebilir. Repository path ve service criticality bu kararda kullanılabilir. Policy otomatik olursa ekip manuel seçim yapmak zorunda kalmaz.

Nightly Full Scan

Nightly full scan uzun analizleri geliştiricinin günlük feedback süresinden ayırır. Full SAST, dependency rescan ve deep DAST bu job içinde çalışabilir. Yeni bulgular sabah ilgili ekiplerin dashboard'unda görünür. Critical sonuç için anlık bildirim tetiklenebilir. Bu yöntem hızlı PR pipeline ile geniş security coverage'ı birlikte sürdürür.

Asynchronous DAST

DAST uzun sürebildiği için bazı testler asynchronous çalıştırılabilir. Pipeline scan başlatır ve sonucu merkezi sistem daha sonra işler. Ancak release için zorunlu risk kontrolü varsa ilgili hızlı DAST profilinin sonucu beklenmelidir. Deep scan deployment sonrasında da devam edebilir. Bulgular build ve environment ID ile doğru ilişkilendirilmelidir.

Her Committe Hangi Taramalar Çalışmalıdır?

Her commit'te çalışacak kontroller hızlı ve yüksek sinyal üretmelidir. Secret scan, hızlı SAST, incremental SCA ve IaC linting çoğu proje için iyi başlangıç setidir. Bu job'lar mümkün olduğunda paralel çalıştırılmalıdır. Deep DAST veya full repository analysis her commit için gereksiz maliyet oluşturabilir. Ekip kendi pipeline süresini ölçerek birkaç dakikayı aşmayan feedback hedefi belirleyebilir.

Secret Scan

Secret scan her commit'te çalışmaya uygun olacak kadar hızlıdır. Yalnızca değişen commit aralığı taranabilir. Gerçek credential bulunursa merge doğrudan engellenebilir. Scanner logunda secret değer maskelenmelidir. Full history scan ilk geçişte veya scheduled job olarak ayrıca yapılabilir.

Hızlı SAST

Hızlı SAST kritik ve yüksek güvenilirlikteki rule set'i kullanabilir. Diff-aware analiz işlem süresini düşürür. Sonuç pull request annotation olarak geliştiriciye gösterilir. Mevcut debt yerine yeni finding odaklı gate uygulanabilir. Full SAST nightly pipeline'a bırakılabilir.

Incremental SCA

Incremental SCA yalnızca değişen manifest veya lock file'daki dependency farkını değerlendirir. Yeni vulnerable package eklendiğinde hızlı feedback verir. Dependency değişikliği yoksa job kısa sürede tamamlanabilir. Critical known-exploited dependency merge'i engelleyebilir. Full dependency monitoring merkezi sistemde devam etmelidir.

IaC Linting

IaC linting ve security scan değişen Terraform veya deployment manifest dosyalarını kontrol eder. Syntax ve güvenlik policy hataları birlikte erken görülebilir. Cloud deployment yapılmadan riskli permission değişikliği engellenebilir. Custom kurallar organization standardını yansıtabilir. Render gerektiren Helm gibi sistemlerde gerçek manifest ayrıca test edilmelidir.

Nightly veya Scheduled Scan'de Neler Çalıştırılmalıdır?

Scheduled taramalar günlük pipeline'ın zaman sınırına sığmayan geniş güvenlik kontrolleri için uygundur. Full SAST, complete dependency scan, container rescan ve deep DAST burada çalıştırılabilir. Vulnerability database güncellendiği için kod değişmese bile yeni riskler ortaya çıkabilir. Sonuçların mevcut baseline ve security debt ile karşılaştırılması önemlidir. Critical yeni bulgu bulunursa servis owner'a otomatik bildirim gönderilebilir.

Full SAST

Full SAST bütün repository ve geniş data flow ilişkilerini analiz eder. Incremental taramanın kaçırabileceği cross-module problemleri yakalayabilir. Scanner rule database güncellendiğinde eski kodda yeni finding oluşabilir. Sonuçlar baseline ile karşılaştırılmalıdır. Yeni kritik bulgular hızlı triage sürecine alınmalıdır.

Full Dependency Scan

Full dependency scan bütün direct ve transitive paketleri yeniden değerlendirir. Yeni CVE bilgileri nedeniyle kod değişmese bile finding oluşabilir. Lock file ve aktif build SBOM bilgisi birlikte kullanılabilir. Fix available sonuçlar upgrade backlog'una aktarılabilir. Production'da kullanılan sürümler öncelikli ele alınmalıdır.

Container Rescan

Container rescan registry'deki mevcut image'ları güncel vulnerability veritabanıyla karşılaştırır. Aktif deployment digest'leri ilk sırada taranmalıdır. Kullanılmayan eski image'lar düşük öncelik alabilir veya retention policy ile silinebilir. Yeni critical CVE alert oluşturabilir. Rebuild veya base image update remediation planına eklenir.

Deep DAST

Deep DAST daha geniş endpoint keşfi ve aktif test seti kullanabilir. Uzun sürmesi nedeniyle gece scheduled job'a uygundur. Authentication ve session renewal doğru çalışmalıdır. Tarama staging veya özel security environment üzerinde yürütülmelidir. Bulunan yeni riskler sabah triage kuyruğuna aktarılabilir.

Vulnerability Database Refresh

Scanner database güncelliği sonuç kalitesini doğrudan etkiler. Scheduled job başlamadan vulnerability feed güncellenebilir. Offline ortamlar için kontrollü mirror mekanizması gerekir. Database version scan raporunda kaydedilmelidir. Böylece aynı artifact'in neden farklı tarihlerde farklı finding ürettiği anlaşılabilir.

Security Debt Analysis

Scheduled süreç açık vulnerability backlog'un trendini analiz etmek için uygundur. Yeni, kapanan, SLA aşan ve yeniden açılan bulgular raporlanabilir. Ekip bazında security debt artışı erken uyarı sağlar. Yalnızca toplam sayı yerine risk ağırlıklı metrik kullanılabilir. Bu veri güvenlik iyileştirme kapasitesi planlamasında yardımcı olur.

Release Öncesi Hangi Güvenlik Kontrolleri Zorunlu Olmalıdır?

Release öncesi zorunlu kontroller uygulamanın risk seviyesine göre belirlenmelidir. Genel olarak yeni critical veya önemli high bulgular, artifact integrity, container scan, SBOM ve staging DAST sonucu değerlendirilmelidir. Security regression testleri daha önce düzeltilmiş kritik hataların geri dönmediğini doğrular. Policy-as-code gate bütün bu sonuçları ortak karar mekanizmasına bağlayabilir. Release kontrolü daha önce yapılmayan testi ilk kez çalıştıran bir nokta değil, sürekli güvenlik zincirinin son doğrulaması olmalıdır.

Critical/High New Findings

Yeni critical finding release öncesi yüksek öncelikli blocker olarak ele alınmalıdır. High bulgular asset criticality ve exposure bilgisiyle değerlendirilmelidir. Legacy security debt ayrı süreçte yönetilebilir. Finding scanner tarafından düşük confidence ile işaretlenmişse hızlı validation yapılabilir. Gate kriterleri release öncesinde değişmemeli ve ekip tarafından önceden bilinmelidir.

Artifact Integrity

Artifact integrity staging'de test edilen build ile production'a giden build'in aynı olduğunu doğrular. Container digest veya cryptographic hash bu amaçla kullanılabilir. Pipeline production'da yeniden build yapmak yerine onaylanan immutable artifact'i promote etmelidir. Signature verification ek güvence sağlar. Böylece kaynak ile deployment arasındaki supply chain değişiklik riski azalır.

Container Scan

Production'a gidecek final container digest'i release öncesinde güncel database ile taranmalıdır. Yeni critical vulnerability varsa gate policy devreye girer. Base image ve application dependency bulguları ayrıştırılabilir. Fix available bilgisi remediation kararını hızlandırır. Onaylanan digest deployment manifest'ine sabitlenmelidir.

SBOM

Release artifact'i için SBOM oluşturulmuş olması component visibility sağlar. SBOM digest ile artifact'e bağlanmalıdır. Merkezi inventory sistemine yüklenebilir. Eksik SBOM supply chain policy açısından release uyarısı veya blocker olabilir. Format ve içerik otomatik validation ile kontrol edilebilir.

Staging DAST

Staging DAST çalışan release candidate üzerinde runtime güvenlik kontrolü sağlar. Authentication ve kritik API endpoint'leri tarama kapsamına alınmalıdır. Aktif scan staging test data ile yürütülmelidir. Yeni doğrulanmış ciddi finding production geçişini durdurabilir. Report build ve environment ID ile saklanmalıdır.

Security Regression Tests

Security regression tests geçmişte düzeltilen risklerin tekrar oluşmadığını doğrular. Authorization, input validation ve authentication bug'ları için özel test yazılabilir. Bu testler scanner sonuçlarından daha deterministik olabilir. Release öncesi normal integration test paketiyle birlikte çalıştırılmalıdır. Başarısız test doğrudan deployment blocker olarak değerlendirilmelidir.

Policy-as-Code Gate

Policy-as-code gate farklı güvenlik sonuçlarını kodla tanımlanmış kurallara göre değerlendirir. Rule değişiklikleri pull request ve review sürecinden geçebilir. Environment ve service criticality bilgisi policy input'u olabilir. Exception kayıtları ayrı ve süreli tutulmalıdır. Bu yapı security gate kararını daha tutarlı ve denetlenebilir hale getirir.

Policy as Code Nedir?

Policy as Code güvenlik ve deployment kurallarının manuel doküman yerine makine tarafından değerlendirilebilir kod halinde tutulmasıdır. Repository içinde version control kullanılması politika değişikliklerini izlenebilir kılar. CI/CD pipeline scanner sonuçlarını ve environment bilgilerini policy engine'e göndererek otomatik karar alabilir. Open Policy Agent gibi araçlar bu model için kullanılabilir. Policy as Code'un asıl değeri kuralların yalnızca yazılı kalmayıp her pipeline çalışmasında aynı biçimde uygulanmasıdır.

Security Policy'leri Kod Olarak Yönetmek

Security policy kod olarak tutulduğunda review, test ve versioning sürecine dahil edilir. Örneğin production deployment için critical finding olmaması kural olarak ifade edilebilir. Policy unit test'leri beklenen input ve output davranışını doğrulayabilir. Değişiklik güvenlik ve platform ekiplerinin review'undan geçebilir. Bu yaklaşım manuel checklist hatalarını azaltır.

Repository İçinde Policy Versioning

Policy repository'si geçmiş karar kurallarını açık biçimde saklar. Hangi tarihte hangi threshold'un geçerli olduğu audit sırasında görülebilir. Tag veya release modeli kullanılarak pipeline'lar belirli policy version'a bağlanabilir. Merkezi template eski policy kullanan repository'leri tespit edebilir. Versioning kontrollü ve geriye dönük izlenebilir değişiklik sağlar.

Open Policy Agent

Open Policy Agent farklı sistemlerden gelen yapılandırılmış veriyi policy kurallarıyla değerlendirmek için kullanılabilir. CI pipeline scanner sonucu, artifact metadata ve environment bilgisini input olarak sağlayabilir. Policy sonucu allow, deny veya ek açıklama üretebilir. Kurallar uygulama kodundan ayrı yönetilebilir. Kullanılan karar modeli ekip tarafından anlaşılabilir ve test edilebilir olmalıdır.

Deployment Policy

Deployment policy hangi artifact'in hangi ortama hangi koşullarda gidebileceğini belirler. Signature, vulnerability threshold ve approval bilgisi kontrol edilebilir. Production politikası staging'e göre daha sıkı olabilir. Environment-specific kurallar merkezi olarak yönetilebilir. Policy başarısız olduğunda geliştiriciye hangi şartın sağlanmadığı açıkça gösterilmelidir.

Exception Policy

Exception policy standart kuraldan geçici sapmanın nasıl yapılacağını tanımlar. Gerekçe, owner, approval ve expiry date zorunlu alanlar olabilir. High risk exception daha yüksek yetki gerektirebilir. Süre dolduğunda istisna otomatik geçersiz hale gelmelidir. Böylece manuel bypass kalıcı güvenlik açığına dönüşmez.

Auditability

Policy-as-code güçlü auditability sağlar çünkü karar ve kullanılan policy version kaydedilebilir. Pipeline log hangi bulgunun hangi kural nedeniyle engellendiğini gösterebilir. Manual approval ve exception kayıtları aynı release ile ilişkilendirilebilir. Bu veri compliance denetiminde teknik kanıt olarak kullanılabilir. Log retention politikası kurumun denetim gereksinimleriyle uyumlu olmalıdır.

CI/CD Pipeline'ın Kendisi Nasıl Güvenceye Alınır?

Uygulama kodunu tararken pipeline'ın kendisini korumamak önemli bir güvenlik boşluğu yaratır. CI sistemi source code, signing key, cloud credential ve production deployment yetkilerine erişebilir. Bu nedenle runner, branch protection, secret management ve third-party action güvenliği ayrı threat model ile değerlendirilmelidir. Security in the pipeline kadar security of the pipeline da önemlidir. Bir saldırgan CI hesabını ele geçirirse scanner'ları atlayabilir veya güvenilir görünen zararlı artifact üretebilir.

Security in the Pipeline vs Security of the Pipeline

Security in the pipeline uygulama ve artifact üzerinde çalışan güvenlik kontrollerini ifade eder. Security of the pipeline ise bu kontrolleri çalıştıran CI altyapısının kendisini korur. Güçlü SAST kullanmak compromised runner riskini çözmez. Aynı biçimde güvenli runner kullanmak vulnerable uygulama kodunu otomatik düzeltmez. İki güvenlik alanı birlikte tasarlanmalıdır.

Least Privilege

Pipeline job'ları yalnızca görevleri için gereken minimum yetkiye sahip olmalıdır. Pull request test job'ının production deployment credential'ına erişmesi gerekmez. Token scope repository write veya cloud admin gibi geniş izinler yerine daraltılmalıdır. Job bazında ayrı permission tanımı yapılabilir. Minimum yetki compromised pipeline etkisini sınırlar.

Branch Protection

Branch protection kritik pipeline ve application koduna kontrolsüz değişiklik yapılmasını önler. Required review ve status checks güvenlik kontrollerini bypass etmeyi zorlaştırır. Force push ve admin bypass yetkileri sınırlanmalıdır. Policy değişiklikleri audit loglarda izlenmelidir. Güvenlik config dosyaları için ayrı CODEOWNERS review kuralı uygulanabilir.

Protected Environments

Protected environments production secret ve deployment yetkisini yalnızca onaylanmış job'lara açar. Pull request gibi güvenilmeyen context bu environment'a erişmemelidir. Manual approval yalnızca gerekli yüksek riskli süreçlerde kullanılabilir. Environment-specific role ve token uygulamak blast radius'u azaltır. Deployment logları hangi build'in hangi yetkiyle yayınlandığını göstermelidir.

MFA

MFA CI/CD yönetim hesabının ele geçirilmesini zorlaştırır. Özellikle admin ve organization owner hesaplarında zorunlu tutulmalıdır. Service account authentication insan MFA modelinden farklı tasarlanabilir. Uzun ömürlü ortak kullanıcı token'ları azaltılmalıdır. Identity provider conditional access politikaları ek güvenlik katmanı sağlayabilir.

Network Restrictions

CI runner'ın network erişimi yalnızca gerekli kaynaklarla sınırlandırılmalıdır. Her job'ın internal production network'e açık erişimi bulunmamalıdır. Egress control malicious dependency veya compromised build'in dışarı veri göndermesini zorlaştırabilir. Self-hosted runner segmentasyonu özellikle önemlidir. Network logları beklenmeyen bağlantıları incelemek için kullanılabilir.

Audit Logs

Audit loglar pipeline configuration, secret erişimi ve deployment olaylarını izlemek için gereklidir. Admin değişiklikleri ve branch protection bypass işlemleri kaydedilmelidir. Logların değiştirilmesi zor merkezi sisteme gönderilmesi daha güvenlidir. Retention süresi incident response ve compliance ihtiyaçlarına göre belirlenmelidir. Alerting kritik policy değişikliklerinde otomatik tetiklenebilir.

CI/CD Secret Management

CI/CD secret management scanner token'larından production credential'larına kadar bütün hassas değerlerin güvenli yaşam döngüsünü kapsar. Secret'ları YAML veya repository içinde saklamak yerine CI secret store, Vault veya cloud secret manager kullanılmalıdır. Environment ayrımı staging credential'ının production üzerinde kullanılmasını önler. Rotation ve short-lived credential yaklaşımı sızıntı etkisini azaltır. Pipeline loglarında secret masking ve minimum permission ayrıca uygulanmalıdır.

Secret'ları YAML İçinde Saklamamak

Pipeline YAML version control altında olduğu için düz metin secret için uygun yer değildir. Private repository bile credential güvenliği için yeterli kontrol değildir. Secret reference kullanılarak değer runtime sırasında alınmalıdır. Configuration file içinde yalnızca secret key adı bulunabilir. Gerçek değer log veya artifact'e yazılmamalıdır.

CI Secret Store

CI platformlarının secret store mekanizması pipeline credential'larını repository kodundan ayırır. Secret environment veya job scope ile sınırlandırılabilir. Masking desteği log sızıntısını azaltır. Ancak geniş admin erişimi olan kullanıcılar secret değerini başka job üzerinden dışarı çıkarabilir. Bu nedenle permission ve branch protection birlikte uygulanmalıdır.

Vault

Vault benzeri merkezi secret sistemleri dinamik credential ve kısa ömürlü token üretimi sağlayabilir. Pipeline job workload identity ile Vault'a kimlik doğrulayabilir. Secret yalnızca job süresi boyunca geçerli olabilir. Audit log hangi pipeline'ın hangi secret'a eriştiğini gösterebilir. Bu model statik credential kullanımını önemli ölçüde azaltır.

Cloud Secret Manager

Cloud secret manager cloud ortamındaki application ve pipeline secret'larını merkezi yönetmek için kullanılabilir. IAM policy job kimliğinin yalnızca gereken secret'a erişmesini sağlamalıdır. Environment bazında ayrı secret path veya account kullanımı faydalıdır. Rotation özelliği destekleniyorsa otomatikleştirilebilir. Secret value build artifact içine yazılmamalıdır.

Secret Rotation

Secret rotation credential'ın düzenli veya olay sonrası yenilenmesini sağlar. Manuel rotation unutulabildiği için otomasyon tercih edilir. Pipeline yeni credential'ı deploy sırasında güvenli store'dan almalıdır. Eski değer belirli geçiş süresi sonunda iptal edilebilir. Rotation başarısızlığını izleyen alert mekanizması kurulmalıdır.

Environment Separation

Development, staging ve production ortamları aynı credential'ı paylaşmamalıdır. Bir test job kompromize olduğunda production erişiminin etkilenmemesi gerekir. Secret store path, cloud account ve IAM role environment bazında ayrılabilir. Production secret yalnızca protected environment job'larında kullanılmalıdır. Bu ayrım incident blast radius'unu önemli ölçüde küçültür.

Uzun Ömürlü Cloud Credential Yerine Ne Kullanılmalı?

Uzun ömürlü cloud credential sızdığında haftalar veya aylar boyunca kötüye kullanılabilir. CI/CD için daha güvenli yaklaşım kısa süreli ve iş yüküne bağlı kimlik bilgileridir. Workload identity ve OIDC federation pipeline'ın statik access key taşımadan cloud role almasını sağlayabilir. Token permission ve lifetime minimum tutulmalıdır. Environment-specific role kullanımı staging ile production yetkilerini birbirinden ayırır.

Short-Lived Credential

Short-lived credential dakikalar veya saatlerle sınırlı geçerlilik süresine sahiptir. Sızsa bile saldırganın kullanabileceği pencere daha küçüktür. Pipeline başlangıcında kimlik doğrulama servisi tarafından üretilebilir. Job tamamlandıktan sonra token doğal olarak sona erer. Rotation operasyonu statik key modeline göre daha basit hale gelir.

Workload Identity

Workload identity CI job veya runner'a insan hesabından bağımsız kimlik sağlar. Cloud IAM bu kimliği belirli role eşleyebilir. Repository, branch veya environment claim'leri authorization kararında kullanılabilir. Statik cloud access key saklama ihtiyacı azalır. Yetki minimum privilege prensibiyle verilmelidir.

OIDC Federation

OIDC federation CI platformunun imzaladığı kısa süreli identity token ile cloud provider'dan role alınmasını sağlar. Pipeline repository ve branch bilgisi token claim'lerinde taşınabilir. Cloud tarafı yalnızca belirli claim kombinasyonlarına güvenecek şekilde yapılandırılmalıdır. Böylece uzun ömürlü secret repository veya CI store içinde tutulmaz. Token lifetime kısa olduğu için credential theft etkisi de azalır.

Least-Privilege Token

Token yalnızca job'ın yaptığı işlem için gereken permission'lara sahip olmalıdır. Build job'ın production deploy yetkisi almaması gerekir. Read-only dependency job repository write access istememelidir. Permission template'leri job türüne göre standartlaştırılabilir. Düzenli erişim review fazla yetkileri zaman içinde azaltır.

Credential Lifetime

Credential lifetime risk ile kullanım kolaylığı arasında önemli parametredir. CI job birkaç dakika sürüyorsa aylarca geçerli token gereksizdir. Token süresi beklenen job süresine küçük tolerans eklenerek belirlenebilir. Yenileme gerekiyorsa workload identity üzerinden tekrar alınabilir. Süresi geçmiş token kullanım denemeleri loglanmalıdır.

Environment-Specific Permission

Production role yalnızca protected production deployment workflow tarafından alınabilmelidir. Staging job aynı role erişmemelidir. OIDC claim veya CI environment bilgisi cloud trust policy'ye dahil edilebilir. Böylece repository içindeki zararlı değişiklik doğrudan production yetkisi elde edemez. Role kullanım logları deployment kayıtlarıyla ilişkilendirilmelidir.

Self-Hosted Runner Güvenliği

Self-hosted runner kurum ağına ve internal kaynaklara erişebildiği için güçlü güvenlik kontrolleri gerektirir. Özellikle public veya untrusted pull request kodunu persistent runner üzerinde çalıştırmak risklidir. Ephemeral runner her job için temiz ortam oluşturarak kalıcı saldırgan izlerini azaltır. Network erişimi ve secret scope minimum tutulmalıdır. Runner cleanup yalnızca workspace silmekle sınırlı kalmamalı, credential ve container kalıntıları da temizlenmelidir.

Persistent Runner Riskleri

Persistent runner birçok job arasında aynı işletim sistemi durumunu paylaşır. Kötü niyetli veya compromised job filesystem'e kalıcı dosya bırakabilir. Sonraki job başka secret veya source code'a eriştiğinde bu kalıntı risk oluşturabilir. Container izolasyonu tek başına her durumda yeterli olmayabilir. Kritik pipeline'larda ephemeral runner daha güvenli model sağlar.

Ephemeral Runner

Ephemeral runner tek job için oluşturulur ve iş bittikten sonra tamamen silinir. Her pipeline temiz sistem image'ıyla başlar. Önceki job'dan secret veya malicious process kalma ihtimali düşer. Auto-scaling altyapı bu modeli destekleyebilir. Base image güvenliği ve patch süreci yine düzenli yönetilmelidir.

Runner Isolation

Runner isolation farklı güven seviyesindeki pipeline'ların aynı host veya credential alanını paylaşmasını sınırlar. Production deployment job'ları untrusted pull request job'larından ayrı runner pool kullanabilir. Container, VM veya dedicated host seçenekleri risk seviyesine göre seçilebilir. Filesystem ve network izolasyonu birlikte ele alınmalıdır. Runner label'larının kötüye kullanılarak yüksek yetkili pool'a job yönlendirmesi engellenmelidir.

Network Access

Self-hosted runner çoğu zaman internal network'e diğer CI seçeneklerinden daha fazla erişir. Job'ın gerçekten hangi endpoint'lere ihtiyaç duyduğu belirlenmelidir. Firewall veya egress proxy ile gereksiz bağlantılar engellenebilir. Production database'e doğrudan erişim çoğu build job için gerekli değildir. Network telemetry incident investigation açısından saklanmalıdır.

Secret Exposure

Runner üzerinde environment variable, temp file veya process argument içinde secret bulunabilir. Job sonrasında güvenli cleanup yapılmadığında sonraki süreç bu değerlere erişebilir. Masking yalnızca log çıktısını korur, runtime erişimini çözmez. Ephemeral execution ve minimum secret scope bu riski azaltır. Scanner veya build tool debug mode kullanırken credential loglanmadığı kontrol edilmelidir.

Untrusted Pull Request

Fork veya harici contributor tarafından gönderilen pull request güvenilmeyen kod olarak değerlendirilmelidir. Bu kod yüksek yetkili runner veya production secret erişimiyle çalıştırılmamalıdır. Pull request validation için ayrı düşük yetkili runner pool kullanılabilir. Approval olmadan secret gerektiren workflow tetiklenmemelidir. Open source projelerde bu ayrım özellikle önemlidir.

Runner Cleanup

Runner cleanup workspace, container, temp file ve credential cache'lerini kapsamalıdır. Persistent runner kullanılıyorsa her job sonrası doğrulanmış cleanup script çalıştırılabilir. Ancak saldırganın cleanup mekanizmasını manipüle etme riski vardır. Ephemeral runner altyapının tamamını silerek daha güçlü sınır sağlar. Runner image düzenli patch ve integrity kontrolünden geçirilmelidir.

Third-Party CI/CD Action ve Plugin Güvenliği

CI/CD pipeline'a eklenen third-party action ve plugin'ler build sırasında source code ve secret'lara erişebilir. Bu nedenle normal application dependency kadar önemli supply chain bileşenleridir. Version tag yerine mümkün olduğunda doğrulanmış immutable commit SHA ile pinleme değişiklik riskini azaltır. Plugin permission minimum tutulmalı ve kullanılan bileşenler allowlist ile yönetilmelidir. Düzenli review kullanılmayan veya güvenilmeyen action'ların kaldırılmasını sağlar.

Dependency Pinning

CI action veya plugin sabitlenmemiş floating version kullanıyorsa upstream değişiklik pipeline davranışını beklenmedik biçimde değiştirebilir. Pinning kullanılan exact version'ı kontrol altında tutar. Update işlemi dependency bot veya düzenli review ile yapılabilir. Yeni version release note ve security durumu incelenmelidir. Immutable reference tercih edilmesi supply chain kontrolünü güçlendirir.

Commit SHA ile Pinleme

Commit SHA ile pinleme action'ın belirli kaynak kod snapshot'ını kullanmasını sağlar. Tag sonradan farklı commit'e taşınabilirse SHA daha güvenilir referanstır. Ancak update yönetimi düzenli yapılmalıdır çünkü eski sürüm güvenlik düzeltmelerini kaçırabilir. SHA yanında okunabilir version comment eklemek bakım kolaylığı sağlar. Organization policy belirli source'lar için SHA pinning zorunlu kılabilir.

Compromised Action Riski

Compromised action pipeline secret'larını okuyabilir veya build artifact'i değiştirebilir. Action'a yalnızca gereken permission ve secret verilmelidir. Pull request job'larında production credential hiç bulunmamalıdır. Kritik third-party action'lar güvenlik review sürecine alınabilir. Mümkün olduğunda basit işlevler için küçük internal script daha anlaşılır güven sınırı sağlayabilir.

Plugin Permission

Plugin'in istediği permission görevinden daha geniş olabilir. Repository write, package publish veya cloud access gibi izinler ayrı ayrı değerlendirilmelidir. Default token permission minimum seviyede tutulmalıdır. Job bazında permission artırmak daha güvenlidir. Kullanılmayan plugin kaldırıldığında ilgili credential ve permission da temizlenmelidir.

Supply Chain Review

Supply chain review kullanılan action, plugin ve build tool kaynaklarını envantere alır. Maintainer durumu, release geçmişi ve security response süreci değerlendirilebilir. Kritik pipeline dependency'leri düzenli olarak güncellenmelidir. SBOM benzeri CI dependency envanteri oluşturmak faydalıdır. Güvenilmeyen veya terk edilmiş bileşenler kontrollü alternatifle değiştirilmelidir.

Allowlist

Allowlist yalnızca onaylanan action ve plugin'lerin CI ortamında kullanılmasına izin verir. Merkezi organization policy geliştiricinin rastgele üçüncü taraf kodunu yüksek yetkili pipeline'a eklemesini önleyebilir. Yeni araç talebi hızlı review süreciyle değerlendirilebilir. Allowlist çok dar tutulup geliştiriciyi bypass yöntemlerine itmemelidir. Onay kriterleri açık ve uygulanabilir olmalıdır.

Software Supply Chain Security

Software supply chain security yalnızca uygulama koduna değil dependency kaynaklarına, build altyapısına ve artifact dağıtım zincirine odaklanır. Dependency confusion, typosquatting, malicious package ve compromised build server bu alandaki önemli risklerdir. Package registry güvenliği ve artifact signing teknik kontrollerin temel parçalarıdır. Build provenance hangi kaynaktan hangi artifact'in üretildiğini kanıtlamaya yardımcı olur. CI/CD güvenliği supply chain perspektifi olmadan eksik kalır.

Dependency Confusion

Dependency confusion package manager'ın internal paket yerine saldırganın public registry'deki aynı isimli paketini seçmesiyle oluşabilir. Internal namespace ve registry priority kuralları bu riski azaltır. Build sistemi yalnızca onaylanan registry kaynaklarına erişmelidir. Package lock ve integrity hash doğrulaması ek koruma sağlar. Şüpheli package indirme olayları proxy veya registry loglarında izlenebilir.

Typosquatting

Typosquatting popüler package adına çok benzeyen zararlı paketlerin yanlışlıkla kurulmasını hedefler. Pull request SCA veya dependency policy yeni package isimlerini görünür hale getirebilir. Package ekleme işlemleri özellikle kritik projelerde code review gerektirmelidir. Internal proxy veya allowlist yaklaşımı risk azaltabilir. Otomatik dependency update araçları da yalnızca güvenilir registry ile çalışmalıdır.

Malicious Package

Malicious package doğrudan zararlı kod içerebilir veya maintainer hesabı ele geçirildikten sonra kötü release yayınlanabilir. Bilinen CVE taraması her zararlı package'ı yakalayamaz. Package provenance, maintainer güveni ve davranış analizi ek sinyal sağlar. Build runner'ın network ve secret erişimini sınırlamak olası zararı azaltır. Yeni dependency eklenmesi security review gerektiren yüksek riskli servislerde daha sıkı yönetilebilir.

Build Server Compromise

Build server compromise güvenilir source code'dan zararlı artifact üretilmesine neden olabilir. Runner isolation, patch yönetimi ve minimum privilege bu riski azaltır. Build provenance hangi runner ve workflow'un artifact ürettiğini kaydeder. Artifact signing yalnızca güvenli build identity tarafından yapılmalıdır. Şüpheli build durumunda signing key ve runner logları incident investigation için kritik veri sağlar.

Artifact Tampering

Artifact build sonrasında registry veya dağıtım yolunda değiştirilirse source code review tek başına koruma sağlayamaz. Cryptographic signing ve digest verification artifact bütünlüğünü doğrulamaya yardımcı olur. Deployment sistemi yalnızca onaylı signature ve digest taşıyan artifact'i kabul etmelidir. Mutable tag kullanımı minimize edilmelidir. Registry audit logları beklenmeyen push veya tag değişikliklerini gösterebilir.

Package Registry Güvenliği

Package registry kurumsal dependency ve release zincirinin kritik bileşenidir. Publish permission minimum kullanıcı ve CI identity ile sınırlandırılmalıdır. MFA insan publisher hesaplarında zorunlu tutulabilir. Immutable version ve retention policy artifact değişimini kontrol eder. Registry audit logları package publish ve delete olaylarını merkezi sisteme göndermelidir.

SLSA Nedir?

SLSA, yazılım artifact'lerinin kaynak ve build süreçleri için güvence seviyelerini tanımlayan supply chain yaklaşımıdır. Temel amaç hangi source'un hangi build süreciyle hangi artifact'i ürettiğini doğrulanabilir hale getirmektir. Build provenance ve attestation bu modelde önemli rol oynar. CI/CD pipeline güvenilir build identity ve kontrollü runner kullanarak daha güçlü provenance üretebilir. SLSA yaklaşımı artifact signing ve deployment verification ile birlikte değerlendirildiğinde supply chain güvenliğini önemli ölçüde güçlendirir.

Software Supply Chain Levels for Software Artifacts

SLSA yazılım tedarik zincirindeki riskleri azaltmak için aşamalı güvence yaklaşımı sunar. Kurum bütün gereksinimleri tek seferde uygulamak zorunda değildir. İlk aşamada build provenance üretmek, ardından build izolasyonu ve doğrulamayı güçlendirmek mümkündür. Olgunluk seviyesi uygulamanın risk profiline göre artırılabilir. Amaç checklist tamamlamak değil artifact güvenilirliğini ölçülebilir biçimde yükseltmektir.

Build Provenance

Build provenance artifact'in hangi source, workflow ve build environment üzerinden üretildiğini belgeleyen metadata'dır. Commit SHA, builder identity ve artifact digest gibi bilgiler içerebilir. Provenance imzalanırsa değiştirilmesi daha zor hale gelir. Deployment policy bu kaydı doğrulayabilir. Incident sırasında production artifact'in gerçekten onaylanan pipeline'dan gelip gelmediği kontrol edilebilir.

Source Provenance

Source provenance build'in hangi repository ve commit'e dayandığını gösterir. Branch protection ve signed commit politikaları bu güven zincirini destekleyebilir. Build sistemi source reference'ı provenance kaydına eklemelidir. Mutable branch adı tek başına yeterli değildir, immutable commit ID kullanılmalıdır. Böylece artifact ile incelenen kod arasında güvenilir bağlantı kurulur.

Trusted Build Process

Trusted build process yetkileri sınırlandırılmış, izole ve doğrulanabilir CI ortamında çalışır. Untrusted pull request aynı signing yetkisine sahip olmamalıdır. Runner image ve pipeline config değişiklikleri review edilmelidir. Build secret'ları kısa süreli credential ile sağlanabilir. Süreç ne kadar kontrol altındaysa provenance kaydının değeri o kadar artar.

Attestation

Attestation build veya güvenlik kontrolü hakkında imzalı doğrulanabilir beyan sağlar. Artifact'in belirli scanner'dan geçtiği veya belirli workflow'da üretildiği ifade edilebilir. Deployment policy attestation olmadan production'a izin vermeyebilir. Attestation içeriği artifact digest ile bağlanmalıdır. İmza anahtarı veya identity güven modeli ayrıca korunmalıdır.

CI/CD Pipeline'da SLSA Yaklaşımı

CI/CD içinde SLSA yaklaşımı immutable source reference, izole build ve provenance üretimiyle başlayabilir. Artifact build sonrasında imzalanır ve metadata registry'de saklanır. Deployment sistemi signature ve provenance kontrolü yapar. Policy yalnızca güvenilir builder identity'den gelen artifact'i kabul eder. Bu model uygulama scanner'larından bağımsız ama onları tamamlayan supply chain güvenliği sağlar.

Artifact Signing Nedir?

Artifact signing build çıktısının kim tarafından üretildiğini ve sonradan değiştirilmediğini doğrulamaya yardımcı olan kriptografik kontroldür. Container image, binary veya package build sonrasında imzalanabilir. Deployment aşamasında signature verification uygulanır. İmza artifact digest'e bağlı olmalıdır. Signing key veya workload identity güvenliği bütün modelin temelidir.

Build Artifact'ın Kimliğini Doğrulamak

Artifact kimliği hash veya digest üzerinden tanımlanabilir. Signature bu immutable değere bağlanarak belirli build identity tarafından onaylandığını gösterir. Deployment sistemi tag yerine digest doğrulamalıdır. Aynı tag başka image'a taşınırsa signature policy bunu fark edebilir. Build provenance ile birlikte artifact'in kaynak ilişkisi daha açık hale gelir.

Container Image Signing

Container image signing registry'ye gönderilen image digest'inin güvenilir build tarafından imzalanmasını sağlar. Signature registry yanında veya ayrı metadata store içinde tutulabilir. Production admission policy yalnızca doğrulanmış image'lara izin verebilir. Developer lokal build'i signing yetkisine sahip olmamalıdır. CI workload identity bu görevi daha kontrollü şekilde üstlenebilir.

Signature Verification

Signature verification artifact kullanılmadan önce imzanın geçerli ve güvenilir identity'ye ait olduğunu kontrol eder. Public key veya keyless identity modeli kullanılabilir. Verification başarısızsa deployment durdurulmalıdır. Trust policy hangi signer'ların hangi environment için kabul edildiğini tanımlar. Verification logu audit kaydı olarak saklanabilir.

Deployment Öncesi Verification

Deployment öncesi verification staging'de test edilen artifact'in production'a giderken değiştirilmediğini doğrular. Digest, signature ve provenance birlikte kontrol edilebilir. Policy engine bu kararı otomatik verebilir. Manual bypass sıkı yetki ve audit gerektirmelidir. Başarılı verification deployment güven zincirinin önemli son adımlarından biridir.

Tamper-Resistant Release Process

Tamper-resistant release process source code'dan production deployment'a kadar artifact değişikliklerini zorlaştırır. Immutable build, signature, provenance ve protected environment bu yapının temel parçalarıdır. Artifact production için yeniden build edilmemelidir. Onaylanan aynı digest ortamlar arasında promote edilmelidir. Böylece test edilen ile yayınlanan çıktı arasındaki fark azaltılır.

Security Regression Testing

Security regression testing daha önce düzeltilen güvenlik hatasının gelecekte tekrar oluşmasını önleyen otomatik test yaklaşımıdır. Scanner bulgusu kapatılırken yalnızca kod düzeltmesi yapmak yerine exploit veya hatalı davranışı tekrar eden test eklemek değerlidir. Unit, integration ve DAST seviyesinde regression case oluşturulabilir. Test normal CI pipeline içinde çalıştırılır. Böylece geçmiş incident ve vulnerability bilgisi kalıcı güvenlik kontrolüne dönüşür.

Düzeltilen Bir Zafiyet İçin Test Yazmak

Bir authorization problemi düzeltildiğinde başka kullanıcıya ait kayda erişimin başarısız olduğunu doğrulayan test eklenebilir. SQL injection için parametrik query davranışı unit veya integration test ile doğrulanabilir. Test zafiyetin teknik root cause'una odaklanmalıdır. Scanner gelecekte rule değiştirirse bile regression test aynı güvenlik davranışını korur. Bu yaklaşım remediation kalitesini artırır.

Güvenlik Hatalarının Yeniden Oluşmasını Önlemek

Aynı güvenlik hatasının tekrar oluşması genellikle bilgi kaybı veya eksik otomasyon nedeniyle yaşanır. Regression test öğrenilen dersin kod haline getirilmesini sağlar. Test failure geliştiriciye güvenlik problemi henüz merge olmadan görünür. Kritik incident'ler için regression test zorunlu closure kriteri olabilir. Zamanla proje kendi risk geçmişine göre güçlü test kütüphanesi oluşturur.

Unit-Level Security Test

Unit-level security test validation, escaping veya authorization helper gibi küçük bileşenlerin beklenen davranışını kontrol eder. Hızlı çalıştığı için her commit'te uygulanabilir. External scanner'a bağımlı değildir. Ancak gerçek deployment veya servis entegrasyon problemlerini göremez. Integration ve DAST seviyesindeki testlerle tamamlanmalıdır.

Integration Security Test

Integration security test birden fazla component ve gerçek authentication akışını birlikte değerlendirir. API endpoint'e farklı role sahip kullanıcıyla request gönderilebilir. Database ve authorization policy etkileşimi test edilir. Pipeline'da normal integration test aşamasına eklenebilir. Hızlı ve deterministik olması release gate için avantaj sağlar.

DAST Regression Case

DAST regression case daha önce bulunan web veya API vulnerability'sini kontrollü request ile tekrar test eder. Generic full scanner yerine belirli endpoint ve payload hedeflenebilir. Bu test kısa sürdüğü için her staging deployment'ta çalıştırılabilir. Sonuç zafiyetin gerçekten kapalı kaldığını doğrular. Deep DAST yine daha geniş risk keşfi için devam etmelidir.

CI/CD Güvenlik Programında Hangi Metrikler İzlenmelidir?

Güvenlik programını yalnızca açık vulnerability sayısıyla ölçmek yeterli değildir. Triage süresi, remediation süresi, production'a kaçan risk oranı, false positive ve scanner runtime gibi süreç metrikleri birlikte izlenmelidir. Metrikler ekipleri cezalandırmak yerine darboğazları bulmak için kullanılmalıdır. Repository ve service criticality bilgisi sonuçları daha anlamlı hale getirir. Zaman içindeki trend tek bir haftalık sayıdan daha değerlidir.

Mean Time to Triage

Mean Time to Triage yeni bulgunun oluşturulması ile ilk doğrulama ve öncelik kararının verilmesi arasındaki süreyi ölçer. Uzun triage süresi scanner sonuçlarının kuyrukta beklediğini gösterir. Otomatik deduplication ve enrichment bu süreyi azaltabilir. Critical bulgular için ayrı hedef belirlenebilir. Metrik scanner veya ekip bazında karşılaştırılabilir.

Mean Time to Remediate

Mean Time to Remediate doğrulanmış vulnerability'nin düzeltilmesine kadar geçen süreyi ölçer. Risk seviyesine göre farklı hedefler kullanılmalıdır. Dependency update ve büyük architectural fix aynı remediation süresine sahip olmayabilir. Trend artıyorsa ekip kapasitesi veya ownership problemi araştırılabilir. Risk accepted kayıtlar metriğe ayrı kategori olarak yansıtılmalıdır.

Vulnerability Escape Rate

Vulnerability Escape Rate pre-production kontrollerinden kaçıp production'da bulunan güvenlik sorunlarının oranını gösterir. Bu metrik security coverage'ın pratik etkisini değerlendirmeye yardımcı olur. Incident veya bug bounty bulguları pipeline'daki kaçırılan kategoriyle eşleştirilebilir. Tekrar eden pattern için yeni SAST, DAST veya regression test kuralı eklenebilir. Amaç zamanla aynı risk türünün production'a ulaşma oranını düşürmektir.

Pre-Production Detection Rate

Pre-Production Detection Rate güvenlik problemlerinin ne kadarının release öncesinde bulunduğunu ölçer. Yüksek oran shift-left ve staging kontrollerinin etkili çalıştığını gösterebilir. Ancak scanner'ın çok fazla düşük değerli finding üretmesi metriği yapay biçimde yükseltmemelidir. Yalnızca doğrulanmış riskler üzerinden hesaplama yapmak daha anlamlıdır. Incident verisiyle birlikte değerlendirilmelidir.

False Positive Rate

False Positive Rate scanner sonuç kalitesinin önemli göstergesidir. Yüksek oran geliştirici güvenini ve triage kapasitesini olumsuz etkiler. Rule, dil ve repository bazında ayrıştırılabilir. Tuning sonrasında oranın değişimi ölçülmelidir. Scanner performansı yalnızca kaç finding bulduğuyla değil ne kadar doğru bulduğu ile değerlendirilmelidir.

Security Gate Failure Rate

Security Gate Failure Rate pull request veya release'lerin ne kadarının güvenlik kuralına takıldığını gösterir. Çok yüksek oran policy'nin fazla sert veya codebase'in güvenlik durumunun zayıf olduğunu gösterebilir. Çok düşük oran scanner coverage eksikliğini de işaret edebilir. Failure reason kategorileri ayrı izlenmelidir. Zaman içinde yeni finding policy'nin etkisi analiz edilebilir.

Findings per Pull Request

Findings per Pull Request geliştiricilerin yeni değişikliklerle ne kadar güvenlik borcu eklediğini ölçmeye yardımcı olur. Ortalama değer zamanla düşüyorsa secure coding eğitimleri ve erken feedback etkili olabilir. Büyük refactor pull request'leri metriği geçici yükseltebilir. Severity ağırlıklı ölçüm düz sayıdan daha anlamlı olabilir. Takım bazında kıyaslama yapılırken proje risk ve dil farklılıkları hesaba katılmalıdır.

Reopened Vulnerabilities

Reopened vulnerability daha önce kapatılan bir riskin tekrar görünmesini ifade eder. Yüksek oran remediation kalitesi veya regression test eksikliği gösterebilir. Kapanış sürecinde rescan ve güvenlik testi zorunlu hale getirilebilir. Tekrarlanan pattern için reusable fix guidance hazırlanabilir. Bu metrik uzun vadeli düzeltme kalitesini değerlendirmede yararlıdır.

Security Debt

Security debt zaman içinde biriken açık vulnerability yükünü ifade eder. Yalnızca finding sayısı değil risk ağırlıklı skor ve SLA durumu izlenmelidir. Legacy ve new finding ayrı gösterilmelidir. Backlog sürekli artıyorsa security capacity veya root cause problemi vardır. Belirli sprint kapasitesini security debt azaltımına ayırmak gerekebilir.

Scanner Runtime

Scanner runtime geliştirici feedback süresini ve CI maliyetini etkiler. P50 ve P95 süreleri birlikte izlenebilir. Cache, incremental scanning ve parallelism iyileştirmelerinin etkisi bu metrikle ölçülür. Derin scheduled taramalar günlük PR scan süresinden ayrı değerlendirilmelidir. Scanner güncellemesi sonrası ani runtime artışı erken fark edilebilir.

Security Coverage Nasıl Ölçülür?

Security coverage bir organizasyonda hangi repository, dil, pipeline, dependency, container ve endpoint'lerin güvenlik kontrolünden geçtiğini ölçer. Yalnızca scanner kurulmuş olması gerçek coverage anlamına gelmez. Authentication çalışmayan DAST job teknik olarak başarılı görünse bile önemli endpoint'leri taramamış olabilir. Bu nedenle kapsam varlık envanteriyle karşılaştırılmalıdır. Coverage metriği güvenlik programındaki görünmeyen boşlukları bulmak için kullanılır.

Repository Coverage

Repository coverage aktif kod repository'lerinin ne kadarında gerekli security pipeline bulunduğunu gösterir. Archive veya demo repository'ler ayrı sınıflandırılabilir. Critical production servisleri yüzde yüz coverage hedefleyebilir. Merkezi template adoption metriği otomasyonu kolaylaştırır. Scanner job'ın yalnızca var olması değil düzenli başarılı çalışması da ölçülmelidir.

Language Coverage

Language coverage kullanılan programlama dillerinin uygun SAST scanner tarafından desteklenip desteklenmediğini ölçer. Monorepo içinde küçük bir unsupported dil alanı görünmeyebilir. Code inventory bu alanları tespit edebilir. Framework-specific rule coverage ayrıca değerlendirilebilir. Yeni teknoloji eklenirken güvenlik tooling desteği platform checklist'ine dahil edilmelidir.

Pipeline Coverage

Pipeline coverage hangi build ve deployment akışlarında zorunlu security gate bulunduğunu gösterir. Bazı legacy servisler manuel deployment yaptığı için merkezi kontrolden kaçabilir. Production deployment path'leri envantere alınmalıdır. Güvenlik policy tüm resmi deployment yollarında uygulanmalıdır. Shadow pipeline veya manuel bypass ayrı risk olarak izlenmelidir.

Dependency Coverage

Dependency coverage kullanılan package ecosystem'lerin SCA tarafından ne ölçüde tarandığını gösterir. Manifest taraması ile final artifact taraması arasında fark olabilir. Runtime dependency'ler ayrıca kontrol edilmelidir. SBOM coverage bu metriği güçlendirir. Unsupported package manager kullanan servisler ayrı remediation planına alınabilir.

Container Coverage

Container coverage production'da kullanılan image'ların ne kadarının build ve registry taramasından geçtiğini ölçer. Image digest envanteri deployment sistemiyle ilişkilendirilebilir. Tag bazlı sayım yanıltıcı olabilir. Aktif image'ların düzenli rescanning durumu ayrıca ölçülmelidir. Tarama yapılmamış image production gate tarafından engellenebilir.

Endpoint Coverage

Endpoint coverage DAST veya API scanner'ın uygulamanın gerçek endpoint setinin ne kadarına eriştiğini gösterir. OpenAPI tanımı beklenen endpoint listesi için referans olabilir. Crawler'ın yalnızca ana sayfayı taraması yüksek coverage anlamına gelmez. Kritik endpoint'ler özel allowlist ile zorunlu tarama kapsamına alınabilir. Coverage raporu scanner success metriğinden ayrı tutulmalıdır.

Authenticated DAST Coverage

Authenticated DAST coverage login arkasındaki işlevlerin gerçekten taranıp taranmadığını ölçer. Scanner session kaybettiğinde coverage ciddi biçimde düşebilir. Farklı role sahip kullanıcı hesapları ayrı coverage alanı oluşturur. Test sonrasında ziyaret edilen endpoint listesi beklenen route inventory ile karşılaştırılabilir. Bu ölçüm dynamic scan'in gerçek değerini anlamak açısından önemlidir.

DevSecOps'ta Security SLA Nasıl Belirlenir?

Security SLA vulnerability'nin risk seviyesine göre ne kadar sürede değerlendirilmesi ve düzeltilmesi gerektiğini tanımlar. Tek bir sabit süre bütün bulgular için uygun değildir. Critical internet-facing riskler kısa sürede ele alınırken düşük riskli internal bulgular daha uzun planlanabilir. Exploitability ve business context SLA'yı etkileyebilir. SLA gerçekçi olmalı, sürekli ihlal edilen hedefler yerine risk azaltımını yönlendirmelidir.

Critical Vulnerability

Critical vulnerability yüksek etki ve ciddi saldırı potansiyeli taşıdığı için hızlı triage gerektirir. Internet-facing ve exploitable durumlarda remediation süresi çok kısa tutulabilir. Geçici compensating control gerekiyorsa hemen uygulanmalıdır. Risk acceptance en yüksek yetki seviyesinde yapılmalıdır. Düzeltme sonrasında rescan ve regression test zorunlu olmalıdır.

High Vulnerability

High vulnerability önemli teknik etki taşır ancak gerçek öncelik exposure ve exploitability bilgisine bağlıdır. Public kritik servislerde hızlı SLA uygulanabilir. Internal düşük değerli sistemlerde daha uzun süre makul olabilir. Fix available dependency high bulguları otomatik upgrade süreciyle hızlandırılabilir. SLA breach merkezi dashboard'da görünür olmalıdır.

Medium Vulnerability

Medium vulnerability genellikle planlı sprint çalışması içinde ele alınabilir. Ancak aktif exploit veya hassas veri etkisi varsa öncelik yükseltilebilir. Çok sayıda medium bulgunun birikmesi security debt oluşturabilir. Risk bazlı batching remediation verimliliğini artırabilir. SLA yalnızca severity adına göre değil uygulama bağlamıyla belirlenmelidir.

Low Vulnerability

Low vulnerability düşük teknik etkiye sahip olsa da tamamen unutulmamalıdır. Secure configuration iyileştirmeleri veya defense-in-depth kontrolleri bu grupta olabilir. Çok sayıda benzer low finding ortak root cause gösterebilir. Scheduled maintenance sırasında toplu remediation yapılabilir. Policy bazı informational bulguları SLA dışında advisory olarak tutabilir.

Internet-Facing Sistemler

Internet-facing sistemler daha fazla saldırgan tarafından erişilebildiği için aynı vulnerability için daha kısa SLA gerektirebilir. Asset inventory exposure bilgisini vulnerability platformuna aktarmalıdır. Public API ve login endpoint'leri özel risk kategorisine alınabilir. Network restriction uygulanması geçici risk azaltımı sağlayabilir. Exposure değiştiğinde SLA otomatik yeniden hesaplanabilir.

Risk-Based SLA

Risk-based SLA severity, exploitability, exposure ve business criticality gibi sinyalleri birlikte kullanır. Bu model yalnızca scanner label'ına göre süre belirlemekten daha anlamlıdır. Policy otomatik hesaplanabilir ve finding oluşturulduğunda due date atanabilir. Risk değişirse SLA yeniden değerlendirilebilir. Yönetim raporları ekiplerin yalnızca sayı değil gerçek risk azaltım performansını göstermelidir.

SAST ve DAST Compliance Süreçlerine Nasıl Katkı Sağlar?

SAST ve DAST otomatik güvenlik kontrollerinin düzenli çalıştığını gösteren teknik kanıt sağlayabilir. Compliance açısından scanner raporu tek başına yeterli değildir ancak secure development sürecinin uygulandığını destekler. Pipeline logları hangi commit'in hangi kontrolden geçtiğini gösterebilir. Vulnerability SLA ve risk acceptance kayıtları bulguların nasıl yönetildiğini belgeler. PCI DSS, ISO 27001, SOC 2 ve KVKK bağlamında gerçek yükümlülükler kurumun kapsamı ve ilgili kontrol setine göre ayrıca değerlendirilmelidir.

PCI DSS

Ödeme kartı verisi kapsamındaki sistemlerde güvenli yazılım geliştirme ve vulnerability management kontrolleri önemli rol oynar. SAST ve DAST düzenli uygulama güvenliği testlerine teknik destek sağlayabilir. Pipeline raporlarının hangi release'e ait olduğu açıkça kaydedilmelidir. Critical bulgu remediation ve approval kayıtları audit evidence olarak değerlendirilebilir. Kesin PCI DSS gereksinimleri kurumun scope ve geçerli standard sürümüne göre uzman ekip tarafından doğrulanmalıdır.

ISO 27001

ISO 27001 kapsamındaki güvenli geliştirme ve değişiklik yönetimi uygulamalarında otomatik security pipeline faydalı kanıt sağlayabilir. Policy-as-code ve branch protection süreçlerin tekrarlanabilir uygulanmasını destekler. Vulnerability triage ve risk acceptance kayıtları risk yönetimiyle ilişkilendirilebilir. Audit log hangi kontrolün ne zaman çalıştığını gösterebilir. Sertifikasyon değerlendirmesi yalnızca scanner kullanımına değil organizasyonun bütün yönetim sistemine bağlıdır.

SOC 2

SOC 2 kontrollerinde değişiklik yönetimi, erişim güvenliği ve vulnerability süreçleri ilgili kapsamda değerlendirilebilir. CI/CD logları code review ve test adımlarının uygulandığını gösterebilir. Protected environment ve least privilege pipeline erişim kontrollerine teknik destek sağlar. Güvenlik bulgularının SLA ile yönetilmesi operasyonel kanıt oluşturur. Kesin kontrol eşlemesi kurumun belirlediği trust services criteria ve denetim kapsamına göre yapılmalıdır.

KVKK ve Güvenli Yazılım Geliştirme

Kişisel veri işleyen uygulamalarda güvenli geliştirme kontrolleri veri güvenliği hedeflerini destekler. SAST input handling ve kod seviyesindeki riskleri erken gösterebilir. DAST production'a benzer ortamda authentication ve exposure problemlerini ortaya çıkarabilir. Scanner raporlarında gerçek kişisel veri kullanılmaması veya maskelenmesi önemlidir. Hukuki yükümlülüklerin uygulanması için KVKK kapsamı ayrıca hukuk ve bilgi güvenliği uzmanlarıyla değerlendirilmelidir.

Audit Evidence

Audit evidence scanner raporundan daha geniş bir kayıt setini kapsar. Pipeline execution logu, policy version, approval, exception ve remediation kanıtı birlikte tutulabilir. Artifact digest kaydı hangi release'in test edildiğini gösterir. Otomatik retention policy geçmiş verinin erişilebilir kalmasını sağlar. Sensitive log içeriği veri koruma politikasına uygun biçimde saklanmalıdır.

Pipeline Loglarının Denetimde Kullanılması

Pipeline logları security job'ın belirli build üzerinde çalıştığını gösterebilir. Log bütünlüğü ve retention süresi önemlidir. Scanner version ve policy version kaydedilirse geçmiş karar yeniden anlaşılabilir. Manuel approval veya bypass olayı ayrıca audit event olarak tutulmalıdır. Denetimde yalnızca başarılı job'lar değil exception süreçleri de açık biçimde gösterilebilmelidir.

AI ile Üretilen Kod CI/CD Güvenlik Taramalarını Nasıl Etkiliyor?

Kod üretim araçları geliştiricilerin daha kısa sürede daha fazla kod oluşturmasını sağlayabildiği için güvenlik feedback hızının önemi artıyor. Üretilen kod yine normal source code gibi SAST, SCA, secret scanning ve code review süreçlerinden geçirilmelidir. Tekrarlanan güvensiz pattern'ler daha büyük codebase'e daha hızlı yayılabilir. Dependency önerileri de doğrulanmadan projeye eklenmemelidir. İnsan code review ve otomatik security gate birlikte kullanıldığında üretim hızının güvenlik kontrolünü aşması önlenebilir.

Artan Kod Üretim Hızı

Daha hızlı kod üretimi daha fazla pull request ve daha sık deployment anlamına gelebilir. Manuel security review kapasitesi aynı hızda artmayabilir. Otomatik SAST ve policy gate bu nedenle daha önemli hale gelir. Scanner feedback süresi geliştirici akışına uyum sağlamalıdır. Incremental scan ve PR annotation yüksek değişiklik hacmini yönetmeye yardımcı olur.

Güvensiz Pattern'lerin Tekrarlanması

Bir kod üretim aracı yanlış security pattern önerdiğinde aynı hata farklı modüllerde tekrar edilebilir. SAST custom rule belirli riskli pattern'i bütün repository'de tespit edebilir. Secure coding template ve internal examples geliştirici yönlendirmesini iyileştirir. Code review yalnızca işlevselliğe değil güvenlik davranışına da bakmalıdır. Tekrarlanan finding root cause eğitimi veya rule geliştirme fırsatı olarak değerlendirilmelidir.

AI-Generated Dependency Riski

Üretilen örnek kod mevcut olmayan, eski veya güvenilmeyen dependency önerebilir. Yeni package otomatik olarak kurulmadan önce registry ve package metadata doğrulanmalıdır. SCA ve allowlist policy dependency ekleme sürecini kontrol edebilir. Lock file review önemlidir. Kritik projelerde yeni dependency için maintainer ve supply chain değerlendirmesi yapılabilir.

SAST'ın Rolü

SAST kodun insanlar veya otomatik araçlar tarafından yazılmış olmasına bakmadan aynı güvenlik kurallarını uygular. Bu tarafsızlık hızlı kod üretim ortamında önemlidir. Pull request scanner riskli data flow veya API kullanımını erken gösterebilir. Custom rules kurumun istemediği pattern'leri engelleyebilir. Scanner sonucu yine insan tarafından bağlam içinde değerlendirilmelidir.

Human Code Review

Human code review business logic ve authorization gibi scanner'ın tam anlayamadığı alanlarda önemini korur. Reviewer kodun gereksiz dependency ekleyip eklemediğini ve güven modelini değiştiren davranışları değerlendirebilir. Otomatik scanner review yükünü azaltarak insanı daha yüksek bağlam gerektiren kararlara yönlendirir. Generated code'un kaynak belirtilmeden güvenilir olduğu varsayılmamalıdır. Review standardı kodun nasıl üretildiğine göre gevşetilmemelidir.

AI-Generated Code İçin Güvenlik Gate'i

Üretilen kod için ayrı ve daha gevşek pipeline uygulanması doğru değildir. Aynı SAST, SCA, secret ve test politikaları bütün kaynak kod değişiklikleri için çalışmalıdır. Riskli modüllerde ek review zorunlu tutulabilir. Dependency ve network erişimi değiştiren pull request'ler daha geniş security scan tetikleyebilir. Gate'in kaynağa değil değişikliğin riskine göre davranması daha sürdürülebilir modeldir.

LLM ve RAG Uygulamaları İçin SAST/DAST Yeterli midir?

Hayır, SAST ve DAST LLM ve RAG uygulamalarındaki bütün güvenlik risklerini kapsamaz. Geleneksel application security problemleri yine bulunduğu için bu kontroller gereklidir. Ancak prompt injection, RAG data leakage, tool authorization ve model-specific abuse senaryoları ayrı test yaklaşımı ister. Model endpoint ve surrounding API klasik güvenlik testlerinden geçirilmelidir. Bunun yanında AI red teaming ve uygulamaya özel abuse case testleri eklenmelidir.

Geleneksel Application Security

LLM kullanan uygulamalar yine web API, database, authentication ve cloud altyapısı üzerinde çalışır. SQL injection, broken authorization veya secret exposure riskleri ortadan kalkmaz. SAST, DAST, SCA ve IaC scanning bu katmanlarda normal şekilde uygulanmalıdır. Model özelliği geleneksel AppSec kontrolünün yerine geçmez. AI-specific testler mevcut security pipeline'ın üzerine ek katman oluşturur.

Prompt Injection

Prompt injection kullanıcı girdisinin model talimatlarını manipüle ederek beklenmeyen davranış üretmesini hedefleyebilir. Klasik SAST scanner bu semantik davranışı doğrudan tespit edemez. Test dataset ve adversarial prompt senaryoları ayrı güvenlik regression paketine eklenebilir. Tool kullanan agent sistemlerinde etkisi daha yüksek olabilir. Yetki kontrolü model cevabına değil uygulama katmanındaki doğrulanmış policy'ye dayanmalıdır.

RAG Data Leakage

RAG uygulamasında model yalnızca kullanıcının yetkili olduğu belgelere erişmelidir. Retrieval katmanında authorization eksikse model başka kullanıcıya ait içeriği cevapta gösterebilir. Bu risk klasik endpoint authorization ile kısmen ilişkili olsa da semantic retrieval testleri ayrıca gerekir. Farklı kullanıcı rolleriyle aynı sorgu seti çalıştırılabilir. Sensitive document erişimi regression testleriyle doğrulanmalıdır.

Model Endpoint Güvenliği

Model endpoint de diğer API'ler gibi authentication, authorization, rate limit ve input validation gerektirir. API security testing bu kontrolleri değerlendirebilir. Request boyutu ve maliyetli inference abuse senaryoları ayrıca dikkate alınmalıdır. Secret model API key'leri CI secret management politikasıyla korunmalıdır. Logging sistemi prompt içinde kişisel veya hassas veri tutuyorsa veri koruma kuralları uygulanmalıdır.

Tool Authorization

LLM bir tool çağırabiliyorsa gerçek permission kontrolü model prompt'unda değil backend tarafında yapılmalıdır. Model “izin var” dedi diye işlem gerçekleştirilmemelidir. Tool gateway kullanıcı identity ve role bilgisini doğrulamalıdır. High-risk işlemler ek confirmation veya policy kontrolü gerektirebilir. Security testleri yetkisiz kullanıcının prompt yoluyla tool erişimi elde etmeye çalıştığı senaryoları içermelidir.

AI Red Teaming

AI red teaming model ve uygulamanın beklenmeyen veya kötü niyetli input'lara karşı davranışını test eder. Prompt injection, data extraction ve tool misuse senaryoları değerlendirilebilir. Testler uygulamanın gerçek threat model'ine göre hazırlanmalıdır. Sonuçlar yalnızca manuel raporda kalmamalı, mümkün olan durumlarda regression testine dönüştürülmelidir. Bu süreç klasik DAST'ın kapsamadığı davranışları tamamlar.

SAST/DAST'ın Kapsamadığı AI Riskleri

SAST ve DAST modelin semantik güvenlik davranışını tam olarak anlayamaz. Hallucinated tool arguments, prompt boundary bypass ve retrieval authorization gibi riskler ayrı değerlendirme ister. Scanner application code içindeki açık güvenlik hatalarını yine bulabilir. Bu nedenle mevcut AppSec kontrolleri kaldırılmamalıdır. AI-specific risk testleri bunların üzerine eklenmelidir.

DevSecOps İçin En İyi Programlama Dili Hangisidir?

DevSecOps için tek bir en iyi programlama dili yoktur. Kullanılacak dil otomasyon ihtiyacı, ekip bilgisi ve mevcut platforma göre seçilmelidir. Python API entegrasyonları için, Go taşınabilir CLI araçları için, Bash küçük runner script'leri için kullanışlı olabilir. JavaScript ve TypeScript de platform otomasyonu ve action geliştirmede yaygındır. Programlama dilinden daha önemli konu güvenli, test edilebilir ve sürdürülebilir pipeline tasarımıdır.

Python

Python okunabilir syntax ve geniş kütüphane ekosistemi sayesinde security automation için sık tercih edilir. Scanner API'lerinden sonuç çekmek, SARIF veya JSON dönüştürmek ve vulnerability platformuna veri göndermek kolaydır. Küçük script hızla büyüyebileceği için test ve dependency management uygulanmalıdır. Secret değerler source code içine yazılmamalıdır. Otomasyon aracı da normal application gibi SCA ve SAST kontrollerinden geçmelidir.

Security automation

Python security automation için rapor işleme, policy evaluation ve scanner orchestration görevlerinde kullanılabilir. CLI script scheduled pipeline içinde çalıştırılabilir. Type hint ve unit test kullanmak uzun ömürlü otomasyonun bakımını kolaylaştırır. External command çağrılarında input validation önemlidir. Otomasyon kodunun production credential erişimi minimum yetkiyle sınırlandırılmalıdır.

API entegrasyonları

Python HTTP client kütüphaneleri scanner ve vulnerability platform API'lerini birbirine bağlamak için uygundur. Retry, timeout ve rate-limit handling açık biçimde uygulanmalıdır. API token secret store üzerinden sağlanmalıdır. Response schema validation beklenmeyen vendor değişikliklerini erken yakalar. Integration test mock veya test tenant üzerinde çalıştırılabilir.

Scanner orchestration

Scanner orchestration birden fazla güvenlik aracını ortak workflow içinde çalıştırmayı gerektirir. Python job durumlarını takip edip sonuçları normalize edebilir. Scanner process timeout ve exit code davranışı ayrı ele alınmalıdır. Paralel çalışma pipeline süresini azaltabilir. Orchestration kodunun kendi logları secret ve sensitive payload içermemelidir.

Go

Go tek binary üretimi ve hızlı başlangıç süresi nedeniyle CI utility geliştirmede avantaj sağlar. Container içine küçük bir binary eklemek dependency yönetimini kolaylaştırabilir. Concurrency modeli paralel scanner entegrasyonlarında kullanılabilir. Güvenli input parsing ve error handling yine dikkat gerektirir. Uzun ömürlü platform tool'larında Go güçlü bir seçenek olabilir.

Bash

Bash basit birkaç komutluk pipeline adımları için pratik ve hızlıdır. Ancak script büyüdükçe error handling ve data parsing zorlaşır. set seçenekleri, exit code kontrolü ve güvenli variable quoting uygulanmalıdır. Secret değerler debug output'a düşürülmemelidir. Karmaşık orchestration daha güçlü bir programlama diline taşınmalıdır.

JavaScript/TypeScript

JavaScript ve TypeScript özellikle CI action, web tooling ve API entegrasyonları için kullanılabilir. TypeScript type sistemi büyük otomasyon projelerinde hata riskini azaltabilir. Package dependency sayısı supply chain riskini artırabileceği için SCA önemlidir. Lock file ve trusted registry kullanılmalıdır. Build output ve dependency provenance pipeline içinde doğrulanabilir.

YAML Neden Önemlidir?

Çoğu CI/CD sistemi workflow ve pipeline tanımını YAML ile yönetir. YAML programlama dili olmasa da security job, permission ve environment ilişkilerini belirlediği için kritik öneme sahiptir. Yanlış indentation veya permission değeri güvenlik etkisi oluşturabilir. IaC scanning benzeri pipeline policy kontrolleri YAML dosyalarını da değerlendirebilir. Shared template kullanmak tekrar eden yanlış yapılandırmaları azaltır.

Programlama Dilinden Daha Önemli Olan Pipeline Tasarımı

Güvenli DevSecOps programı belirli bir dili bilmekten daha geniş beceri gerektirir. Security gate, credential model, runner isolation ve vulnerability workflow mimarinin temel parçalarıdır. İyi script kötü permission modelini düzeltmez. Aynı biçimde güçlü scanner yanlış pipeline noktasına konursa geliştiricinin işini zorlaştırabilir. Önce güvenlik ve teslimat akışı tasarlanmalı, ardından uygun otomasyon dili seçilmelidir.

DevSecOps Alanında Yazılımcı Olmak İçin Ne Yapmalı?

DevSecOps alanında ilerlemek isteyen bir geliştiricinin yalnızca scanner kullanımını değil yazılım teslimat zincirini bütün olarak anlaması gerekir. Git, Linux, networking, CI/CD, container ve cloud temelleri güçlü başlangıç oluşturur. Bunun üzerine OWASP Top 10, SAST, DAST, SCA ve IaC güvenliği eklenebilir. Küçük açık kaynak pipeline projeleri teoriyi pratiğe dönüştürmek için çok etkilidir. Öğrenme yolculuğunu yerel ekiplerle ve gerçek projelerle desteklemek isteyenler https://www.diyarbakiryazilim.com.tr/projects sayfasındaki topluluk çalışmalarını inceleyebilir.

Git Öğrenmek

Git DevSecOps otomasyonunun temel veri kaynaklarından biridir. Commit, branch, tag ve diff kavramlarını iyi anlamak incremental scanning için gereklidir. History rewrite secret incident yönetiminde önem kazanır. Branch protection ve signed commit gibi güvenlik özellikleri de öğrenilmelidir. Küçük repository üzerinde farklı merge stratejilerini denemek pratik kazandırır.

Linux

CI runner ve container ortamlarının büyük bölümü Linux üzerinde çalışır. Process, filesystem permission, network ve package management bilgisi pipeline sorunlarını çözmeyi kolaylaştırır. Shell script güvenliği de günlük DevSecOps işinin parçasıdır. Log ve system service inceleme becerisi incident sırasında önemlidir. Temel Linux bilgisi scanner araçlarını daha rahat kullanmanızı sağlar.

Networking

Networking bilgisi DAST, API security ve runner izolasyonunu anlamak için gereklidir. TCP/IP, DNS, TLS, proxy ve firewall temel konuları öğrenilmelidir. HTTP request ve response davranışı özellikle application security için kritiktir. Network segmentation CI runner güvenliğini doğrudan etkiler. Küçük lab ortamında reverse proxy ve TLS kurmak iyi bir pratik olabilir.

CI/CD

CI/CD öğrenirken yalnızca YAML syntax'a değil pipeline lifecycle'a odaklanmak gerekir. Trigger, artifact, environment, approval ve secret kavramları anlaşılmalıdır. Basit test pipeline'ına önce SAST sonra container scan eklemek iyi bir egzersizdir. Daha sonra staging deploy ve DAST ile akış genişletilebilir. Her adımın neden pipeline'ın o noktasında olduğunu açıklayabilmek önemli bir beceridir.

Docker

Docker build ve runtime güvenliği DevSecOps içinde sık karşılaşılan konulardır. Dockerfile, image layer, registry ve digest kavramları iyi öğrenilmelidir. Minimal image ve non-root user gibi güvenli yapılandırmalar uygulanmalıdır. Image scanner kullanılarak dependency riskleri incelenebilir. Multi-stage build secret ve build dependency yönetiminde önemli avantaj sağlar.

Kubernetes

Kubernetes modern deployment ortamlarında sık kullanıldığı için security context, RBAC ve network policy bilgisi değerlidir. Manifest taraması CI/CD'ye eklenebilir. Admission policy pipeline güvenlik kurallarını cluster tarafında tekrar uygulayabilir. Service account permission ve secret yönetimi dikkatle öğrenilmelidir. Küçük lokal cluster üzerinde güvenli ve güvensiz manifest karşılaştırması iyi pratik sağlar.

OWASP Top 10

OWASP Top 10 web uygulaması güvenliğinde yaygın risk kategorilerini anlamak için güçlü başlangıç kaynağıdır. Ancak yalnızca listeyi ezberlemek yeterli değildir. Her risk için örnek vulnerable uygulama ve düzeltme yöntemi incelenmelidir. Daha sonra SAST ve DAST scanner'larının hangi kategorileri ne kadar görebildiği test edilebilir. Bu çalışma scanner çıktısını daha doğru yorumlamaya yardımcı olur.

SAST

SAST öğrenirken yalnızca tool çalıştırmak yerine data flow ve source-to-sink mantığını anlamak gerekir. Birkaç gerçek bulguyu manuel analiz etmek çok faydalıdır. Custom rule yazmak scanner'ın nasıl düşündüğünü öğretir. False positive nedenlerini incelemek güvenlik review becerisini geliştirir. CI pipeline'a incremental tarama eklemek iyi uygulama projesidir.

DAST

DAST öğrenirken HTTP, authentication ve session yönetimi temel konulardır. Scanner'ın crawling ve active scan davranışı gözlemlenmelidir. Vulnerable test uygulaması üzerinde proxy ile request incelemek faydalıdır. Authentication script hazırlamak gerçek projelerde önemli beceridir. Production tarama risklerini anlamak da teknik kullanım kadar önemlidir.

SCA

SCA öğrenmek dependency tree ve package manager davranışını anlamayı gerektirir. Direct ve transitive dependency farkı incelenmelidir. Bir test projesinde vulnerable package kullanıp scanner sonucu analiz edilebilir. CVSS, fix version ve exploitability sinyalleri karşılaştırılabilir. SBOM üretimiyle çalışma genişletilebilir.

Cloud Security

Cloud security IAM, network, storage ve workload identity temellerini içerir. CI/CD çoğu zaman cloud deployment yetkisine sahip olduğu için bu alan DevSecOps açısından önemlidir. Least privilege role tasarlamak iyi bir pratiktir. OIDC federation ile statik key olmadan deployment denenebilir. Audit log ve policy-as-code bilgisi de zamanla eklenmelidir.

Infrastructure as Code

Infrastructure as Code cloud kaynaklarını version control ve review sürecine taşır. Terraform veya benzeri araçla küçük altyapı oluşturmak iyi başlangıçtır. Bilerek güvensiz örnekler eklenip IaC scanner sonucu incelenebilir. Policy-as-code ile public storage veya open port kontrolü yazılabilir. Bu çalışma security automation düşüncesini güçlendirir.

Software Supply Chain Security

Supply chain security dependency'den build runner'a kadar geniş bir alanı kapsar. SBOM, provenance, signing ve package registry güvenliği öğrenilmelidir. Basit container build'i imzalayıp deployment öncesi signature verify etmek iyi bir laboratuvar çalışmasıdır. Third-party CI action pinning de günlük uygulamaya kolayca eklenebilir. Bu konu modern DevSecOps rolünde giderek daha fazla önem taşır.

Open Source ve İşbirliği ile DevSecOps

Açık kaynak projelere katkı yapmak DevSecOps öğrenmenin en etkili yollarından biridir. Scanner rule geliştirmek, dokümantasyon düzeltmek veya örnek pipeline hazırlamak gerçek ekip çalışma biçimini öğretir. Kod review ve issue tartışmaları farklı güvenlik yaklaşımlarını görmenizi sağlar. Küçük katkılar bile zamanla güçlü teknik portföye dönüşebilir. Topluluk içinde ortak proje üretmek isteyenler Diyarbakır Yazılım Topluluğu çalışmalarını da takip edebilir.

Açık Kaynak Security Scanner'lar

Açık kaynak scanner'lar yalnızca kullanıcı olarak değil contributor olarak da öğrenme fırsatı sunar. Rule repository'leri incelenerek vulnerability detection mantığı anlaşılabilir. False positive için test case eklemek değerli katkıdır. CI integration örnekleri gerçek proje ihtiyacına göre geliştirilebilir. Contribution süreci code review ve release yönetimi deneyimi kazandırır.

OWASP Projelerine Katkı

OWASP projeleri application security alanında geniş katkı fırsatları sunar. Dokümantasyon, test, eklenti ve rule geliştirme farklı deneyim seviyelerine uygundur. Issue listesinden küçük ve açık görevlerle başlanabilir. Katkı sırasında proje contribution guideline'larına uyulmalıdır. Düzenli küçük katkılar güvenlik bilgisini gerçek uygulamayla pekiştirir.

GitHub Security Tooling

GitHub üzerinde güvenlik otomasyonu için action, workflow template ve scanner integration projeleri geliştirilebilir. SARIF upload veya dependency kontrolü gibi küçük örnekler iyi başlangıçtır. Workflow permission güvenliği özellikle doğru uygulanmalıdır. Public repository katkıları portföy açısından görünür örnek oluşturur. Open source pipeline template'leri farklı ekiplerin kullanım geri bildirimleriyle gelişebilir.

Scanner Rule Geliştirme

Scanner rule geliştirmek bir zafiyetin kod seviyesinde nasıl göründüğünü anlamayı gerektirir. Rule için positive ve negative test case hazırlanmalıdır. Yalnızca vulnerable örneği eşleştiren ama güvenli örnekleri de işaretleyen kural uzun vadede sorun yaratır. False positive oranı katkı kalitesinin önemli ölçüsüdür. Gerçek incident pattern'ini genelleştiren rule yüksek değer sağlayabilir.

Semgrep Rule Paylaşımı

Semgrep rule yazımı belirli güvensiz pattern'leri otomatik tanımak için güzel bir eğitim alanıdır. Rule küçük örnek kodlarla test edilmelidir. Framework-specific sanitization davranışı dikkate alınmalıdır. Toplulukla paylaşılan kuralın açıklaması ve remediation önerisi açık olmalıdır. Repository içinde rule testlerini CI ile çalıştırmak sürdürülebilir katkı sağlar.

OWASP ZAP Add-on Geliştirme

OWASP ZAP add-on geliştirme dinamik güvenlik testi ve web protocol bilgisini birlikte kullanmayı sağlar. Yeni passive veya active scan davranışları üzerinde çalışılabilir. Test hedefi olarak yalnızca kontrollü vulnerable application kullanılmalıdır. Add-on code quality ve false positive etkisi değerlendirilmelidir. Contribution dokümantasyonu takip edilerek küçük issue'larla başlanabilir.

Ortak DevSecOps Pipeline Template'leri

Ortak pipeline template geliştiricilerin her repository için aynı güvenlik entegrasyonunu tekrar kurmasını önler. SAST, SCA, secret ve IaC job'ları reusable yapı haline getirilebilir. Template versioning breaking change yönetimini kolaylaştırır. Repository yalnızca dil ve environment bilgisi sağlayarak hazır güvenlik akışını kullanabilir. Böyle bir açık kaynak proje yerel topluluk için de güçlü öğrenme alanı oluşturur.

Diyarbakır Yazılım Topluluğu İçin DevSecOps Proje Fikirleri

Diyarbakır Yazılım Topluluğu içinde DevSecOps odaklı projeler hem yeni başlayan hem deneyimli geliştiriciler için ortak öğrenme ortamı oluşturabilir. Uygulamalı workshop, vulnerable application ve reusable pipeline template gibi çalışmalar teorik güvenlik bilgisini gerçek kodla buluşturur. Katılımcılar yalnızca scanner çalıştırmak yerine finding triage ve remediation adımlarını da deneyebilir. Açık kaynak yayınlanan çıktılar başka geliştiricilerin katkısını kolaylaştırır. Topluluğun yaklaşımı ve faaliyetleri hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about sayfası incelenebilir.

Açık Kaynak Güvenli CI/CD Template Projesi

Topluluk ortak bir güvenli CI/CD template repository'si geliştirebilir. Template secret scan, SAST, SCA, container scan ve SBOM adımlarını örnek uygulamayla gösterebilir. Farklı dil örnekleri contribution için ayrı issue haline getirilebilir. Policy-as-code ve security gate bölümü ileri seviye katılımcılara görev sağlar. Gerçek kullanılabilir bir proje ortaya çıkması öğrenme motivasyonunu artırır.

GitHub Actions Security Pipeline

GitHub Actions üzerinde küçük bir web uygulamasına uçtan uca security pipeline kurulabilir. Pull request'te secret scan ve SAST, build sonrasında container scan çalıştırılabilir. Preview environment mevcutsa DAST eklenebilir. Katılımcılar permission ve branch protection ayarlarını da inceleyebilir. Workshop sonunda her adımın neden kullanıldığı birlikte tartışılabilir.

OWASP ZAP Atölyesi

OWASP ZAP atölyesinde kontrollü vulnerable uygulama üzerinde passive ve active scan farkı gösterilebilir. Katılımcılar HTTP request ve response'ları inceleyebilir. Authentication gerektiren demo uygulamasına login script eklemek ileri bölüm olabilir. Scanner bulguları manuel doğrulanarak false positive kavramı anlatılabilir. Son adımda ZAP taraması basit CI pipeline'a bağlanabilir.

Semgrep Custom Rule Workshop

Semgrep custom rule workshop belirli güvenli olmayan kod pattern'ini otomatik tespit etmeye odaklanabilir. Katılımcılar önce vulnerable ve safe örnekler yazar. Ardından rule geliştirilip test edilir. False positive azaltmak için pattern iyileştirilir. Sonuç repository CI pipeline'ına eklenerek gerçek otomasyon deneyimi sağlanır.

Vulnerable Application Hackathon'u

Vulnerable application hackathon'u ekiplerin hem zafiyet ekleme hem bulma hem düzeltme aşamalarını deneyimlemesini sağlayabilir. Ortam yalnızca eğitim amacıyla lokal veya izole lab üzerinde çalıştırılmalıdır. Her takım belirli OWASP kategorisinden örnek hazırlayabilir. Başka takım scanner ve manuel review ile problemi bulur. Son aşamada güvenlik regression testi eklenerek düzeltmenin kalıcı olması sağlanır.

Open Source Security Contribution Day

Contribution day katılımcıların açık kaynak güvenlik projelerinde küçük issue seçip birlikte çalışmasını sağlayabilir. İlk katkı yapan kişiler için dokümantasyon veya test issue'ları tercih edilebilir. Daha deneyimli katılımcılar rule veya integration geliştirebilir. Pull request review süreci birlikte incelenebilir. Gün sonunda katkıların teknik öğrenme notları paylaşılabilir.

Yerel Projeler İçin Ücretsiz Security Scan Günü

Yerel açık kaynak veya izin verilmiş demo projeler için güvenlik tarama günü düzenlenebilir. Her proje sahibinden açık test izni ve kapsam alınmalıdır. Scanner sonuçları geliştiriciyle birlikte doğrulanarak yanlış yorumların önüne geçilebilir. Secret veya hassas veri içeren raporlar herkese açık paylaşılmamalıdır. Amaç yalnızca zafiyet saymak değil güvenli geliştirme alışkanlığı kazandırmak olmalıdır.

Uygulamalı Bir DevSecOps Pipeline Örneği

Basit bir web uygulaması üzerinden uygulanabilir DevSecOps pipeline düşünelim. Geliştirici pull request açtığında secret scan, SAST ve dependency taraması paralel çalışır. Testler başarılı olunca container üretilir, image scan ve SBOM oluşturma adımları tamamlanır. Aynı image staging ortamına deploy edilir ve authenticated DAST çalıştırılır. Security gate kabul edilebilir risk seviyesini doğruladığında aynı immutable artifact production'a taşınır.

Örnek Web Uygulaması

Örnek uygulama basit REST API ve web arayüzüne sahip olabilir. Repository application code, Dockerfile ve deployment manifest'lerini birlikte içerir. Dependency lock file version control altında tutulur. Test ortamında ayrı database ve kullanıcı hesapları kullanılır. Bu yapı birçok DevSecOps kontrolünü tek proje üzerinde deneyebilmek için yeterlidir.

Pull Request Oluşturma

Geliştirici feature branch'ten pull request açar. Pipeline yalnızca değişen kod ve dependency farkını hızlı biçimde analiz etmeye başlar. CODEOWNERS ilgili reviewer'ı otomatik ekleyebilir. Security job sonuçları review ekranına gelir. Merge yalnızca required checks tamamlandığında mümkün olur.

Secret Scan

Secret scanner pull request commit aralığını kontrol eder. API key benzeri gerçek değer bulunursa job başarısız olur. Geliştirici secret'ı repository'den çıkarıp güvenli store'a taşır. Eğer gerçek credential daha önce push edilmişse rotation yapılır. Düzeltilmiş commit yeni pipeline başlatır.

SAST

SAST changed code üzerinde veri akışı ve güvenli olmayan API kullanımını kontrol eder. Yalnızca yeni finding'ler pull request'i etkiler. Sonuç kod satırına annotation olarak eklenebilir. Geliştirici bulguyu düzeltir veya gerekçeli review talep eder. Rule false positive ise security team tuning sürecine alır.

Dependency Scan

Dependency scanner lock file'daki bütün paketleri bilinen vulnerability verisiyle karşılaştırır. Yeni eklenen vulnerable package varsa risk seviyesi gösterilir. Fix version mevcutsa update önerilir. Known exploited critical dependency merge gate'i durdurabilir. Sonuç SBOM sistemiyle daha sonra da takip edilir.

Unit Tests

Unit tests application davranışını ve security helper fonksiyonlarını doğrular. Daha önce düzeltilen vulnerability için regression test burada çalışabilir. Test failure merge'i engeller. Güvenlik scanner'ı başarılı olsa bile iş mantığı testi yine gereklidir. Test coverage kritik authentication ve authorization kodunu kapsamalıdır.

Container Build

Container build doğrulanmış source commit'ten immutable image üretir. Multi-stage build final image içinde gereksiz tool bırakmaz. Build secret'ları layer içine yazılmaz. Image digest pipeline metadata'sına kaydedilir. Sonraki bütün kontroller aynı digest üzerinde çalışır.

Container Scan

Container scanner işletim sistemi ve uygulama bileşenlerini inceler. Base image CVE'leri ve dependency sonuçları raporlanır. Yeni critical finding varsa image promotion durur. Gereksiz package tespit edilirse Dockerfile sadeleştirilebilir. Başarılı scan digest bilgisiyle kaydedilir.

SBOM

SBOM final image üzerinden oluşturularak gerçek build içeriğini temsil eder. CycloneDX veya SPDX dosyası build artifact'i olarak saklanabilir. Merkezi dependency platformuna yüklenir. Image digest ile association yapılır. Yeni CVE çıktığında bu build yeniden risk açısından değerlendirilebilir.

Staging Deployment

Onaylanan image digest staging ortamına deploy edilir. Staging secret'ları production'dan ayrıdır. Health check başarılı olduğunda dynamic security job tetiklenir. Test data başlangıç durumu otomatik hazırlanabilir. Deployment ID DAST sonucuna eklenir.

Authenticated DAST

DAST scanner test service account ile login olur. Public ve authenticated endpoint'leri tarar. Authorization için sınırlı kullanıcı senaryoları çalıştırılabilir. Active payload'lar yalnızca staging ortamında kullanılır. Kritik doğrulanmış sonuç security gate'e aktarılır.

Security Gate

Security gate SAST, SCA, container ve DAST sonuçlarını ortak policy ile değerlendirir. Yeni critical bulgu bulunmaması zorunlu olabilir. High risk asset context'e göre karar alır. Exception varsa expiry ve approval kaydı kontrol edilir. Başarılı gate production promotion'a izin verir.

Production Deployment

Production deployment staging'de test edilen aynı image digest'i kullanır. Signature ve provenance yeniden doğrulanır. Production-specific secret workload identity üzerinden alınır. Deployment log audit sistemine yazılır. Sonrasında monitoring ve continuous rescanning süreci başlar.

SAST/DAST Pipeline'ı Aşamalı Olarak Nasıl Devreye Alınır?

Eski ve büyük bir yazılım ortamında bütün security scanner'ları ilk günden blocking hale getirmek çoğu zaman ters sonuç verir. Daha iyi yaklaşım önce visibility sağlayıp mevcut durumu ölçmek, ardından baseline oluşturmaktır. False positive'ler temizlendikten sonra yalnızca yeni bulgular için gate uygulanabilir. Sonraki aşamada risk-based enforcement ve full DevSecOps automation genişletilir. Bu model teknik dönüşümün yanında geliştirici alışkanlıklarının da kontrollü biçimde gelişmesini sağlar.

Aşama 1: Visibility

İlk aşamada scanner'lar çalıştırılır ancak build otomatik olarak engellenmez. Amaç gerçek finding hacmini ve false positive oranını anlamaktır. Repository ve dil coverage ölçülür. Geliştiriciler sonuçları görmeye ve yorumlamaya başlar. Bu dönemde rule tuning için veri toplanır.

Scanner çalıştır

SAST, SCA ve secret scanner önce advisory mode ile pipeline'a eklenebilir. Staging bulunan projelerde DAST de aynı yaklaşımda kullanılabilir. Sonuçlar merkezi dashboard'a aktarılır. Scanner süreleri ve başarısızlık oranları ölçülür. Bu veri sonraki enforcement kararlarını destekler.

Build'i engelleme

İlk aşamada düşük güvenilirlikteki scanner sonuçları build'i durdurmamalıdır. Ekip hangi rule'ların gerçekten değer sağladığını gözlemlemelidir. Kritik ve açıkça gerçek secret gibi istisnai bulgular için erken blocking düşünülebilir. Genel yaklaşım önce güven inşa etmektir. Birkaç haftalık veri sonrası policy netleştirilebilir.

Aşama 2: Baseline

Baseline aşamasında mevcut vulnerability envanteri doğrulanır ve legacy security debt ayrılır. False positive kayıtları temizlenir. Scanner configuration gerçek framework davranışına göre ayarlanır. Mevcut bulgular owner ve SLA ile backlog'a aktarılır. Böylece yeni risklerin eski sonuçlarla karışması önlenir.

Security debt belirle

Security debt bütün açık bulguların risk seviyesine göre görünür hale getirilmesidir. Yalnızca toplam sayı değil exploitability ve asset criticality değerlendirilebilir. En önemli legacy riskler için remediation plan oluşturulur. Backlog sahipliği ilgili servis ekiplerine atanır. Trend daha sonra program başarısını ölçmek için kullanılır.

False positive temizle

False positive temizliği blocking gate'e geçmeden önce yapılmalıdır. Geliştiriciler scanner sonucuna güvenmezse enforcement sürekli tartışma yaratır. Yanlış rule'lar kapatılır veya daraltılır. Suppression gerekçeli ve süreli tutulur. Scanner başına kalite metriği oluşturulur.

Aşama 3: New Findings Gate

Bu aşamada yalnızca baseline sonrasında oluşan yeni güvenlik bulguları merge veya deployment kararını etkiler. Geliştirici kendi değişikliğinden gelen riski düzeltir. Legacy debt ayrı programda yönetilmeye devam eder. Critical ve high-confidence rule'lar blocking hale getirilebilir. Bu model güvenliği artırırken eski sistem nedeniyle günlük geliştirmeyi durdurmaz.

Aşama 4: Risk-Based Enforcement

Risk-based enforcement severity dışındaki context bilgisini policy'ye ekler. Internet exposure, exploitability, asset criticality ve data sensitivity kullanılabilir. Böylece her high finding aynı şekilde ele alınmaz. Exception süreci standartlaştırılır. Gate kararının nedeni geliştiriciye açık biçimde gösterilir.

Aşama 5: Full DevSecOps Automation

Son aşamada SAST, DAST, SCA, secret, IaC, container, SBOM ve supply chain kontrolleri ortak lifecycle içinde çalışır. Vulnerability sonuçları merkezi sistemde normalize edilir. Policy-as-code otomatik gate kararı verir. Incident bulguları yeni regression test ve scanner rule'larına dönüştürülür. Program sürekli metric ve coverage verisine göre iyileştirilir.

CI/CD Güvenlik Taramalarında En Sık Yapılan Hatalar

CI/CD güvenliği kurarken en yaygın hata çok sayıda scanner ekleyip sonuç yönetimini tasarlamamaktır. Güvenlik aracı çalışsa bile false positive, ownership ve remediation süreci yoksa zaman içinde uyarılar birikir. Diğer bir hata bütün finding'leri aynı severity modeline göre blocking hale getirmektir. Production DAST, secret management ve pipeline'ın kendi güvenliği de sık ihmal edilir. Başarılı program araçlardan önce süreç, policy ve geliştirici deneyimine odaklanır.

Her Bulguda Build'i Durdurmak

Her finding için build durdurmak ilk bakışta güvenli görünebilir ancak pratikte sürdürülemez. Informational veya false positive uyarılar geliştirici akışını gereksiz keser. Zamanla ekip bypass yöntemleri aramaya başlayabilir. New finding ve risk-based gate daha dengeli yaklaşım sağlar. Blocking yalnızca açıkça tanımlanmış yüksek değerli kurallarda kullanılmalıdır.

False Positive'leri Yönetmemek

False positive biriktikçe scanner dashboard'u gerçek riskleri saklayan gürültülü alana dönüşür. Geliştiriciler aynı yanlış uyarıyı tekrar tekrar görmek istemez. Rule tuning ve suppression workflow zorunludur. Suppression kalıcı ve gerekçesiz olmamalıdır. False positive rate scanner kalitesinin temel metriği olarak izlenmelidir.

Sadece SAST Kullanmak

SAST kaynak kod güvenliğinde değerli olsa da runtime ve deployment problemlerini tam göremez. Authentication flow veya HTTP header hatası yalnızca çalışan uygulamada ortaya çıkabilir. SCA ve container riskleri de SAST kapsamı dışında kalabilir. DAST ve diğer scanner türleri farklı görünürlük sağlar. Tek scanner güvenlik programı için yeterli değildir.

Sadece DAST Kullanmak

DAST yalnızca erişebildiği çalışan endpoint'leri test eder. Henüz tetiklenmeyen vulnerable code path'i göremez. Hard-coded secret veya bazı güvensiz kriptografi kullanımları dinamik taramada fark edilmeyebilir. SAST erken feedback sağlar. İki yöntemin birlikte kullanılması daha geniş coverage oluşturur.

Dependency'leri Taramamak

Modern uygulamaların büyük bölümü üçüncü taraf paketlere dayanır. Sadece application source code taramak vulnerable dependency riskini kaçırır. SCA direct ve transitive paketleri değerlendirebilir. Scheduled rescan yeni CVE'leri kod değişmeden yakalar. SBOM aktif build etkisini anlamayı kolaylaştırır.

Secret Scanning Yapmamak

Repository'ye yanlışlıkla credential eklenmesi sık görülen ve etkisi yüksek hatalardandır. SAST bazı secret'ları bulsa da özel scanner daha geniş pattern desteği sunar. Pre-commit ve CI kontrolü birlikte kullanılmalıdır. Gerçek secret bulunursa rotation zorunludur. History taraması eski sızıntıları da ortaya çıkarabilir.

IaC ve Container'ları Unutmak

Uygulama kodu güvenli olsa bile altyapı yanlış yapılandırılabilir veya container vulnerable package içerebilir. IaC scan deployment öncesi config risklerini gösterir. Container scan final image içeriğini değerlendirir. Bu kontroller build ve deploy lifecycle'a eklenmelidir. Security coverage yalnızca source repository ile sınırlı düşünülmemelidir.

DAST'ı Authentication Olmadan Çalıştırmak

Anonymous DAST login sayfası arkasındaki endpoint'leri göremeyebilir. Tarama başarılı görünse bile coverage çok düşük kalabilir. Test service account ve session renewal yapılandırılmalıdır. Farklı roller authorization testlerini güçlendirir. Authenticated endpoint coverage ayrıca ölçülmelidir.

Production'a Kontrolsüz DAST Göndermek

Aktif scanner production verisini değiştirebilir veya servis yükünü artırabilir. Staging bu testler için daha güvenli hedeftir. Production gerekiyorsa safe scan policy ve read-only account kullanılmalıdır. Rate limit ve maintenance window planlanabilir. Operasyon ekibi scanner trafiğini gözlemleyebilmelidir.

Scanner Token'larını Repository'de Tutmak

Scanner API token'ı da diğer credential'lar gibi secret kabul edilmelidir. YAML veya source code içine yazılmamalıdır. CI secret store veya workload identity kullanılabilir. Token minimum permission ve kısa lifetime ile sınırlandırılmalıdır. Secret scanning kendi scanner credential'larını da kontrol edebilir.

Security Debt ile Yeni Bulguları Ayırmamak

Legacy repository'ye scanner eklendiğinde yüzlerce eski finding ortaya çıkabilir. Hepsini blocking yapmak günlük geliştirmeyi durdurur. Baseline oluşturulmalı ve new findings gate uygulanmalıdır. Eski debt ayrı SLA ve backlog ile yönetilmelidir. Bu ayrım DevSecOps geçişini uygulanabilir hale getirir.

Security Exception'ları Süresiz Bırakmak

Süresiz exception zamanla unutulan kalıcı güvenlik açığına dönüşebilir. Her risk kabulünün owner ve expiration date'i olmalıdır. Süre dolunca yeniden review yapılmalıdır. Context değiştiyse risk seviyesi de yeniden hesaplanmalıdır. Automated reminder ve policy check bu süreci kolaylaştırır.

Pipeline'ın Kendisini Güvenceye Almamak

Scanner'ların çalıştığı runner ve CI account kompromize edilirse bütün security gate bypass edilebilir. Branch protection, MFA, least privilege ve runner isolation uygulanmalıdır. Third-party action'lar kontrol edilmelidir. Production credential untrusted job'lara verilmemelidir. Pipeline security ayrı threat model olarak ele alınmalıdır.

Yalnızca CVSS Skoruyla Önceliklendirmek

CVSS teknik severity için yararlıdır ancak gerçek riskin tamamını göstermez. Internet exposure, exploit availability ve asset criticality sonucu değiştirebilir. Known exploited vulnerability daha düşük CVSS ile bile acil olabilir. Risk-based prioritization bu sinyalleri birleştirir. Security SLA da aynı context bilgisine göre ayarlanmalıdır.

Production-Ready CI/CD Security Checklist

Production-ready güvenlik checklist'i pipeline'ın her aşamasında hangi kontrolün bulunması gerektiğini netleştirir. Pull request aşamasında hızlı kod ve dependency kontrolleri, build aşamasında artifact güvenliği, staging'de dinamik testler ve gate aşamasında risk kararı uygulanabilir. Production tarafında monitoring ve rescanning süreci devam eder. Checklist yalnızca bir kez doldurulan belge yerine pipeline tarafından otomatik doğrulanan policy'ye dönüştürülebilir. Böylece yeni repository'ler aynı minimum güvenlik standardıyla başlayabilir.

Pull Request

Pull request aşaması geliştiriciye en hızlı güvenlik geri bildiriminin verildiği noktadır. Secret scan, SAST, SCA ve IaC scan paralel çalışabilir. Yeni ve yüksek riskli finding'ler merge protection ile ilişkilendirilebilir. Legacy debt baseline dışında tutulabilir. Sonuçlar doğrudan review ekranında görünmelidir.

Secret scan

Secret scan yeni commit'lerde credential pattern'lerini kontrol etmelidir. Gerçek secret bulunduğunda merge engellenmelidir. Secret değeri logda maskelenmelidir. Sızıntı repository'ye ulaşmışsa rotation başlatılmalıdır. Full history scan scheduled olarak ayrıca yürütülebilir.

SAST

SAST changed code üzerinde hızlı statik analiz çalıştırmalıdır. High-confidence kurallar pull request gate'e bağlanabilir. SARIF annotation geliştiricinin bağlamı hızlı anlamasını sağlar. False positive suppression review sürecinden geçmelidir. Full scan scheduled pipeline'da devam etmelidir.

SCA

SCA dependency manifest ve lock file değişikliklerini kontrol etmelidir. Yeni vulnerable package eklenmesi görünür olmalıdır. Known exploited critical dependency blocking policy için güçlü adaydır. Fix version bilgisi geliştiriciye sunulmalıdır. Scheduled monitoring kod değişmeden çıkan yeni CVE'leri takip etmelidir.

IaC scan

IaC scan Terraform, Kubernetes ve diğer deployment tanımlarını kontrol etmelidir. Public resource veya geniş permission gibi riskler pull request'te görünür olmalıdır. Custom organizational policy uygulanabilir. Render edilen manifest gerektiğinde ayrıca taranmalıdır. Production config değişikliği güvenlik review sürecine bağlanabilir.

Build

Build aşaması kaynak koddan dağıtılabilir artifact üretir ve supply chain güvenliği açısından kritik noktadır. SBOM oluşturma, container scan ve artifact signing burada yapılabilir. Build runner izole ve minimum yetkili olmalıdır. Artifact immutable digest ile tanımlanmalıdır. Sonraki environment'lar aynı artifact'i kullanmalıdır.

SBOM

SBOM final build içindeki bileşenleri belgelemelidir. CycloneDX veya SPDX formatı kullanılabilir. Artifact digest ile association kurulmalıdır. Merkezi dependency platformuna yüklenebilir. Yeni CVE çıktığında eski build tekrar değerlendirilebilir.

Container scan

Container scan final image içindeki OS package ve application dependency'leri kontrol etmelidir. Base image riski ayrı görülebilmelidir. Critical yeni finding image promotion'ı durdurabilir. Scanner database güncel tutulmalıdır. Registry rescanning production sonrasında devam etmelidir.

Artifact signing

Artifact signing build çıktısının güvenilir pipeline'dan geldiğini doğrulamaya yardımcı olur. Signature immutable digest ile ilişkilendirilmelidir. Signing identity yalnızca protected build job'da kullanılmalıdır. Production deployment signature'ı tekrar doğrulamalıdır. Provenance ek güvence sağlar.

Staging

Staging çalışan uygulamanın güvenlik davranışını production öncesinde test etmek için temel environment'tır. Authenticated DAST, API security ve regression testleri burada çalıştırılabilir. Test hesapları ve sentetik veri tercih edilmelidir. Environment production'a mümkün olduğunca yakın olmalıdır. Sonuçlar security gate kararına girdi sağlar.

Authenticated DAST

Authenticated DAST login arkasındaki uygulama alanlarını taramalıdır. Session renewal ve test account yönetimi otomatik olmalıdır. Different role senaryoları authorization coverage'ı artırır. Active scan staging data üzerinde çalıştırılmalıdır. Endpoint coverage raporu ayrıca incelenmelidir.

API security scan

API security scan OpenAPI veya schema üzerinden endpoint listesini kullanabilir. Authentication ve object-level authorization senaryoları test edilmelidir. Rate-limit kontrolü kontrollü request sayısıyla yapılabilir. Sonuç build ile ilişkilendirilmelidir. Kritik API bulgusu release gate'e dahil edilmelidir.

Security regression

Security regression geçmişte düzeltilen vulnerability'lerin tekrar oluşmadığını doğrular. Testler unit, integration veya DAST seviyesinde olabilir. Kritik incident sonrası yeni regression case eklemek iyi practice'tir. Test failure doğrudan blocking olmalıdır. Sonuç diğer functional testlerle birlikte raporlanabilir.

Gate

Gate aşaması bütün security sinyallerini ortak risk kararına dönüştürür. Severity yanında exploitability ve business context kullanılmalıdır. Exception policy geçici sapmaları kontrollü yönetir. Approval gerektiğinde doğru yetki seviyesine yönlendirilmelidir. Otomatik karar gerekçesi pipeline logunda görünmelidir.

Risk threshold

Risk threshold hangi bulguların release'i durduracağını belirler. Critical new finding çoğu sistem için blocker olabilir. High bulgular exposure ve asset criticality ile değerlendirilmelidir. Threshold service tier'a göre değişebilir. Policy version control altında tutulmalıdır.

Exception policy

Exception policy risk kabulünün nasıl yapılacağını belirler. Gerekçe, compensating control, owner ve expiry date zorunlu olabilir. High risk için security approval eklenebilir. Süre dolduğunda exception otomatik geçersiz olmalıdır. Bypass logları audit sistemine gönderilmelidir.

Approval

Approval otomatik veya manuel olabilir. Normal düşük riskli release'lerde policy otomatik karar vermelidir. Belirsiz veya yüksek etkili exception'da insan review gerekebilir. Approval kişinin rolü ve zamanı ile kaydedilmelidir. Aynı kişinin hem risk oluşturup hem kontrolsüz onay vermesi separation of duties açısından değerlendirilmelidir.

Production

Production güvenliği deployment tamamlandığında bitmez. Monitoring, rescanning, vulnerability SLA ve incident feedback loop sürekli çalışmalıdır. Aktif deployment digest envanteri güncel tutulmalıdır. Yeni CVE çıktığında ilgili servis hızlı bulunabilmelidir. Production bulguları yeniden pipeline control'üne dönüştürülmelidir.

Monitoring

Monitoring authentication hataları, beklenmeyen traffic ve uygulama güvenlik olaylarını gözlemlemelidir. Loglar merkezi ve erişimi sınırlı sistemde tutulmalıdır. Scanner trafiği gerçek kullanıcı trafiğinden ayrıştırılabilir. Alert threshold yanlış alarm üretmeyecek şekilde ayarlanmalıdır. Incident verisi security rule geliştirmede kullanılabilir.

Rescanning

Dependency ve container image'lar yeni vulnerability bilgileriyle düzenli yeniden taranmalıdır. Kod değişmese bile risk durumu değişebilir. Active deployment'lar öncelikli değerlendirilmelidir. Critical yeni finding owner'a otomatik atanabilir. Rescan sonucu SBOM ve asset inventory ile ilişkilendirilmelidir.

Vulnerability SLA

Production vulnerability SLA risk ve exposure seviyesine göre belirlenmelidir. Internet-facing critical risk en kısa remediation süresine sahip olmalıdır. SLA breach yönetim dashboard'unda görünmelidir. Risk acceptance süreli ve onaylı olmalıdır. Düzeltme sonrası rescan closure için kanıt sağlar.

Incident feedback loop

Incident feedback loop production'da öğrenilen güvenlik problemini geliştirme sürecine geri taşır. Root cause için yeni SAST rule, regression test veya deployment policy oluşturulabilir. Böylece aynı problem gelecekte daha erken yakalanır. Incident review yalnızca insan hatasına odaklanmamalı, otomasyon boşluğunu araştırmalıdır. Bu döngü DevSecOps programının zamanla olgunlaşmasını sağlar.

Sık Sorulan Sorular

CI/CD güvenlik taramalarında ekiplerin en sık sorduğu sorular araç seçiminden gate politikasına kadar geniş bir alanı kapsar. Aşağıdaki cevaplar temel karar noktalarını hızlı biçimde özetler. Her proje farklı teknoloji ve risk profiline sahip olduğu için scanner ayarları gerçek uygulama üzerinde test edilmelidir. Özellikle production DAST ve blocking gate gibi kontroller aşamalı devreye alınmalıdır. CI/CD Ortamında Otomatik Güvenlik Taramaları (SAST/DAST) yaklaşımında hedef daha fazla uyarı üretmek değil geliştiricinin doğru riski doğru anda görmesini sağlamaktır.

SAST nedir?

SAST kaynak kodu veya statik build çıktısını uygulama çalışmadan analiz eden güvenlik testidir. Injection, riskli API kullanımı ve hard-coded credential gibi kod seviyesindeki sorunları bulmaya çalışır. Pull request aşamasında çalıştırıldığında erken feedback sağlar. Sonuçların doğruluğu dil ve framework desteğine bağlıdır. DAST ve diğer scanner türleriyle birlikte kullanılması daha geniş coverage sağlar.

DAST nedir?

DAST çalışan web uygulaması veya API'yi dışarıdan test eden dinamik güvenlik yöntemidir. Scanner HTTP request'leri gönderir ve response davranışını analiz eder. Authentication, runtime configuration ve injection gibi problemleri gösterebilir. Genellikle staging deployment sonrasında çalıştırılır. Production taraması için özel safe scan policy kullanılmalıdır.

SAST ile DAST arasındaki fark nedir?

SAST kaynak kodu analiz ederken DAST çalışan uygulamayı test eder. SAST daha erken pipeline aşamasında çalışabilir. DAST gerçek deployment davranışını gözlemleyebilir. White-box ve black-box bakışları farklı riskleri yakalar. Bu nedenle ikisi birbirinin yerine değil birlikte kullanılmalıdır.

SAST mı DAST mı daha önemlidir?

Tek birinin daha önemli olduğunu söylemek doğru değildir. SAST erken code-level feedback için çok değerlidir. DAST gerçek runtime davranışını ve deployment kaynaklı riskleri gösterir. Uygulamanın threat model'i hangi kontrole daha fazla ağırlık verileceğini belirleyebilir. Temel DevSecOps yapısında ikisi birlikte kullanılır.

SAST pipeline'ın hangi aşamasında çalıştırılmalıdır?

SAST pull request veya merge öncesi aşamada hızlı feedback için çalıştırılmalıdır. IDE ve pre-commit kontrolleri daha erken sinyal sağlayabilir. Default branch üzerinde geniş scan yapılabilir. Nightly job full repository analysis için uygundur. Release öncesi tarama son doğrulama olarak kullanılabilir.

DAST CI/CD pipeline'a nasıl eklenir?

Önce uygulama build edilip staging veya preview environment'a deploy edilir. Pipeline hedef URL ve test credential bilgisini DAST job'ına aktarır. Scanner headless mode ile çalışır ve machine-readable report üretir. Bulgular merkezi vulnerability sistemine gönderilir. Risk threshold'u aşan yeni finding release gate'i durdurabilir.

DAST production ortamında çalıştırılabilir mi?

Evet, ancak yalnızca kontrollü ve düşük riskli policy ile çalıştırılmalıdır. Active destructive payload'lar production için uygun değildir. Read-only test account ve düşük request rate kullanılabilir. Mümkün olduğunda kapsamlı DAST staging ortamında yapılmalıdır. Production taraması daha çok sınırlı doğrulama ve passive güvenlik kontrolü olarak düşünülmelidir.

SCA ile SAST arasındaki fark nedir?

SAST uygulamanın kendi kaynak kodunu analiz eder. SCA üçüncü taraf dependency ve package vulnerability'lerine odaklanır. Bir uygulama temiz SAST sonucuna rağmen vulnerable dependency kullanabilir. Tersi durumda dependency'ler güncel olsa da custom code güvenlik hatası içerebilir. Bu nedenle ikisi CI/CD içinde birlikte çalıştırılmalıdır.

OWASP ZAP CI/CD'de nasıl kullanılır?

OWASP ZAP headless veya container mode ile staging uygulamasına karşı çalıştırılabilir. Baseline scan hızlı passive kontrol için uygundur. Active scan daha geniş test sağlar ve staging ortamında tercih edilmelidir. Authentication context login arkasındaki endpoint'leri taramak için yapılandırılabilir. Rapor security gate ve vulnerability yönetim sistemine aktarılabilir.

Semgrep CI/CD'ye nasıl entegre edilir?

Semgrep CLI pipeline job içinde repository üzerinde çalıştırılabilir. Pull request diff'i kullanılarak hızlı incremental analiz yapılabilir. Rule configuration repository veya merkezi template üzerinden yönetilebilir. Sonuç SARIF veya başka machine-readable formatta dışarı aktarılabilir. High-confidence new findings merge gate'e bağlanabilir.

Güvenlik bulguları build'i ne zaman durdurmalıdır?

Build veya deployment yalnızca anlamlı ve güvenilir riskler için durdurulmalıdır. Yeni critical bulgu güçlü blocker adaydır. High finding internet exposure ve exploitability bilgisine göre değerlendirilebilir. Legacy security debt baseline dışında tutulabilir. Exception süreci süreli, gerekçeli ve onaylı olmalıdır.

False positive'ler nasıl yönetilir?

False positive rule tuning, suppression ve security review ile yönetilmelidir. Suppression gerekçesi ve expiry date kaydedilmelidir. Scanner bazında false positive oranı ölçülmelidir. Çok gürültülü rule advisory moda alınabilir. Amaç geliştiricinin security feedback'e güvenmesini sağlamaktır.

SBOM nedir ve CI/CD'de neden oluşturulmalıdır?

SBOM build içindeki software component'lerin envanteridir. Build sırasında oluşturulduğunda artifact içeriğini daha doğru temsil eder. Container digest veya package hash ile ilişkilendirilmelidir. Yeni CVE çıktığında hangi aktif build'in etkilendiğini hızlı belirlemeyi sağlar. CycloneDX ve SPDX yaygın formatlardır.

SARIF nedir?

SARIF statik analiz sonuçlarını ortak formatta taşımaya yarayan standarttır. Dosya, satır, rule ve message bilgisi taşıyabilir. Code scanning platformları SARIF sonucunu pull request annotation olarak gösterebilir. Birden fazla scanner aynı ingestion workflow'una bağlanabilir. Merkezi normalization ve reporting süreçlerini kolaylaştırır.

DevSecOps pipeline nasıl kurulur?

DevSecOps pipeline önce hızlı secret, SAST ve SCA kontrolleriyle başlayabilir. Build sonrasında SBOM ve container scan eklenir. Staging ortamında authenticated DAST çalıştırılır. Risk-based security gate production kararını verir. Süreç vulnerability management, SLA, exception ve continuous monitoring ile tamamlanır.

Açık kaynak SAST ve DAST araçları hangileridir?

SAST tarafında Semgrep, CodeQL, Bandit, Brakeman ve SpotBugs gibi araçlar farklı teknoloji yığınlarında kullanılabilir. DAST tarafında OWASP ZAP yaygın seçeneklerden biridir ve Nuclei belirli template tabanlı kontroller için değerlendirilebilir. Araç seçerken dil desteği, authentication, CI kullanımı ve false positive oranına bakılmalıdır. Her scanner gerçek proje üzerinde pilot testten geçirilmelidir. Birden fazla araç kullanılıyorsa sonuçlar merkezi sistemde normalize edilmelidir.

CI/CD ortamında SAST ve DAST güvenlik taramaları nasıl otomatikleştirilir?

CI/CD ortamında otomasyon için ilk adım kontrolleri doğru pipeline noktalarına yerleştirmektir. SAST pull request veya merge öncesinde, DAST ise çalışan staging veya preview environment oluşturulduktan sonra çalıştırılmalıdır. Scanner'ların CLI veya API üzerinden non-interactive çalışması ve machine-readable report üretmesi gerekir. Sonuçlar ortak vulnerability management sistemine gönderilip policy-as-code gate ile değerlendirilebilir. En iyi başlangıç modeli önce advisory scan çalıştırmak, baseline oluşturmak ve daha sonra yalnızca yeni ve yüksek riskli bulgular için blocking uygulamaktır.

SAST ve DAST arasındaki fark nedir ve CI/CD pipeline’ının hangi aşamalarında çalıştırılmalıdır?

SAST kaynak kodu veya statik build bilgisini analiz ederken DAST çalışan uygulamanın dışarıdan gözlemlenebilir davranışını test eder. Bu nedenle SAST pull request, merge ve default branch gibi erken aşamalara daha uygundur. DAST ise build sonrasında staging veya preview environment üzerinde çalışmalıdır. SAST hızlı feedback verirken DAST authentication, deployment ve runtime configuration gibi farklı riskleri ortaya çıkarabilir. İki kontrol aynı security gate içinde birleştirildiğinde daha dengeli güvenlik coverage'ı elde edilir.

Otomatik güvenlik taramalarında bulunan zafiyetler hangi kriterlere göre build veya deployment sürecini durdurmalıdır?

Gate kararı yalnızca scanner'ın severity alanına bağlı olmamalıdır. Yeni olup olmadığı, exploitability, internet exposure, asset criticality, sensitive data etkisi ve bilinen exploit durumu birlikte değerlendirilmelidir. Yeni critical ve yüksek güvenilirlikteki authentication bypass gibi bulgular güçlü blocking adaylarıdır. Legacy security debt baseline altında ayrı backlog'da yönetilebilir. Risk kabul gerekiyorsa gerekçe, compensating control, owner, approval ve expiration date içeren kayıt oluşturulmalıdır.

SAST ve DAST taramalarında yanlış pozitifler ve pipeline performans sorunları nasıl azaltılır?

False positive azaltmak için scanner rule tuning yapılmalı, framework davranışını anlamayan kurallar iyileştirilmeli ve suppression kontrollü biçimde kullanılmalıdır. Suppression kayıtlarında gerekçe ve sona erme tarihi bulunması önemlidir. Pipeline performansı için incremental SAST, changed-file scanning, cache ve parallel jobs kullanılabilir. Deep DAST ve full repository taramaları nightly veya scheduled pipeline'a taşınabilir. Böylece geliştirici pull request sırasında hızlı feedback alırken geniş güvenlik coverage'ı daha uzun süreli job'larla korunur.

CI/CD ortamında SAST/DAST kurulumu ve DevSecOps danışmanlığını yakınımda nerede bulabilirim?

SAST DAST ve DevSecOps danışmanlığı yakınımda diye araştırırken yalnızca bir scanner kurabilen hizmete değil pipeline mimarisini, vulnerability yönetimini ve geliştirici deneyimini birlikte ele alan yaklaşıma odaklanmak gerekir. Kurumsal CI/CD SAST DAST ve DevSecOps güvenlik entegrasyonu hizmeti; scanner seçimi, baseline oluşturma, security gate, secret management, runner güvenliği ve remediation workflow gibi başlıkları beraber değerlendirmelidir. Diyarbakır'da yazılım, güvenlik otomasyonu ve topluluk odaklı teknik çalışmalarla bağlantı kurmak için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects sayfalarından başlayabilirsiniz. Projenin mevcut CI platformu, teknoloji yığını ve risk profili ilk değerlendirmede açık biçimde çıkarılmalıdır. Böylece yalnızca araç kurulumu değil sürdürülebilir DevSecOps çalışma modeli oluşturmak mümkün olur.

Sonuç

CI/CD Ortamında Otomatik Güvenlik Taramaları (SAST/DAST), güvenliği yazılım teslimatından ayrı bir kontrol olmaktan çıkarıp geliştirmenin günlük akışına yerleştirir. SAST erken kod geri bildirimi sağlarken DAST çalışan uygulamadaki gerçek davranışı kontrol eder; SCA, secret scanning, IaC, container scan, SBOM ve supply chain kontrolleri ise bu iki katmanın göremediği riskleri tamamlar. Başarılı DevSecOps programında asıl hedef mümkün olan en fazla scanner'ı çalıştırmak değil, geliştiriciye hızlı ve güvenilir sinyal verirken production'a giden riski ölçülebilir biçimde azaltmaktır. Bu süreci kendi projenizde uygulamak, güvenli pipeline örnekleri geliştirmek veya Diyarbakır'daki yazılım topluluğuyla bağlantı kurmak istiyorsanız https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz. Küçük bir pilot repository ile başlayıp SAST, SCA ve secret scan'i pull request'e, DAST'ı staging'e ve risk tabanlı gate'i release sürecine eklemek uygulanabilir ve sürdürülebilir bir ilk adımdır.