---
title: "GitHub Actions'ta lockfile desteği GA oldu: tag yerine kilitli commit"
description: "GitHub Actions lockfile desteği GA oldu. Runner tag yerine kilitli commit'i çalıştırıyor. Geçiş sırası, Dependabot riski ve 2 Aralık notu."
image: "https://sezer.in/wp-content/uploads/2026/11/generatedHeaderImage-1793888107988.jpg"
url: "https://sezer.in/haberler/github-actions-lockfile-ga/"
date: "2026-11-08T17:16:10+03:00"
updated: "2026-11-08T17:16:10+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/github-actions-lockfile-ga/"
---

# GitHub Actions'ta lockfile desteği GA oldu: tag yerine kilitli commit

GitHub, GitHub Actions lockfile desteğini 28 Ekim 2026'da, public preview'a girdikten iki hafta sonra genel kullanıma açtı. Workflow'daki tag veya branch referansı sonradan değişse bile runner, .github/workflows/actions.lock dosyasında kayıtlı commit'i çalıştırıyor. Özellik GitHub Enterprise Cloud, data residency'li Enterprise Cloud, Team ve Free planlarında kullanılabiliyor.

## GitHub Actions nedir, ne için kullanılır?

GitHub Actions, GitHub'ın repo'lara gömülü CI/CD ve otomasyon platformudur. Workflow'lar YAML dosyalarıyla tanımlanır ve push, pull request veya zamanlanmış tetikleyicilerle runner'larda çalışır. Build, test, deployment ve repo otomasyonu için kullanılır; başkalarının yazdığı action'lar workflow'a bağımlılık olarak eklenir. Bilinen alternatifleri GitLab CI/CD, CircleCI ve Azure Pipelines'tır.

## Tag yerinde dursa da commit değişebilir

`actions/checkout@v4` yazdığınızda bir commit'e güvenmiyorsunuz, taşınabilir bir etikete güveniyorsunuz. Action'ın sahibi ele geçirilirse tag başka bir commit'e çekilebilir. Sizin repo'nuzda tek satır değişmez, pipeline yine de yeni kodu çalıştırır.

Şimdiye kadarki çare tam SHA ile pin'lemekti. Bu yöntem iki sorun çıkarıyordu: workflow dosyası okunmaz hale geliyor, composite action'ların içinden çağrılan action'lar da pin'siz kalıyordu. GitHub Actions lockfile bu iki işi ayırıyor. Workflow'da `@v4` okunur kalıyor, runner ise `actions.lock` içindeki commit'i çalıştırıyor. Transitive bağımlılıklar da aynı dosyaya yazılıyor.

Npm'deki `package-lock.json` dosyasının workflow'lar için karşılığı gibi düşünebilirsiniz.

## GitHub Actions lockfile ile ilk workflow'lar

Geçişi her workflow için ayrı yapıyorsunuz, organizasyonun tamamı tek seferde geçmiyor. Bir workflow'u onboard ettiğinizde içindeki her bağımlılığın lockfile kaydı olması gerekiyor. Lockfile'ı GitHub CLI için yazılmış `gh actions-lock` extension'ı üretiyor ve güncel tutuyor.

Şu sırayla ilerleyin:

- Önce release ve deployment workflow'larını geçirin. Secret ve yazma yetkisi taşıyan iş akışları saldırganın asıl hedefi.
- Extension'ın verification modunu CI'a ekleyin. Bu mod hiçbir dosyayı değiştirmeden lockfile'ın workflow dosyalarıyla uyumlu olup olmadığına bakıyor; uyumsuzluk varsa adım başarısız oluyor.
- Dependabot'un birleşik pull request'lerinin mevcut inceleme düzeninize oturduğunu birkaç hafta gözleyin.
- "Require lockfile" politikasını en sona bırakın. Enterprise, organization veya repo düzeyinde açılabiliyor; repo düzeyinde başlayıp yukarı çıkmak daha az sürpriz çıkarır.

Desteklenen planlar arasında GitHub Enterprise Server geçmiyor. GHES işletiyorsanız GitHub Docs'taki workflow dependency lockfiles sayfasından durumu doğrulayın.

## Dependabot PR'ı yeni kontrol noktanız

Dependabot bir action için sürüm güncellemesi açtığında lockfile kaydını aynı pull request'te güncelliyor. Ek yapılandırma gerekmiyor. Pin'lemenin klasik derdi olan bayat pin sorunu böylece büyük ölçüde kalkıyor.

GitHub sınırı açıkça çiziyor: lockfile, kilitlediğiniz commit'in çalışacağını garanti ediyor, o commit'in güvenli olduğunu değil. Action güncellemelerini auto-merge ile geçiriyorsanız zararlı bir sürüm doğrudan lockfile'a girer ve orada kilitlenir. Koruma ortadan kalkmaz, ters yöne döner.

Action güncellemelerini auto-merge kurallarınızdan çıkarın. PR'da tag değişikliğine ek olarak lockfile diff'ini de okuyun. Yeni bir transitive kayıt belirmişse o action'ın neden eklendiğini anlamadan merge etmeyin.

## 2 Aralık'ta pull_request_target kapanıyor

GitHub, 2 Kasım tarihli changelog'da `pull_request_target` tetikleyicisinin 2 Aralık'tan itibaren varsayılan olarak engelleneceğini duyurdu. Hedef aynı: güvenilmeyen kodun yetkili workflow bağlamına ulaşmasını kesmek. Lockfile geçişini planlarken bu tarihi de takvime koyun.

Bu tetikleyiciyi hangi workflow'ların kullandığını şimdiden çıkarın:

```
grep -rn "pull_request_target" .github/workflows/
```

Çıkan her dosya için changelog'daki geçiş notlarını okuyun. Bu workflow'lar genelde fork PR'larına yorum yazan veya etiket basan otomasyonlar; 2 Aralık'ta sessizce durabilirler.

## GitLab veya Azure Pipelines'ta

Rakip platformlarda native bir karşılık henüz yok. GitLab, include ve component'leri commit SHA'ya, image'ları digest'e elle pin'lemenizi öneriyor. Microsoft'un Azure Pipelines için Zero Trust rehberi de SHA pinning ve Marketplace extension'larını sınırlamayı öneriyor. CircleCI orb'ları commit hash yerine immutable bir semver registry'ye dayanıyor.

Pinner gibi araçlar tag'i SHA'ya çeviriyor, ActionSieve gibi tarayıcılar pin'siz referansları işaretliyor. İkisi de yalnızca pipeline dosyasında yazan referansı görüyor ve transitive bağımlılığı çözmüyor. Karma bir ortam işletiyorsanız GitHub'da GitHub Actions lockfile kullanın, diğer platformlarda SHA pin ile tarayıcıyı birlikte çalıştırın. Hangi platformda olursanız olun, bir bağımlılığı kilitlemeden önceki inceleme adımı tek gerçek güvenlik kontrolünüz olarak kalıyor.