GitHub Actions “pull_request_target” Neden Risklidir?

GitHub Actions pull_request_target tek başına her workflow'u riskli yapmaz. Risk, pull request içeriğinden gelen güvenilmeyen kodun veya girdinin, hedef repository'nin daha ayrıcalıklı GITHUB_TOKEN'ı ya da secrets değerleriyle aynı akışta buluşmasıyla ortaya çıkar.

Bu nedenle değerlendirme yalnızca event adına bakılarak yapılmaz. Workflow dosyasının hangi ref'ten okunduğu, checkout adımının hangi kodu çalışma alanına aldığı, sonraki adımların bu kodu çalıştırıp çalıştırmadığı ve işin hangi yetkilere sahip olduğu birlikte incelenir.

pull_request_target neden risklidir? Temel risk zinciri

pull_request_target, pull request etkinliğine hedef repository bağlamında yanıt vermek için tasarlanmıştır. Workflow dosyası ve ref belirtilmemiş checkout çağrısı varsayılan olarak hedef repository'nin default branch'inden gelir. Böylece fork'tan gönderilen kod, kendiliğinden çalıştırılmaz. Ancak workflow açıkça pull request kodunu checkout eder ve ardından bu kodu çalıştırırsa, daha ayrıcalıklı çalışma ortamı ile güvenilmeyen içerik aynı iş içinde buluşur.

Temel risk zinciri şu dört halkadan oluşur:

1. Olay ve yetki: pull_request_target çalışması, hedef repository'nin GITHUB_TOKEN'ını ve workflow tarafından kullanılabilen repository veya organization secrets değerlerini alabilir. Token yetkileri permissions ile daraltılabilir, fakat event'in temel özelliği ayrıcalıklı repository bağlamıdır.
2. Checkout: Ref belirtilmeyen checkout default branch'i alır. Buna karşılık pull request head SHA'sı, merge ref'i veya fork repository'si açıkça seçilirse pull requestteki dosyalar çalışma alanına taşınır.
3. Çalıştırma: Checkout yalnızca dosyaları indirir, tek başına kod çalıştırmaz. Sonraki make test, build, test, bağımlılık kurma veya yapılandırma adımı çalışma alanındaki dosyalara dayanıyorsa pull request kodu dolaylı ya da doğrudan çalışabilir.
4. Yetkili etki alanı: Bu kod aynı iş içinde kullanılan token'a ve workflow'a açılmış secrets değerlerine ulaşmayı deneyebilir. Ayrıca token yetkileri elveriyorsa repository üzerinde kimlik doğrulamalı API işlemleri yapabilir.

GitHub'ın resmî pull_request_target güvenlik rehberi bu deseni “pwn request” olarak açıklar. Buradaki belirleyici nokta fork pull requestin varlığı değil, güvenilmeyen kodun ayrıcalıklı bir workflow içinde çalıştırılmasıdır.

pull_request ile pull_request_target farkı nasıl değerlendirilir?

GitHub'ın workflow olayları dokümantasyonunda açıklanan farkları değerlendirirken event adı, workflow dosyasının kaynağı, checkout ref'i, token, secrets ve fork davranışı birlikte okunmalıdır.

Bu karşılaştırmada tek bir satıra bakmak yeterli değildir. Örneğin pull_request_target ile yalnızca pull request numarasını okuyup etiket eklemek, pull request dosyalarını checkout edip test komutu çalıştırmakla aynı risk zincirini oluşturmaz. Öte yandan token yetkisini azaltmak da checkout edilen kodu güvenilir hâle getirmez. Kaynak kod, yetki ve secrets ayrı ayrı incelenmelidir.

Fork kaynaklı pull requestlerde güvenilmeyen kod nerede devreye girer?

Public bir öğrenci projesinde, başka bir repository'den gelen fork pull requestinin test betiğini, build ayarını veya workflow tarafından çağrılan başka bir dosyayı değiştirdiğini varsayalım. Bu pull requestin fork'tan gelmesi tek başına kötü niyet göstergesi değildir. Teşhis, değişikliğin workflow içinde hangi aşamada kullanıldığına göre yapılır.

1. Pull request hangi dosyaları değiştiriyor?

