Yazılım Güvenliği

GitHub Actions cache-mode: Cache Poisoning Riskine Karşı En Az Yetki Rehberi

← Tüm yazılara dön

GitHub Actions cache-mode: Cache Poisoning Riskine Karşı En Az Yetki Rehberi

GitHub Actions cache-mode, iş akışı ve iş düzeyinde önbellek erişimini sınırlandırıyor. Güvenilmeyen olaylarda cache poisoning riskini azaltma adımları.

cache-mode neden eklendi?

GitHub, 10 Eylül 2026 tarihinde Actions önbelleğine erişimi iş akışı veya iş düzeyinde sınırlayan cache-mode ayarını genel kullanıma açtı. Amaç, her iş akışına yalnız ihtiyaç duyduğu okuma veya yazma yetkisini vererek gereksiz önbellek erişimini ve cache poisoning riskini azaltmak.

Derleme önbellekleri hız kazandırırken güvenilir iş akışlarının daha önce düşük güvenli bir bağlam tarafından yazılmış içeriği kullanmasına yol açabilir. Bu nedenle önbellek, yalnız performans bileşeni değil, yazılım tedarik zincirinin güven sınırlarından biri olarak ele alınmalıdır.

Dört erişim modu ne anlama geliyor?

read mevcut önbelleği geri yükler ancak yeni kayıt yapılmasını engeller. write hem geri yükleme hem kaydetme izni verir; write-only yalnız kayıt yapar, none ise önbellek erişimini tamamen kapatır.

İş düzeyindeki ayar, workflow düzeyindeki ayarı geçersiz kılar. Yeniden kullanılabilir iş akışlarında çağrılan akış, çağıranın verdiğinden daha geniş bir önbellek yetkisi alamaz; bu davranış yetki yükselmesini önleyen önemli bir sınırdır.

Güvenilmeyen olaylarda varsayılanlar

GitHub, pull_request_target gibi düşük güvenli olaylar için varsayılan olarak yalnız okuma erişimi uyguluyor. Güvenilir push olaylarında ise varsayılan mod yazmadır.

Düşük güvenli bir olayda açıkça write veya write-only seçilirse GitHub uyarı ekliyor. Bu uyarı göz ardı edilmemeli; dış katkı kodunun güvenilir dalların kullanacağı önbelleği etkileyip etkileyemediği incelenmelidir.

Cache poisoning nasıl oluşabilir?

Saldırgan kontrollü bir iş akışı tahmin edilebilir bir anahtarla önbelleğe zararlı veya değiştirilmiş çıktı yazarsa daha ayrıcalıklı bir akış bu içeriği geri yükleyebilir. Risk; derleme betikleri, paket çıktıları veya çalıştırılabilir dosyalar doğrulama olmadan önbellekten alındığında büyür.

Önbellek anahtarlarını dal, işletim sistemi, bağımlılık kilit dosyası ve güven seviyesiyle ayırmak yararlıdır. Ancak anahtar ayrımı tek başına yetmez; yazma yetkisi gerçekten ihtiyaç duymayan akışlardan kaldırılmalıdır.

Güvenli geçiş adımları

  • Tüm workflow dosyalarında önbellek kullanan işleri belirleyin.
  • Dış katkı veya düşük güvenli olaylarda read ya da none kullanın.
  • Önbellek üreten güvenilir işleri ayrı tutun.
  • Yeniden kullanılabilir workflow zincirlerinde etkin yetkiyi doğrulayın.
  • Yazma yetkisi verilen istisnaları kod incelemesine bağlayın.

Dağıtım sonrası ne izlenmeli?

Ayar değişikliğinden sonra önbellek isabet oranı, derleme süresi ve başarısız geri yüklemeler izlenmelidir. Performans düşüşü görülürse güvenlik sınırını kaldırmak yerine güvenilir bir önbellek üretim işi tasarlanmalıdır.

  1. Pilot depoda modu etkinleştirin.
  2. Pull request ve push akışlarını ayrı test edin.
  3. Uyarı ek açıklamalarını inceleyin.
  4. Kuruluş standardını belgeleyip diğer depolara yayın.

Kaynaklar

OKUMAYA DEVAM EDİN

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