📌 Hızlı Özet & Temel Çıkarım:
DevSecOps ve Güvenlik Otomasyonu, güvenlik denetimlerini yazılım canlıya çıkmadan önceki son güne bırakmak yerine; her kod commit’inde ve Pull Request aşamasında otomatik olarak çalıştıran (Shift-Left Security) modern mühendislik yaklaşımıdır. Statik Kod Analizi (SAST), Bağımlılık Taraması (SCA) ve Container İmaj Zafiyet Taramaları CI/CD hattına entegre edilerek; kritik güvenlik açıkları ve sızdırılmış gizli anahtarlar (secrets) üretime ulaşmadan engellenir.

1. Shift-Left Felsefesi: Güvenliği En Başa Çekmek

Geleneksel yazılım süreçlerinde güvenlik ekipleri projeyi ancak canlıya alınmadan birkaç gün önce penetrasyon testine tabi tutardı. Bu aşamada tespit edilen kritik bir mimari açık, projenin haftalarca ertelenmesine veya milyonlarca liralık refactoring maliyetine yol açardı.

Shift-Left prensibiyle güvenlik kontrolleri yazılımcının geliştirme ortamına ve CI/CD hattına çekilir:

  1. Pre-commit Hook: Kod commit edilmeden önce yerel makinede gizli anahtarlar (API key, token) taranır (gitleaks).
  2. Pull Request CI Pipeline: Kod depoya gönderildiği anda statik analiz araçları çalışır ve güvenlik puanı düşerse PR birleştirmesi engellenir.
  3. Build Aşaması: Docker imajı oluşturulduğu anda bilinen CVE (Common Vulnerabilities and Exposures) açıkları taranır.

2. GitHub Actions ile Üretim Seviyesi DevSecOps Hattı

Aşağıdaki iş akışı (workflow), hem uygulama kodunu hem de üretilen container imajını otomatik olarak denetleyen gerçek dünya CI/CD hattını gösterir:

name: DevSecOps Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  security-audit:
    runs-on: ubuntu-latest
    steps:
    - name: Depoyu Klonla
      uses: actions/checkout@v4

    - name: Secret Leak Taramasi (Gitleaks)
      uses: gitleaks/gitleaks-action@v2
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    - name: Statik Kod Analizi (Semgrep SAST)
      run: |
        docker run --rm -v "${{ github.workspace }}:/src" returntocorp/semgrep           semgrep scan --config=auto --error --severity=ERROR

    - name: Docker Imajini Derle
      run: |
        docker build -t myapp:${{ github.sha }} .

    - name: Container Zafiyet Taramasi (Trivy)
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: 'myapp:${{ github.sha }}'
        format: 'table'
        exit-code: '1' # Kritik acik varsa pipeline'i kirmizi yap
        ignore-unfixed: true
        severity: 'CRITICAL,HIGH'

    - name: SBOM (Software Bill of Materials) Uretimi
      uses: anchore/sbom-action@v0
      with:
        image: 'myapp:${{ github.sha }}'
        format: 'spdx-json'
        output-file: 'sbom.spdx.json'

Bu boru hattı sayesinde:

  • Eğer koda yanlışlıkla bir AWS anahtarı eklenmişse gitleaks anında pipeline’ı kırar.
  • Eğer kodda SQL Injection veya güvensiz eval kullanımı varsa semgrep uyarır.
  • Eğer temel Docker imajında kritik bir OpenSSL açığı varsa trivy dağıtımı durdurur.

3. SBOM (Software Bill of Materials) Neden Zorunlu Hale Geldi?

Modern yazılımlar binlerce açık kaynak kütüphanenin üzerine inşa edilir (Log4j krizini hatırlayın). Kuruluşunuzun kullandığı bir alt bağımlılıkta sıfır-gün (zero-day) açığı çıktığında, “Biz bu kütüphaneyi hangi servislerimizde kullanıyoruz?” sorusuna anında yanıt verebilmek için her derlemede bir Yazılım Malzeme Listesi (SBOM) üretilmelidir.

SPDX veya CycloneDX formatındaki bu dijital envanter, denetçilere ve kurumsal müşterilere yazılım tedarik zincirinizin (software supply chain) güvenilir olduğunu kanıtlar.