Değişiklik yalnızca kaynak kodda olabilir, fakat test komutları, build dosyaları, paket yöneticisi yapılandırmaları ve yardımcı betikler de çalışma davranışını etkileyebilir. Bu dosyalardan biri daha sonra runner üzerinde çalıştırılacaksa, kod incelemesi yalnızca ana kaynak dosyalarıyla sınırlı kalmamalıdır.

2. Workflow hangi ref'i checkout ediyor?

pull_request_target içinde ref belirtilmemişse checkout hedef repository'nin default branch'ine yönelir. Workflow, pull request head SHA'sını, merge ref'ini veya fork repository'sini açıkça seçtiğinde güvenilmeyen pull request içeriği çalışma alanına girer. Workflow dosyasının default branch'ten gelmeye devam etmesi bu ayrımı değiştirmez.

3. Hangi adım bu kodu çalıştırıyor?

Checkout adımı tek başına dosyaları çalışma alanına taşır. Asıl risk, ardından gelen make test, npm install, build komutu, test runner veya yapılandırma dosyasının çalışmasıyla tamamlanabilir. Bazı araçlar bağımlılık kurarken ya da build başlatırken proje içindeki ek betikleri de çağırabilir.

4. Token ve secrets nerede devreye giriyor?

pull_request_target çalışmasında hedef repository token'ı varsayılan olarak repository için okuma ve yazma yetkisi taşıyabilir; bu yetki permissions ile azaltılmalıdır. Workflow'a açılan repository veya organization secrets değerleri de ayrı bir inceleme konusudur. Pull request kodu aynı iş içinde çalışıyorsa, bu kodun runner ortamında sunulan kimlik bilgilerini ve yetkili API erişimini kullanma ihtimali değerlendirilmelidir.

5. Kullanıcı girdileri nasıl kullanılıyor?

Pull request başlığı, açıklaması, branch adı, etiketler ve benzeri metadata değerleri güvenilmeyen girdilerdir. Bu değerleri doğrudan run içinde shell komutuna yerleştirmek script injection riskine yol açabilir. Değerleri ara ortam değişkenleri veya action girdileri üzerinden işlemek ve beklenen biçimi doğrulamak daha temkinli bir yaklaşımdır.

GitHub'ın resmî script injection rehberi de pull request metadata değerlerinin kod gibi yorumlanabileceği noktalara doğrudan aktarılmamasını önerir. Sonuç olarak fork pull request teşhisinde şu ayrım korunmalıdır: metadata üzerinde yetkili işlem yapmak başka, pull requestten gelen dosyaları yetkili iş içinde çalıştırmak başkadır.

Riskli ve daha temkinli YAML akışları nasıl karşılaştırılır?

İki akışı karşılaştırırken temel soru, pull request kodunun hangi yetkilerle çalıştırıldığıdır. pull_request_target varsayılan olarak temel deponun güvenilen varsayılan dalındaki workflow'u kullanır ve temel deponun token ile secret bağlamına erişebilir. Fork kaynaklı pull_request akışlarında ise GitHub, varsayılan güvenlik davranışı olarak salt okunur GITHUB_TOKEN kullanır ve diğer secret'ları göndermez. Risk, pull_request_target içinde PR başını alıp bu kodu aynı ayrıcalıklı akışta çalıştırınca oluşur.

Riskli örnek: Ayrıcalıklı olayda PR kodunu çalıştırmak

Güncel actions/checkout davranışında fork PR kodunun pull_request_target ile alınması varsayılan olarak reddedilir. Aşağıdaki allow-unsafe-pr-checkout: true satırı bu korumayı bilinçli olarak aşan riskli deseni görünür hâle getirir.

name: Riskli PR testi

on:
  pull_request_target:

permissions: write-all

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: PR başını checkout et
        uses: actions/checkout@v7
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          allow-unsafe-pr-checkout: true
      - name: PR betiğini çalıştır
        run: bash scripts/test.sh
        env:
          PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
          GH_TOKEN: ${{ github.token }}

Beklenen çalışma davranışı: Olay politikası çalıştırmaya izin veriyorsa workflow, PR başındaki commit'i alır ve PR deposundaki scripts/test.sh dosyasını çalıştırır. Betik, özel secret'a ve write-all ile genişletilmiş token bağlamına erişebilecek bir adımda çalışır. permissions anahtarı, GITHUB_TOKEN kapsamını workflow veya job düzeyinde belirler.

