Translated ['', 'src/pentesting-cloud/azure-security/az-post-exploitatio

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

@@ -4,80 +4,80 @@
 
 ## बुनियादी संरचना
 
-एक बड़ी **कंपनी** के github पर्यावरण की बुनियादी संरचना यह होती है कि वह एक **enterprise** की मालिक होती है जो कई **organizations** की मालिक होती है और प्रत्येक में **कई repositories** और **कई teams** हो सकते हैं। छोटी कंपनियाँ सिर्फ़ **एक organization की मालिक और कोई enterprise नहीं** भी हो सकती हैं।
+एक बड़े **company** के लिए बुनियादी github वातावरण की संरचना यह है कि उसके पास एक **enterprise** होता है जो कई **organizations** का मालिक होता है और हर एक में कई **repositories** और कई **teams** हो सकते हैं। छोटी कंपनियों के पास केवल **एक organization और कोई enterprise नहीं** भी हो सकता है।
 
-यूज़र की नज़र से एक **user** विभिन्न **enterprises और organizations** का **member** हो सकता है। इनके भीतर उपयोगकर्ता के पास अलग-अलग **enterprise, organization और repository roles** हो सकते हैं।
+किसी user के दृष्टिकोण से एक **user** अलग-अलग **enterprises और organizations** का **member** हो सकता है। इनके भीतर user के पास **विभिन्न enterprise, organization और repository रोल्स** हो सकते हैं।
 
-इसके अलावा, एक उपयोगकर्ता अलग-अलग टीमों का **part** हो सकता है जिनमें अलग-अलग enterprise, organization या repository roles हो सकते हैं।
+इसके अलावा, एक user अलग-अलग **teams** का हिस्सा हो सकता है जिनमें अलग-अलग enterprise, organization या repository रोल्स होते हैं।
 
-और अंततः **repositories में विशेष protection mechanisms हो सकते हैं।**
+और अंत में **repositories में विशेष protection mechanisms हो सकते हैं।**
 
 ## Privileges
 
 ### Enterprise Roles
 
-- **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** होते हैं।
+- **Enterprise owner**: इस रोल वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं।** हालांकि, वे **organization settings या content तक पहुँच नहीं बना सकते** जब तक उन्हें organization owner बनाया न गया हो या सीधे organization-owned repository का access न दिया गया हो।
+- **Enterprise members**: आपके enterprise द्वारा owned organizations के members स्वचालित रूप से **enterprise के members** भी होते हैं।
 
 ### Organization Roles
 
-एक organisation में users के अलग-अलग roles हो सकते हैं:
+एक organisation में users के अलग-अलग रोल हो सकते हैं:
 
-- **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 नहीं है**।
+- **Organization owners**: Organization owners के पास **आपकी organization पर पूर्ण administrative access** होता है। यह रोल सीमित रखा जाना चाहिए, लेकिन आपकी organization में कम से कम दो लोगों से कम नहीं होना चाहिए।
+- **Organization members**: organization में लोगों के लिए डिफ़ॉल्ट, non-administrative रोल organization member है। डिफ़ॉल्ट के रूप में, organization members **कई permissions** रखते हैं।
+- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के billing settings, जैसे payment information, **manage कर सकते हैं**।
+- **Security Managers**: यह एक रोल है जिसे organization owners किसी भी टीम को दे सकते हैं। लागू होने पर, यह टीम के हर सदस्य को **organization भर में security alerts और settings manage करने की permissions देता है, साथ ही organization के सभी repositories के लिए read permissions** देता है।
+- यदि आपकी organization में एक security team है, तो आप security manager रोल का उपयोग टीम के सदस्यों को organization तक न्यूनतम आवश्यक access देने के लिए कर सकते हैं।
+- **Github App managers**: किसी organization द्वारा owned GitHub Apps को अतिरिक्त users को **manage करने के लिए** अनुमति देने के लिए, एक owner उन्हें GitHub App manager permissions दे सकता है।
+- **Outside collaborators**: Outside collaborator वह व्यक्ति होता है जिसे **एक या अधिक organization repositories तक पहुँचन है पर वह organization का स्पष्ट रूप से member नहीं है।**
 
-आप इन 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)
+आप इन रोल्स की 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
 
