GitHub Actions Checkout ve pull_request_target Güvenliği

GitHub Actions güvenliği açısından kritik nokta, yalnızca actions/checkout satırının hangi sürümü kullandığı değildir. pull_request_target ile çalışan bir workflow incelenirken çalıştırılan commit, event bağlamı, GITHUB_TOKEN izinleri ve secrets akışı birlikte değerlendirilmelidir.

GitHub’ın 18 Haziran 2026 tarihli resmî duyurusunda, fork kaynaklı pull request kodunun ayrıcalıklı workflow’larda checkout edilmesini önlemeye yönelik actions/checkout davranış değişikliği açıklanmıştır. Bu koruma önemli bir güvenlik katmanı ekler; ancak workflow’un başka yollarla güvenilmeyen kod indirip çalıştırmasını veya gereğinden geniş izinlerle işlem yapmasını tek başına ortadan kaldırmaz.

GitHub Actions checkout değişikliği workflow güvenliğini neden etkiliyor?

Bir GitHub Actions workflow’unda actions/checkout adımı, depo içeriğini runner üzerindeki çalışma alanına getirir. Sonraki adımlarda npm install, pytest, mvn test, özel shell script’leri veya proje tarafından sağlanan başka komutlar çalıştırılıyorsa checkout edilen içerik doğrudan yürütme zincirinin parçası hâline gelir. Bu nedenle güvenlik değerlendirmesi, “checkout başarılı mı?” sorusundan çok “hangi commit, hangi yetkilerle ve hangi event bağlamında çalıştırıldı?” sorusuna dayanır.

Özellikle pull_request_target olayında workflow, taban deponun varsayılan dalı bağlamında çalışır. Bu event; pull request etiketleme, yorum yazma veya metadata okuma gibi ayrıcalıklı işlemler için yararlı olabilir. Fakat aynı workflow içinde fork pull request’inin head veya merge commit’i checkout edilip çalıştırılırsa, güvenilmeyen kod ayrıcalıklı bağlama taşınabilir. GitHub dokümantasyonu bu nedenle pull_request_target ile güvenilmeyen pull request kodunun birlikte kullanılmasını dikkat gerektiren bir yapı olarak açıklar.

18 Haziran 2026 tarihli GitHub Changelog duyurusu, actions/checkout v7’nin fork pull request kodunu pull_request_target ve belirli workflow_run senaryolarında güvensiz girdilerle çekmeyi varsayılan olarak reddetmeye başladığını belirtir. Duyuruda örnek olarak pull request merge ref’inin, head commit SHA’sının veya fork deposu adının checkout girdisi olarak verilmesi gösterilir. Aynı duyuru, bu korumanın yalnızca belirli checkout biçimlerini kapsadığını; örneğin bir run adımında git ya da gh kullanılarak güvenilmeyen kodun dolaylı biçimde indirilmesi ve çalıştırılmasının ayrıca incelenmesi gerektiğini vurgular.

Değişiklik hangi güvenlik problemini hedefliyor?

Temel problem, güvenilmeyen pull request kodunun ayrıcalıklı bir workflow içinde çalıştırılmasıdır. Güvenlik literatüründe bu desen çoğu zaman “pwn request” olarak adlandırılır. Buradaki risk, yalnızca kötü niyetli bir dosyanın checkout edilmesi değildir. Saldırgan kontrollü kod aşağıdaki kaynaklara erişmeye çalışabilir:

• Workflow’a açıkça verilen veya ortam değişkenlerine aktarılan secrets değerleri,
• Depoya yazma yetkisi bulunan geniş kapsamlı GITHUB_TOKEN,
• Runner üzerinde daha önce oluşturulmuş dosyalar ve ortak çalışma alanları,
• İş akışının kullandığı özel paket depoları veya kimlik doğrulama bilgileri,
• Yanlış yapılandırılmış cache, artifact ya da sonraki job’lara aktarılan çıktılar.

Bu nedenle “checkout adımı artık hata veriyor, sorun çözüldü” şeklinde kesin bir sonuca varmak doğru değildir. Checkout koruması belirli bir saldırı yolunu engelleyebilir; ancak workflow dosyasında güvenilmeyen kodun başka bir komutla indirilmesi, bir script’in doğrudan çalıştırılması veya secrets değerlerinin gereksiz biçimde bir job’a aktarılması hâlâ ayrı değerlendirme gerektirir.

Checkout edilen commit neden güvenlik kararının merkezindedir?

Bir pull request workflow’unda “pull request’i test etmek” ifadesi tek bir commit’i ifade etmeyebilir. Test edilen içerik aşağıdakilerden biri olabilir:

• Taban dal ile pull request dalının birleştirilmiş sonucu,
• Pull request’in head dalındaki son commit,
• Taban deponun varsayılan dalındaki güvenilir workflow ve dosyalar,
• Başka bir repository’den veya artifact içinden indirilen içerik.

pull_request event’inde actions/checkout varsayılan olarak pull request’in merge ref’ini kullanır. Böylece testler, pull request değişiklikleri ile taban dalın birleşmiş sonucu üzerinde çalışır. Buna karşılık pull_request_target bağlamında workflow’un kendisi taban deponun varsayılan dalı üzerinden değerlendirilirken, checkout adımına açıkça verilen ref veya repository değerleri güvenilmeyen pull request içeriğine yönelirse ayrı bir risk oluşur.

İnceleme sırasında özellikle şu ifadeler dikkatle okunmalıdır:

• ref: ${{ github.event.pull_request.head.sha }}
• ref: refs/pull/${{ github.event.pull_request.number }}/merge
• repository: ${{ github.event.pull_request.head.repo.full_name }}
• git fetch, git checkout veya gh pr checkout komutları,
• Checkout sonrasında pull request deposundan gelen script’lerin çalıştırılması.

Bu ifadeler tek başına her projede aynı sonucu doğurmaz; event türü, repository’nin fork olup olmadığı, token izinleri ve workflow’un sonraki adımları birlikte okunmalıdır. Ancak ayrıcalıklı event ile güvenilmeyen ref’in aynı workflow’da birleştiği görülüyorsa, bu yapı güvenlik incelemesinin öncelikli adayıdır.

