# Basiese Github Inligting

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

## Basiese Struktuur

Die basiese Github-omgewingstruktuur van 'n groot **company** is om 'n **enterprise** te besit wat **verskeie organizations** besit en elk van hulle kan **verskeie repositories** en **verskeie teams** bevat. Kleinere maatskappye besit moontlik net **een organization en geen enterprises** nie.

Vanuit 'n gebruiker se oogpunt kan 'n **gebruiker** 'n **lid** van **verskillende enterprises en organizations** wees. Binne hulle kan die gebruiker **verskillende enterprise-, organization- en repository-rolle** hê.

Boonop kan 'n gebruiker **deel wees van verskillende teams** met verskillende enterprise-, organization- of repository-rolle.

En uiteindelik kan **repositories spesiale beskermingsmeganismes hê**.

## Privileges

### Enterprise Roles

- **Enterprise owner**: Mense met hierdie rol kan **administrateurs bestuur, organizations binne die enterprise bestuur, enterprise-instellings bestuur, beleid oor organizations afdwing**. Hulle **kan egter nie toegang hê tot organization-instellings of inhoud** tensy hulle 'n organization owner gemaak word of direkte toegang tot 'n deur 'n organization besit repo gegee word.
- **Enterprise members**: Lede van organizations wat deur jou enterprise besit word, is ook **outomaties lede van die enterprise**.

### Organization Roles

In 'n organization kan gebruikers verskillende rolle hê:

- **Organization owners**: Organization owners het **volledige administratiewe toegang tot jou organization**. Hierdie rol moet beperk word, maar aan nie minder as twee mense in jou organization gegee word nie.
- **Organization members**: Die **standaard**, nie-administratiewe rol vir **mense in 'n organization** is die organization member. Standaard het organization members **'n aantal toestemmings**.
- **Billing managers**: Billing managers is gebruikers wat die **billing-instellings vir jou organization kan bestuur**, soos betalingsinligting.
- **Security Managers**: Dit is 'n rol wat organization owners aan enige span in 'n organization kan toeken. Wanneer toegepas, gee dit elke lid van die span toestemming om **security alerts en instellings oor jou organization te bestuur, sowel as lees-toestemmings vir alle repositories** in die organization.
- As jou organization 'n security span het, kan jy die security manager-rol gebruik om lede van die span die minste toegang te gee wat hulle nodig het tot die organization.
- **Github App managers**: Om addisionele gebruikers te laat **manage GitHub Apps owned by an organization**, kan 'n owner hulle GitHub App manager-permissies gee.
- **Outside collaborators**: 'n Outside collaborator is 'n persoon wat **toegang het tot een of meer organization repositories maar nie uitdruklik 'n lid** van die organization is nie.

