DevSecOps: Koddan Canlıya Uçtan Uca Güvenlik Mimarisi

Günde onlarca kez canlıya kod çıkan modern mühendislik ekipleri için hız her şeydir. Fakat teslimat hızı arttıkça, yönetilmesi ve güvenceye alınması gereken güvenlik açıkları da katlanarak büyür. Eskiden yaptığımız gibi projenin en sonuna üç haftalık sızma testi koymak veya güvenlik ekibinin önüne onay biletleri yığmak, artık sürekli teslimat (CI/CD) pipeline'larının hızına yetişemiyor; geliştiricilerin hevesini kıran devasa bir darboğaza dönüşüyor.

Geçtiğimiz yıllarda yaşanan küresel felaketler, güvenliği en sona ertelemenin ne kadar pahalıya patladığını hepimize gösterdi:

• SolarWinds Olayı: Zararlı kodların doğrudan derleme (build) aşamasında enjekte edilebileceğini ve tüm tedarik zincirini zehirleyebileceğini kanıtladı.
• Log4Shell Krizi: Farkında bile olmadığımız derin açık kaynak bağımlılıklarının tüm kurumsal sistemleri bir gecede sıfırıncı gün (0-day) krizine sürükleyebileceğini ortaya koydu.
• Capital One İhlali: Basit bir SSRF zafiyetinin aşırı yetkili bulut rolleriyle birleştiğinde nasıl devasa bir veri sızıntısına dönüştüğünü belgeledi.
• XZ Utils ve Codecov Vakaları: Saldırganların artık doğrudan geliştirici araçlarını, CI runner'larını ve açık kaynak depolarını hedef aldığını gösterdi.

İşte bu yüzden DevSecOps, sağdan soldan araç satın alıp pipeline'lara rastgele tarayıcılar tıkıştırma işi değildir. DevSecOps; güvenliği ilk kod satırından canlı runtime'a kadar her aşamaya organik biçimde yediren bir mühendislik kültürü ve mimari disiplindir.

DevSecOps Operasyonel Modeli ve Temel Prensipler

DevSecOps dönüşümünün sürdürülebilir olması; salt araç tedarikine değil, İnsan, Süreç ve Yönetişim sütunlarının sağlam bir mimari zemin üzerine kurulmasına bağlıdır.

graph LR
    subgraph S1 ["Geliştirici Ortamı (Inner Loop)"]
        IDE["IDE: Semgrep ve Snyk"] --> Hook["Pre-commit: Gitleaks"]
    end

    subgraph S2 ["CI/CD Pipeline (Build ve Test)"]
        SAST["SAST ve SCA Taraması"] --> Sign["Cosign: İmaj İmzalama"]
    end

    subgraph S3 ["Dağıtım ve Çalışma Zamanı (Outer Loop)"]
        GitOps["GitOps: ArgoCD"] --> Runtime["Runtime: Falco ve eBPF"]
    end

    Hook --> SAST
    Sign --> GitOps
    Runtime -.->|Geri Bildirim ve Triyaj| IDE

    class IDE,Hook node-accent;
    class SAST,Sign node-success;
    class GitOps node-warning;
    class Runtime node-danger;

Shift-Left ve Shift-Everywhere Dengesi

Yazılım güvenliğindeki klasik "Shift-Left" yaklaşımı, güvenlik kontrollerini yazılım yaşam döngüsünün başlangıcına (IDE ve Pull Request seviyesine) çekmeyi savunur. Yazılım mühendisliği literatüründe (özellikle IBM Systems Sciences Institute ve NIST çalışmalarında) sıklıkla vurgulandığı üzere, zafiyetlerin tespit ve onarım maliyetleri yaşam döngüsünün ilerleyen aşamalarına doğru doğrusal olmayan bir ivmeyle artar.

• Tasarım ve Kodlama Aşaması: Bir mantıksal açığı veya güvensiz kütüphaneyi yerel ortamda tespit edip gidermek minimum maliyetle ve anında çözülür.
• Pipeline (Build/Test): CI aşamasında yakalanan açıklar, derleme blokajı ve PR geri bildirimiyle mühendislik sprint'i içinde eritilir.
• Canlı Ortam (Production): Canlıya sızmış bir zafiyeti onarmak; acil yama dağıtımları, operasyonel iş kesintileri, hukuki sorumluluklar (GDPR, KVKK, PCI DSS v4.0) ve veri ihlali riskleriyle katlanarak ağırlaşır.

Ancak yalnızca Shift-Left'e odaklanmak şu yapısal kör noktaları doğurur:

1. Çalışma Zamanı Dinamikleri: Altyapı sapmaları (drift), dinamik yetkilendirme hataları ve servisler arası ağ ihlalleri statik kaynak kod analizinde görünmez.
2. Bilinmeyen Tehditler ve Sıfırıncı Gün Açıkları: Kodlama anında henüz kamuya açıklanmamış veya kurumsal çevreye özgü istismar zincirleri statik kural setlerini atlatabilir.
3. Tedarik Zinciri ve Altyapı: CI runner'ının ele geçirilmesi veya üretim ortamı container kaçışları kod seviyesindeki kontrollerden bağımsız gerçekleşir.

Bu nedenle modern mimariler, Shift-Left'i üretim ortamının dinamik korumasıyla harmanlayan "Shift-Everywhere" (veya Tam Yaşam Döngüsü Güvenliği) modelini benimser.

Uçtan Uca SDLC Güvenlik Yaşam Döngüsü

Bütüncül bir güvenlik mimarisi; planlamadan çalışma zamanına kadar her aşamanın kendine has tehditlerine karşı özelleşmiş kontroller tanımlar.

flowchart TD
    subgraph PlanCode ["1. Planlama & Kodlama"]
        Plan["Tehdit Modelleme"] --> Code["IDE Lint & SAST"] --> Commit["Secret Tarama"]
    end

    subgraph BuildTest ["2. Derleme & Doğrulama"]
        Commit --> Build["SCA & Güçlendirme"] --> Test["DAST & Politika Kapısı"] --> Sign["Provenance & Cosign"]
    end

    subgraph DeployRun ["3. Dağıtım & İzleme"]
        Sign --> Deploy["Kabul Denetimi"] --> Run["eBPF & Çalışma Zamanı (Falco)"] --> Feed["Geri Bildirim & İyileştirme"]
        Feed -.-> Plan
    end

Geliştirici Ortamı ve İç Döngü Güvenliği (Inner Loop)

Geliştiricinin yerel makinesinde başlayan iç döngü (Inner Loop), güvenlik geri bildiriminin en ucuz ve en hızlı sağlandığı katmandır.

Modern SAST Derinliği: AST'nin Ötesinde Analiz

Statik Uygulama Güvenlik Testi (SAST), kaynak kodun derlenmeden veya çalıştırılmadan incelenmesidir. Geleneksel yaklaşımlar yalnızca basit düzenli ifadeler veya Soyut Sözdizimi Ağaçları (AST) üzerinde yüzeysel kontroller yaparken, modern kurumsal SAST motorları (ör. CodeQL, Semgrep Pro) çok boyutlu analiz tekniklerini harmanlar:

1. Soyut Sözdizimi Ağacı (AST): Kodun dilbilgisi yapısını hiyerarşik bir ağaç olarak modeller; güvensiz fonksiyon çağrılarını yapısal olarak bulur.
2. Kontrol Akışı Analizi (Control-Flow Analysis): Kod bloklarının hangi koşullarda ve hangi sırada icra edileceğini belirleyen yürütme yollarını modeller.
3. Veri Akışı ve Leke Takibi (Data-Flow & Taint Tracking): Güvenilmeyen bir kaynaktan (Source - ör. HTTP sorgu parametresi) gelen girdinin, güvenli bir arındırma fonksiyonundan (Sanitizer) geçmeden kritik bir noktaya (Sink - ör. eval(), SQL sorgusu, OS komutu) ulaşıp ulaşmadığını izler.
4. Semantik Analiz: Kodun yürütme niyetini ve tip güvenliğini anlamlandırarak yanlış pozitif (FP) oranlarını düşürür.

Gizli Anahtar Taraması: Algoritmalar ve Yanlış Pozitif Yönetimi

Kaynak kod depolarına sızan API anahtarları, özel sertifikalar ve veri tabanı şifreleri, kimlik tabanlı saldırıların temelini oluşturur. Modern tarayıcılar (Gitleaks, TruffleHog) tespit doğruluğunu artırmak için hibrit bir mimari kullanır:

• Düzenli İfade (Regex) Kütüphaneleri: Bilinen sağlayıcıların (AWS AKIA..., GitHub ghp_..., Slack token'ları) standart formatlarını arar.
• Shannon Entropi Analizi: Karakter dizisindeki rastgelelik seviyesini ölçer. Yüksek entropiye sahip dizgiler şifrelenmiş veya rastgele üretilmiş kimlik bilgilerine işaret eder.
• Bağlamsal Anahtar Kelime Doğrulaması: Değişken adları (password, bearer_token, private_key) ile yakınındaki dizgiler arasındaki ilişkiyi inceler.

Gizli anahtar taramasında "sıfır yanlış pozitif" (zero false positives) iddiası gerçekçi değildir. Test dosyalarındaki sahte mock veriler, karmaşık hash değerleri veya yüksek entropili UUID'ler alarm tetikleyebilir. Başarılı bir DevSecOps uygulaması; kural setlerinin kurumsal bağlama göre özelleştirilmesini ve .gitleaksignore ile meşru istisnaların kayıt altına alınmasını gerektirir.

Aşağıdaki yapılandırma, geliştiricinin makinesinde yerel olarak çalışan ve hassas verileri merkezi depoya ulaşmadan engelleyen hafif bir pre-commit kurulumunu modeller:

# .pre-commit-config.yaml - Hızlı Yerel Kontroller (< 3 sn)
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
        name: Detect Hardcoded Secrets
        entry: gitleaks protect --verbose --redact --staged

  - repo: https://github.com/returntocorp/semgrep
    rev: v1.75.0
    hooks:
      - id: semgrep
        name: Fast Local SAST (High-Confidence Rules)
        args: ['--config=p/security-audit', '--error', '--skip-unknown-extensions']

CI/CD Pipeline Tehdit Modeli

Merkezi CI/CD pipeline'ları (GitHub Actions, GitLab CI, Jenkins), kurumsal ortamın en yüksek ayrıcalıklara sahip yürütme merkezleridir. Kod derleme, container oluşturma ve bulut ortamlarına dağıtım yetkilerine sahip oldukları için saldırganların birincil hedefi haline gelmiştir.

flowchart LR
    subgraph Vectors ["Saldırı Vektörleri"]
        V1["Fork PR İstismarı"]
        V2["Zehirlenmiş Action"]
        V3["Güvensiz Runner"]
    end

    subgraph Pipeline ["Hedef CI/CD"]
        Runner["Yetkili Runner & Sırlar"]
    end

    subgraph Impact ["Saldırı Etkisi"]
        I1["Kimlik Sızıntısı"]
        I2["Artifakt Zehirleme"]
        I3["Bulut Ele Geçirme"]
    end

    Vectors --> Runner --> Impact

Kötü Niyetli Pull Request ve Tetikleyici İzolasyonu

GitHub Actions ekosisteminde en sık yapılan yapılandırma hatası pull_request ile pull_request_target tetikleyicileri arasındaki ayrımın yanlış anlaşılmasıdır:

• pull_request: Çatallanmış (fork) depodan gelen PR kodunu çalıştırır; ancak kaynak depodaki gizli anahtarlara (secrets) erişemez ve salt-okunur izinlerle sınırlandırılmıştır.
• pull_request_target: Hedef ana deponun bağlamında çalışır; depodaki gizli anahtarlara tam erişim sağlayabilir ve yazma izinlerine sahip olabilir.

Pipeline Sertleştirme: Harden-Runner ve OIDC Entegrasyonu

Pipeline güvenliğinde iki vazgeçilmez temel prensip vardır:

1. Ağ Çıkış Denetimi (Egress Filtering): Runner'ların yalnızca GitHub, paket depoları veya izin verilen adreslerle iletişim kurmasına izin verilir.
2. Statik Anahtarsız Bulut Erişimi (OIDC): CI ortamında uzun ömürlü AWS_SECRET_ACCESS_KEY saklamak yerine, OpenID Connect (OIDC) ile kısa ömürlü geçici oturum token'ları talep edilir.

Temel GitHub Actions Güvenlik Pipeline'ı

Aşağıdaki iş akışı; modern action sürümlerini, tam SHA sabitlemeyi, minimal token izinlerini ve çok katmanlı tarama disiplinlerini bir araya getiren temel bir CI pipeline'ını modeller.

name: Baseline Security Pipeline

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

permissions:
  contents: read

jobs:
  security-audit:
    name: Fast Triage and Static Verification
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write

    steps:
      - name: Harden Runner (Egress Security)
        uses: step-security/harden-runner@63c24ba6bd7ba022e95695ff85de572c04a18142 # v2.8.1
        with:
          egress-policy: audit

      - name: Checkout Code
        uses: actions/checkout@v6

      - name: Scan for Hardcoded Secrets
        uses: gitleaks/gitleaks-action@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Run SAST Analysis (Semgrep)
        uses: returntocorp/semgrep-action@713efdd345f30344b03657d5bd8a30176b440669 # v1
        with:
          config: p/ci
          generateSarif: "semgrep.sarif"

      - name: Upload Security Findings to GitHub
        if: always()
        uses: github/codeql-action/upload-sarif@d39d31e687223d841ef683f52467bd88e9b21c14 # v3.25.3
        with:
          sarif_file: semgrep.sarif

Yazılım Tedarik Zinciri Güvenliği: SBOM, Provenance ve SLSA

Yazılım geliştirme süreçleri devasa miktarda açık kaynak bağımlılığı üzerine inşa edilir. Bir uygulamanın kod tabanının %80'inden fazlası üçüncü taraf kütüphanelerden oluşur. Tedarik zinciri güvenliği, bu bağımlılıkların ve derleme çıktılarının uçtan uca doğrulanabilir olmasını şart koşar.

flowchart LR
    SCA["1. SCA Taraması<br/>(Açık Tespiti)"] --> SBOM["2. SBOM Üretimi<br/>(Syft Envanteri)"]
    SBOM --> Build["3. İzole Derleme<br/>(Hermetik Ortam)"]
    Build --> Prov["4. Provenance<br/>(SLSA v1.0 Kanıtı)"]
    Prov --> Sign["5. Kriptografik İmza<br/>(Cosign / Sigstore)"]
    Sign --> Gate["6. Kabul Kapısı<br/>(Kyverno Admission)"]

    class SCA,SBOM node-accent;
    class Build,Prov node-success;
    class Sign,Gate node-warning;

Tedarik Zinciri Katmanlarının Ayrımı

Tedarik zinciri kavramları sıklıkla birbirine karıştırılır. Bu disiplinler hiyerarşik bir güven zinciri oluşturur:

1. SCA (Yazılım Bileşen Analizi): Bilinen zafiyetleri (CVE), lisan ihlallerini ve eskiyen paketleri tespit eder.
2. SBOM (Yazılım Malzeme Listesi): Uygulamadaki doğrudan ve transitif tüm bağımlılıkların, sürümlerin ve hash değerlerinin standart makine formatındaki (CycloneDX veya SPDX) eksiksiz envanteridir.
3. Derleme İzolasyonu (Hermetic Builds): Derleme işleminin harici ağ erişimi olmadan, yalnızca doğrulanmış girdi paketleriyle tekrarlanabilir (reproducible) şekilde çalıştırılmasıdır.
4. Provenance (Köken Belgesi): Bir derleme artifaktının hangi kaynak kod commit'inden, hangi derleyicide ve hangi pipeline tarafından üretildiğini kanıtlayan değiştirilemez üst veridir.
5. SLSA (Supply-chain Levels for Software Artifacts): Tedarik zinciri bütünlüğünü değerlendirmek için standartlaştırılmış bir güvenlik çerçevesidir (SLSA v1.0). SLSA, salt bir imzalama standardı değil; kaynak kod, derleme ortamı ve kanıt doğrulama seviyelerini (Build Levels 1–3) tanımlayan mimari bir rehberdir.
6. Kriptografik İmzalama ve Kanıtlama (Cosign & In-Toto): Üretilen container imajını ve SBOM/Provenance üst verilerini bir imza anahtarı veya OIDC kimliğiyle şifreleyerek kayıt altına alır.

Dağıtım Güvenliği ve GitOps Mimarisi (CD)

Sürekli dağıtım (CD) aşamasında geleneksel "Push-Based" modelin yetersizlikleri belirginleşmiş, yerini "Pull-Based" GitOps modeline bırakmıştır.

flowchart LR
    subgraph PushModel ["Push Modeli (Geleneksel)"]
        direction TB
        Runner["CI Runner"] -->|Dışarıya Açık Yönetici Kubeconfig| Ingress["Giriş Portu 6443"] --> ProdCluster["Üretim Kümesi"]
    end

    subgraph PullModel ["Pull Modeli (GitOps Sıfır Güven)"]
        direction TB
        GitRepo["Git Deposu (SSOT)"] <--|Yalnızca Dışa Doğru Güvenli Çekme| Operator["Küme İçi Operatör (ArgoCD)"] --> LocalPods["Üretim Podları"]
    end

Kubernetes Kabul Denetleyicileri (Admission Controllers)

İmzasız veya tedarik zinciri kanıtı bulunmayan hiçbir imajın üretim kümesinde ayağa kalkmaması için giriş kapısında bir denetçi bulunmalıdır. Kyverno, Cosign ile imzalanmamış imajları doğrudan API sunucusu sınırında engeller:

# Kyverno ClusterPolicy - Cosign İmzası Zorunluluğu
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature-policy
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources: { kinds: ["Pod"] }
      verifyImages:
        - imageReferences: ["ghcr.io/enterprise-org/*"]
          attestors:
            - entries:
                - keys:
                    publicKeys: |
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----

Gizli Anahtar Yönetimi ve Süreç İzolasyonu

Veri tabanı şifrelerini, API anahtarlarını veya özel sertifikaları container ortamına düz ortam değişkeni (env) olarak aktarmak güvenlik tehdit yüzeyini genişletir.

flowchart TD
    subgraph EnvRisk ["Ortam Değişkeni Riskleri (env)"]
        Env["Plain Environment Variable"]
        Proc["/proc/$PID/environ Okunabilirliği"]
        Dump["Crash Dump & Hata Logları"]
        Sub["Alt Süreçlerin Miras Alması"]
        Env --> Proc
        Env --> Dump
        Env --> Sub
    end

    subgraph MemorySafe ["Bellek İçi İzolasyon (tmpfs)"]
        Vault["HashiCorp Vault"]
        CSI["Secrets Store CSI Driver"]
        RAM["tmpfs In-Memory Volume"]
        App["Uygulama Süreci (Okuma Yetkisi)"]
        Vault -->|Kısa Ömürlü Token| CSI
        CSI -->|"RAM'e Yaz (Diske Yazma Yok)"| RAM
        RAM -->|Yalnızca İlgili Dosyayı Oku| App
    end

    class Env,Proc,Dump,Sub node-danger;
    class Vault,CSI,RAM,App node-success;

Ortam değişkenlerinin risk modeli şu dinamiklere dayanır:

• Aynı kullanıcı yetkisine sahip diğer süreçler /proc/$PID/environ üzerinden bu değişkenleri okuyabilir.
• Uygulama çöktüğünde üretilen bellek dökümleri (core dumps), hata takip sistemleri veya merkezi log toplayıcılar ortam değişkenlerini farkında olmadan kaydedebilir.
• Ana süreçten çatallanan (fork) alt süreçler bu değişkenleri otomatik olarak miras alır.

Secrets Store CSI Driver ile sırlar diske yazılmadan doğrudan RAM tabanlı geçici dosya sistemine (tmpfs) monte edilir. Uygulama sırları dosya okuma yetkisiyle tüketir ve süreç bittiğinde bellekten tamamen silinir:

# Pod Volume Mount - RAM Tabanlı Gizli Anahtar
volumeMounts:
  - name: secrets-store-inline
    mountPath: "/mnt/secrets"
    readOnly: true
volumes:
  - name: secrets-store-inline
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: "vault-database-credentials"

Olay Güdümlü ve Sunucusuz Mimarilerde Güvenlik (Serverless & Event-Driven)

Modern bulut mimarileri geleneksel sanal makinelerden ve Kubernetes kümelerinden hızla sunucusuz (Serverless) ve Edge Computing (Cloudflare Workers, AWS Lambda) platformlarına kaymaktadır. Bu mimariler işletim sistemi yönetim yükünü ortadan kaldırsa da kendilerine has bir güvenlik ve tehdit profili sunar.

flowchart TD
    subgraph Sources ["Olay Kaynakları (Event Triggers)"]
        H["HTTP Request"]
        Q["Queue Message (SQS / Cloudflare Queues)"]
        C["Cron / Scheduled Event"]
        W["Webhook Payload"]
        S["Object Storage Event (S3 / R2)"]
    end

    subgraph RuntimeContext ["Sunucusuz Yürütme Bağlamı"]
        Engine["FaaS / V8 Isolate Runtime"]
        Bindings["Platform Bindings (KV, D1, Secret Enjeksiyonu)"]
        Warm["Warm Start (Süreç Durumu Yeniden Kullanımı)"]
    end

    subgraph Sinks ["Kritik Noktalar (Application Sinks)"]
        DB[(Veritabanı / D1)]
        ExtAPI[Harici API İstekleri]
        Store[(Nesne Deposu / R2)]
    end

    Sources --> Engine
    Engine --> Bindings
    Engine --> Warm
    Bindings --> Sinks

    class Sources node-accent;
    class Engine,Bindings,Warm node-warning;
    class Sinks node-success;

Olay Kaynakları ve SAST Leke Analizi Kör Noktaları

Geleneksel SAST kuralları, güvenlik açıklarını ararken çoğunlukla standart HTTP girdi parametrelerini (req.params, req.body, $_GET) potansiyel leke kaynakları (taint sources) olarak modeller. Ancak olay güdümlü mimarilerde veri akışı HTTP sınırlarının çok ötesine geçer:

• Kuyruk Mesajları (Queue Events): Asenkron mesaj kuyruklarından tüketilen veriler genellikle güvenilir kabul edilerek doğrudan arka plan işleyicilerine aktarılır; bu durum dolaylı enjeksiyon açıklarına yol açabilir.
• Webhook ve Nesne Depolama Olayları: Dış servislerden gelen webhook yükleri veya depoya yüklenen bir dosyanın meta verileri arındırılmadan bir veritabanı veya komut çağrısına ulaştığında kritik açıklara neden olur.
• Hizmet Bağlayıcıları (Service Bindings & Environment): Cloudflare Workers gibi izole ortamlarda servisler arası iletişim ağ soketleri yerine doğrudan bellek içi platform bağlamları (Bindings) üzerinden sağlanır.

Geliştiricilerin ve güvenlik ekiplerinin statik analiz araçlarını HTTP dışı olay kaynaklarını da birer girdi olarak tanıyacak şekilde özel leke kurallarıyla (custom taint rules) yapılandırması şarttır.

Sıcak Başlatma (Warm Start) ve Durum Yeniden Kullanımı

Sunucusuz fonksiyonlar her çağrıda sıfırdan ayağa kalkmaz. Bulut sağlayıcılar maliyeti ve gecikmeyi düşürmek için yürütme ortamını "sıcak" tutar (warm start).

• Fonksiyon kapsamı dışındaki global değişkenler ve yerel geçici disk alanları (/tmp) ardışık çağrılar arasında korunabilir.
• Bir kullanıcının talebi sırasında global bir nesneye yazılan hassas kimlik bilgisi veya oturum verisi, bir sonraki çağrıda farklı bir kullanıcının bağlamına sızabilir.
• Çözüm: Fonksiyonlar tamamen durumsuz (stateless) tasarlanmalı, çağrı sonunda hassas değişkenler açıkça temizlenmeli ve gizli anahtarlar disk yerine platformun güvenli bağlayıcıları (Secret Bindings / IAM Roles) üzerinden anlık okunmalıdır.

Runtime Güvenliği (Runtime Security: eBPF, Falco ve Tetragon)

Ne kadar sıkı test edilirse edilsin, hiçbir sistem üretim ortamında sıfır risk garantisi veremez. Canlı ortamda gerçekleşen yetki yükseltme, container kaçışı veya sıfırıncı gün saldırılarını yakalamak için çekirdek (kernel) seviyesinde görünürlük zorunludur.

flowchart TD
    subgraph UserSpace ["Kullanıcı Alanı (Uygulamalar & Alarmlar)"]
        Workload["İş Yükü Podları"]
        Falco["Falco Motoru (Alarmlar)"]
    end

    subgraph KernelSpace ["Linux Çekirdek Alanı (eBPF)"]
        Syscalls["Sistem Çağrıları (execve, connect, openat)"]
        eBPF["eBPF Hook'ları & LSM Hooks"]
        Tetragon["Tetragon (Engelleme)"]
    end

    Workload --> Syscalls --> eBPF
    eBPF -->|Olay Akışı| Falco
    eBPF --> Tetragon -.->|SIGKILL ile Sonlandırma| Workload

eBPF Teknolojisi: Çekirdek Seviyesinde Gözlemlenebilirlik

Geleneksel güvenlik ajanları (ör. auditd, ptrace), her sistem çağrısında kullanıcı alanı ile çekirdek arasında yoğun context switch'e yol açarak %15–30 arasında işlemci yükü oluşturur.

eBPF (Extended Berkeley Packet Filter), Linux çekirdeğini yeniden derlemeden veya riskli çekirdek modülleri yüklemeden doğrudan çekirdek alanı içerisinde güvenli, sanal makine tabanlı kod çalıştırma imkanı sunar:

• Çekirdek olayları (tracepoints, kprobes, LSM hooks) minimum ek yükle izlenir.
• Bir container içinde ptrace veya kullanıcı alanı araçları saldırgan tarafından devre dışı bırakılsa dahi çekirdek seviyesindeki görünürlük kesintiye uğramaz.

Falco ve Tetragon: Tespit ve Engelleme Ayrımı

Kurumsal mimarilerde bu iki açık kaynaklı eBPF aracı farklı sorumluluklar üstlenir:

• Falco (Tehdit Tespiti ve Görünürlük): Sistem çağrılarını (execve, openat, socket) dinler, kullanıcı alanındaki kural motoruyla eşleştirir ve anomali anında SIEM/Slack alarmları üretir. Bir container içinde interaktif kabuk (/bin/bash) açılması veya /etc/shadow dosyasına erişilmesi gibi davranışları raporlar.
• Tetragon (Cilium - Doğrudan Çekirdekte Engelleme): Yalnızca tespit etmekle kalmaz; Linux Güvenlik Modülleri (LSM) hook'larını kullanarak kötü niyetli bir işlemi kullanıcı alanındaki ajanın onayını beklemeden doğrudan çekirdek seviyesinde (in-kernel) engelleyebilir veya süreci sonlandırabilir (SIGKILL).

# Örnek Falco Kuralı - Container İçinde Kabuk Başlatma Tespiti
- rule: Container İçinde Yetkisiz Kabuk Açılması
  desc: Üretim ortamında bir container içinde shell açıldığında tetiklenir
  condition: >
    spawned_process and container and
    (proc.name in (bash, sh, zsh, ksh))
  output: >
    Kritik Güvenlik Alarmı: Pod içinde kabuk başlatıldı
    (user=%user.name pod=%k8s.pod.name image=%container.image.repository)
  priority: CRITICAL
  tags: [runtime, container, mitre_execution]

RASP (Runtime Application Self-Protection) Gerçekleri

RASP, uygulamanın çalıştığı sanal makinenin veya çalıştırma motorunun (JVM, Node.js, CLR) içine entegre olan bir güvenlik katmanıdır. Dış çevre güvenliği sağlayan WAF (Web Application Firewall) cihazlarının şifreli trafik veya karmaşık yükler karşısında yetersiz kaldığı durumlarda RASP; gelen verinin bellekte nasıl işlendiğini, veritabanına giden sorgunun yapısını veya dosya sistemi çağrılarını bağlamsal olarak denetler. RASP, çevre kontrollerinin ayırt etmekte zorlandığı deserialization veya kör SQL injection gibi karmaşık saldırı sınıflarına karşı bağlamsal doğrulama sağlar.

Altyapı Güvenliği ve Platform Metadata Kontrolleri

Bulut ortamlarında çalışan uygulamalar için en ölümcül saldırı vektörlerinden biri Sunucu Taraflı İstek Sahteciliği (SSRF) zafiyetidir. Uygulama üzerindeki bir SSRF açığı, saldırganın platformun dahili Metadata Servisine (169.254.169.254) erişerek sunucuya atanmış bulut kimlik rollerini (IAM Credentials) sızdırmasına olanak tanır.

Her bulut platformu bu riski yönetmek için farklı savunma mimarileri uygular.

# AWS EC2 Terraform - Güvenli IMDSv2 ve Container Hop Limit Yapılandırması
resource "aws_instance" "secure_workload" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required" # IMDSv1'i devre dışı bırakır, v2 oturumu zorunlu kılar
    http_put_response_hop_limit = 2          # Container/bridge ağları için güvenli sınır
    instance_metadata_tags      = "disabled"
  }
}