Görünen risk: Checkout işlemi tek başına kod çalıştırmaz. Risk, hemen ardından PR içinden gelen betiğin çalıştırılmasıyla tamamlanır. Betik kötü amaçlıysa secret'ı okumayı, token ile yetkili işlemler yapmayı veya bağımlılıkları üzerinden aynı bağlama erişmeyi deneyebilir. Bu nedenle PR başını checkout etmek, secret kullanmak ve geniş token vermek aynı job içinde birleştirilmemelidir.

Daha temkinli örnek: Testleri pull_request ile çalıştırmak

name: Temkinli PR testi

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Pull request birleşimini checkout et
        uses: actions/checkout@v7
      - name: Testleri çalıştır
        run: bash scripts/test.sh

Beklenen çalışma davranışı: ref belirtilmediği için checkout, pull_request olayının birleşim commit'i bağlamını kullanır. Fork kaynaklı PR'larda GitHub'ın varsayılan korumaları token'ı salt okunur tutar, diğer secret'ları workflow'a vermez ve gerektiğinde onay politikalarını uygular. Açıkça belirtilen contents: read izni de checkout için gereken kapsamı dar tutar.

Neden güvenlik garantisi değildir? Bu yapı secret ve yazma yetkisi riskini azaltır, ancak PR kodu yine runner üzerinde çalışır. Test betikleri, yapılandırma dosyaları, paket kurulumları ve kullanılan üçüncü taraf action'lar ayrıca incelenmelidir. pull_request_target gerekiyorsa daha temkinli tasarım, checkout yapmadan yalnızca pull request metadata'sını işleyen ve yalnız gerekli API izinlerini isteyen ayrı bir akış oluşturmaktır.

Workflow yayımlanmadan önce kontrol edilecek beş nokta

GitHub Actions incelemesini yalnızca YAML söz dizimine bakarak yapmak yeterli değildir. Tetikleyici, checkout ref'i, token yetkisi ve secret erişimi birlikte değerlendirilmelidir. GitHub, permissions ile en düşük token kapsamının belirlenmesini ve fork kaynaklı pull request akışlarında güvenlik sınırlarının ayrıca incelenmesini önerir.

Bu dört sütundan biri açıklanamıyorsa workflow yayımlanmadan önce yeniden incelenmelidir. Özellikle checkout edilen ref ile yetki ve secret erişimi aynı job içinde birleşiyorsa, yalnızca test adının güvenli görünmesi yeterli değildir.

2 Kasım 2026 politika değişikliği neyi kapsıyor?

GitHub'ın 17 Eylül 2026 tarihli duyurusuna göre, public repository'lerde uygulanabilir başka bir Actions event policy'si bulunmuyorsa pull_request_target olayını engelleyen varsayılan bir koruma uygulanıyor. Bu varsayılan kural private ve internal repository'leri kapsamıyor. Kural önce değerlendirme modunda çalışıyor, böylece etkilenecek run'lar görülebiliyor.

2 Kasım 2026 tarihinde, genel kullanılabilirlikten önce varsayılan pull_request_target politikasını kullanan etkilenen repository'lerde bu kural otomatik olarak uygulanacak. Workflow hâlâ bu olaya ihtiyaç duyuyorsa, ilgili Actions event policy içinde pull_request_target açıkça izinli hâle getirilebilir ve gerekirse belirli workflow dosyaları allowlist'e alınabilir. İzin verilmezse olayla tetiklenen workflow run'ları politika nedeniyle engellenir. Bu geçiş, PR kodunu ayrıcalıklı bağlamda çalıştırma riskini ortadan kaldırmaz; açıkça izin verilen akışlarda token, secret, checkout ref'i ve çalıştırılan adımlar yine ayrı ayrı denetlenmelidir.

Son karar: pull_request_target hangi koşullarda değerlendirilebilir?