-_in_ https://github.com/organizations/\<org_name>/settings/member_privileges आप देख सकते हैं कि **organisation का भाग होने के नाते users को किन permissions का अधिकार मिलेगा**।
+_in_ https://github.com/organizations/\<org_name>/settings/member_privileges आप देख सकते हैं कि **organization का हिस्सा होने के नाते users को कौन-कौन सी permissions मिलेंगी**।
 
-यहाँ जो settings configure की गई हैं वे organization के सदस्यों के निम्नलिखित permissions को निर्दिष्ट करेंगी:
+यहाँ configured settings organization के members की निम्नलिखित permissions को संकेत करेंगी:
 
-- सभी organization repos पर admin, writer, reader या कोई permission नहीं होना।
+- organization के सभी repos पर admin, writer, reader या कोई permission नहीं होना।
 - क्या members private, internal या public repositories बना सकते हैं।
 - क्या repositories का forking संभव है।
 - क्या outside collaborators को invite करना संभव है।
-- क्या public या private sites publish किए जा सकते हैं।
-- repositories पर admins के permissions।
+- क्या public या private sites publish की जा सकती हैं।
+- repositories पर admins के पास क्या permissions हैं।
 - क्या members नई teams बना सकते हैं।
 
 ### Repository Roles
 
-डिफ़ॉल्ट रूप से repository roles बनाए जाते हैं:
+डिफ़ॉल्ट रूप से repository रोल्स बनाये जाते हैं:
 
-- **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 करना शामिल हैं।
+- **Read**: उन **non-code contributors** के लिए अनुशंसित जो आपका प्रोजेक्ट देखना या उस पर चर्चा करना चाहते हैं।
+- **Triage**: उन contributors के लिए अनुशंसित जो issues और pull requests को proactively manage करने की ज़रूरत रखते हैं बिना write access के।
+- **Write**: उन contributors के लिए अनुशंसित जो **actively आपके प्रोजेक्ट में push करते हैं**।
+- **Maintain**: उन project managers के लिए अनुशंसित जो repository को manage करने की ज़रूरत रखते हैं बिना संवेदनशील या destructive क्रियाओं के access के।
+- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट पर **पूर्ण access** चाहिए, जिसमें security manage करना या repository delete करना जैसी संवेदनशील और destructive क्रियाएँ शामिल हैं।
 
-आप प्रत्येक 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)
+आप प्रत्येक रोल की 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)
 
-आप अपने खुद के roles भी _https://github.com/organizations/\<org_name>/settings/roles_ में बना सकते हैं।
+आप अपने खुद के roles भी बना सकते हैं _https://github.com/organizations/\<org_name>/settings/roles_
 
 ### Teams
 
-आप किसी organization में बनाए गए teams की **सूची** _https://github.com/orgs/\<org_name>/teams_ में देख सकते हैं। ध्यान दें कि किसी parent team के children teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
+आप किसी organization में बनाए गए teams की सूची _https://github.com/orgs/\<org_name>/teams_ पर देख सकते हैं। ध्यान दें कि किसी team के child teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
 
 ### Users
 
-Organization के users को **list** किया जा सकता है _https://github.com/orgs/\<org_name>/people_ में।
+Organization के users _https://github.com/orgs/\<org_name>/people_ में **listed** हो सकते हैं।
 
-प्रत्येक user की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किन **teams का सदस्य** है, और किन **repos तक उपयोगकर्ता की पहुँच** है।
+प्रत्येक user की जानकारी में आप देख सकते हैं कि user किस **teams** का member है, और user को कौन-कौन से **repos** का access है।
 
 ## Github Authentication
 
-Github आपके account में authenticate करने और आपकी ओर से actions perform करने के लिए विभिन्न तरीके प्रदान करता है।
+Github आपके account में authenticate करने और आपकी ओर से actions perform करने के विभिन्न तरीके ऑफर करता है।
 
 ### Web Access
 
-**github.com** पर पहुँचकर आप अपने **username और password** (और संभवतः **2FA**) का उपयोग करके login कर सकते हैं।
+**github.com** तक पहुँच कर आप अपने **username और password** (और संभावित रूप से **2FA**) का उपयोग करके login कर सकते हैं।
 
 ### **SSH Keys**
 
@@ -85,72 +85,71 @@ Github आपके account में authenticate करने और आपक
 
 #### **GPG Keys**
 