Organizasyonel Güvenlik ve Olgunluk Modelleri

DevSecOps dönüşümünün başarısız olmasının en yaygın sebebi teknik araç yetersizliği değil, organizasyonel kültür ve süreç kopukluğudur.

Güvenlik Şampiyonları (Security Champions) Ağı

Merkezi bir güvenlik ekibinin her sprint planlamasına, mimari tartışmaya veya pull request onayına dahil olması matematiksel olarak imkansızdır. Çözüm, her geliştirme takımının (Squad) içerisinden gönüllü ve güvenlik bilincine sahip bir mühendisin Güvenlik Şampiyonu olarak yetiştirilmesidir.

graph TD
    SecTeam["Merkezi Güvenlik Mühendisliği"]
    Champion1["Şampiyon: Squad A"]
    Champion2["Şampiyon: Squad B"]
    Champion3["Şampiyon: Squad C"]

    DevsA["Geliştiriciler (Squad A)"]
    DevsB["Geliştiriciler (Squad B)"]
    DevsC["Geliştiriciler (Squad C)"]

    SecTeam <-->|Politika Eğitimi ve Araç Desteği| Champion1
    SecTeam <-->|Politika Eğitimi ve Araç Desteği| Champion2
    SecTeam <-->|Politika Eğitimi ve Araç Desteği| Champion3

    Champion1 <-->|Yerel Tehdit Modelleme ve PR İncelemesi| DevsA
    Champion2 <-->|Yerel Tehdit Modelleme ve PR İncelemesi| DevsB
    Champion3 <-->|Yerel Tehdit Modelleme ve PR İncelemesi| DevsC

    class SecTeam node-danger;
    class Champion1,Champion2,Champion3 node-warning;
    class DevsA,DevsB,DevsC node-accent;

