Yazılım Güvenliği

GitHub Actions Eylül 2026 Güncellemeleri: Runner ve GITHUB_TOKEN Güvenlik Rehberi

← Tüm yazılara dön

GitHub Actions Eylül 2026 Güncellemeleri: Runner ve GITHUB_TOKEN Güvenlik Rehberi

Runner kullanım ömrü API’si, Dependabot uyarıları için yeni GITHUB_TOKEN izni ve yeniden kullanılabilir iş akışı kimliği nasıl yönetilmeli?

Eylül güncellemesinin üç güvenlik bileşeni

GitHub, 3 Eylül 2026 tarihinde Actions platformu için görünürlük ve yetki denetimini geliştiren üç yenilik duyurdu. Bunlar runner sürümlerinin kullanım ömrünü sorgulayan yeni API, Dependabot uyarılarına özel GITHUB_TOKEN izni ve yeniden kullanılabilir iş akışlarının kaynağını gösteren yeni iş bağlamı alanlarıdır.

Her yenilik farklı bir sorunu çözüyor: eski runner kullanımı, gereğinden geniş belirteç yetkileri ve çağrılan iş akışının gerçek kimliğini ayırt etme güçlüğü. Kuruluşlar bunları ayrı ayarlar olarak değil, CI güven zincirinin birbirini tamamlayan katmanları olarak ele almalıdır.

Runner sürüm eskimesini önceden izleyin

Yeni REST API, belirli bir runner sürümünün kayıt ve çalışma zamanı desteğinin ne zaman sona ereceğini döndürüyor. Depo, kuruluş veya kurumsal düzeyde kullanılabilen uç nokta; sürüm numarasıyla birlikte iki ayrı sona erme zamanını raporluyor.

Kayıt desteğinin bitmesi yeni runner eklemeyi, çalışma zamanı desteğinin bitmesi ise mevcut runner işlerini etkileyebilir. Özellikle sabit makine imajları ve uzun ömürlü şirket içi runner havuzları için bu tarihlerin envanter ve bakım takvimine bağlanması gerekir.

  • Tüm self-hosted runner sürümlerini merkezi olarak listeleyin.
  • Kayıt ve çalışma zamanı bitiş tarihlerini ayrı takip edin.
  • Güncellemeyi önce temsili bir runner grubunda sınayın.
  • Eski temel imajların yeni runner üretmesini engelleyin.

Dependabot erişiminde en az ayrıcalık

GITHUB_TOKEN artık vulnerability-alerts izniyle Dependabot uyarılarına yalnızca okuma erişimi verebiliyor. İzin read veya none değerlerini desteklediğinden iş akışının daha geniş kapsamlar istemesine gerek kalmıyor.

Bir raporlama işinin yalnızca güvenlik uyarılarını okuması gerekiyorsa yazma ya da depo yönetimi yetkileri verilmemelidir. Kuruluş düzeyindeki varsayılan izinler de incelenmeli ve iş akışı dosyasında açık, dar kapsamlı bir izin bölümü kullanılmalıdır.

Yeniden kullanılabilir iş akışının kimliği

Yeni job.workflow_ref, job.workflow_sha, job.workflow_repository ve job.workflow_file_path alanları çalışan işi tanımlayan iş akışının gerçek kaynağını gösteriyor. Bu değerler, çağıran iş akışını temsil eden mevcut github bağlamından yeniden kullanılabilir akışlarda ayrışabilir.

Kaynak depo ve tam commit kimliğinin kayda alınması, olay incelemesinde hangi iş akışı kodunun gerçekten çalıştığını kanıtlamayı kolaylaştırır. GitHub bu alanların GitHub Enterprise Server üzerinde bulunmadığını belirttiği için hibrit ortamlar farklı kayıt yöntemleri planlamalıdır.

  1. Runner sürüm raporunu zamanlanmış envanter işine ekleyin.
  2. GITHUB_TOKEN izinlerini iş başına daraltın.
  3. Yeniden kullanılabilir iş akışı kaynak kimliğini günlükleyin.
  4. Beklenmeyen depo veya SHA değerinde işi durdurun.
  5. Pilot sonuçlarından sonra kuruluş genelinde uygulayın.

Uygulama ve doğrulama planı

Yeni özelliklerin mevcut olması güvenliği otomatik olarak artırmaz. API çıktısının izlenmesi, dar izinlerin uygulanması ve kaynak kimliğinin politika kararlarında kullanılması gerekir.

Kapanış kanıtı; güncel runner oranını, iş akışlarının gerçek izinlerini ve yeniden kullanılabilir akışların beklenen kaynaklardan geldiğini göstermelidir. Yapılandırma değişiklikleri denetim kaydına bağlanmalı ve başarısız işler ayrı takip edilmelidir.

Kaynaklar

OKUMAYA DEVAM EDİN

Yazılım Güvenliği kategorisi →