-आप इन 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) के बारे में और जानें।
+आप इन keys से user का impersonate नहीं कर सकते लेकिन अगर आप इसे उपयोग नहीं करते हैं तो ऐसा हो सकता है कि आप **commits बिना signature के भेजने पर पता चल जाएं**। इसके बारे में और जानने के लिए [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) देखें।
 
 ### **Personal Access Tokens**
 
-आप एक application को आपके account तक access देने के लिए personal access token generate कर सकते हैं। Personal access token बनाते समय **user** को यह **निर्दिष्ट** करना होता है कि token के पास कौन-कौन सी **permissions** होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
+आप personal access token generate कर सकते हैं ताकि कोई application **आपके account तक access पा सके**। Personal access token बनाते समय **user** को यह **निर्धारित** करना होता है कि token को कौन-कौन से **permissions** मिलेंगे। [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए** ताकि कुछ actions perform किए जा सकें। इस functionality का सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms पर पा सकते हैं।
+Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने के लिए या आपकी नकल कर कुछ actions करने के लिए**। इसका एक सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms में देख सकते हैं।
 
-- आप अपने खुद के **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/\<org_name>/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/\<org_name>/settings/oauth_application_policy_ पर देख सकते हैं।
 
 कुछ **security recommendations**:
 
-- एक **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).
+- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub पर काम करना चाहिए** (उदा., user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
+- OAuth App को authenticated user के लिए "Login with GitHub" को सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
+- **Don't** एक **OAuth App** बनाएं यदि आप चाहते हैं कि आपका application केवल **single repository** पर काम करे। `repo` OAuth scope के साथ, OAuth Apps authenticated user के सभी repositories पर काम कर सकते हैं।
+- **Don't** OAuth App बनाएं जो आपकी **team या company** के लिए application के रूप में काम करे। OAuth Apps एक single user के रूप में authenticate करते हैं, इसलिए अगर किसी व्यक्ति ने company के लिए OAuth App बनाया और फिर वह व्यक्ति कंपनी छोड़ देता है, तो किसी और के पास उसका access नहीं रहेगा।
+- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) देखें।
 
 ### Github Applications
 
-Github applications आपकी github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए permissions माँग सकती हैं ताकि वे specific resources पर specific actions कर सकें। Github Apps में आपको यह निर्दिष्ट करना होता है कि app किन repositories तक access रखेगा।
+Github applications permissions माँग सकते हैं ताकि वे **आपकी github जानकारी तक पहुँच सकें या आपकी नकल करके** specific resources पर कुछ actions कर सकें। Github Apps में आपको यह specify करना होता है कि app किन repositories तक access रखेगा।
 
-- किसी 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/\<org_name>/settings/installations_ में देख सकते हैं।
+- GitHub App install करने के लिए, आपको **organisation owner होना चाहिए या किसी repository में admin permissions** होने चाहिए।
+- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
+- आप अपना 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/\<org_name>/settings/installations_ पर देख सकते हैं।
 
 कुछ security recommendations:
 
-- एक 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 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 के लिए exchange किया जा सके। अधिक जानकारी के लिए देखें "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- सुनिश्चित करें कि GitHub App **विशिष्ट repositories** के साथ integrate हो।
+- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
+- 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) का उपयोग करके users को login करवा सकता है _और_ अन्य चीजें भी कर सकता है।
+- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files modify करना चाहते हैं, तो आपको 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** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) देखें।
 
 ### Github Actions
 
-यह **github में authenticate करने का तरीका नहीं है**, पर एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दिए गए **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी देखें।
+यह **github में authenticate करने का तरीका नहीं है**, लेकिन एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दी गई **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी दी गई है।
 
 ## Git Actions
 
