1. DevSecOps Nedir?
DevSecOps, “güvenlik ekibi ayrı bir kapıda kontrol yapar” yaklaşımını bırakır; güvenliği pipeline’ın içine dağıtır ve otomasyonla ölçekler. Amaç, güvenliği yavaşlatmak değil; erken yakalayıp daha ucuz düzeltmektir.
Bu nedenle CI/CD pipeline içine güvenlik gate eklemek, modern web ve yazılım altyapısında güvenli release yönetiminin temel parçası haline gelir; güvenlik kontrolü release sonrasına değil, doğrudan teslimat akışına taşınır.
DevSecOps nedir, klasik DevOps’tan farkı nedir?
DevOps hız ve otomasyon odaklıdır; DevSecOps ise aynı otomasyonun içine güvenlik kontrollerini (SAST/SCA/secret scan/policy) gate olarak ekler. Fark; güvenliği “son adım” değil “sürekli süreç” haline getirmesidir; bulgular prod’a çıkmadan yakalanır ve backlog’a bağlanır.
Neden “shift-left” yaklaşımı kritik?
- •Erken bulgu = daha düşük maliyet
- •Prod bulgusu = acil hotfix ve risk
- •Sürekli değişen dependency ve kod akışında “son kontrol” yetişmez
☑ Mini Check : DevSecOps olgunluğu
- •CI/CD var ve standart mı?
- •Güvenlik kontrolleri otomatik mi?
- •Kritik bulguda release bloklanıyor mu?
- •Bulgular backlog’a akıyor mu?
- •Re-test döngüsü var mı?
Ne yapmalıyım?
- • Gate’leri kademeli ekle; önce görünürlük, sonra blok.
- • Kritik bulguyu prod’a sokma; gate ile engelle.
- • Bulguları sprint planına bağla.
- • Policy setini yaşayan doküman yap (180 gün kalibrasyon).
2. Güvenlik Ekiplerini Pipeline’a Dahil Etmek
DevSecOps “güvenlik ekibi kod yazsın” demek değildir. Güvenlik ekibi; standartları, eşikleri ve exception süreçlerini tasarlar; geliştirici ekipler ise pipeline içinde uygular. Ortak dil: risk sınıfları ve kapanış SLA’larıdır.
Rol paylaşımı (pratik)
- •Güvenlik: policy, eşik, risk sınıfı, exception yönetimi
- •DevOps: pipeline entegrasyonu, raporlama, gate işletimi
- •Geliştirici: fix, test, re-test doğrulaması
Backlog ve SLA
Bulgular “rapor” olarak kalırsa DevSecOps olmaz. Bulgu; ticket olur, owner atanır, SLA alır ve re-test ile kapanır.
Özellikle altyapı manifest’leri, rol tanımları ve güvenlik eşiklerinin doğrudan kod üzerinden yönetildiği yapılarda security as code yaklaşımı sayesinde manuel kontrol yükü azalır ve güvenlik kararları pipeline içinde tekrarlanabilir hale gelir.
Ayrıca secret scan bulguları, erişim kayıtları ve hassas veri sızıntısı sinyallerinin secret scan ve veri güvenliği perspektifiyle ele alınması; teknik tedbir kanıtı ve veri koruma disiplini açısından kritiktir.
☑ Mini Check : Operasyon modeli
- •Security policy dokümanı var mı?
- •Exception (süreli) yönetimi var mı?
- •Bulgu→ticket→owner akışı var mı?
- •SLA ve re-test kuralı var mı?
- •KVKK teknik tedbir kanıtı olarak kayıt tutuluyor mu?
Ne yapmalıyım?
- • Security policy + gate kriterlerini yazılı hale getir.
- • Exception’ları süreli yap; kapanış tarihi zorunlu olsun.
- • Bulgu yönetimini backlog’a bağla; re-test ile kapat.
- • Raporlamayı standardize et (dashboard + aylık özet).
3. CI/CD’de Güvenlik Gate’leri (SAST, SCA, Secret Scan, Policy Check)
Gate’ler, pipeline’da doğru noktaya konduğunda hem etkili hem düşük maliyetlidir. En pratik yerleşim:
- •Commit/Merge: secret scan + temel lint
- •Build/Test: SAST + SCA
- •Deploy öncesi: policy check + hardening doğrulaması
- •Deploy sonrası: hafif DAST/monitoring (kapsama göre)
CI/CD pipeline’ına hangi güvenlik gate’lerini eklemeliyim?
En düşük sürtünmeli başlangıç; commit/merge’de secret scan, build aşamasında SCA (dependency) ve temel SAST, deploy öncesinde policy check’tir. Kritik sistemlerde (ödeme/rezervasyon) bu gate’ler “block” moduna alınır; diğer projelerde önce “warn” ile başlayıp kademeli sıkılaştırılır.
SAST, SCA ve secret scan arasında ne fark var?
- •Secret scan: repo’ya yanlışlıkla giren API key/parola gibi secret’ları yakalar.
- •SCA: dependency ve lockfile üzerinden üçüncü parti riskleri (CVE, supply chain) yakalar.
- •SAST: kodun içinde potansiyel güvenlik hatalarını (injection, auth zayıflığı) analiz eder.
Üçü birlikte, en sık üretime taşınan riskleri azaltır.
Bu kontrollerin staging, tekrar test ve açık doğrulama tarafı ise SAST, SCA ve sürekli güvenlik testleri yaklaşımıyla tamamlanır; böylece pipeline bulguları sahadaki gerçek güvenlik davranışıyla eşleştirilmiş olur.
Özellikle üçüncü taraf paketler, lockfile disiplini ve registry kaynakları söz konusu olduğunda dependency scanning ve supply chain güvenliği aynı build zincirinin vazgeçilmez parçası haline gelir.
Policy check (deploy gate)
- •IaC policy: açık port, public bucket, geniş IAM gibi riskleri engeller
- •Image policy: tarama sonucu kritik CVE varsa deploy blok
- •K8s policy: privileged pod, hostPath mount gibi yasaklar
Gate eşikleri nasıl belirlenir? (kademeli sertleştirme)
- 1. faz: görünürlük (raporla, bloklama yok)
- 2. faz: kritik bulguda blok (high/critical)
- 3. faz: orta seviye bulgular için SLA + bloklama
Bu yaklaşım, “pipeline’ı kilitlemeden” olgunlaşmayı sağlar.
Gate sonuçlarının eğilim bazında izlenebilmesi için pipeline güvenlik bulgularının raporlanması gerekir; fail/pass oranları, açık yoğunluğu ve tekrar eden ihlaller tek panelde görünür hale gelmeden sürekli iyileştirme zorlaşır.
☑ Mini Check : Gate yerleşimi
- •Secret scan commit/merge’de
- •SCA build’de (lockfile zorunlu)
- •SAST build/test’te
- •Policy check deploy öncesi
- •Kritik bulguda block, diğerlerinde backlog kuralı var
Ne yapmalıyım?
- • İlk hafta: secret scan + SCA’yı hızlı kazanım olarak kur.
- • İkinci adım: SAST’ı ekle; false-positive yönetimi yap.
- • Deploy öncesi policy check ile misconfig’leri yakala.
- • Gate sonuçlarını sprint backlog’una akıt.
4. Otel ve B2B İçin DevSecOps Örnekleri
DevSecOps’un değeri, “kritik akışlar” üzerinden görünür olur.
Otel örneği — rezervasyon/ödeme modülleri
- •Secret scan: ödeme anahtarları repo’ya girmesin
- •SCA: ödeme ve rezervasyon paketleri kilitli (lockfile)
- •SAST: auth ve input validation odaklı
- •Policy check: prod deploy’da açık port/yanlış IAM blok
B2B örneği — portal/API release’leri
- •SAST: RBAC/tenant izolasyonu risklerine odak
- •SCA: entegrasyon SDK’ları ve dependency hijyeni
- •Policy: K8s pod security ve network policy kontrolü
- •Backlog: bulgular sprint planına girer, re-test ile kapanır
Fark yaratan mini bölüm (Competitor Gap): “Güvenlik backlog’u”
DevSecOps’un olgunlaştığı yer, bulguların backlog’a girip kapanmasıdır. Gate’ler tek başına “rapor üretir”; backlog + SLA + re-test ise “sonuç üretir”.
Release sonrasında yönlendirme, build çıktısı, frontend varlıkları ve performans davranışı da izlenmelidir; çünkü hatalı bir deployment yalnız güvenlik açığı değil, aynı zamanda release sonrası teknik SEO kontrolü gerektiren erişilebilirlik ve crawl problemleri de üretebilir.
☑ Mini Check : Uygulama örnekleri
- •Otel rezervasyon/ödeme modüllerinde stricter gate var
- •B2B portal/API’de RBAC odaklı SAST kuralları var
- •Policy check misconfig’leri yakalıyor
- •Bulgu SLA ve re-test kuralı var
- •Aylık security ops raporu var (trendler)
Ne yapmalıyım?
- • Kritik modüllerde gate’i “block” yap, diğerlerinde “warn→block” kademesi uygula.
- • Security backlog’u sprint planning’e dahil et.
- • Kapanışı re-test ile doğrula.
- • Web geliştirme ve sunucu güvenlik süreçleriyle entegre et.
5. İçerik içi tablo (Gate türleri ve önerilen eşik yaklaşımı)
| Gate | Pipeline noktası | Eşik yaklaşımı | Aksiyon |
|---|---|---|---|
| Secret scan | Commit/MR | Her zaman block | Merge engelle + secret revoke |
| SCA | Build | Critical→block, High→SLA | Ticket + fix + re-test |
| SAST | Build/Test | İlk faz warn, sonra critical block | Backlog + kademeli sertleştirme |
| Policy check | Deploy öncesi | Misconfig critical→block | Deploy engelle + düzelt |
| DAST (opsiyonel) | Staging | Critical→block | Release engelle + re-test |
6. CI/CD İçin DevSecOps Güvenlik Gate Planlama Şablonunu İndir
CI/CD İçin DevSecOps Güvenlik Gate Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon, CI/CD içinde security gate’leri doğru noktaya yerleştirip eşiklerini kademeli sertleştirmek için hazırlanmıştır. Secret scan, SAST, SCA ve policy check çıktılarının ticket/backlog’a düşmesini ve kritik bulguda release bloklamayı standardize eder. Amaç; prod’a zafiyet taşıma oranını ve acil hotfix ihtiyacını azaltmaktır.
Kim Kullanır?
DevOps/Platform lead, güvenlik lideri, backend lead, release sorumlusu.
Nasıl Kullanılır?
- Pipeline adımlarını (commit→build→test→deploy) ve gate yerleşimini yaz.
- Eşik kademesini (warn→block) ve SLA’ları tanımla.
- Bulgu→backlog→fix→re-test kapanış döngüsünü ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Secret scan her zaman block
- ▢ ✅ SCA lockfile ile bağlı
- ▢ ✅ Policy check deploy öncesi
- ▢ ✅ Backlog + re-test döngüsü var
- ▢ ✅ 180 gün kalibrasyon takvimi var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Pipeline güvenlik modelini kurumsal ölçekte netleştirmek için Sunucu ve Güvenlik hizmetiyle shift left security sürecinizi güçlendirin; uygulama kapsamı ve ek sorular için de Sunucu ve Güvenlik hakkında sık sorulan sorular sayfasına bakın.
Bir Sonraki Adım
SAST/SCA/secret scan ve policy gate setini CI/CD’ye doğru yerleştirip prod’a zafiyet taşıma riskini azaltmak isteyen otel ve B2B ekipleri için.