Token izinleri ve secrets neden checkout’tan ayrı düşünülmemeli?

actions/checkout çoğu senaryoda repository içeriğini almak için GITHUB_TOKEN kullanır. Checkout’un çalışabilmesi için gerekli izin ile workflow’un sonraki adımlarında kullanılabilecek izin aynı şey değildir. Örneğin repository içeriğini okumak için contents: read yeterli olabilir; fakat workflow’a issues: write, pull-requests: write veya başka yazma izinleri verilmişse, checkout edilen kodun etkileyebileceği alan genişler.

GitHub Actions dokümantasyonunda izinlerin repository, organization veya enterprise varsayılanlarından başlayıp workflow ve job seviyesindeki permissions ayarlarıyla daraltılabildiği açıklanır. Fork kaynaklı pull_request çalıştırmalarında yazma izinleri varsayılan olarak salt okunur hâle getirilebilir; ancak event türü ve repository ayarları incelenmeden yalnızca bu genel kurala dayanarak güvenlik sonucu çıkarılmamalıdır.

Secrets için de benzer bir ayrım vardır. Bir fork pull request’inde normal repository secrets değerlerinin runner’a aktarılmaması, workflow’un güvenli olduğu anlamına gelmez. Workflow yine de repository kodunu okuyabilir, token ile API çağrısı yapabilir, log üretebilir veya güvenilmeyen girdileri işleyebilir. Tersine, pull_request_target ayrıcalıklı bağlam sunduğu için secrets ve token erişimi daha hassas bir tasarım kararı hâline gelir.

Pratik incelemede şu dört soruyu aynı anda sormak gerekir:

1. Bu workflow hangi event ile tetikleniyor?
2. Checkout hangi repository ve hangi ref’i getiriyor?
3. Sonraki komutlar checkout edilen dosyalardan kod çalıştırıyor mu?
4. Job’un GITHUB_TOKEN ve secrets erişimi gerçekten gerekli mi?

Basit ve daha kontrollü bir checkout örneği

Aşağıdaki örnek, güvenilmeyen pull request’leri test etmek için pull_request event’ini kullanır ve token yetkisini repository içeriğini okumayla sınırlar. Workflow, checkout edilen kodun commit bilgisini yazdırır; beklenen çıktı, çalıştırılan pull request merge commit’ine ait kısa SHA değeridir.

name: Pull request inceleme

on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Kodu al
        uses: actions/checkout@v7

      - name: Commit bilgisini yazdır
        run: |
          echo "Event: ${{ github.event_name }}"
          echo "Commit: $(git rev-parse --short HEAD)"

Örnek çalıştığında log’da Event: pull_request satırı ve checkout edilen commit’in kısa SHA değeri görülür. Bu yapı her test workflow’u için otomatik olarak ideal anlamına gelmez; çünkü test komutları pull request kodunu çalıştıracaksa bağımlılık kurulumları, script’ler ve test fixture’ları da ayrıca incelenmelidir. Buradaki amaç, checkout ref’i ile token iznini açıkça görünür hâle getirmektir.

Değişikliğin sınırları nasıl okunmalı?

Güncel duyurudaki koruma, fork pull request’inin head veya merge içeriğini belirli güvensiz girdilerle checkout etmeyi hedefler. Bu, ayrıcalıklı bir event içinde bulunan tüm riskli işlemlerin otomatik biçimde engellendiği anlamına gelmez. Örneğin workflow, checkout kullanmadan dış bir repository’den kod indirebilir veya bir shell komutuyla pull request içeriğini alıp çalıştırabilir.

Ayrıca güvenlik kararı yalnızca action sürümüne bağlanmamalıdır. Action’ları tam commit SHA’sına sabitlemek, üçüncü taraf action kaynaklarını incelemek, job seviyesinde minimum izin vermek ve secrets değerlerini yalnızca ihtiyaç duyan adıma aktarmak daha geniş bir savunma yaklaşımının parçalarıdır. GitHub’ın güvenli kullanım rehberi de ayrıcalıklı event’lerde güvenilmeyen pull request kodunun açıkça checkout edilmemesini önerir.

pull_request ile pull_request_target arasındaki güvenlik farkı nasıl okunmalı?

pull_request ile pull_request_target arasındaki farkı yalnızca “biri güvenli, diğeri güvensiz” şeklinde ezberlemek yetersizdir. Doğru okuma; workflow dosyasının hangi ref’ten alındığını, event’in hangi repository bağlamında çalıştığını, checkout’un hangi kodu getirdiğini ve token ile secrets erişiminin ne olduğunu birlikte karşılaştırmayı gerektirir.

GitHub’ın resmî event dokümantasyonuna göre pull_request çalıştırmalarında GITHUB_REF açık ve merge edilebilir pull request’ler için refs/pull/NUMARA/merge değerini, GITHUB_SHA ise merge commit’ini ifade eder. actions/checkout varsayılan davranışla bu merge ref’ini checkout edebilir. pull_request_target ise taban repository’nin varsayılan dalı bağlamında çalışır; bu nedenle pull request head kodunu build veya test etmek için kullanılmaması gerektiği özellikle belirtilir.

“Güvenilir workflow dosyası” ile “güvenilmeyen pull request kodu” ayrımı

pull_request_target tasarımının önemli fikri, workflow dosyasını taban repository’nin güvenilir bağlamından çalıştırırken pull request olayının metadata’sını kullanabilmektir. Örneğin bir workflow, fork pull request’ine etiket eklemek veya pull request hakkında yorum yazmak isteyebilir. Bu işlemler için değiştirilen projenin kaynak kodunu checkout edip çalıştırması gerekmeyebilir.

Burada iki farklı varlık birbirine karıştırılmamalıdır:

• Güvenilir workflow dosyası: Taban repository’nin kontrol ettiği ve incelenmiş olması beklenen YAML tanımıdır.
• Güvenilmeyen pull request kodu: Fork’tan gelen kaynak dosyaları, build script’leri, bağımlılık tanımları, test kodları ve çalıştırılabilir komutlardır.

Bir workflow dosyasının güvenilir bir daldan seçilmesi, checkout sonrasında getirilen pull request kodunun da güvenilir olduğu anlamına gelmez. Örneğin taban dalda bulunan YAML dosyası şu tür bir işlem yapıyorsa risk yeniden ortaya çıkabilir:

steps:
  - name: Fork kodunu al
    uses: actions/checkout@v7
    with:
      repository: ${{ github.event.pull_request.head.repo.full_name }}
      ref: ${{ github.event.pull_request.head.sha }}

  - name: Proje komutunu çalıştır
    run: ./scripts/check.sh

Bu örnekte YAML dosyası taban repository’de bulunsa bile checkout edilen içerik fork pull request’inin head commit’idir. Ardından ./scripts/check.sh çalıştırıldığı için güvenilmeyen kod yürütme zincirine girer. Yeni checkout koruması bazı fork pull request checkout biçimlerini reddedebilir; ancak tasarımın güvenli olup olmadığı, yalnızca action’ın hata verip vermemesine göre değil, workflow’un gerçekten ne yapmaya çalıştığına göre değerlendirilmelidir.

Event seçimi için pratik karar ölçütü

İlk karar sorusu “Pull request kodunu çalıştırmam gerekiyor mu?” olmalıdır.

• Yanıt evet ise, test ve build işlemleri için çoğu durumda pull_request bağlamı daha anlaşılır bir başlangıç noktasıdır. Bununla birlikte checkout edilen kodun çalışacağı ve bağımlılık kurulumlarının güvenilmeyen içerik barındırabileceği unutulmamalıdır.
• Yanıt hayır ise, pull request metadata’sını okuyup etiketleme veya yorumlama gibi işlemler için pull_request_target değerlendirilebilir. Bu durumda kaynak kodunu checkout etmemek ve çalıştırmamak temel tasarım ilkesi olmalıdır.
• Özel bir ayrıcalık gerçekten gerekiyorsa, token izinleri ve secrets erişimi yalnızca gereken job veya step ile sınırlandırılmalıdır.
• Workflow’un doğrudan checkout etmediği içerikler de incelenmelidir; git, gh, artifact, cache veya harici indirme adımları aynı güvenlik sınırını dolaylı biçimde aşabilir.

Özetle, pull_request güvenilmeyen değişiklikleri düşük yetkili bir test bağlamında çalıştırma ihtiyacına; pull_request_target ise taban repository bağlamında ayrıcalıklı metadata işlemleri yapma ihtiyacına daha yakındır. Hiçbiri tek başına bütün workflow’lar için otomatik güvenlik garantisi vermez. İnceleme sırasında izlenecek doğru sıra; güvenilmeyen kodu belirlemek, checkout ref’ini görmek, event bağlamını anlamak, token izinlerini daraltmak ve secrets akışını en son doğrulamaktır.

Bir workflow dosyası hangi sırayla denetlenmeli?

Bir GitHub Actions workflow’unu güvenlik açısından incelerken yalnızca actions/checkout satırına bakmak yeterli değildir. Daha sağlıklı yaklaşım, güvenilmeyen kodun kaynağından başlayıp kodun çalıştırıldığı adıma kadar ilerlemektir. Böylece tetikleyici, checkout edilen commit, token izinleri ve secrets kullanımı arasındaki ilişkiyi birlikte değerlendirebilirsiniz.

Aşağıdaki sıra, özellikle fork üzerinden açılan pull request’leri inceleyen öğrenciler ve küçük ekipler için pratik bir denetim akışı olarak kullanılabilir. actions/checkout resmî dokümantasyonu, repository girdisinin hangi depodan checkout yapılacağını, ref girdisinin dal, etiket veya SHA belirtebildiğini ve path girdisinin depoyu çalışma alanı altındaki hangi konuma yerleştireceğini açıklar. Aynı dokümantasyonda pull request bağlamında ref’in açıkça belirtilmesi gereken senaryolar da gösterilir. ([github.com](https://github.com/actions/checkout?utm_source=openai))

1. Güvenilmeyen kodun kaynağını belirleyin

İlk soru, workflow’un hangi kod üzerinde işlem yaptığıdır. Kod doğrudan ana depodaki güvenilir bir commit’ten mi geliyor, aynı depodaki bir daldan mı geliyor, yoksa dış bir fork’tan açılan pull request’in head commit’inden mi çekiliyor?

Bir pull request’in başlığı, açıklaması, dal adı, değiştirilen dosyaları ve özellikle kodun kendisi güvenilmeyen girdi olarak ele alınmalıdır. Dış fork’tan gelen bir pull request, depoya yazma yetkisi olmayan bir geliştirici tarafından hazırlanmış olabilir. Bu durum tek başına kötü niyet anlamına gelmez; ancak otomasyon açısından kodun önceden incelenmeden güvenilir kabul edilmemesi gerektiğini gösterir.

• Sorulacak soru: Workflow hangi kullanıcı, dal veya depodan gelen içeriği işliyor?
• Risk işareti: pull_request_target kullanılıyor ve workflow, pull request sahibinin değiştirebildiği dosyaları çalıştırıyor.
• Güvenli inceleme notu: Fork pull request’lerini varsayılan olarak güvenilmeyen kaynak kabul edin. Tetikleyiciyi daha sonra inceleyecek olsanız bile ilk varsayımınız “bu kod çalıştırılabilir” değil, “bu kod saldırgan tarafından değiştirilebilir” olsun.

GitHub’ın güvenlik dokümantasyonu, pull_request_target ile untrusted pull request kodunun checkout edilip çalıştırılmasının cache poisoning, istenmeyen yazma yetkisi veya secrets erişimi gibi riskler oluşturabileceği konusunda uyarır. Bu tetikleyici, pull request’in değişikliklerini derlemekten çok etiketleme, yorum yazma veya durum güncelleme gibi ayrıcalıklı işlemler için düşünülmelidir. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows?scid=7013o000002CceTAAS&utm_source=openai))

2. Checkout ref’ini ve çalışacak commit’i inceleyin

İkinci aşamada “workflow hangi commit’i checkout ediyor?” sorusunu yanıtlayın. Burada yalnızca actions/checkout kullanılıp kullanılmadığına değil, with bloğundaki bütün önemli girdilere bakılır:

