GitHub Actions pull_request_target zorunluluğu 2 Kasım 2026'da public repolarda başlıyor

GitHub, Actions için yeni varsayılan event politikasını 2 Kasım 2026'da değerlendirme modundan aktif zorunluluğa geçiriyor ve pull_request_target event'ine güvenen public repo maintainer'ları, bu geçiş gerçekleştiğinde job'ların çalışmayı durdurduğunu görebilir. 20 Ekim 2026'da dev.to'da yayımlanan, GitHub'ın resmi dokümantasyonuna atıfta bulunan bağımsız bir teknik açıklamaya göre, temeldeki workflow çalıştırma korumaları 17 Eylül 2026'da genel kullanıma açıldı. Genel kullanıma açılmadan önce hâlâ varsayılan politikayı kullanan etkilenen repolarda zorunluluk 2 Kasım'da başlayacak.

Kimler etkilenir

dev.to makalesi, yeni varsayılanın yalnızca organizasyon veya repo düzeyinde önceden yapılandırılmış bir Actions event politikası olmayan public repolara uygulandığına dikkat çekiyor. Mevcut politikalar değiştirilmiyor ve private ya da internal repolar kapsam dışında. Değerlendirme modunda bulunan repolarda workflow'lar normal şekilde çalışmaya devam ederken GitHub, hangi çalışmaların engellenmiş olacağını kaydediyor; bu yüzden son tarihten önce politika içgörülerine bakmak gerekiyor. Makale, sinyalleri iki yönde de fazla yorumlamamak konusunda uyarıyor: tek bir uyarı tüm reponun güvensiz olduğu anlamına gelmez ve uyarı olmaması da workflow YAML'sinin sağlam olduğunu kanıtlamaz.

pull_request_target neden riskli

Bu event, bazı otomasyonların fork'lardan gelen pull request'lere, örneğin label uygulama gibi, base repo metadata'sına yazma erişimi tutarak yanıt vermesi gerektiği için var. Bunun bedeli, pull_request_target tarafından tetiklenen workflow'ların normalde bir fork katkısının alacağı salt okunur bağlam yerine base reponun güveni, izinleri ve secret'larıyla çalışmasıdır.

Açıklama yazısı, GitHub'ın kendisinin uyardığı desenleri listeliyor: güvenilmeyen bir fork'un head'ini checkout edip ayrıcalıklı job içinde paket kurulumu, test runner, build script veya shell çalıştırmak; fork tarafından sağlanan metni sağlam bir işleme sınırı olmadan shell komutlarına yerleştirmek; yalnızca metadata okuyan bir job'a geniş yazma izinleri veya secret'lar vermek; ve kasıtlı bir tasarım olmadan cache ya da artifact'leri güven sınırları boyunca paylaşmak. GitHub'ın actions/checkout'u da bu senaryo için özel korumalar ve allow-unsafe-pr-checkout adında bir opt-out input ile geliyor. Makale, opt-out kullanımının güvenilmeyen kod çalıştırmayı güvenli hale getirmediğini, ek inceleme yükümlülükleri getirdiğini ve yalnızca uyarıyı bastırmak için kullanılmaması gerektiğini vurguluyor.

Son tarihten önce neleri kontrol etmeli

.github/workflows dosyalarında pull_request_target arayın ve her workflow'un buna neden ihtiyaç duyduğunu sorun. Önerilen değişiklikleri build etmek ve test etmek genellikle salt okunur contents iznine sahip düşük ayrıcalıklı pull_request event'ine aittir; üçüncü taraf ve birinci taraf Actions'ları incelenmiş commit SHA'larına pinlemek bağımlılık bütünlüğünü daha da güçlendirir.

Ayrıcalıklı davranışın gerçekten gerekli olduğu yerlerde makale, güven sınırlarını ayırmayı öneriyor: katkıcı tarafından sağlanan kodu ayrıcalıklı job'un dışında tutun ve tek ayrıcalıklı işlem CI bittikten sonraki bir API güncellemesi ise, güvenilmeyen katkı kodunu ayrıcalıklı bağlamda çalıştırmak yerine açık yetkilendirme ve provenance kontrolleriyle ayrı bir güvenilir workflow değerlendirin. Yazar ayrıca workflow başına kanıt kaydetmeyi öneriyor — varsayılan politika geçerli mi, hangi belirli API işlemi event'e ihtiyaç duyuyor, job hiç katkıcı kodu çalıştırıyor mu, bunun yerine düşük ayrıcalıklı bir pull_request çalışması geçiyor mu ve herhangi bir istisna ne kadar dar kapsamlı. Bir geri alma planı belgelenmeli; makale ayrıca CI'yı yeşil tutmak için event'i her yerde etkinleştirmeye veya genel geçerli bir checkout opt-out'u dağıtmaya karşı uyarıyor, çünkü bu politikanın kapatmaya çalıştığı açığı yeniden yaratır.

Bir uyarı: dev.to yazısı resmi bir GitHub duyurusu değil bağımsız bir açıklamadır ve yazarı, GitHub'ın politikanın tarihlerini ve koşullarını yayından sonra güncelleyebileceğini belirtiyor; bu yüzden yetkili kaynak resmi Actions dokümantasyonu olmaya devam ediyor.

Neden önemli

Burada iki makul başarısızlık senaryosu var. İlki aksaklık: değerlendirme modu bulgularını görmezden gelen repolar, zorunluluk 2 Kasım 2026'da başladığında job'ların beklenmedik şekilde engellendiğini görebilir. İkincisi daha kötü: pull_request_target'ı geniş çapta yeniden etkinleştiren veya checkout korumalarını devre dışı bırakan aceleci bir çözüm, güvenilmeyen fork kodunun repo secret'larına erişimle çalıştığı bilinen bir supply-chain saldırı yolunu yeniden getirir. Şimdi yapılacak odaklı bir denetim — hangi workflow'ların event'e ihtiyaç duyduğunu belirlemek, gerisini pull_request'e taşımak ve kalan ayrıcalıklı işlemleri izole etmek — her iki sonucu da önler.