GitHub Actions bir tetikleyiciyi varsayılan kapatacak; tarih 2 Kasım
GitHub, mevcut bir olay politikası bulunmayan kapsamdaki public depolarda pull_request_target tetikleyicisini varsayılan olarak engelleyecek. 17 Eylül 2026’da genel kullanıma açılan korumaya ilişkin ReleaseBytes özeti, kuralın 2 Kasım 2026’da uygulanacağını; private ve internal depoların bu otomatik değişikliğin dışında kaldığını aktarıyor.
Kural önce Evaluate modunda çalışıyor: workflow çalıştırmalarını henüz durdurmuyor, fakat 2 Kasım’da hangilerinin engelleneceğini Policy insights bölümünde gösteriyor. GitHub’ın yönetim belgesi de public depolardaki varsayılan politikanın 2 Kasım 2026’da uygulanacağını ve Evaluate durumunun yalnızca olası engellemeleri görünür kıldığını doğruluyor.
Koruma hem aktörü hem olayı denetliyor
Workflow execution protections, bir Actions workflow’u başlamadan önce iki koşulu değerlendiriyor: Çalıştırmayı başlatan aktör izinli mi ve tetikleyici olay kabul ediliyor mu? Aktör kuralları kullanıcıları, depo rollerini, belirli ekipleri ve bot kimliklerini; olay kuralları ise push, pull_request, pull_request_target ve workflow_dispatch gibi tetikleyicileri sınırlandırabiliyor.
Bir politikada iki tür kural da varsa ikisinin birlikte karşılanması gerekiyor. İzinli bir ekip üyesi, listede bulunmayan bir olay üzerinden hedeflenen workflow’u başlatamıyor; izin verilen bir olay da aktör listesinin dışındaki kullanıcıya tek başına çalıştırma yetkisi vermiyor.
Politikalar enterprise, organization ve repository düzeylerinde katmanlanabiliyor. Hedef yalnızca depo olmak zorunda değil: Koruma belirli workflow yollarıyla sınırlandırılabildiği için üretim dağıtımı yapan bir dosyaya daha dar kurallar uygulanırken aynı depodaki farklı otomasyonlar ayrı kapsamda tutulabiliyor.
Genel erişim sürümünde üç önemli yenilik var
GitHub’ın 17 Eylül duyurusu, daha önce public preview aşamasında bulunan özelliğin genel kullanıma açıldığını ve sürüme workflow dosyası hedefleme, politika içgörüleri ile REST API yönetiminin eklendiğini belirtiyor. Evaluate modu ise ön izleme sürümünden taşındı.
- Workflow dosyası hedefleme: Bir kural bütün depo yerine belirli workflow yollarına uygulanabiliyor.
- Policy insights: Evaluate durumundaki bir politikanın hangi çalıştırmaları engellemiş olacağı, aktif bir politikanın ise hangi çalıştırmaları durdurduğu görülebiliyor.
- REST API: Politikalar ve workflow yolu koşulları enterprise, organization ve repository düzeylerinde programlı olarak yönetilebiliyor.
Bu üç özellik birlikte değerlendirildiğinde yöneticiler önce kuralın etkisini gözlemleyebiliyor, ardından yalnızca gerçekten gerekli dosyalar için istisna tanımlayabiliyor. Böylece pull_request_target izni bütün depoya yayılmadan tek bir workflow yoluyla sınırlandırılabiliyor.
2 Kasım kuralının kapsamı sınırlı
Yaklaşan değişiklik bütün GitHub depolarını veya bütün Actions tetikleyicilerini kapatmıyor. Varsayılan kural, public olan ve hâlihazırda uygulanabilir bir Actions olay politikası bulunmayan depolarda pull_request_target olayını hedefliyor.
Otomatik uygulama da bu grubun tamamı için aynı geçmişe sahip değil. GitHub’ın tanımladığı etkilenen grup, genel erişimden önce varsayılan pull_request_target politikasını kullanan depolardan oluşuyor. Önceden tanımlanmış uygulanabilir bir olay politikası varsayılan kuralla değiştirilmiyor; private ve internal depolara da bu otomatik politika eklenmiyor.
Evaluate ile etkin uygulama arasındaki fark burada belirleyici. Evaluate kaydı mevcut bir workflow hatası anlamına gelmiyor; aynı eşleşmenin politika etkinleştirildiğinde durdurulacağını gösteriyor. 2 Kasım tarihi, kapsamdaki varsayılan kuralın gözlemden gerçek engellemeye geçeceği tarih.
Neden pull_request_target seçildi?
pull_request_target, pull request’in geldiği fork yerine temel deponun bağlamında çalışıyor. Temel deponun GITHUB_TOKEN izinlerine ve sırlara erişebilen bir iş, fork’tan gelen güvenilmeyen kodu çalıştırırsa işlem hattının değiştirilmesi veya sırların dışarı aktarılması riski doğabiliyor.
Bununla birlikte tetikleyici; etiketleme, sınıflandırma veya yetkili bir durum kontrolü yayımlama gibi, temel depo bağlamının gerekli olduğu otomasyonlarda kullanılabiliyor. GitHub bu nedenle olayı platformdan kaldırmıyor: Public depolar için güvenli varsayılanı engelleme yönünde kurarken, gerçek bir bağımlılığı bulunan workflow’ların uygulanabilir bir olay politikasıyla açıkça izinli hâle getirilmesine olanak tanıyor.
Etkilenecek workflow’lar nasıl ayrılabilir?
- Repository, organization veya enterprise düzeyindeki Actions Policies bölümünde varsayılan pull_request_target politikasının hangi depoları ve workflow’ları hedeflediğini belirleyin.
- Policy insights içindeki Evaluate sonuçlarından, politika etkin olsaydı engellenecek çalıştırmaları ve bunlara ait workflow yollarını çıkarın.
- Her workflow için pull_request_target bağımlılığının gerekli olup olmadığını değerlendirin. Gerekli olmayan kullanımlarda varsayılan engeli koruyun.
- Tetikleyici zorunluysa pull_request_target olayını uygulanabilir bir Actions olay politikasında açıkça izinli kılın; istisnayı yeni dosya hedefleme özelliğiyle gereken workflow yoluna daraltın.
- Aynı politika aktörleri de kısıtlıyorsa gerekli kullanıcı, ekip veya bot kimliğinin aktör izin listesinde bulunduğunu doğrulayın.
Kesinleşen takvime göre özellik genel kullanıma açık, varsayılan pull_request_target kuralı ise henüz Evaluate aşamasında. Sonraki değişiklik 2 Kasım 2026’da, yalnızca tanımlanan public depo grubunda otomatik uygulamanın başlaması olacak; private ve internal depolar bu geçişten etkilenmeyecek.
Ayrıca okuyun:
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.