• ref: Checkout edilecek dalı, etiketi veya commit SHA’sını belirler.
• repository: Hangi depo üzerinde işlem yapılacağını belirler. Belirtilmediğinde action, workflow’u tetikleyen mevcut depoyu temel alır.
• path: Checkout edilen içeriğin çalışma alanı altında hangi göreli klasöre yerleştirileceğini belirler.
• fetch-depth: Git geçmişinin ne kadarının indirileceğini etkiler; güvenlik kararı açısından tek başına güven sınırı oluşturmaz.
• submodules: Alt modüllerin de checkout edilip edilmeyeceğini belirler. Alt modüller de ayrıca incelenmelidir.

pull_request ve pull_request_target olaylarının çalışma bağlamları aynı değildir. GitHub dokümantasyonuna göre pull_request_target için GITHUB_SHA ve GITHUB_REF taban deponun varsayılan dalındaki bağlamı temsil eder. Bu nedenle pull request’in değişen kodu, ref açıkça belirtilmeden otomatik olarak çalışıyor varsayılmamalıdır. Buna karşılık pull_request akışında checkout davranışı pull request’in birleştirme commit’iyle ilişkilendirilebilir. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows?scid=7013o000002CceTAAS&utm_source=openai))

• Sorulacak soru: ref değeri sabit bir dal, güvenilir bir SHA veya pull request head SHA’sı mı?
• Risk işareti: pull_request_target altında github.event.pull_request.head.sha ya da head branch checkout ediliyor ve hemen ardından proje kodu çalıştırılıyor.
• Güvenli inceleme notu: Ref’in checkout edilmesi ile o ref’teki kodun çalıştırılmasını ayrı kararlar olarak değerlendirin. Bir commit’i indirmek, onu güvenilir hâle getirmez; yalnızca hangi içeriğin çalışma alanına geldiğini netleştirir.

Özellikle repository değeri dinamik bir ifadeden oluşturuluyorsa, bunun dış fork’u işaret edip etmediğini kontrol edin. path değeri farklı bir klasör gösteriyorsa sonraki run ve uses adımlarının gerçekten hangi checkout üzerinde çalıştığını da izleyin. Bir workflow birden fazla depo checkout ediyorsa, yanlış klasörde çalıştırılan komutlar denetimin gözden kaçmasına neden olabilir.

3. permissions bloğunu kontrol edin

Üçüncü aşama, workflow’un aldığı GITHUB_TOKEN izinlerini anlamaktır. İzinler yazılmamışsa “kesinlikle salt okunur” veya “kesinlikle yazma yetkili” sonucu çıkarılamaz; başlangıç kapsamı kurumsal, organizasyon veya depo ayarlarına bağlı olabilir. Bu nedenle hem workflow dosyasındaki açık tanımı hem de depo ayarlarındaki varsayılanı incelemek gerekir.

GitHub Actions sözdiziminde permissions altında izinler read, write veya none olarak belirlenebilir. Belirli izinlerden biri açıkça yazıldığında, belirtilmeyen izinler none olarak değerlendirilir. Örneğin yalnızca contents: read tanımı, checkout işlemi için gereken okuma yetkisini sınırlandırılmış biçimde ifade eder. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax?utm_source=openai))

• Sorulacak soru: Bu job’un gerçekten hangi token izinlerine ihtiyacı var?
• Risk işareti: permissions: write-all, contents: write veya ihtiyaç duyulmayan pull-requests: write gibi yetkilerle birlikte güvenilmeyen kod çalıştırılıyor.
• Güvenli inceleme notu: Önce permissions: {} veya yalnızca gerekli okuma izinleriyle başlayın; checkout için çoğu senaryoda ihtiyaç duyulan yetkiyi ayrıca ve açıkça değerlendirin.

