CI/CD Güvenliği: Pipeline'a Sızan Bir Saldırı Nasıl Önlenir

Modern yazılım teslimatının omurgası olan CI/CD pipeline'ları, kod deposundan üretime kadar geniş bir yetki alanına sahiptir: sırları okuyabilir, imzalı artefakt üretebilir ve doğrudan üretim ortamına dağıtım yapabilir. Bu geniş yetki, pipeline'ı saldırganlar için son derece cazip bir hedefe dönüştürür. SolarWinds ve Codecov vakaları, tedarik zincirine sızmanın tek bir uygulamayı değil, o pipeline'ı kullanan yüzlerce müşteriyi aynı anda etkileyebileceğini göstermiştir.

Saldırı Yüzeyi Nasıl Genişler

Bir pipeline'ın saldırı yüzeyi üç ana bileşenden oluşur: kod deposu (pull request üzerinden kötü niyetli değişiklik önerisi), pipeline tanım dosyaları (YAML içindeki komutların manipülasyonu) ve bağımlılık zinciri (paket deposuna sızan kötü niyetli sürümler). Özellikle "pull_request_target" gibi tetikleyicilerin yanlış kullanımı, dış katkıcıların gizli sırlara erişecek şekilde kod çalıştırmasına izin verebilir.

Secret Sızıntısını Önlemek

En yaygın hata, sırları düz metin olarak ortam değişkenlerine gömmek veya log çıktısında maskelemeden bırakmaktır. GitHub Actions üzerinde doğru yaklaşım şudur:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # OIDC ile bulut kimlik doğrulama, statik anahtar yok
    steps:
      - uses: actions/checkout@v4
      - name: Bulut kimlik doğrulama (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-deploy-role
          aws-region: eu-central-1
      - name: Dağıtım
        run: ./deploy.sh
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}

Burada iki kritik ilke uygulanmıştır: birincisi, statik erişim anahtarları yerine OpenID Connect (OIDC) ile kısa ömürlü, göreve özel kimlik bilgisi üretilmesi; ikincisi, iş akışına yalnızca ihtiyaç duyduğu izinlerin (permissions bloğu) tanımlanmasıdır. secrets.API_TOKEN gibi değerler CI motoru tarafından otomatik olarak log çıktısında maskelenir, ancak geliştiricinin bu değeri echo ile bilinçli şekilde yazdırması bu korumayı by-pass edebilir; bu yüzden log'lara asla ham secret basılmamalıdır.

En Az Ayrıcalık ve İzolasyon

Her pipeline adımının yalnızca ihtiyaç duyduğu kaynaklara erişmesi gerekir. Üretim dağıtım yetkisine sahip bir job ile test çalıştıran bir job aynı ortam değişkenlerini paylaşmamalıdır. Runner'lar mümkünse tek kullanımlık (ephemeral) olmalı, iş bitince tamamen imha edilmelidir; kalıcı self-hosted runner'lar bir kez ele geçirildiğinde art arda gelen tüm işlerde arka kapı olarak kullanılabilir.

Tedarik Zincirini Doğrulamak

Bağımlılıkların sürüm numaralarını sabitlemek (pinning), üçüncü taraf Actions/eklentileri commit hash'i ile referanslamak (uses: actions/checkout@8f4b7f8... gibi, sadece @v4 değil) ve artefaktları Sigstore gibi araçlarla imzalamak, tedarik zinciri saldırılarına karşı temel savunma katmanlarıdır. SLSA (Supply-chain Levels for Software Artifacts) çerçevesi, derleme süreci bütünlüğünü kanıtlamak için giderek daha fazla kurum tarafından benimsenmektedir.

Bir pipeline'ın güvenliği, en gevşek yetkilendirilmiş adımı kadar güçlüdür.

Sonuç olarak CI/CD güvenliği; secret yönetimi, en az ayrıcalık, ephemeral çalışma ortamları ve artefakt bütünlüğünün doğrulanması olmak üzere dört sütun üzerinde yükselir. Bu sütunlardan biri eksik olduğunda, pipeline saldırganlar için üretim ortamına giden en kısa yol haline gelir. Konuyla ilişkili parola güvenliği pratikleri için Yazılım Geliştirme kategorisindeki diğer yazılara da göz atabilirsiniz.