Jy kan **die toestemmings** van hierdie rolle **vergelyk** in hierdie tabel: [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_ kan jy die **toestemmings sien wat gebruikers sal hê net omdat hulle deel is van die organization**.

Die instellings wat hier gekonfigureer word, dui die volgende toestemmings van lede van die organization aan:

- Om admin, writer, reader of geen toestemming oor al die organization repos te wees.
- Of lede private, internal of public repositories kan skep.
- Of forking van repositories moontlik is.
- Of dit moontlik is om outside collaborators uit te nooi.
- Of public of private sites gepubliseer kan word.
- Die toestemmings wat admins oor die repositories het.
- Of lede nuwe teams kan skep.

### Repository Roles

By verstek word repository-rolle geskep:

- **Read**: Aanbeveel vir **non-code contributors** wat jou projek wil sien of bespreek.
- **Triage**: Aanbeveel vir **contributors wat issues en pull requests proaktief moet bestuur** sonder write-toegang.
- **Write**: Aanbeveel vir contributors wat **aktief na jou projek push**.
- **Maintain**: Aanbeveel vir **projekbestuurders wat die repository moet bestuur** sonder toegang tot sensitiewe of vernietigende aksies.
- **Admin**: Aanbeveel vir mense wat **volle toegang tot die projek benodig**, insluitend sensitiewe en vernietigende aksies soos security bestuur of 'n repository verwyder.

Jy kan **die toestemmings** van elke rol **vergelyk** in hierdie tabel [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)

Jy kan ook **jou eie rolle skep** in _https://github.com/organizations/\<org_name>/settings/roles_

### Teams

Jy kan **die teams wat in 'n organization geskep is lys** in _https://github.com/orgs/\<org_name>/teams_. Let wel, om die teams te sien wat kinders van ander teams is, moet jy elke ouer-span toegaan.

### Users

Die gebruikers van 'n organization kan **gelys** word in _https://github.com/orgs/\<org_name>/people._

In die inligting van elke gebruiker kan jy die **teams sien waarvan die gebruiker lid is**, en die **repos waartoe die gebruiker toegang het**.

## Github Authentication

Github bied verskillende maniere om by jou rekening aan te meld en aksies namens jou uit te voer.

### Web Access

Toegang tot **github.com** kan jy aanmeld met jou **username and password** (en moontlik 'n **2FA**).

### **SSH Keys**

Jy kan jou rekening met een of verskeie public keys konfigureer wat die verwante **private key to perform actions on your behalf** toelaat. [https://github.com/settings/keys](https://github.com/settings/keys)

#### **GPG Keys**

Jy **kan nie die gebruiker met hierdie keys imiteer nie**, maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word omdat jy commits sonder 'n handtekening stuur**. Leer meer oor [vigilant mode hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).

### **Personal Access Tokens**

Jy kan personal access tokens genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer jy 'n personal access token skep, moet die **gebruiker** die **toestemmings** wat die **token** sal hê **spesifiseer**. [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Oauth Applications

Oauth applications mag jou vra vir toestemmings **om deel van jou github-inligting te bekom of om jou te impersonate** om sekere aksies uit te voer. 'n Algemene voorbeeld hiervan is die **login with github knop** wat jy op sekere platforms kan sien.

- Jy kan **jou eie Oauth applications skep** in [https://github.com/settings/developers](https://github.com/settings/developers)
- Jy kan al die **Oauth applications wat toegang tot jou rekening het** sien in [https://github.com/settings/applications](https://github.com/settings/applications)
- Jy kan die **scopes wat Oauth Apps kan vra** sien in [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)
- Jy kan derdeparty-toegang van toepassings in 'n **organization** sien in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_

Sommige **security-aanbevelings**:

- 'n **OAuth App** moet altyd **optree as die geauthentiseerde GitHub user oor alle van GitHub** (byvoorbeeld wanneer dit gebruikerskennisse voorsien) en slegs toegang hê tot die gespesifiseerde scopes.
- 'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Login with GitHub" vir die geauthentiseerde gebruiker moontlik te maak.
- **Moenie** 'n **OAuth App** bou as jy wil hê jou toepassing moet optree op 'n **single repository**. Met die `repo` OAuth scope kan OAuth Apps **optree op _all_ of die geauthentiseerde gebruiker se repositories**.
- **Moenie** 'n OAuth App bou om as 'n toepassing vir jou **span of maatskappy** op te tree nie. OAuth Apps verifieer as 'n **enkele gebruiker**, so as een persoon 'n OAuth App vir 'n maatskappy skep en dan die maatskappy verlaat, sal niemand anders toegang hê nie.
- **Meer** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).

### Github Applications

Github applications kan vra vir toestemmings om **jou github-inligting te bekom of jou te impersonate** om spesifieke aksies oor spesifieke bronne uit te voer. In Github Apps moet jy die repositories spesifiseer waartoe die app toegang sal hê.

- Om 'n GitHub App te installeer, moet jy 'n **organisation owner or have admin permissions** in 'n repository wees.
- Die GitHub App moet **connect to a personal account or an organisation**.
- Jy kan jou eie Github application skep in [https://github.com/settings/apps](https://github.com/settings/apps)
- Jy kan al die **Github applications wat toegang tot jou rekening het** sien in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- Dit is die **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). Afhangend van die permissies van die App sal dit sommige van hulle kan toegang.
- Jy kan geïnstalleerde apps in 'n **organization** sien in _https://github.com/organizations/\<org_name>/settings/installations_

Sommige security-aanbevelings:

- 'n GitHub App moet **aksies onafhanklik van 'n gebruiker neem** (tensy die app 'n [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token gebruik). Om user-to-server access tokens veiliger te hou, kan jy access tokens gebruik wat na 8 uur verval, en 'n refresh token wat ingeruil kan word vir 'n nuwe access token. Vir meer inligting, sien "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Maak seker die GitHub App integreer met **spesifieke repositories**.
- Die GitHub App moet **connect to a personal account or an organisation**.
- Moet nie verwag dat die GitHub App alles weet en kan doen wat 'n gebruiker kan nie.
- **Moenie 'n GitHub App gebruik as jy net 'n "Login with GitHub" diens nodig het nie**. Maar 'n GitHub App kan 'n [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) gebruik om gebruikers aan te meld _en_ ander dinge te doen.
- Moet nie 'n GitHub App bou as jy _slegs_ wil optree as 'n GitHub user en alles wil doen wat daardie gebruiker kan doen nie.
- As jy jou app met GitHub Actions gebruik en workflow-lêers wil wysig, moet jy verifieer namens die gebruiker met 'n OAuth token wat die `workflow` scope insluit. Die gebruiker moet admin of write-permissie op die repository hê wat die workflow-lêer bevat. Vir meer inligting, sien "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **Meer** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).

### Github Actions

Dit **is nie 'n manier om in github te autentikeer nie**, maar 'n **malicious** Github Action kan **unauthorised access to github** kry en, **afhangend** van die **privileges** wat aan die Action gegee is, verskeie **verskillende aanvalle** uitvoer. Sien hieronder vir meer inligting.

## Git Actions

Git actions laat toe om die **uitvoering van kode te outomatiseer wanneer 'n gebeurtenis plaasvind**. Gewoonlik is die uitgevoerde kode **op een of ander manier verwant aan die kode van die repository** (byvoorbeeld om 'n docker container te bou of te kontroleer dat die PR geen geheime bevat nie).

### Configuration

In _https://github.com/organizations/\<org_name>/settings/actions_ is dit moontlik om die **konfigurasie van die github actions** vir die organization te kontroleer.

Dit is moontlik om die gebruik van github actions heeltemal te verbied, **alle github actions toe te laat**, of net sekere actions toe te laat.

Dit is ook moontlik om te konfigureer **wie goedkeuring nodig het om 'n Github Action te hardloop** en die **toestemmings van die GITHUB_TOKEN** van 'n Github Action wanneer dit uitgevoer word.

### Git Secrets

Github Action benodig gewoonlik sekere geheime om met github of derdeparty-toepassings te kommunikeer. Om te **voorkom dat hulle in plain-text in die repo gesit word**, laat github toe om hulle as **Secrets** te plaas.

Hierdie secrets kan gekonfigureer word **vir die repo of vir die hele organization**. Dan, sodat die **Action toegang tot die secret kan hê**, moet jy dit verklaar soos:
```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 }}
```
#### Voorbeeld met 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 **kan slegs deur die Github Actions** wat hulle gedeclareer het, benader word.

> Sodra dit in die repo of die organizations gekonfigureer is **sal users of github hulle nie weer kan benader nie**, hulle sal net in staat wees om hulle te **verander**.

Daarom is die **enigste manier om github secrets te steel om toegang tot die masjien te kry wat die Github Action uitvoer** (in daardie scenario sal jy slegs toegang hê tot die secrets wat vir die Action gedeclareer is).

### Git Environments

Github laat toe om **environments** te skep waar jy **secrets** kan stoor. Dan kan jy die github action toegang gee tot die secrets binne die environment met iets soos:
```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.\
Daarnaast sluit environment protections in:
- **Required reviewers**: hou jobs wat op die environment gemik is terug totdat dit goedgekeur is. Skakel **Prevent self-review** aan om 'n behoorlike vier‑oog‑beginsel op die goedkeuring self af te dwing.
- **Deployment branches and tags**: beperk watter branches/tags na die environment kan deploy. Kies by voorkeur spesifieke branches/tags en maak seker daardie takke is beskerm. Let wel: die "Protected branches only" option geld vir klassieke branch-beskermings en mag nie soos verwag werk as jy rulesets gebruik nie.
- **Wait timer**: vertraag deployments vir 'n konfigureerbare tydperk.

Dit kan ook 'n **number of required reviews** stel voordat 'n **action** wat 'n **environment** gebruik **executing** word, of 'n **time** wag voordat deployments voortgaan.
### Git Action Runner

A Github Action kan **executed inside the github environment** word of in 'n **third party infrastructure** uitgevoer word wat deur die gebruiker gekonfigureer is.

Verskeie organisasies sal toelaat dat Github Actions in 'n **third party infrastructure** loop omdat dit gewoonlik **goedkoper** is.

Jy kan **list the self-hosted runners** van 'n organisasie vind by _https://github.com/organizations/\<org_name>/settings/actions/runners_

Die manier om te vind watter **Github Actions are being executed in non-github infrastructure** is om te soek na `runs-on: self-hosted` in die Github Action konfigurasie-yaml.

Dit is **not possible to run a Github Action of an organization inside a self hosted box** van 'n ander organisasie omdat **a unique token is generated for the Runner** wanneer dit gekonfigureer word sodat dit weet waar die runner behoort.

As die custom **Github Runner is configured in a machine inside AWS or GCP** byvoorbeeld, kan die Action toegang hê tot die metadata endpoint en die token van die service account steel waarmee die masjien loop.

### Git Action Compromise

As alle actions (of 'n kwaadwillige action) toegelaat word, kan 'n gebruiker 'n **Github action** gebruik wat **malicious** is en die **container** waar dit uitgevoer word **compromise**.

> [!CAUTION]
> 'n **malicious Github Action** run kan deur die aanvaller misbruik word om:
>
> - **Steel al die geheime** waarna die Action toegang het
> - **Beweeg lateraal** as die Action binne 'n **third party infrastructure** uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, verkrygbaar is (waarskynlik via die metadata service)
> - **Misbruik die token** wat deur die **workflow** gebruik word om **die kode van die repo te steel** waar die Action uitgevoer word of dit **selfs te verander**.

## Branch Protections

Branch protections is ontwerp om nie gebruikers die volledige beheer oor 'n repository te gee nie. Die doel is om verskeie beskermingsmetodes in plek te hê voordat iemand in staat is om kode in 'n tak te skryf.

Die **branch protections of a repository** kan gevind word by _https://github.com/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> Dit is **not possible to set a branch protection at organization level**. Dus moet al hierdie reëls op elke repo afsonderlik gedeclareer word.

Verskeie beskermings kan op 'n tak toegepas word (soos op master):

- Jy kan **require a PR before merging** (sodat jy nie direk kode oor die tak kan merge nie). As dit gekies is, kan verskeie ander beskerminge in plek wees:
- **Require a number of approvals**. Dit is baie algemeen om 1 of 2 ekstra mense te vereis om jou PR goed te keur sodat 'n enkele gebruiker nie in staat is om kode direk te merge nie.
- **Dismiss approvals when new commits are pushed**. Indien nie, kan 'n gebruiker legit kode goedkeur en dan kwaadwillige kode byvoeg en dit merge.
- **Require approval of the most recent reviewable push**. Verseker dat enige nuwe commits na 'n goedkeuring (insluitend pushes deur ander medewerkers) hernude hersiening veroorsaak sodat 'n aanvaller nie post-goedkeuring veranderinge kan push en merge nie.
- **Require reviews from Code Owners**. Ten minste 1 code owner van die repo moet die PR goedkeur (sodat "lukrake" gebruikers dit nie kan goedkeur nie).
- **Restrict who can dismiss pull request reviews.** Jy kan mense of spanne spesifiseer wat pull request reviews mag dismiss.
- **Allow specified actors to bypass pull request requirements**. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.
- **Require status checks to pass before merging.** Sekere kontroles moet slaag voordat die commit gemerg kan word (soos 'n GitHub App wat SAST-resultate rapporteer). Wen: bind vereiste kontroles aan 'n spesifieke GitHub App; anders kan enige app die kontrolle via die Checks API spoofs, en baie bots aanvaar skip-direktiewe (bv., "@bot-name skip").
- **Require conversation resolution before merging**. Alle kommentaar op die kode moet opgelos wees voordat die PR gemerg kan word.
- **Require signed commits**. Die commits moet onderteken wees.
- **Require linear history.** Voorkom merge commits om naicktakke gepush te word.
- **Include administrators**. As dit nie gestel is nie, kan admins die beperkings omseil.
- **Restrict who can push to matching branches**. Beperk wie 'n PR kan stuur.

> [!NOTE]
> Soos jy kan sien, selfs al kry jy sommige credentials van 'n gebruiker, **repos mag beskerm wees wat jou verhinder om kode na master te push** byvoorbeeld om die CI/CD-pyplyn te kompromitteer.

## Tag Protections

Tags (soos latest, stable) is standaard veranderlik. Om 'n vier‑oog‑vloei op tag-opdaterings af te dwing, beskerm tags en koppel beskermings deur environments en branches:

1) In die tag protection rule, skakel **Require deployments to succeed** aan en vereis 'n suksesvolle deployment na 'n beskermde environment (bv., prod).
2) In die beoogde environment, beperk **Deployment branches and tags** tot die release branch (bv., main) en konfigureer opsioneel **Required reviewers** met **Prevent self-review**.
3) Op die release branch, konfigureer branch protections om **Require a pull request** te vereis, stel approvals ≥ 1, en skakel beide **Dismiss approvals when new commits are pushed** en **Require approval of the most recent reviewable push** aan.

Hierdie ketting verhoed dat 'n enkele medewerker tags kan heretiketteer of force-publish releases deur workflow YAML te wysig, aangesien deployment gates buite workflows afgedwing word.

## References

- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
- [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)

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