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

# Basic Github Information

{{#include ../../banners/hacktricks-training.md}}

## Basic Structure

एक बड़े **कंपनी** का बुनियादी गिटहब वातावरण संरचना एक **उद्यम** है जो **कई संगठनों** का मालिक है और उनमें से प्रत्येक में **कई रिपॉजिटरी** और **कई टीमें** हो सकती हैं। छोटे कंपनियों के पास केवल **एक संगठन और कोई उद्यम** हो सकता है।

एक उपयोगकर्ता के दृष्टिकोण से, एक **उपयोगकर्ता** **विभिन्न उद्यमों और संगठनों** का **सदस्य** हो सकता है। उनके भीतर उपयोगकर्ता के पास **विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ** हो सकती हैं।

इसके अलावा, एक उपयोगकर्ता **विभिन्न टीमों** का **भाग** हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।

और अंत में, **रिपॉजिटरी में विशेष सुरक्षा तंत्र** हो सकते हैं।

## Privileges

### Enterprise Roles

- **Enterprise owner**: इस भूमिका वाले लोग **व्यवस्थापकों का प्रबंधन, उद्यम के भीतर संगठनों का प्रबंधन, उद्यम सेटिंग्स का प्रबंधन, संगठनों के बीच नीति लागू करने** में सक्षम होते हैं। हालाँकि, वे **संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते** जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
- **Enterprise members**: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी **स्वचालित रूप से उद्यम के सदस्य** होते हैं।

### Organization Roles

एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:

- **Organization owners**: संगठन के मालिकों के पास **आपके संगठन तक पूर्ण प्रशासनिक पहुँच** होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
- **Organization members**: **डिफ़ॉल्ट**, गैर-प्रशासनिक भूमिका **संगठन में लोगों** के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास **कई अनुमतियाँ** होती हैं।
- **Billing managers**: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो **आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन** कर सकते हैं, जैसे भुगतान जानकारी।
- **Security Managers**: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को **आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ** देता है।
- यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
- **Github App managers**: अतिरिक्त उपयोगकर्ताओं को **संगठन द्वारा स्वामित्व वाले GitHub Apps का प्रबंधन** करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub App प्रबंधक अनुमतियाँ दे सकता है।
- **Outside collaborators**: एक बाहरी सहयोगी वह व्यक्ति है जिसके पास **एक या अधिक संगठन रिपॉजिटरी तक पहुँच है लेकिन वह स्पष्ट रूप से संगठन का सदस्य नहीं है**।

आप इन भूमिकाओं के अनुमतियों की **तुलना** इस तालिका में कर सकते हैं: [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/\<org_name>/settings/member_privileges_ में आप देख सकते हैं कि **संगठन का हिस्सा होने के नाते उपयोगकर्ताओं के पास कौन सी अनुमतियाँ होंगी**।

यहाँ कॉन्फ़िगर की गई सेटिंग्स संगठन के सदस्यों की निम्नलिखित अनुमतियों को इंगित करेंगी:

- सभी संगठन रिपॉजिटरी पर व्यवस्थापक, लेखक, पाठक या कोई अनुमति नहीं होना।
- यदि सदस्यों को निजी, आंतरिक या सार्वजनिक रिपॉजिटरी बनाने की अनुमति है।
- यदि रिपॉजिटरी का फोर्क करना संभव है।
- यदि बाहरी सहयोगियों को आमंत्रित करना संभव है।
- यदि सार्वजनिक या निजी साइटों को प्रकाशित किया जा सकता है।
- रिपॉजिटरी पर व्यवस्थापकों के पास जो अनुमतियाँ हैं।
- यदि सदस्यों को नई टीमें बनाने की अनुमति है।

### Repository Roles

डिफ़ॉल्ट रूप से रिपॉजिटरी भूमिकाएँ बनाई जाती हैं:

- **Read**: **गैर-कोड योगदानकर्ताओं** के लिए अनुशंसित जो आपके प्रोजेक्ट को देखना या चर्चा करना चाहते हैं।
- **Triage**: **योगदानकर्ताओं के लिए अनुशंसित जिन्हें मुद्दों और पुल अनुरोधों का सक्रिय रूप से प्रबंधन करने** की आवश्यकता होती है बिना लिखने की पहुँच के।
- **Write**: योगदानकर्ताओं के लिए अनुशंसित जो **सक्रिय रूप से आपके प्रोजेक्ट में योगदान करते हैं**।
- **Maintain**: **प्रोजेक्ट प्रबंधकों के लिए अनुशंसित जिन्हें रिपॉजिटरी का प्रबंधन करने** की आवश्यकता होती है बिना संवेदनशील या विनाशकारी कार्यों की पहुँच के।
- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें **प्रोजेक्ट तक पूर्ण पहुँच** की आवश्यकता होती है, जिसमें सुरक्षा प्रबंधन या रिपॉजिटरी को हटाने जैसे संवेदनशील और विनाशकारी कार्य शामिल हैं।

आप इस तालिका में प्रत्येक भूमिका के अनुमतियों की **तुलना** कर सकते हैं [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/\<org_name>/settings/roles_ में अपनी स्वयं की भूमिकाएँ भी **बना सकते हैं**।

### Teams

आप _https://github.com/organizations/\<org_name>/teams_ में **एक संगठन में बनाई गई टीमों की सूची** देख सकते हैं। ध्यान दें कि अन्य टीमों के बच्चों को देखने के लिए आपको प्रत्येक माता-पिता टीम तक पहुँचने की आवश्यकता है।

### Users

एक संगठन के उपयोगकर्ताओं को _https://github.com/orgs/\<org_name>/people_ में **सूचीबद्ध** किया जा सकता है।

प्रत्येक उपयोगकर्ता की जानकारी में आप देख सकते हैं कि **उपयोगकर्ता किस टीम का सदस्य है**, और **उपयोगकर्ता को किन रिपॉजिटरी तक पहुँच है**।

## Github Authentication

Github आपके खाते में प्रमाणित होने और आपके पक्ष में कार्य करने के लिए विभिन्न तरीके प्रदान करता है।

### Web Access

**github.com** पर पहुँचते समय आप अपने **उपयोगकर्ता नाम और पासवर्ड** (और संभावित रूप से **2FA**) का उपयोग करके लॉगिन कर सकते हैं।

### **SSH Keys**

आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित **निजी कुंजी आपके पक्ष में कार्य करने की अनुमति देती है।** [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) के बारे में अधिक जानें।

### **Personal Access Tokens**

आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि **एक एप्लिकेशन को आपके खाते तक पहुँच** मिल सके। व्यक्तिगत पहुँच टोकन बनाते समय, **उपयोगकर्ता** को **अनुमतियाँ** निर्दिष्ट करने की आवश्यकता होती है जो **टोकन** के पास होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Oauth Applications

Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं **आपकी गिटहब जानकारी के एक भाग तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए कुछ कार्य करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण **गिटहब के साथ लॉगिन बटन** है जो आप कुछ प्लेटफार्मों पर पा सकते हैं।

- आप [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/\<org_name>/settings/oauth_application_policy_ में एक **संगठन** में एप्लिकेशनों की तीसरी पार्टी पहुँच देख सकते हैं।

कुछ **सुरक्षा सिफारिशें**:

- एक **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) में।

### Github Applications

Github एप्लिकेशन अनुमतियाँ मांग सकते हैं ताकि **आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए विशिष्ट कार्यों को विशिष्ट संसाधनों पर किया जा सके। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक एप्लिकेशन की पहुँच होगी।

- 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/\<org_name>/settings/installations_ में एक **संगठन** में स्थापित एप्लिकेशन देख सकते हैं।

कुछ सुरक्षा सिफारिशें:

- एक 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 Actions

यह **गिटहब में प्रमाणित होने का एक तरीका नहीं है**, लेकिन एक **दुर्भावनापूर्ण** GitHub Action **गिटहब तक अनधिकृत पहुँच प्राप्त कर सकता है** और **अनुमतियों** के आधार पर जो Action को दी गई हैं, कई **विभिन्न हमले** किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।

## Git Actions

Git actions को **जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित** करने की अनुमति देता है। आमतौर पर निष्पादित कोड **रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है** (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।

### Configuration

_https://github.com/organizations/\<org_name>/settings/actions_ में आप संगठन के लिए **गिटहब क्रियाओं की कॉन्फ़िगरेशन** की जांच कर सकते हैं।

गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करना, **सभी गिटहब क्रियाओं की अनुमति देना**, या केवल कुछ क्रियाओं की अनुमति देना संभव है।

यह भी संभव है कि **किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है** और जब GitHub Action चलाया जाता है तो **GITHUB_TOKEN** की अनुमतियाँ कॉन्फ़िगर की जा सकें।

### Git Secrets

Github Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। **उन्हें स्पष्ट पाठ में रखने से बचने के लिए**, गिटहब उन्हें **Secrets** के रूप में रखने की अनुमति देता है।

ये रहस्य **रिपॉजिटरी या सभी संगठन** के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, **Action को रहस्य तक पहुँच प्राप्त करने के लिए** आपको इसे इस तरह घोषित करना होगा:
```yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
```
#### Bash का उपयोग करते हुए उदाहरण <a href="#example-using-bash" id="example-using-bash"></a>
```yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
> Secrets **केवल उन Github Actions से एक्सेस किए जा सकते हैं** जिनमें उन्हें घोषित किया गया है।

> एक बार जब उन्हें रिपॉजिटरी या संगठनों में कॉन्फ़िगर किया जाता है, तो **github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे**, वे केवल **उन्हें बदलने** में सक्षम होंगे।

इसलिए, **github secrets चुराने का एकमात्र तरीका है उस मशीन तक पहुंच प्राप्त करना जो Github Action को निष्पादित कर रही है** (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुंच प्राप्त कर पाएंगे)।

### Git Environments

Github **पर्यावरण** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप कुछ इस तरह से वातावरण के अंदर secrets तक github action को एक्सेस देने के लिए कह सकते हैं:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
```
आप एक वातावरण को **सभी शाखाओं** (डिफ़ॉल्ट), **केवल संरक्षित** शाखाओं या **निर्धारित** करने के लिए कॉन्फ़िगर कर सकते हैं कि कौन सी शाखाएँ इसे एक्सेस कर सकती हैं।\
यह एक **क्रिया** को **निष्पादित** करने से पहले **आवश्यक समीक्षाओं की संख्या** भी सेट कर सकता है या **तैनाती** को आगे बढ़ाने से पहले कुछ **समय** तक **रुक** सकता है।

### Git Action Runner

एक Github Action को **github वातावरण के अंदर निष्पादित** किया जा सकता है या इसे उपयोगकर्ता द्वारा कॉन्फ़िगर की गई **तीसरी पार्टी अवसंरचना** में निष्पादित किया जा सकता है।

कई संगठन Github Actions को **तीसरी पार्टी अवसंरचना** में चलाने की अनुमति देंगे क्योंकि यह आमतौर पर **सस्ता** होता है।

आप _https://github.com/organizations/\<org_name>/settings/actions/runners_ में एक संगठन के **स्व-होस्टेड रनर्स** की सूची देख सकते हैं।

यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में `runs-on: self-hosted` के लिए खोजें।

यह **संभव नहीं है कि एक संगठन का Github Action एक अलग संगठन के स्व-होस्टेड बॉक्स के अंदर चलाया जाए** क्योंकि **रनर के लिए एक अद्वितीय टोकन उत्पन्न होता है** जब इसे कॉन्फ़िगर किया जाता है ताकि यह पता चल सके कि रनर किसका है।

यदि कस्टम **Github Runner को AWS या GCP के अंदर एक मशीन में कॉन्फ़िगर किया गया है** उदाहरण के लिए, तो Action **मेटाडेटा एंडपॉइंट तक पहुँच** प्राप्त कर सकता है और **सेवा खाते के टोकन को चुरा सकता है** जिसके साथ मशीन चल रही है।

### Git Action Compromise

यदि सभी क्रियाएँ (या एक दुर्भावनापूर्ण क्रिया) की अनुमति है, तो एक उपयोगकर्ता एक **Github action** का उपयोग कर सकता है जो **दुर्भावनापूर्ण** है और **कंटेनर** को **समझौता** करेगा जहाँ इसे निष्पादित किया जा रहा है।

> [!CAUTION]
> एक **दुर्भावनापूर्ण Github Action** चलाया जा सकता है जिसे हमलावर द्वारा **दुरुपयोग** किया जा सकता है:
>
> - **सभी रहस्यों को चुराना** जिन तक Action की पहुँच है
> - यदि Action को **तीसरी पार्टी अवसंरचना** के अंदर निष्पादित किया जाता है तो **पार्श्व में स्थानांतरित करना** जहाँ SA टोकन का उपयोग मशीन को चलाने के लिए किया जा सकता है (संभवतः मेटाडेटा सेवा के माध्यम से)
> - **टोकन का दुरुपयोग** करना जिसका उपयोग **कार्यप्रवाह** द्वारा **कोड को चुराने** के लिए किया जाता है जहाँ Action निष्पादित होता है या **यहाँ तक कि इसे संशोधित करना**।

## Branch Protections

शाखा सुरक्षा को **एक भंडार का पूर्ण नियंत्रण** उपयोगकर्ताओं को न देने के लिए डिज़ाइन किया गया है। लक्ष्य यह है कि **कुछ शाखा के अंदर कोड लिखने से पहले कई सुरक्षा विधियाँ लगाई जाएँ**।

**एक भंडार की शाखा सुरक्षा** को _https://github.com/\<orgname>/\<reponame>/settings/branches_ में पाया जा सकता है।

> [!NOTE]
> यह **संभव नहीं है कि संगठन स्तर पर शाखा सुरक्षा सेट की जाए**। इसलिए सभी को प्रत्येक भंडार पर घोषित किया जाना चाहिए।

एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):

- आप **मर्ज करने से पहले एक PR की आवश्यकता** कर सकते हैं (इसलिए आप सीधे शाखा पर कोड मर्ज नहीं कर सकते)। यदि यह चयनित है तो विभिन्न अन्य सुरक्षा लागू की जा सकती हैं:
- **अनुमोदनों की संख्या की आवश्यकता**। यह बहुत सामान्य है कि 1 या 2 और लोगों को आपके PR को अनुमोदित करने की आवश्यकता होती है ताकि एकल उपयोगकर्ता सीधे कोड मर्ज करने में सक्षम न हो।
- **नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें**। यदि नहीं, तो एक उपयोगकर्ता वैध कोड को अनुमोदित कर सकता है और फिर उपयोगकर्ता दुर्भावनापूर्ण कोड जोड़ सकता है और इसे मर्ज कर सकता है।
- **कोड मालिकों से समीक्षाओं की आवश्यकता**। भंडार के कम से कम 1 कोड मालिक को PR को अनुमोदित करने की आवश्यकता है (ताकि "यादृच्छिक" उपयोगकर्ता इसे अनुमोदित न कर सकें)
- **पुल अनुरोध समीक्षाओं को अस्वीकार करने के लिए किसे प्रतिबंधित करें।** आप उन लोगों या टीमों को निर्दिष्ट कर सकते हैं जिन्हें पुल अनुरोध समीक्षाओं को अस्वीकार करने की अनुमति है।
- **निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें**। ये उपयोगकर्ता पिछले प्रतिबंधों को बायपास करने में सक्षम होंगे।
- **मर्ज करने से पहले स्थिति जांचों को पास करने की आवश्यकता।** कुछ जांचों को कमिट को मर्ज करने से पहले पास करना आवश्यक है (जैसे एक github action यह जांचता है कि कोई स्पष्ट रहस्य नहीं है)।
- **मर्ज करने से पहले बातचीत के समाधान की आवश्यकता**। कोड पर सभी टिप्पणियों को PR को मर्ज करने से पहले हल किया जाना चाहिए।
- **हस्ताक्षरित कमिट्स की आवश्यकता**। कमिट्स को हस्ताक्षरित होना चाहिए।
- **रेखीय इतिहास की आवश्यकता।** मेल खाने वाली शाखाओं में मर्ज कमिट्स को धकेलने से रोकें।
- **व्यवस्थापकों को शामिल करें**। यदि यह सेट नहीं है, तो व्यवस्थापक प्रतिबंधों को बायपास कर सकते हैं।
- **मेल खाने वाली शाखाओं पर धकेलने के लिए किसे प्रतिबंधित करें**। यह निर्धारित करें कि कौन PR भेज सकता है।

> [!NOTE]
> जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, **भंडार सुरक्षा कर सकते हैं जिससे आप उदाहरण के लिए मास्टर पर कोड धकेलने से रोक सकते हैं** ताकि CI/CD पाइपलाइन को समझौता न किया जा सके।

## References

- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
- [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)

{{#include ../../banners/hacktricks-training.md}}