- 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@v4gibi 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:
@v4gibi 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-filesolayı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'nuncargo 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.cskodunda 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
integrityanahtarı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
2 yorum
Muhtemelen ancak başlarına gelince akıllanırlar.
Hacker News yorumu
GHA'yı (GitHub Actions) savunmak istemem ama belgelerde, kararlılık ve güvenlik için commit SHA sabitleme önerildiği açıkça yazıyor
Bunu doğrudan bir lock dosyası gibi uygulayabilirsiniz, ancak transitive dependency'leri kontrol etmek mümkün olmadığından tam bir çözüm değil
Sonuçta güvenlik yamalarını takip etme ve hash güncelleme yükü ortaya çıkıyor; muhtemelen bu yüzden hash tabanlı sabitleme yaygın kullanılmıyor
Çoğu kullanıcı sorunun farkında değil, farkında olanlar da neredeyse hiç SHA kullanmıyor
Ben şahsen Actions'ı seviyorum ve birkaç tanesinin bakımını yapıyorum ama herkese açık depolara baktığınızda %90'ı
@v1, %9'u@v1.2, yalnızca %1'i commit SHA kullanıyorGitHub biraz yatırım yapsa lock dosyası çözümü oluşturabilirdi
Sıklıkla belirli bir Node sürümüne veya API sürümüne bağımlı oluyor; bu yüzden bazen @main kullanmanın daha iyi olduğu deneyimlerim oldu
İnsanlar “sabitlenmiş sürüm” elde ettiklerini sanıyor ama gerçekte öyle değil
Bunu iki kez sorun yaşadıktan sonra anladım — ya lock dosyası vardır ya da yoktur
GitHub kendi Actions'larının bakımını neredeyse hiç yapmıyor ve en temel işlevler bile resmi olmayan fork'lara dayanır hale geliyor
Tüm ekosistem geçici çözümlerle ayakta tutuluyormuş gibi hissettiriyor
Çünkü GitHub, özellik geliştirmeden çok Azure migrasyonuna öncelik vereceğini açıkladı
ilgili haber
Bizim küçük şirketimiz bile ayda 200 dolardan fazla ödüyor
Windows'tan daha önemli bir yeni gelir kaynağı olarak görüldüğü hissi var
Muhtemelen asıl yazarlar çoktan şirketten ayrıldı
ArgoCD'yi CI hattı olarak kullanan var mı, merak ediyorum
Bence GHA, 'less is more' felsefesinin başarısız bir örneği
Sektör standardı haline gelmiş olması en büyük sorun
Azıcık yatırımla çok daha iyi bir CI yapılabilirdi; MS sanki IE6 dönemindeki hatayı tekrar etmiş gibi
Artık kıyaslama deneyimi olmayan genç mühendis kuşakları onun sınırlarını fark etmiyor
Emekliye ayırdığım bir dizüstü bilgisayarı Woodpecker sunucusu olarak çalıştırmayı düşünüyorum. İnsanların nefret etmediği bir CI nasıl oluyor görmek istiyorum
GHA'nın buna kıyasla pek bir değer sunduğunu düşünmüyorum
Şirket Jenkins/Ansible'dan GHA'ya geçmek istediğinde buna karşı çıkmıştım; şimdi bakınca doğru karar vermişim gibi görünüyor
CI her zaman yüksek bakım yükü getirir ve özellikle Mac ortamı hâlâ uğraştırıcıdır
“GitHub'ın doğru SHA kodunu verdiğine inanıyor musun?” sorusuna gelince,
çoğu kişinin GitHub-hosted runner kullandığı düşünülürse buna güvenmiyorsanız zaten daha büyük bir sorununuz var demektir
GitHub Actions local-first bir yapıda olup Nix tabanlı kilitleme (locking) destekleseydi nasıl olurdu diye düşünmeden edemiyorum
cachix/cloud.devenv.sh
Birçok üçüncü taraf Action, belgelerde veya örneklerde doğrudan master branch'i referans gösteriyor
Tek bir kötü niyetli push ile sayısız depoda veri sızıntısı yaşanabilir
Tag kullanmak da tam koruma sağlamıyor çünkü onlar da taşınabiliyor
Araştırmacıların CI/CD için söylediği dört temel güvenlik özelliğine (kimlik doğrulama, yürütme, kod, gizli bilgilere erişim) bakınca aklıma şu geliyor
CI/CD'nin gerçekten gizli bilgilere (secrets) erişmesi gerekiyor mu?
Bence yalnızca API çağrısı yetkisi yeterli olmalı
İdeal bir sistem, gizli bilgileri doğrudan işlememeli; bunun yerine güvenli enclave benzeri bir adaptör üzerinden dolaylı şekilde çalışmalı
Gerçekte müşterilerin çoğu hâlâ gizli bilgilere ihtiyaç duyuyor
Platformun en azından güvenli bir gizli bilgi yönetim mekanizması sunması gerekiyor
Özellikle açık kaynak projeleri, CI üzerinden doğrudan deploy yapmak istiyor
“Güvenli enclave yaklaşımı”nın somut olarak nasıl farklı olduğunu merak ediyorum
ama pratikte ortamlar farklı ve uygulama maliyeti yüksek olduğu için çoğu yerde container + environment variable yaklaşımında karar kılındı
Bu tür testleri otomatikleştirmek istiyorsanız gizli bilgiler kaçınılmaz
Eğer lock dosyası depoya commit edilecekse, ilk oluşturma aşamasında bir bootstrapping sorunu ortaya çıkar
Bunu çözmek için Actions'ı yerelde çalıştırabilme özelliği gerekir
nektos/act gibi araçlar var ama bunlar daha çok debug amaçlı
Muhtemelen statik analiz tabanlı ayrı bir mekanizma gerekecek