En kısa karar şudur: pull_request_target, güvenilmeyen pull request kodunu çalıştırmayan ve yalnızca gerekli ayrıcalıklı işlemleri yapan workflow’larda koşullu olarak değerlendirilebilir. Etiketleme, yorum gönderme veya durum bildirimi gibi işlemler bu kapsama girebilir. Ancak fork’tan gelen kod checkout edilecek, derlenecek, test edilecek ya da çalıştırılacaksa aynı akışta secrets veya geniş yetkili GITHUB_TOKEN bulundurmak temkinli bir tasarım değildir. GitHub’ın güvenlik rehberi de bu olayla çalışan workflow’larda güvenilmeyen pull request kodunun çalıştırılmamasını önerir.

Kararı verirken önce tek bir soruya yanıt ver: Pull request’ten gelen kod gerçekten çalıştırılacak mı? Yanıt evetse pull_request olayını kullanabilir veya güvenilmeyen test akışı ile ayrıcalıklı bildirim akışını birbirinden ayırabilirsin. Ek secret erişimi gerekmeyen fork testlerinde pull_request, GitHub’ın uyguladığı salt okunur token ve secret kısıtlamaları nedeniyle daha temkinli bir başlangıç noktasıdır.

Yanıt hayırsa ikinci inceleme katmanına geç: kullanılan olay, checkout edilen kodun hangi ref’ten geldiği, GITHUB_TOKEN izinleri ve secrets akışı birlikte değerlendirilmelidir. pull_request_target workflow’u varsayılan olarak temel deponun varsayılan dalındaki workflow koduyla çalışır. Checkout adımında özel bir ref belirtilmediğinde yine bu güvenilir bağlam kullanılır. Fakat pull request başını açıkça checkout etmek, git fetch ile fork kodu almak veya indirilen içeriği çalıştırmak bu ayrımı bozabilir.

Bu nedenle pull_request_target için doğru yaklaşım, olayı baştan güvenli ya da güvensiz ilan etmek değil, ayrıcalıklı otomasyon ile güvenilmeyen kodun aynı çalışma alanında buluşup buluşmadığını incelemektir. Güvenilmeyen içerik yalnızca veri olarak analiz ediliyor, token izinleri dar tutuluyor ve gerekli olmayan secrets workflow’a aktarılmıyorsa kullanım değerlendirilebilir. Kod çalıştırma zorunluysa secret erişimini bu işten ayıran başka bir akış tasarlamak daha uygun olur.

Sık Sorulan Sorular

pull_request_target kullanmak her zaman riskli midir?

Hayır. Risk, olay adından çok ayrıcalıklı bağlamda güvenilmeyen kodun çalıştırılmasıyla ortaya çıkar. Varsayılan daldaki güvenilir workflow yalnızca etiketleme, yorumlama veya durum bildirimi yapıyorsa değerlendirme farklıdır. Fork kodu checkout edilip build, test, kurulum veya başka bir komutla çalıştırıldığında risk artar.

Fork’tan gelen pull requestlerde testleri hangi olayla çalıştırmak daha temkinlidir?

Test için ek secret erişimi veya ayrıcalıklı yazma izni gerekmiyorsa pull_request daha temkinli seçenektir. Fork kaynaklı pull requestlerde bu olay, varsayılan olarak salt okunur GITHUB_TOKEN kullanır ve diğer secrets değerlerini aktarmaz.

pull_request_target içinde pull request kodunu checkout etmek neden sorun yaratabilir?

Checkout adımı tek başına kod çalıştırmaz. Sorun, sonrasında pull request içindeki Makefile, yapılandırma dosyası, bağımlılık, test komutu veya kurulum betiğinin çalıştırılmasıyla başlar. Bu komutlar, workflow’un sahip olduğu token izinlerine ve aktarılmış secrets değerlerine erişmeye çalışabilir.

permissions: read yazmak secrets riskini tek başına ortadan kaldırır mı?

Hayır. permissions ayarı öncelikle GITHUB_TOKEN izinlerini sınırlar. Secrets akışı ayrı bir konudur. Bir secret workflow’a veya adıma aktarılmışsa salt okunur token kullanmak, secret’ın çalıştırılan güvenilmeyen kod tarafından okunmasını tek başına engellemez.

Güvenli kararın temeli, olay adını değil kodun nereden geldiğini, nerede çalıştığını ve hangi yetkilere eriştiğini birlikte değerlendirmektir.