GITHUB_TOKEN otomatik oluşturulan, job süresiyle sınırlı ve workflow’un bulunduğu depoyla ilişkili bir tokendir. Ancak token’ın erişim sınırını yalnızca “otomatik token” olması belirlemez; workflow, depo ve üst seviye ayarlardaki izin politikaları da önemlidir. Fork pull request’lerinde yazma izinlerinin okuma seviyesine düşürülebilmesi de tetikleyiciye ve depo ayarlarına göre değerlendirilmelidir. ([docs.github.com](https://docs.github.com/en/actions/concepts/security/github_token?utm_source=openai))

4. Secrets kullanımını izleyin

Dördüncü aşamada workflow’un hangi secrets değerlerine eriştiğini ve bu değerlerin hangi adımlara aktarıldığını takip edin. Bunun için yalnızca secrets. ifadelerini aramak yeterli değildir. Bir secret, ortam değişkeniyle, bir action’ın with girdisiyle veya bir komutun parametresiyle dolaylı olarak kullanılabilir.

• Sorulacak soru: Hangi adımlar secret kullanıyor ve bu adımlar güvenilmeyen kodun çalıştırıldığı job ile aynı mı?
• Risk işareti: Secret içeren bir environment değişkeni, pull request’ten checkout edilen projenin test veya build komutuyla aynı job’da bulunuyor.
• Güvenli inceleme notu: Secrets gerektiren işlemleri untrusted kodu derleyen veya test eden adımdan ayırın. Mümkünse sonuç üretme ve ayrıcalıklı yorumlama/yayınlama işlerini farklı workflow’lara bölün.

Bir secret’ın doğrudan komut satırına yazılmaması, riskin tamamen ortadan kalktığı anlamına gelmez. Çalıştırılan test, bağımlılık kurulumu, build script’i veya özel action, çalışma ortamındaki değişkenlere erişmeye çalışabilir. Bu yüzden secret’ın kullanılmadığı bir job’da bile token izinleri ve checkout edilen kodun güven düzeyi birlikte değerlendirilmelidir.

5. Kod çalıştıran adımları ve tetikleyici koşullarını değerlendirin

Son aşamada workflow’un gerçekten kod çalıştırdığı bütün noktaları listeleyin. Tehlike yalnızca npm run build, pytest veya mvn test gibi açık komutlardan oluşmaz. Bağımlılık kurulumu sırasında çalışan lifecycle script’leri, test keşfi, özel action’lar, Makefile hedefleri, Docker build adımları ve proje yapılandırma dosyaları da kod çalıştırabilir.

• Sorulacak soru: Checkout edilen içerik hangi adımda yorumlanıyor veya çalıştırılıyor?
• Risk işareti: npm install, npm ci, pytest, mvn test, gradle build, make veya benzeri komutlar pull_request_target job’unda çalışıyor.
• Güvenli inceleme notu: Komutun adına değil, komutun proje tarafından hangi dosyaları ve bağımlılıkları çalıştırdığına bakın. Untrusted kodun yalnızca veri olarak incelenmesiyle gerçekten çalıştırılması arasında net bir ayrım kurun.

Tetikleyici koşullarını da bu son aşamada tekrar kontrol edin. branches, paths, types ve job seviyesindeki if ifadeleri workflow’un kimler tarafından ve hangi değişikliklerde çalışacağını sınırlar. Ancak bir filtre kullanılması, workflow’un güvenli olduğu anlamına gelmez. Örneğin yalnızca belirli bir dosya değiştiğinde çalışan ayrıcalıklı bir job, o dosyanın içeriğini çalıştırıyorsa yine dikkat gerektirir.

İnceleme sonunda şu zinciri tek satırda kurabiliyor olmalısınız: “Bu kaynak tarafından değiştirilebilen kod, şu ref ile checkout ediliyor; şu token izinleriyle çalışıyor; şu secrets değerlerine aynı job’dan erişebiliyor; ardından şu komutlar tarafından yürütülüyor.” Bu zincirin herhangi bir halkası belirsizse workflow’u onaylamadan önce o belirsizliği giderin.

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

Aşağıdaki iki örnekte temel fark, yalnızca tetikleyici adı değildir. Asıl fark; ayrıcalıklı bir bağlamda dış pull request kodunun checkout edilmesi, token izinlerinin genişletilmesi ve bu kodun bağımlılık kurulumuyla çalıştırılması arasındaki birleşimdir.

Riskli yapı: ayrıcalıklı bağlamda pull request kodunu çalıştırmak

name: Riskli PR testi
on:
  pull_request_target:
permissions:
  contents: write
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci
      - run: npm test

Bu workflow, pull_request_target olayında pull request’in head commit’ini açıkça checkout eder. Ardından npm ci ile bağımlılık kurulumu ve npm test ile proje kodu çalıştırılır. Pull request sahibi package.json, test dosyaları, build ayarları veya bağımlılık tanımları üzerinde değişiklik yapabiliyorsa bu adımların davranışı da değişebilir.

Buradaki contents: write izni, job’un depo içeriği üzerinde yazma yetkisine ihtiyaç duyduğunu belirtir. Örneğin yalnızca test çalıştırmak için bu yetki gerekli olmayabilir. Yetki azaltılsa bile pull_request_target altında untrusted kodu checkout edip çalıştırma problemi ayrıca devam eder. GitHub’ın güvenlik uyarısı da bu tetikleyiciyle untrusted fork kodunun çalıştırılmamasını özellikle vurgular. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows?scid=7013o000002CceTAAS&utm_source=openai))

Beklenen davranış: Workflow, pull request açıldığında veya güncellendiğinde hedef deponun ayrıcalıklı bağlamında çalışır; belirtilen head commit’i çalışma alanına getirir ve bu commit’in proje komutlarını çalıştırır. Bu nedenle örnek, güvenlik garantisi sunan bir şablon değil, denetimde aranması gereken riskli birleşimi gösteren bir karşılaştırma örneğidir.

Daha temkinli yapı: test bağlamını ve yetkileri ayırmak

name: PR testi
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci
      - run: npm test

Bu örnekte workflow pull_request olayıyla çalışır, yalnızca main dalını hedefleyen pull request’leri kabul eder ve token için contents: read iznini açıkça belirtir. Checkout ref’i de doğrudan pull request head SHA’sı olarak yazılmıştır. Böylece incelenen kodun hangi commit olduğu belirsiz bırakılmaz.

Bu yapı yine dışarıdan gelen kodu çalıştırır; dolayısıyla “mutlak güvenli” olarak etiketlenmemelidir. Temkinli olmasının nedeni, test job’unun ayrıcalıklı pull_request_target bağlamında çalışmaması ve gereksiz yazma izni talep etmemesidir. Test runner’ı, kullanılan bağımlılıkları, self-hosted runner yapılandırmasını ve diğer action’ları ayrıca denetlemek gerekir.

Secrets gerektiren adımları neden ayırmak gerekir?

Bir pull request’in test edilmesiyle harici bir servise kimlik doğrulama yapılması aynı güvenlik kararını gerektirmez. Test job’u untrusted kodu çalıştırabilir; secret kullanan yayınlama, yorum yazma veya harici API çağrısı job’u ise ayrı bir güven sınırında ele alınmalıdır.

• Pull request test job’unda mümkün olduğunca repository secrets kullanmayın.
• Test sonuçlarını, yalnızca gerekli bilgileri içeren çıktılar veya artifact’ler olarak üretin.
• Secret gerektiren sonraki adımı ayrı bir workflow veya kontrollü bir manuel onay süreci olarak tasarlayın.
• İkinci aşamada artifact içeriğini de güvenilmeyen veri kabul edin; artifact’ten gelen dosyaları doğrudan script veya komut olarak çalıştırmayın.
• Yorum yazma ya da etiketleme gibi işlemler gerekiyorsa, bu işlemlerin gerçekten pull request kodunu checkout etmediğini doğrulayın.

Karşılaştırmayı şu kısa çerçeveyle yapabilirsiniz:

Uygulanabilir kısa denetim listesi

• pull_request_target varsa, workflow’un gerçekten ayrıcalıklı bir bağlama ihtiyaç duyup duymadığını sorun.
• actions/checkout girdilerinde repository, ref ve path değerlerini tek tek okuyun.
• Checkout edilen commit’in dış fork’tan gelip gelmediğini belirleyin.
• permissions bloğunu job düzeyinde de kontrol edin; yalnızca workflow başındaki tanıma güvenmeyin.
• secrets, GITHUB_TOKEN ve özel token’ların hangi adımlara ulaştığını izleyin.
• Bağımlılık kurulumu, test, build, Docker ve özel action adımlarının proje kodu çalıştırıp çalıştırmadığını değerlendirin.
• Şüpheli bir workflow’u test etmek için gerçek secret, üretim deposu veya yıkıcı komut kullanmayın; izole bir deneme deposu ve sahte girdiler tercih edin.