4. İlgili Konular ve İç Bağlantılar

5. Sıkça Sorulan Sorular

SAST ile DAST arasındaki temel fark nedir?

SAST (Static Application Security Testing) kaynak kodu derlemeden beyaz kutu (white-box) olarak inceler. DAST (Dynamic Application Security Testing) ise çalışan uygulamaya dışarıdan sahte saldırılar göndererek kara kutu (black-box) güvenlik açıklarını arar. İdeal bir DevSecOps hattında her ikisi de bulunmalıdır.

Zafiyet taramasında her uyarı için pipeline durdurulmalı mıdır?

Hayır. Düşük (Low) veya düzeltmesi henüz yayınlanmamış (unfixed) uyarılar için geliştirme süreçleri bloke edilmemelidir. Eşik değeri genellikle CRITICAL ve HIGH seviyesine ayarlanır.

6. Güvenli Dağıtım Modelleri: Mavi-Yeşil (Blue-Green) ve Kanarya (Canary) Dağıtımları

Güvenlik testlerinden başarıyla geçen bir kodun canlı ortama aktarılırken kullanıcılara kesinti yaşatmaması için modern dağıtım stratejileri uygulanır:

  1. Blue-Green Deployment: Canlıda yeşil sürüm çalışırken, yeni kod tamamen izole mavi ortama kurulur. Duman testleri (smoke tests) başarıyla tamamlandığında yük dengeleyici trafiği tek milisaniyede maviye çevirir. Bir hata çıkarsa anında yeşile dönülür.
  2. Canary (Kanarya) Dağıtımı: Yeni sürüm önce kullanıcıların yalnızca %2’sine açılır. Prometheus ve OpenTelemetry metrikleri hata oranı ve gecikme açısından otomatik izlenir; eğer P99 süresi yükselmezse oran kademeli olarak %10, %50 ve %100’e çıkarılır.

Bu disiplin, yazılım ekiplerinin cuma günleri dahi güvenle canlıya kod çıkabilmesini sağlayan en yüksek operasyonel olgunluk seviyesidir.

7. GitHub Actions Self-Hosted Runner Güvenliği ve Ephemeral İşçiler

Kurumsal ortamlarda ve robotik projelerinde donanım testleri veya büyük container derlemeleri için GitHub’ın paylaşımlı sunucuları yerine yerel sunucularda koşan self-hosted runner işçileri kullanılır.

Ancak kalıcı (persistent) runner’lar ciddi bir güvenlik riski taşır: Bir önceki iş akışında container içinde kalan zararlı bir script, bir sonraki derlemenin gizli anahtarlarını çalabilir.

Bu riski önlemek için Ephemeral (Tek Kullanımlık) Runner mimarisi uygulanır:

  • GitHub Webhook sinyali geldiğinde Kubernetes veya Docker üzerinde yeni bir izole sanal makine ayağa kalkar.
  • Derleme ve güvenlik testleri bu izole ortamda koşulur.
  • Testler bittiği anda makine kendini imha eder (terminate) ve diski tamamen silinir.
  • Bu sayede iş akışları arasında kalıntı veri veya zehirlenmiş paket geçişi imkansız hale gelir.

8. Üretim Dağıtım Öncesi Son Güvenlik Kontrol Listesi

Boru hattının (pipeline) yeşil yanması tek başına yeterli değildir; canlıya çıkış öncesi operasyonel güvenlik ekibi şu maddeleri doğrular:

  • Bütün bağımlılıkların hash doğrulama anahtarları (checksums) kilit dosyasında (package-lock.json veya poetry.lock) sabitlenmiş mi?
  • Dağıtımı tetikleyen Git commit’i GPG anahtarı ile doğrulanmış (verified commit) imzaya sahip mi?
  • Üretim ortamı için ayrılan API gizli anahtarları yalnızca korumalı dallardan (protected branches) okunabilecek şekilde kısıtlanmış mı?
  • Güvenlik açığı tarama raporu otomatik olarak merkezi SIEM / güvenlik paneline aktarıldı mı? Bu dörtlü teyit mekanizması, insan hatasından kaynaklanabilecek güvenlik sızıntılarını tamamen sıfırlayan son savunma kalkanıdır.