GitHub Actions Güvenliği: Üretime Dağıtım Yapan CI Pipeline'larını Güçlendirmek

CI pipeline'ları secret'ları, cloud kimlik bilgilerini ve dağıtım yetkilerini tek bir yerde toplar. Ele geçirilen bir workflow; kod yayınlayabilir, token sızdırabilir veya doğrudan üretime dağıtım yapabilir. GitHub mekanikleri GitHub Actions güvenliği dokümantasyonunda anlatır, OWASP CI/CD Top 10 kategorileri neyin öncelikli olduğunu listeler. Aşağıdaki kontrol listesi ikisini de uygulanabilir hale getirir.

1. Action'ları Etiket veya SHA ile Sabitleyin

Üçüncü taraf action'ları dal veya yüzen minor sürümle değil, tam sürüm etiketi veya commit SHA ile referanslayın. Dal referansı zararsız görünür; dal saldırgana ait koda hareket edene kadar. Sabitleme (pinning), bir ekibin ekleyebileceği en kolay tedarik zinciri kontrolüdür.

2. GITHUB_TOKEN'ı Varsayılan Olarak Kısıtlayın

Workflow başına permissions: ayarı koyun ve bir job'ın gerçekten ihtiyaçtan fazlasına ihtiyacı yoksa contents: read seviyesine düşürün. Bir container build edip görsel gönderen bir workflow'un sessizce contents: write + packages: write + id-token: write tutmaması gerekir — her izin, tek bir workflow çalışmasından miras alınan bir capability'dir.

3. Saklanan Cloud Anahtarları Yerine OIDC Tercih Edin

CI'da uzun ömürlü AWS/GCP/Azure kimlik bilgilerini OpenID Connect federasyonu ile değiştirin: workflow, OIDC kimliğini kısa ömürlü cloud token'larıyla takas eder. Böylece pipeline'ın taç mücevheri bir statik AWS_ACCESS_KEY_ID olmaz ve ele geçirilen bir log dosyasına asla girmez.

4. Secret'ları Log'lardan Uzak Tutun — Güvenilmez Tetikleyicileri Reddedin

• Secret'ların debug modda echo, --verbose CLI bayrakları veya job summary'lerinden geçirilmesi, toplu log arşivlerinde sızıntı yapar. Workflow şablonlarında güvensiz interpolasyonları denetleyin.
• Kök uyarı: PR'daki kodun checkout edildiği pull_request_target tetikleyicisiyle workflow ASLA çalıştırmayın. Bu tetikleyici, güvenilmez kodu yazma yeteneği olan token'larla birleştirir — pipeline zehirlemenin klasik yolu budur.

Dört Geçişte Yayınlayın

Deploy pipeline'larıyla başlayın: riskin çoğu, yüksek değerli workflow'larda OIDC, varsayılan reddet izinleri ve sabitlenmiş action'larla kapanır. Ardından kalan şablonları aynı kurallarla süpürün. Üçüncü geçişte pull_request_target checkout'larını kaldırın ve bir action referansı hareket ettiğinde pull request'i düşüren bir CI kontrolü ekleyin. Son olarak runner izolasyonunu yol haritasına alın: self-hosted runner'lar tek işlik, geçici makineler olmalı ki ele geçirilen bir job, bir sonraki çalışmaya kalıntı bırakamasın.

Sık Yapılan Hatalar

En yaygın üç hata aynı kalıpta çıkar. Birincisi, actions/checkout veya popüler bir community action'ı master/main dalından çekmek; dal kurcalanıp saldırgan koduna döndüğünde pipeline anında ele geçirilir. İkincisi, permissions bloğunu job seviyesine yazmayı unutmak; böylece her job workflow'un bütün izinlerini taşır. Üçüncüsü, secret'ı env değişkeni olarak plaintext şekilde yazdırmak yerine Secrets mağazasına koymak. Üç hata da erken yakalanır; pahalı olan sonradan yakalamaktır. Yeni ekiplerin çoğu ilk incelemede bu üçünü düzeltir; ancak saldırı yüzeyi genişledikçe aynı kalıp yeni bir şablonda tekrar sürpriz yapar.

Bir İnceleme Nasıl Görünür

Bir Actions incelemesi workflow ağacını dal dal dolaşır: tetikleyici yüzeyi, token kapsamı, action pinning, OIDC benimsenmesi, secret akışları ve self-hosted runner izolasyonu. Üretim altyapısını dağıtabilen veya değiştirebilen her workflow en katı incelemeye tabi olur — çünkü çalınmaya değer token'lar oradadır.

Kaynaklar

• GitHub Actions güvenlik dokümantasyonu
• GitHub Actions OIDC güvenilir yayın rehberi
• OWASP CI/CD Top 10