GitHub Actions önbelleğine dört yetki geldi; yanlış “write” zehirlenme riski
GitHub, 10 Eylül 2026’da GitHub Actions önbellek erişimini iş akışı ve görev düzeyinde sınırlayan cache-mode özelliğini genel kullanıma açtı. GitHub’ın yayımladığı duyuru, özelliğin github.com üzerindeki tüm planlara geldiğini ve read, write, write-only ile none olmak üzere dört erişim düzeyi sunduğunu belirtiyor.
Yeni ayarda güvenilmeyen girdilerin etkileyebildiği pull_request_target çalışmaları için güvenli seçim read. Bu tür düşük güvenli bir akışta açıkça write veya write-only tanımlamak, tetikleyiciden gelen salt okuma varsayılanını kaldırıyor ve saldırganın etkileyebildiği içeriğin daha ayrıcalıklı bir çalışma tarafından geri yüklenebilecek önbelleğe yazılması riskini yeniden doğuruyor.
Dört mod okuma ve yazmayı nasıl ayırıyor?
cache-mode iki ayrı işlemi denetliyor: var olan bir önbelleği geri yüklemek ve yeni bir önbellek kaydetmek. GitHub Actions söz dizimi belgesi, erişimin kapsamlandırılmış önbellek belirteçleriyle uygulandığını ve izin verilmeyen işlemlerin görev tarafından gerçekleştirilemediğini açıklıyor.
- read: Var olan önbelleği geri yükleyebilir, yeni kayıt oluşturamaz. Güvenilir bir çalışmanın hazırladığı önbelleği yalnızca tüketmesi gereken görevler için uygundur.
- write: Hem geri yükleme hem kaydetme yetkisi verir. Güvenilir bir tetikleyici altında önbelleği kullanan ve güncelleyen görevlerin ihtiyaç duyduğu en geniş düzeydir.
- write-only: Var olan önbelleği geri yüklemeden yeni bir kayıt oluşturabilir. Eski paylaşılan durumu kullanmadan önbellek üreten ayrılmış görevlerde kullanılabilir.
- none: Geri yükleme ve kaydetme işlemlerinin ikisini de kapatır. Görevi paylaşılan önbellek durumundan tamamen ayırır.
Bir işlemin seçilen mod tarafından engellenmesi, iş akışını otomatik olarak başarısız kılmıyor. Engellenen geri yükleme bir cache miss gibi işleniyor; kaydetme atlanıyor, günlükte bilgilendirme mesajı oluşuyor ve çalışma devam ediyor. Bu nedenle yeşil durum işareti, önbelleğin gerçekten okunduğunu veya yazıldığını tek başına göstermiyor.
cache-mode YAML’da iki kapsamda tanımlanıyor
Bütün görevler aynı güven sınırını paylaşacaksa cache-mode, on ve jobs ile aynı üst düzeyde yer alıyor. pull_request_target ile başlayan ve yalnızca mevcut önbelleği tüketmesi gereken bir akışta temel sıra on: pull_request_target, cache-mode: read ve jobs bölümlerinden oluşabilir. YAML anahtarlarının sırası sonucu değiştirmese de bu yerleşim read politikasını dosyanın tamamı için görünür kılıyor.
Görevlerin ihtiyaçları farklıysa üst düzey değer başlangıç politikası olarak bırakılıp belirli bir görevin altında jobs.<job_id>.cache-mode tanımlanabiliyor. Örneğin üst düzey read politikasına sahip güvenilir bir push akışında, yalnızca temiz önbellek üreten görev write-only; paylaşılan durum kullanmaması gereken doğrulama görevi ise none alabilir.
Buradaki kritik davranış, görev düzeyindeki değerin iş akışı düzeyindeki değeri yalnızca daraltmaması, tamamen geçersiz kılması. Üst düzeyde read bulunan bir dosyadaki tek görev cache-mode: write olarak ayarlanırsa o görev hem geri yükleme hem kaydetme yetkisi kazanıyor. Dolayısıyla üst düzey read, görev istisnaları ayrıca incelenmediğinde kesin bir tavan oluşturmuyor.
pull_request_target üzerinde write riski neden geri getiriyor?
pull_request_target, issue_comment ve belirli workflow_run bağlamları dışarıdan etkilenebilen olaylarla varsayılan dal kapsamında çalışabildiği için GitHub bunlara salt okunur önbellek erişimi uyguluyor. Amaç, düşük güvenli bir çalışmanın daha sonra push veya schedule gibi güvenilir bir çalışma tarafından geri yüklenebilecek önbelleğe içerik kaydetmesini engellemek.
Açık bir write veya write-only değeri bu korumayı bilinçli olarak geçersiz kılıyor. İş akışı saldırganın etkileyebildiği kodu, bağımlılık betiklerini ya da ifadeleri önbellek kaydedilmeden önce çalıştırıyorsa değiştirilmiş dosyalar paylaşılan önbelleğe girebilir. Daha ayrıcalıklı bir çalışma bu kaydı güvenerek geri yüklediğinde saldırgan denetimindeki içerik yürütülebilir.
GitHub Actions, düşük güvenli tetikleyicide yazma yetkisi görüldüğünde bir uyarı açıklaması ekliyor; ancak uyarı yetkiyi engellemiyor. Bağımsız bir teknik değerlendirme olan Haebomgyeol’un erişim karşılaştırması da pull_request ile pull_request_target olaylarının aynı değerlendirilmemesi gerektiğini, ikincisinde açık yazma izninin salt okuma sınırını kaldırdığını vurguluyor.
Salt geri yükleme gereken pull_request_target görevinde açık cache-mode: read kullanılması hem davranışı sınırlar hem de niyeti kod incelemesinde görünür hale getirir. Önbelleği güncelleme görevi ise güvenilir varsayılan dal push’uyla çalışan ayrı bir akışa bırakılabilir. write-only, geri yüklemeyi kapatsa da kaydetmeyi açtığı için güvenilmeyen girdiyi işleyen bir görevde write’a karşı otomatik olarak güvenli bir alternatif değildir.
Yeniden kullanılan iş akışlarında açık sınır belirleyici
cache-mode, çağıran iş akışından yeniden kullanılan iş akışına aktarılıyor. Çağıran görevde açıkça belirlenen veya çağıran iş akışının üst düzeyinden miras alınan değer, çağrılan tanımın isteyebileceği erişim için tavan oluşturuyor. Çağıran taraf read ile sınırlandıysa çağrılan taraf write isteyemiyor; çalışma başlamadan doğrulama hatası oluşuyor.
Örtük varsayılan ile YAML’da açıkça yazılan sınır burada aynı sonucu vermeyebiliyor. Çağıran görev herhangi bir cache-mode tanımlamaz ve yalnızca düşük güvenli tetikleyicinin varsayılan read erişimine dayanırsa, yeniden kullanılan iş akışı açıkça write isteyebiliyor. Yazma yetkisinin aktarılmasını kesin biçimde engellemek için çağıran görevde read değerinin açıkça belirtilmesi gerekiyor.
read ile write-only de birbirinin alt kümesi değil: ilki yalnızca okuma, ikincisi yalnızca yazma sağlıyor. Bu nedenle read sınırındaki çağıranın write-only isteyen bir tanımı veya write-only sınırındaki çağıranın read isteyen bir tanımı çalıştırması erişim artışı sayılıyor ve doğrulamada durduruluyor.
Özellik genel kullanıma açık ve cache-mode eklenmemiş mevcut iş akışları tetikleyiciye dayalı varsayımlarla çalışmayı sürdürüyor: düşük güvenli olaylar read, güvenilir olaylar ise write alıyor. Yeni anahtarın getirdiği asıl değişiklik, bu örtük kararın YAML’da görünür biçimde daraltılabilmesi; aynı esneklik, pull_request_target altında düşünülmeden verilen write istisnasını da güvenlik sınırını kaldıran bir yapılandırmaya dönüştürüyor.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.