-Git actions आपको अनुमति देता है कि जब कोई event होता है तो **कोड के execution को automate किया जाए**। आमतौर पर executed कोड **repository के कोड से somehow संबंधित** होता है (शायद docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
+Git actions यह अनुमति देता है कि जब कोई event हो तो **कोड के execution को automate किया जाए**। आम तौर पर execute किया जाने वाला कोड **रिपॉजिटरी के कोड से संबंधित** होता है (जैसे docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
 
 ### Configuration
 
-_in_ https://github.com/organizations/\<org_name>/settings/actions_ आप organization के लिए **github actions की configuration** देख सकते हैं।
+_in_ https://github.com/organizations/\<org_name>/settings/actions_ में आप organization के लिए **github actions की configuration** देख सकते हैं।
 
-आप github actions के उपयोग को पूरी तरह disallow कर सकते हैं, **सभी github actions allow कर सकते हैं**, या केवल कुछ specific actions को ही allow कर सकते हैं।
+आप github actions का उपयोग पूरी तरह से disallow कर सकते हैं, **सभी github actions की अनुमति दे सकते हैं**, या केवल कुछ select actions की अनुमति दे सकते हैं।
 
-यह भी संभव है कि यह configure किया जा सके कि **किसे Github Action चलाने के लिए approval की आवश्यकता है** और Github Action के चलने पर GITHUB_TOKEN की **permissions** क्या होंगी।
+यहाँ यह भी configure करना संभव है कि **किसे Github Action चलाने के लिए approval चाहिए** और Github Action के run होने पर उस Action के **GITHUB_TOKEN की permissions** क्या होंगी।
 
 ### Git Secrets
 
-Github Action को आमतौर पर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचने के लिए, github उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
+Github Action अक्सर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचाने के लिए, github इन्हें **Secrets** के रूप में रखने की अनुमति देता है।
 
-ये secrets **repo के लिए या पूरे organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके** आपको इसे इस तरह declare करना होगा:
+ये secrets **repo के लिए या पूरी organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके**, आपको इसे इस प्रकार declare करना होगा:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,15 +167,15 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें उन्हें declared किया गया हो।
+> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें वे declare किए गए हों।
 
-> एक बार repo या organizations में configure करने के बाद **github के users उन्हें फिर कभी एक्सेस नहीं कर पाएँगे**, वे सिर्फ़ उन्हें **बदल सकते हैं**।
+> एक बार repo या organizations में configure होने के बाद **users of github फिर उन्हें access नहीं कर पाएँगे**, वे केवल उन्हें **change** कर सकेंगे।
 
-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).
+इसलिए, **github secrets चोरी करने का एकमात्र तरीका यह है कि आप उस मशीन तक पहुँच सकें जो Github Action चला रही है** (ऐसी स्थिति में आप केवल उन secrets तक ही पहुँच पाएँगे जो उस Action के लिए declare किए गए हैं)।
 
 ### Git Environments
 
-Github आपको **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप किसी environment के अंदर के secrets तक github action को access दे सकते हैं, उदाहरण के लिए:
+Github आपको ऐसे **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सेव कर सकते हैं। फिर, आप github action को उस environment के अंदर के secrets तक access देने के लिए कुछ ऐसा दे सकते हैं:
 ```yaml
 jobs:
 deployment:
@@ -215,43 +214,43 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
 > - **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 के अंदर कोड लिखने से पहले कई सुरक्षा उपाय लागू हों।
+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**.
 
-किसी repository की **branch protections** इस लिंक पर मिल सकती हैं: _https://github.com/\<orgname>/\<reponame>/settings/branches_
+The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> यह **संभव नहीं है कि branch protection organization स्तर पर सेट किया जाए**। इसलिए इन्हें हर repo पर अलग से घोषित करना होगा।
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-एक branch (जैसे master) पर अलग‑अलग protections लागू किए जा सकते हैं:
+Different protections can be applied to a branch (like to master):
 
-- आप **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 भेज सकता है।
+- 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]
-> जैसा कि आप देख सकते हैं, भले ही आप किसी user के credentials हासिल कर लें, **repos protected हो सकते हैं जिससे आप master पर कोड push कर के CI/CD pipeline को compromise नहीं कर पाएँगे**।
+> 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.
 
 ## Tag Protections
 
-Tags (जैसे latest, stable) default रूप से mutable होते हैं। Tag updates पर four‑eyes flow लागू करने के लिए tags को protect करें और protections को environments और branches के माध्यम से chain करें:
+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) 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** को सक्षम करें।
+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**.
 
-यह chain किसी single collaborator को retag या force‑publish release करने से रोकती है सिर्फ workflow YAML edit करके, क्योंकि deployment gates workflows के बाहर enforce होते हैं।
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
 
 ## References