Değişiklik sonrası workflow güvenli biçimde nasıl test edilir?

Bir workflow’un çalışması, onun güvenli olduğu anlamına gelmez. Güvenlik testi; işin başarıyla tamamlanıp tamamlanmadığını değil, hangi commit’in checkout edildiğini, hangi kodun çalıştırıldığını, token’ın ne yapabildiğini ve secrets değerlerinin hangi koşullarda erişilebilir olduğunu doğrulamalıdır.

En düşük riskli yaklaşım, değişikliği doğrudan üretim repository’sinde denemek yerine ayrı bir deneme repository’sinde veya düşük önem taşıyan bir fork üzerinde test etmektir. İlk testte gerçek dağıtım anahtarları, özel paket kayıt defteri bilgileri, bulut erişim anahtarları ve yazma yetkili token’lar kullanılmamalıdır. GitHub’ın fork pull request workflow’ları için önerdiği temel güvenlik modeli, mümkün olduğunda salt okunur GITHUB_TOKEN kullanmak ve secrets erişimini kapalı tutmaktır. asenkron yazılım eğitimleri içinde Git, YAML ve workflow temellerini sistemli biçimde çalışmak, bu tür test planlarını daha bilinçli uygulamaya yardımcı olabilir.

GitHub Actions güvenlik rehberi, güvenilmeyen girdilerin workflow içinde nasıl kullanıldığının ve ayrıcalıklı çalışma bağlamlarıyla nasıl birleştirildiğinin özellikle incelenmesini önerir. Bu nedenle test, yalnızca “job yeşil mi?” sorusuna indirgenmemelidir. ([docs.github.com](https://docs.github.com/en/enterprise-server%403.22/actions/reference/security/securely-using-pull_request_target?utm_source=openai))

1. Düşük riskli bir test alanı hazırlayın

Önce üretim repository’sinin kritik verilerini ve yetkilerini taşımayan bir deneme alanı oluşturun. Bu alan, gerçek projedeki workflow dosyasının kontrollü bir kopyasını içerebilir; ancak aşağıdaki değerleri başlangıçta kullanmamak gerekir:

• Üretim ortamına ait API anahtarları
• Yazma yetkili kişisel erişim token’ları
• Bulut hesaplarına erişim sağlayan secrets değerleri
• Özel paket deposu veya özel Docker registry kimlik bilgileri
• Dağıtım, release veya repository ayarlarını değiştirebilen yetkiler

Test repository’sinde yalnızca gerekli örnek dosyaları bulundurun. Örneğin basit bir kaynak dosyası, bir test dosyası ve workflow’un checkout ettiği commit’i gösterecek bir adım yeterlidir. İlk çalıştırmada amaç uygulamanın bütün özelliklerini sınamak değil, workflow’un güvenlik sınırlarını gözlemlemektir.

2. Zararsız bir fork pull request açın

Test için fork’tan gelen, yalnızca zararsız bir dosyada küçük değişiklik yapan pull request kullanın. Değişiklik; bir README satırı, yorum veya test verisi gibi workflow davranışını etkilemeyen bir içerik olabilir. İlk aşamada Makefile, paket kurulum betiği, yapılandırma dosyası veya otomatik çalıştırılan script içine komut eklemeyin.

Bu pull request çalıştırıldığında şu soruların cevaplarını ayrı ayrı kaydedin:

• Workflow hangi event ile başladı?
• Workflow dosyası hangi branch veya commit bağlamından yüklendi?
• actions/checkout hangi repository ve ref değerini kullandı?
• Checkout sonrasında çalışma alanındaki HEAD hangi commit’i gösteriyor?
• Fork’tan gelen kaynak kod hangi adımda okunuyor veya çalıştırılıyor?
• Koşullu olarak kapatılması gereken adımlar gerçekten atlandı mı?
• GITHUB_TOKEN beklenenden geniş bir yetkiye sahip mi?
• Secrets değerleri ilk testte gerçekten erişilemez durumda mı?

3. Checkout edilen commit’i açıkça doğrulayın

Güvenlik değişikliği sonrasında en kritik kontrollerden biri checkout edilen commit’in doğrulanmasıdır. Yalnızca checkout adımının başarılı olması yeterli değildir. Log içinde repository, branch, ref ve commit bilgilerini gözlemleyin; ardından çalışma alanındaki gerçek commit’i git rev-parse HEAD ile kontrol edin.

Aşağıdaki örnek, hassas değerleri yazdırmadan test bağlamını ve checkout edilen commit’i gözlemlemek için kullanılabilir:

name: Safe workflow inspection

on:
  pull_request:
  pull_request_target:

permissions:
  contents: read

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v7

      - name: Inspect context
        run: |
          echo "event=${{ github.event_name }}"
          echo "ref=${{ github.ref }}"
          echo "sha=${{ github.sha }}"
          echo "head=$(git rev-parse HEAD)"
          git status --short

Beklenen çıktı, event türüne göre yorumlanmalıdır. github.ref veya github.sha ile çalışma alanındaki HEAD aynı şeyi ifade etmek zorunda değildir; özellikle pull request bağlamlarında workflow kaynağı, temel repository ve checkout edilen kaynak farklı kavramlar olabilir. Testin amacı bu değerleri otomatik olarak eşitlemek değil, aralarındaki farkı fark etmektir.

Fork pull request’lerinden gelen kodu ayrıcalıklı bir event içinde checkout etmeye çalışan bazı yaygın kalıplar için actions/checkout güvenlik korumaları uygulanmaktadır. GitHub’ın duyurusuna göre bu koruma, fork pull request’inin head veya merge commit’ine yönelen belirli repository ve ref kullanımlarını hedefler; ancak run içinde git veya gh ile güvenilmeyen kodu çekmek gibi farklı yolları otomatik olarak kapsamaz. ([github.blog](https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/?utm_source=openai))

4. Event değişkenlerini ve koşullu adımları gözleyin

Workflow içinde if: koşulları varsa, test pull request’inin bu koşulları beklenen yönde tetiklediğinden emin olun. Örneğin yalnızca güvenilir branch’lerde çalışması gereken bir adımın fork pull request’inde çalışmaması gerekir. Benzer şekilde yalnızca push event’i için tasarlanmış bir dağıtım adımının pull request testinde devreye girmemesi beklenir.

Her koşul için önce mantıksal beklentiyi yazılı hâle getirin, sonra logu bu beklentiyle karşılaştırın:

• pull_request geldiğinde: test adımları çalışmalı, dağıtım adımları atlanmalıdır.
• Fork pull request’inde: secrets gerektiren adımlar varsayılan test akışında çalışmamalıdır.
• Güvenilmeyen kod checkout edilmiyorsa: kaynak kodu çalıştıran adımlar da buna göre sınırlandırılmalıdır.
• permissions: contents: read tanımlıysa: token’ın issue, pull request yazma veya release değiştirme yetkileri beklenmemelidir.

Bir adımın logda görünmemesi her zaman güvenli olduğu anlamına gelmez. Adım, koşul nedeniyle mi atlandı, job hiç çalışmadı mı, yoksa workflow başka bir yoldan aynı işi yaptı mı? Bu ayrımı job özeti, adım durumu ve workflow dosyasındaki koşulları birlikte okuyarak yapın.

5. Token izinlerini ve secrets davranışını sınayın

İlk testte amaç token’ın yapabildiği işlemleri genişletmek değil, kapsamını sınırlı tutup beklenen sınırda kaldığını göstermektir. Workflow seviyesinde yalnızca gerekli izni tanımlamak, tanımlanmayan izinlerin verilmemesini kolaylaştırır. GitHub Actions sözdizimine göre permissions içinde belirli izinleri açıkça tanımladığınızda, tanımlanmayan izinler none olarak değerlendirilir; ancak repository ve organizasyon varsayılanları da ayrıca hesaba katılmalıdır. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax?utm_source=openai))

