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.
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? (SXO aksiyon listesi)
- • 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 (Internal link: /tr/yazilim/bakim-ve-destek).
- • 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.
☑ 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? (Internal link: /tr/raporlama/kvkk-veri-guvenligi)
Ne yapmalıyım? (SXO aksiyon listesi)
- • 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.
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.
☑ 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? (SXO aksiyon listesi)
- • İ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 (Internal link: /tr/yazilim/bakim-ve-destek).
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”.
☑ 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? (SXO aksiyon listesi)
- • 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 (Internal link: /tr/yazilim/web-sitesi-gelistirme, /tr/yazilim/sunucu-guvenlik).
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
5) Kontrol Listesi
- •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
Deliverables + “Buraya:” notları
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.