GitHub Actions Workflow Lockfile: actions.lock ile Action Bağımlılıklarını Commit'e Kilitleme ve Tedarik Zinciri Güvenliği

Hangi sorunu çözüyor? (The problem)

Bir iş akışında uses: octo-org/deploy-action@v3 yazdığınızda, v3 sabit bir sürüm değil, taşınabilir bir etikettir. Action'ın sahibi (ya da hesabını ele geçiren biri) etiketi yeni bir commit'e taşırsa, bir sonraki çalıştırmada sizin hattınız farklı kodu çalıştırır. Son yıllardaki birçok tedarik zinciri saldırısı tam olarak bu yolla, yaygın kullanılan action'ların etiketleri kötü amaçlı commit'lere yönlendirilerek yapıldı. Bu saldırılarda CI ortamındaki gizli anahtarlar (secrets) dışarı sızdırıldı.

Bugüne kadarki önlem, her uses satırına 40 karakterlik commit SHA'sı yazmaktı. Bu yöntem işe yarıyor, ama okunması ve güncellenmesi zor. Ayrıca action'ın kendi içinde çağırdığı başka action'ları (dolaylı bağımlılıklar) kilitlemiyor. Kilit dosyası bu iki sorunu birlikte çözüyor. GitHub belgelerine göre kilit dosyası kullanan depolarda iş akışlarına SHA yazmak artık gerekmiyor.

Kilit dosyasının biçimi (Lockfile format)

Dosya makine tarafından üretiliyor ve elle düzenlenmemesi gerekiyor. GitHub belgelerindeki örnek şöyle:

# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
version: 'v0.0.2'
workflows:
    '.github/workflows/ci.yml':
        - 'octo-org/deploy-action@v3.1.0'
dependencies:
    'octo-org/deploy-action@v3.1.0':
        ref: 'v3.1.0'
        commit: 'sha1-...'
        owner_id: 44036562
        repo_id: 197814629

• workflows: kilide alınmış her iş akışının kullandığı bağımlılıklar.
• ref: iş akışında yazan etiket veya dal.
• commit: gerçekte çalışacak commit.
• owner_id ve repo_id: kaynak deponun sayısal kimlikleri. Actions bunları çalışma anında kontrol ediyor. Böylece bir depo silinip aynı adla başkası tarafından yeniden açılsa bile (repo-jacking) farklı kod çalışmıyor.

Kurulum ve ilk kilit (Getting started)

1. GitHub CLI eklentisini kurun: gh extension install github/gh-actions-lock
2. Depo kökünde gh actions-lock çalıştırın. Eklenti iş akışlarını tarayıp .github/workflows/actions.lock dosyasını üretir.
3. Kilitlemeden önce bağımlılıkları inceleyin. GitHub'ın uyarısı açık: kilitlemek, bağımlılığın güvenli olduğunu göstermez. Yalnız şu anki hâlini dondurur.
4. Kilit dosyasını ve iş akışı değişikliklerini birlikte commit'leyin.
5. CI'a eklentinin dosyaya dokunmadan "kilit güncel mi" denetimini ekleyin. Böylece iş akışını değiştirip kilidi güncellemeyi unutan pull request'ler yakalanır.

Geçiş iş akışı bazında yapılıyor, yani hepsini birden taşımak zorunda değilsiniz. Bir iş akışı kilide alındıktan sonra kullandığı her action'ın kilit dosyasında kaydı olmalı.

Dependabot ve zorunlu tutma (Dependabot and policy)

Kilide alınmış iş akışlarında Dependabot bir action için sürüm güncellemesi açtığında, kilit dosyasındaki ilgili kaydı aynı pull request içinde yeniliyor. Ek yapılandırma gerekmiyor. Böylece "SHA sabitledik, ama artık kimse güncellemiyor" sorunu da çözülüyor.

Kuruluş, organizasyon ya da depo yöneticileri, yine önizlemedeki Require lockfile kuralıyla o kapsamdaki iş akışlarının kilit dosyası kullanmasını zorunlu tutabiliyor. İzin verilen action'lar politikası (allowed actions) da artık kilitli commit üzerinden denetleniyor.

Sınırlar ve dikkat edilecekler (Limitations)

• Önizleme: Dosya biçimi (version: 'v0.0.2') ve komutlar değişebilir.
• Planlar: GitHub Free, Team, Enterprise Cloud ve veri yerleşimli Enterprise Cloud'da kullanılabiliyor.
• Güvenlik kararı sizde: Kilit, kötü bir sürümü kilitlemeyi engellemez. Yeni action eklerken kaynağı ve izinleri yine incelemek gerekiyor.
• Diğer önlemlerle birlikte: İş akışlarında permissions: ile en az yetki vermek, gizli anahtarları ortam (environment) korumasıyla sınırlamak ve fork'tan gelen pull request'lerde gizli anahtar kullanmamak hâlâ temel kurallar.

Aynı hafta GitHub, kod taramasına PHP, Bash, Terraform ve Dockerfile dosyalarını da kapsayan AI Scan özelliğini genel kullanıma açtı. İki özellik birlikte CI hattının hem kendi kodunu hem de çalıştırdığı üçüncü taraf kodu daha görünür kılıyor. Alesta WEB'de dağıtım betiklerimizde dış kaynaklı her bileşeni sabit sürümde tutuyoruz. Kilit dosyası, bu disiplinin Actions tarafındaki karşılığı.

Sık sorulan sorular

İş akışlarımdaki SHA'ları kaldırmalı mıyım?

Kilit dosyasına geçen depolarda GitHub, SHA yazmayı gereksiz sayıyor. Okunabilirlik için @v3 gibi etiketlere dönebilirsiniz. Ama özellik önizlemede olduğu için kritik depolarda acele etmemek daha doğru olur.

Kilit dosyası Docker tabanlı action'ların imajını da kilitliyor mu?

Belgeler action'ları, dolaylı bağımlılıklarını ve yeniden kullanılabilir iş akışlarını sayıyor. Docker imaj özetleri (digest) için ayrı bir bilgi yok. Bu tür action'larda imajı özetle sabitlemeye devam edin.

Kilit dosyasında olmayan bir action eklersem ne olur?

Kilide alınmış iş akışında her bağımlılığın dosyada bulunması gerekiyor. Yeni action ekledikten sonra gh actions-lock ile dosyayı yeniden üretin.

Ücretsiz hesapta kullanabilir miyim?

Evet, Free planında da önizlemede.

İlgili yazılar: Git 2.56 · Copilot CLI yerel modeller · Next.js güvenlik güncellemesi · Web yazılım hizmetleri · İletişim

Kapak fotoğrafı: Rubaitul Azad / Unsplash