Basit bir doğrulama senaryosunda token’ın değerini veya secrets içeriğini loglamayın. Bunun yerine hangi işlemin başarıyla veya başarısızlıkla sonuçlandığını gözlemleyin. Örneğin kaynak kodunu okumak için contents: read yeterli olabilir; issue kapatma, pull request’e etiket ekleme veya release oluşturma gibi işlemler için daha geniş izinler gerekiyorsa bunlar ilk testte devre dışı bırakılmalıdır.

pull_request_target bağlamında secrets ve temel repository token’ı kullanılabildiği için, fork’tan gelen kodu bu bağlamda çalıştırmak özel dikkat gerektirir. GitHub dokümantasyonu, bu event’in yüksek güven düzeyinde çalıştığını ve pull request kodu checkout edilmeden önce güvenlik modelinin ayrıca incelenmesi gerektiğini belirtir. ([docs.github.com](https://docs.github.com/en/enterprise-server%403.22/actions/reference/security/securely-using-pull_request_target?utm_source=openai))

6. Logları güvenlik kanıtı gibi değil, gözlem aracı gibi okuyun

Log incelemesinde şu noktaları arayın:

• Checkout adımında kullanılan repository ve ref bilgisi
• Gerçek çalışma alanı commit’i
• Çalıştırılan shell komutları ve script yolları
• Paket kurulumunun hangi dosyalara dayandığı
• Koşullu adımların “skipped” durumuna geçip geçmediği
• Beklenmeyen ağ bağlantıları veya uzak kaynak indirmeleri
• Token, secret veya ortam değişkenlerinin komutlara aktarılıp aktarılmadığı
• Artifact, cache veya çıktı dosyalarının güvenilmeyen koddan etkilenip etkilenmediği

Daha ayrıntılı teşhis gerektiğinde GitHub Actions’ın step debug veya runner diagnostic log seçenekleri kullanılabilir. Bu loglar daha fazla teknik ayrıntı sağlar; ancak ayrıntılı logun kendisi de hassas bilgilerin yanlışlıkla görünmemesi için dikkatle incelenmelidir. GitHub, debug loglamayı repository’deki ilgili ayar veya secret üzerinden etkinleştirir ve bu nedenle debug özelliğinin de erişim yetkileriyle birlikte değerlendirilmesini önerir. ([docs.github.com](https://docs.github.com/en/actions/how-tos/monitor-workflows/enable-debug-logging?utm_source=openai))

Beklenen ve şüpheli gözlemler

Bu tablo bir otomatik güvenlik garantisi değildir. Özellikle üçüncü taraf action’lar, paket kurulum script’leri, cache içerikleri ve shell komutları ayrıca incelenmelidir. Test sırasında zararlı bir davranış görülmemesi, bu davranışın başka bir commit’te veya farklı bir tetikleyicide ortaya çıkmayacağı anlamına gelmez.

Öğrenci projelerinde uygulanabilir son kontrol listesi

Workflow’u yayınlamadan veya merge etmeden önce aşağıdaki kısa karar akışını uygulayın. Her soruyu “evet” diye geçmek yerine, cevabın hangi dosya, event, commit veya izin tanımıyla kanıtlandığını gösterin.

1. Güvenilmeyen kod var mı? Fork’tan gelen kaynak, pull request içeriği, kullanıcı tarafından değiştirilebilen script, Makefile, paket yapılandırması veya uzaktan indirilen dosya varsa “incele” sonucuyla devam edin.
2. Checkout ref’i hangi commit’i gösteriyor? Ref, repository ve gerçek HEAD değeri doğrulanamıyorsa “durdur ve doğrula” sonucunu verin.
3. Kaynak kod çalıştıran adım var mı? npm install, pip install, make, test runner, build script veya benzeri bir adım güvenilmeyen kodu çalıştırıyorsa akışı ayrı ve düşük yetkili bir job’a “daha güvenli alternatife ayırın”.
4. permissions en az yetkide mi? Yalnızca okuma gereken bir job’da yazma izni bulunuyorsa “durdur ve doğrula” deyin.
5. Secrets gerçekten gerekli mi? Bir secret yalnızca kolaylık için kullanılıyorsa kaldırın. Fork pull request’i için gerekli olduğu iddia edilen secret, güven sınırı ayrıca kanıtlanmadan etkinleştirilmemelidir.
6. Tetikleyici doğru event ile sınırlı mı? Test, etiketleme veya doğrulama işi ile deploy, release ve yazma işlemlerini aynı ayrıcalıklı tetikleyicide birleştirmeyin. Gerekirse “daha güvenli alternatife ayırın”.
7. Koşullar logda doğrulandı mı? if: koşullarının gerçekten beklenen adımları atladığını gözlemlemeden “inceleme tamamlandı” demeyin.

Karar akışını pratikte nasıl kullanabilirsiniz?

Örneğin bir öğrenci projesindeki workflow fork pull request’ini test ediyor, repository içeriğini checkout ediyor, bağımlılık kuruyor ve test çalıştırıyorsa ilk soru “test başarılı mı?” olmamalıdır. Önce kodun hangi commit’ten geldiğini, bağımlılık kurulumunun hangi script’leri çalıştırdığını ve token’ın yalnızca okuma yetkisine sahip olup olmadığını kontrol edin. Bu üç noktadan biri belirsizse test sonucu başarılı görünse bile merge işlemini bekletmek daha doğru olur.

Temel Git, YAML ve yazılım workflow kavramlarındaki seviyenizi ölçmek isterseniz ücretsiz kodlama bilgisi testi başlangıç noktası olarak kullanılabilir. Bu test, güvenlik incelemesinin veya GitHub’ın resmî dokümantasyonunu okumanın yerine geçmez; yalnızca hangi temel konuları pekiştirmeniz gerektiğini görmenize yardımcı olur.

GitHub’ın güncel güvenlik önerileriyle uyumlu bir son kontrolde özellikle şu üçlü birlikte aranmalıdır: güvenilmeyen kodun ayrıcalıklı bağlamda çalıştırılmaması, GITHUB_TOKEN izinlerinin sınırlandırılması ve secrets erişiminin ihtiyaç yoksa kapalı tutulması. Fork workflow ayarlarında yazma token’ları veya secrets erişimi açılmışsa, repository yöneticisi bu tercihi ayrıca gözden geçirmelidir. ([docs.github.com](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository?apiVersion=2022-11-28&utm_source=openai))

• Güvenilmeyen kod bulunmuyorsa: İncele
• Checkout commit’i ve ref’i açıkça doğrulanamıyorsa: Durdur ve doğrula
• Kod çalıştırma ile ayrıcalıklı işlemler aynı job’daysa: Daha güvenli alternatife ayır
• Gereksiz yazma izni varsa: Durdur ve doğrula
• Secrets yalnızca opsiyonel bir işlem için kullanılıyorsa: İncele ve kaldırmayı değerlendir
• Event koşulu açık ve sınırlıysa: İncele

Sık Sorulan Sorular

pull_request_target kullanmak tek başına workflow’u güvenli hale getirir mi?

Hayır. pull_request_target, workflow’un temel repository bağlamında ve daha yüksek güven düzeyiyle çalışmasını sağlar; bu nedenle token ve secrets erişimi bakımından dikkat gerektirir. Fork’tan gelen kodu checkout edip çalıştırmak, bu yüksek güven bağlamını güvenilmeyen kaynak koduyla birleştirebilir. Event adı tek başına güvenlik garantisi değildir; checkout ref’i, çalıştırılan komutlar, koşullar, token izinleri ve secrets kullanımı birlikte incelenmelidir.

actions/checkout adımında ref değerini neden özellikle incelemeliyim?

Çünkü ref değeri workflow’un çalışma alanına hangi commit’in getirileceğini belirler. Bir ref fork pull request’inin head veya merge commit’ine yöneliyorsa, sonrasında çalışan test, build veya script adımları pull request sahibinin değiştirebildiği kodu çalıştırabilir. Bu nedenle github.sha, checkout sonrası git rev-parse HEAD, repository adı ve kullanılan ref birlikte kontrol edilmelidir.

Fork’tan gelen pull request’lerde secrets kullanmak neden risk oluşturabilir?

Fork pull request’i dışarıdan gelen ve güvenilmeyen kod içerebilir. Bu kod bir runner üzerinde çalışırken ortam değişkenlerine, komut satırına veya kullanılan araçların davranışına erişmeye çalışabilir. Secret değerlerinin loglarda maskelenmesi de tek başına tam bir güvenlik sınırı değildir. Bu yüzden fork pull request testlerinde secrets erişimi varsayılan olarak gerekli olmadıkça kullanılmamalı; gerekli bir işlem varsa ayrı bir güvenlik tasarımı, düşük yetki ve insan onayı değerlendirilmelidir.

GITHUB_TOKEN için permissions bloğunu nasıl en az yetkiyle yapılandırabilirim?

Önce workflow’un hangi GitHub işlemlerini yaptığını listeleyin. Sadece repository içeriğini okumak gerekiyorsa contents: read gibi dar bir izin tanımlayın. Yazma, issue, pull request, package, deployment veya security-events izinlerini ihtiyaç kanıtlanmadan eklemeyin. İzinleri workflow seviyesinde veya yalnızca ihtiyaç duyan job seviyesinde açıkça belirtmek, beklenmeyen varsayılan yetkileri fark etmeyi kolaylaştırır.

Workflow değişikliğini gerçek projeye uygulamadan önce nasıl düşük riskli test edebilirim?

Ayrı bir deneme repository’si veya düşük önem taşıyan bir fork kullanın. Zararsız bir pull request açın, ilk çalıştırmada secrets kullanmayın, token’ı yalnızca okuma izinleriyle sınırlandırın ve loglarda event, checkout ref’i, gerçek commit, koşullu adımlar ve çalıştırılan script’leri inceleyin. Testin başarılı olması yalnızca workflow’un o senaryoda hata vermediğini gösterir; güvenlik değerlendirmesi için beklenen ve şüpheli gözlemleri ayrıca karşılaştırmanız gerekir.

Güvenli bir Actions workflow’u tek bir ayarın sonucu değil, tetikleyici, checkout, çalıştırılan kod, token izinleri ve secrets kullanımının birlikte denetlenmesiyle ortaya çıkar.