GitHub Actions, supply-chain güvenliği için SHA-pinning'in yerini alan workflow lockfile desteği ekledi

GitHub Actions'a lockfile desteği geldi

GitHub Actions artık workflow lockfile'larını destekliyor; bu değişiklik, Kasım 2026'da hugovk.dev üzerinde yayımlanan bir blog yazısında adım adım anlatıldı. Şimdiye dek oynanmış action'lara karşı standart savunma, her birini doğrudan workflow dosyası içinde tam commit SHA'sı ile referanslamaktı. Action'lar Git repository'lerinden çekildiği için tag'ler değiştirilebilir: upstream repository'ye yazma erişimi olan biri, kullanıcıların zaten güvendiği bir tag'ı yeniden hedefleyebilir ve sessizce kötücüll koda yönlendirebilir. SHA pinning bunu önledi, ama okunabilirlik pahasına.

Lockfile yaklaşımı ise workflow içinde insan tarafından okunabilir sürüm tag'ını korur ve çözülmesi gereken kesin commit'i ayrı, makine tarafından üretilen bir dosyaya kaydeder.

Nasıl çalışıyor

Mekanizma bir gh CLI uzantısı tarafından yönetiliyor. github/gh-actions-lock kurup bir repository içinde gh actions-lock komutunu çalıştırmak, workflow'ları doğruluyor, her uses: satırını ham commit hash'inden actions/[email protected] gibi bir tag'a geri dönüştürüyor ve .github/workflows/actions.lock dosyasını üretiyor.

Lockfile, her bağımlılığın ref'ini ve commit SHA'sını, ayrıca sahibi olan hesap ve repository'nin sayısal tanımlayıcılarını kaydediyor. Dosyanın başlığı, makine tarafından üretildiğini net biçimde belirtiyor: elle değiştirmeyin, güncellemek için aracı yeniden çalıştırın.

Lockfile'ı güncel tutmak

Düzenin zamanla ayakta kalabilmesi için iki şeyin olması gerekiyor: lockfile'ın bağımlılık güncellemelerini takip etmesi ve CI içinde bir şeyin onu denetlemesi.

hugovk.dev yazısına göre hem Renovate hem de Dependabot yeni formatı zaten destekliyor; dolayısıyla planlanmış bağımlılık güncellemeleri lockfile'ı workflow referanslarıyla birlikte güncelleyecek. Yazar, bu güncellemelerin temposunu ayarlamak için cooldown kullanılmasını öneriyor.

GitHub ayrıca lockfile'ların workflow'larla senkron kalıp bozulmadıklarını doğrulamak için CI'da denetlenmesini öneriyor ve repository'lerin kopyalayabileceği bir verify-lockfile.yml workflow'u yayımlıyor. Yazının yazarı ise bu denetimi, paralel çalışan bağımsız bir job olarak mevcut bir lint workflow'una katmış; uzantıyı — kendisi v0.4.1'e sabitlenmiş olarak — kurup gh actions-lock --verify komutunu çalıştırıyor ve işi daha hafif olan ubuntu-slim runner'a bırakıyor.

Yazarın dikkate sunduğu operasyonel bir pürüz de var: bir workflow'u düzenledikten sonra — doğrulama job'ının kendisini eklerken de — gh actions-lock'u yeniden çalıştırmanız gerekiyor ki yeni referans verilen action'lar kapsansın. Unutursanız CI bu eksiği işaretler.

Araçlar da yetişiyor

Yazıda ayrıca yazarın şiddetle önerdiği, GitHub Actions için bir güvenlik linter'ı olan zizmor vurgulanıyor. v1.32.0 öncesi sürümler kullanıcılara action'larını hash ile sabitlemelerini söylüyordu; v1.32.0 lockfile'ları anlayan ilk sürüm ve bu öğüdü geçersiz kılıyor.

Python ekosisteminde benimsenme süreci de başladı bile; python/cpython, python-pillow/Pillow, python/release-tools ve python/miss-islington için lockfile dönüşümleri önerildi.

Neden önemli

SHA pinning işe yarıyordu, ama gerçek bir bedelle: 40 karakterlik hash'lerle dolu bir workflow, hangi action sürümünü çalıştırdığınız konusunda size hiçbir şey söylemiyor ve diff'ler, gözden geçiricilerin alışkanlıkla gözden kaçırdığı bir gürültüye dönüşüyor. Lockfile'lar bu kaygıları ayırıyor — insanlar tag'ları okur, makineler commit'leri doğrular — tıpkı package-lock dosyalarının npm tarzı paket yöneticilerinde semantik sürümleri bütünlükten ayırması gibi.

Her commit'in yanında sahibi olan hesap ve repository tanımlayıcılarının kaydedilmesi, doğrulamaya çıplak bir dizginin ötesinde denetlenecek daha güçlü bir şey veriyor; bu da takas edilmiş bir upstream repository'nin sızdırılmasını zorlaştırıyor. Renovate, Dependabot ve zizmor formatı zaten desteklediğine göre, elle bakılan hash'lerden uzaklaşma yolu kısa ve CI doğrulaması çemberi tamamlıyor.