DevSecOps Olgunluk Çerçeveleri: SAMM vs DSOMM

Kurumlar güvenlik yolculuklarındaki ilerlemelerini tarafsız çerçevelerle ölçmelidir:

• OWASP SAMM (Software Assurance Maturity Model v2.0): Organizasyonel düzeyde yazılım güvencesini ölçer; Yönetişim, Tasarım, Uygulama, Doğrulama ve Operasyon olmak üzere 5 temel alanı kapsar.
• OWASP DSOMM (DevSecOps Maturity Model v5.1): Doğrudan CI/CD pipeline'larına, otomatik testlere ve DevOps iş akışlarına entegre teknik faaliyetlerin derinliğini ölçer (Statik Derinlik, Dinamik Derinlik, Yoğunluk ve Konsolidasyon boyutları).
• NIST SSDF (SP 800-218): ABD federal standartlarında güvenli yazılım geliştirme uygulamalarını belirleyen kurumsal çerçevedir.

Pratik DevSecOps Uygulama Yol Haritası

Tüm bu araç ve süreçleri bir gecede devreye almaya çalışmak "güvenlik yorgunluğuna" ve mühendislik direncine yol açar. Kademeli bir uygulama planı izlenmelidir:

flowchart TD
    P1["1. Envanter & İç Döngü"] --> P2["2. CI Kalite Kapısı & SBOM"]
    P2 --> P3["3. GitOps & Kabul Denetimi"]
    P3 --> P4["4. Runtime eBPF & Şampiyonlar"]

