- GitHub Actions, iş akışı dosyalarındaki
uses: sözdizimiyle paket bağımlılıklarını bildirip çalıştıran bir yapıya sahiptir ve bu yapı ile fiilen bir paket yöneticisi işlevi görür
- Ancak lockfile, bütünlük karması, transitif bağımlılık sabitleme, bağımlılık ağacı görünürlüğü gibi diğer paket yöneticilerinin varsayılan olarak sunduğu özellikler burada tamamen yoktur
- Araştırmalar, çoğu GitHub Actions kullanıcısının doğrulanmamış dış kod çalıştırdığını ve kod enjeksiyonu zafiyetlerinin binlerce iş akışında bulunduğunu gösteriyor
- GitHub bazı azaltıcı önlemler (değişmez sürümler, SHA sabitleme politikası vb.) getirmiş olsa da, transitif bağımlılık ve yeniden üretilebilirlik sorunları hâlâ giderilememiştir
- Bu yapısal kusur yazılım tedarik zinciri güvenliğinin tamamını etkiler ve GitHub Actions tabanlı diğer CI sistemlerine de aynı problemi yayar
GitHub Actions'ın Paket Yönetim Yapısı ve Sorunları
uses: actions/checkout@v4 gibi bir sözdizimi bir bağımlılık bildirimidir; GitHub bunu yorumlayıp indirir ve çalıştırır
- Bu, standart bir paket yönetimi davranışıyla aynı olsa da, lockfile bulunmadığından her çalıştırmada farklı bir sürüm seçilebilir
- Diğer paket yöneticileriyle (npm, Cargo, NuGet vb.) karşılaştırıldığında, Actions, lockfile, transitive pinning, bütünlük doğrulaması, bağımlılık ağacı görünürlüğü, çözümleme spesifikasyonu gibi tüm bunları eksik bırakır
- Lockfile eksikliği temel problemdir; bu yüzden çalıştırma başına bağımlılık çözümleme farklılaşır ve deterministik olmayan derlemeler oluşabilir
Güvenlik Araştırmaları ve Zafiyetler
- USENIX Security 2022 çalışmasına göre, repozisyonların %99.7'si harici geliştiricilerin Actions'larını çalıştırıyor, %97'si doğrulanmamış üreticilerden, %18'i güvenlik güncellemelerini kaçırmış durumda
- Ardışık araştırmalarda, 2.7 milyon iş akışından 4,300'den fazlasında kod enjeksiyonu zafiyeti bulunduğu tespit edildi
- GitHub Actions, CI/CD için gerekli olan admittance control, execution control, code control, secrets erişim kontrolü gibi güvenlik özelliklerini yeterince sağlamıyor
Temel Teknik Kusurlar
- Değişken sürüm sorunu:
@v4 gibi etiketler, yöneticinin yeni bir commit ile yeniden etiketlenebildiğinden kod sessizce değişebilir
- Lockfile olsaydı, bu etiketin hangi SHA ile çözümlendiği kaydedilebilirdi
- Transitif bağımlılık şeffaflığının olmaması: Composite Action içinde çağrılan başka Action'lar görünmez ve kontrol edilemez
- Araştırmalar, JavaScript Actions'ların %54'ünün güvenlik açığı içerdiğini ve bunun çoğunun dolaylı bağımlılıklardan kaynaklandığını gösteriyor
tj-actions/changed-files olayında, transitif bağımlılık güncellemesiyle bir gizli anahtar sızıntısı saldırısı gerçekleştirildi
- Bütünlük doğrulaması eksikliği: npm veya Cargo, hash'leri kaydederek indirme doğrulaması yaparken, Actions yalnızca SHA temelli güvene dayanıyor
- Tekrar çalıştırmada yeniden üretilemezlik: GitHub'un “versiyon zorla gönderildiğinde en güncel sürümü alırız” beyanına göre, aynı iş akışı farklı bir kod çalıştırabilir
- Bağımlılık ağacı görünmezliği: npm'nin
npm ls'i veya Cargo'nun cargo tree'si gibi bir özellik olmadan, tüm bağımlılık yapısını görmenin bir yolu yok
- Çözümleme kurallarının kapalı olması: Actions'ta bağımlılık çözümleme kuralı dokümante edilmemiştir;
ActionManager.cs kodunda yalnızca basit özyinelemeli indirme mantığı bulunur
Ek Yapısal Sınırlamalar
- Merkezi kayıt defteri yokluğu: Actions, Git deposunda bulunur ve güvenlik taraması, kötü amaçlı yazılım algılama, typosquatting engelleme işlevleri içermez
- Paylaşılan ortam sorunu: Birçok Action aynı
$PATH'i değiştirir ve çalıştırma sırasına göre sonuçlar farklılaşır
- Çevrimdışı çalıştırılamama: Her seferinde GitHub'dan indirme yapmak gerekir; bu yüzden ağ olmadan çalıştırılamaz
- Ad alanı zayıflığı: GitHub kullanıcı adı doğrudan ad alanı olduğundan, hesap ele geçirilmesi veya yazım hatası saldırılarına açıktır
- Lockfile ve bütünlük hash'leri olsaydı, kod değişirse derleme hatasıyla bu durum algılanabilirdi
Tasarım Arka Planı ve Etkileri
- Actions runner'ları aslında Azure DevOps tabanlı olarak geliştirildi ve başlangıçta kapalı güven ortamı varsayıldı
- GitHub bunu genel bir pazar yeri olarak açarken güven modeli yeniden tasarlanmadı
- Sonuç olarak lockfile, bütünlük doğrulaması, transitif pinning, bağımlılık görünürlüğü gibi temel yetkinlikler atlandı
- OIDC tabanlı otomatik paket dağıtımı yaygınlaştıkça, Actions'ın güvenlik açıkları paket kayıt defterinin genel tedarik zinciri güvenliğine etki ediyor
- GitLab CI, hash doğrulamasını desteklemek için
integrity anahtarını ekledi ancak GitHub aynı talebi “plan yok” diyerek kapattı
- Forgejo Actions gibi GitHub uyumlu CI sistemleri de aynı yapıyı benimsediklerinden, bu kusurlar ekosisteme yayılıyor
İyileştirme Önerileri ve Güncel Durum
- Topluluk lockfile desteğini (issue #2195) talep etti, ancak GitHub bunu 2022'de “planlanmıyor” diyerek kapattı
- Palo Alto çalışmaları, yalnızca SHA pinlemenin transitif bağımlılıkları korumada yetersiz olduğunu kanıtladı
- Bazı ekipler Dependabot güncellemeleri, kendi depo vendor'lama süreçleri, zizmor güvenlik tarayıcısı gibi yöntemlerle açıkları kapatmaya çalışıyor
- Temel çözüm, tüm Action'lar ve transitif bağımlılıkların SHA ile birlikte bütünlük hashlerini kaydeden lockfile getirmektir
- GitHub bunu benimsemediği sürece, CI/CD tedarik zinciri güvenilirliği sağlanamaz
Henüz yorum yok.