1. Aşama 1 — Keşif ve Envanter: Mevcut kod depolarını, kullanılan bağımlılıkları ve bulut varlıklarını listeleyin.
2. Aşama 2 — İç Döngü Hijyeni: Pre-commit hook'larını (Gitleaks) devreye alarak depolara yeni gizli anahtar sızmasını tamamen durdurun.
3. Aşama 3 — Temel CI Kalite Kapıları: CI pipeline'larına hafif SAST ve SCA kontrolleri ekleyin; sonuçları SARIF formatında geliştiriciye sunun.
4. Aşama 4 — Tedarik Zinciri Güvenliği: Distroless imajlara geçin, Syft ile SBOM üretin ve Cosign ile imajları kriptografik olarak imzalayın.
5. Aşama 5 — GitOps ve Kabul Kontrolleri: Dağıtımı ArgoCD ile çekme (pull) modeline taşıyın; Kyverno ile imzasız imajların ayağa kalkmasını engelleyin.
6. Aşama 6 — Runtime Görünürlüğü: Üretim Kubernetes kümelerine eBPF tabanlı Falco ve Tetragon kurarak çekirdek seviyesinde anomali takibi başlatın.
7. Aşama 7 — Olgunluk ve Şampiyonlar: Güvenlik Şampiyonları ağını kurun, OWASP DSOMM 5.1 ile kurumun olgunluk seviyesini periyodik olarak değerlendirin.

Güvenlik bir varış noktası değil, sürekli evrilen bir yolculuktur. Yazılım geliştirme hızınızı düşürmeden, geliştiriciyi düşman değil ortak görerek ve her adımı koda dökerek dirençli sistemler inşa edebilirsiniz. Verinizin ve kodunuzun mimarı olun!

Kaynakça

1. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. National Institute of Standards and Technology.
2. OWASP SAMM v2.0: Software Assurance Maturity Model: A Guide to Building Security into Software Development. OWASP Foundation.
3. OWASP DSOMM v5.1: DevSecOps Maturity Model (Released September 2026): Dimensions for Evaluating Engineering Workflows. OWASP Foundation.
4. SLSA Specification v1.0: Supply-chain Levels for Software Artifacts: Build Track & Provenance Requirements. OpenSSF.
5. GitHub Actions Security Documentation: Securely using pull_request_target & Hardening Runners with OpenID Connect (OIDC). GitHub Docs.
6. CNCF Cloud Native Security Whitepaper v2: Cloud Native Computing Foundation Security Technical Advisory Group.
7. Sigstore & Cosign Architecture: Standard for Container Signing, Verification and Storage in OCI Registries. Linux Foundation.
8. Kyverno Documentation: Kubernetes Native Policy Management and Image Verification Engine.
9. Falco & Tetragon Kernel Tracing Documentation: Runtime Security and eBPF-Based In-Kernel Observability and Enforcement.
10. CIS Benchmarks: Center for Internet Security Benchmarks for Kubernetes and Linux Operating Systems.