Translated ['', 'src/pentesting-cloud/pentesting-cloud-methodology.md',

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

@@ -4,153 +4,153 @@
 
 ## Basiese Struktuur
 
-Die basiese github omgewingsstruktuur van 'n groot **company** is om 'n **enterprise** te besit wat **verskeie organizations** besit en elk van hulle mag **verskeie repositories** en **verskeie teams** bevat. Kleinêre maatskappye mag net **een organization besit en geen enterprises** hê nie.
+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 **user** 'n **member** van **verskillende enterprises en organizations** wees. Binne hulle kan die gebruiker **verskillende enterprise-, organization- en repository-rolle** hê.
+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ê.
 
-Verder kan 'n gebruiker deel wees van **verskillende teams** met verskillende enterprise-, organization- of repository-rolle.
+Boonop kan 'n gebruiker **deel wees van verskillende teams** met verskillende enterprise-, organization- of repository-rolle.
 
-En uiteindelik kan **repositories spesiale beskermingsmeganismes** hê.
+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 afdwing oor organizations**. Hulle **kan egter nie toegang hê tot organization-instellings of inhoud** tensy hulle 'n organization owner gemaak word of direkte toegang tot 'n organisation-besit repository gegee word.
+- **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 wees, maar tot nie minder as twee persone in jou organization nie.
-- **Organization members**: Die **standaard**, nie-administratiewe rol vir **mense in 'n organization** is die organization member. By verstek het organization members **'n aantal permissies**.
-- **Billing managers**: Billing managers is gebruikers wat die **betaalinstellings vir jou organization kan bestuur**, soos betalingsinligting.
-- **Security Managers**: Dit is 'n rol wat organization owners aan enige team in 'n organization kan toeken. Wanneer toegepas, gee dit elke lid van die team permissies om **security alerts en instellings oor jou organization te bestuur, sowel as read permissions vir alle repositories** in die organization.
-- As jou organization 'n security team het, kan jy die security manager-rol gebruik om lede van die team die minste toegang te gee wat hulle nodig het tot die organization.
-- **Github App managers**: Om ekstra gebruikers toe te laat om **GitHub Apps besit deur 'n organization te bestuur**, 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 eksplisiet 'n member** van die organization is nie.
+- **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 permissies vergelyk** van hierdie rolle 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)
+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 **permissies sien wat gebruikers sal hê net omdat hulle deel is van die organization**.
+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 permissies van lede van die organization aan:
+Die instellings wat hier gekonfigureer word, dui die volgende toestemmings van lede van die organization aan:
 
-- Wees admin, writer, reader of geen toestemming oor al die organization repos nie.
+- 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 permissies wat admins oor die repositories het
-- Of lede nuwe teams 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
 
-Standaard word repository rolle geskep:
+By verstek word repository-rolle geskep:
 
-- **Read**: Aanbeveel vir **non-code contributors** wat jou projek wil sien of bespreek
-- **Triage**: Aanbeveel vir **contributors wat proaktief issues en pull requests moet bestuur** sonder write-toegang
-- **Write**: Aanbeveel vir contributors wat **aktiwiteit na jou projek push**
-- **Maintain**: Aanbeveel vir **projekbestuurders wat die repository moet bestuur** sonder toegang tot sensitiewe of destruktiewe aksies
-- **Admin**: Aanbeveel vir mense wat **volle toegang tot die projek nodig het**, insluitend sensitiewe en destruktiewe aksies soos security bestuur of 'n repository uitvee
+- **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 permissies vergelyk** van elke rol 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 **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_. Neem kennis dat om die teams te sien wat kinders van ander teams is, moet jy elke ouerteam besoek.
+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 'n lid is**, en die **repos waartoe die gebruiker toegang het**.
+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 te autentiseer en aksies namens jou uit te voer.
+Github bied verskillende maniere om by jou rekening aan te meld en aksies namens jou uit te voer.
 
 ### Web Access
 
-Deur **github.com** te besoek kan jy aanmeld met jou **username en password** (en 'n **2FA moontlik**).
+Toegang tot **github.com** kan jy aanmeld met jou **username and password** (en moontlik 'n **2FA**).
 
 ### **SSH Keys**
 
-Jy kan jou rekening instel met een of meer public keys wat die verwante **private key toelaat om aksies namens jou uit te voer.** [https://github.com/settings/keys](https://github.com/settings/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 daarmee impersonate nie** maar as jy dit nie gebruik nie kan dit moontlik wees dat jy **ontdek word vir die stuur van commits sonder 'n signature'**. Lees 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).
+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 token genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer jy 'n personal access token skep, moet die **user** die **permissies** wat die **token** sal hê **spesifiseer**. [https://github.com/settings/tokens](https://github.com/settings/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 permissies **om 'n gedeelte van jou github-inligting te benader of om jou te impersonate** om sekere aksies uit te voer. 'n Algemene voorbeeld van hierdie funksionaliteit is die **login with github button** wat jy op sekere platforms mag vind.
+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 **sekuriteitsaanbevelings**:
+Sommige **security-aanbevelings**:
 
-- 'n **OAuth App** behoort altyd **op te tree as die geverifieerde GitHub user oor die hele GitHub** (byvoorbeeld, wanneer dit gebruikerskennisgewings voorsien) en slegs toegang tot die gespesifiseerde scopes te hê.
-- 'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Login with GitHub" vir die geverifieerde gebruiker aan te skakel.
-- **Moet nie** 'n **OAuth App** bou as jy wil hê jou toepassing moet op 'n **enkele repository** optree nie. Met die `repo` OAuth scope kan OAuth Apps **optree op _all_** van die geverifieerde gebruiker se repositories.
-- **Moet nie** 'n OAuth App bou om as 'n toepassing vir jou **team of maatskappy** op te tree nie. OAuth Apps autentiseer 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.
+- '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 permissies om **jou github-inligting te benader 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ê.
+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 of admin permissions** in 'n repository wees.
-- Die GitHub App moet **koppel aan 'n personal account of 'n organisation**.
+- 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 in staat wees om sommige van hulle te benader
+- 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 sekuriteitsaanbevelings:
+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 meer veilig te hou, kan jy toegangstokens gebruik wat na 8 uur verval, en 'n refresh token wat uitgeruil 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)."
+- '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 **koppel aan 'n personal account of 'n organisation**.
-- Moet nie verwag dat die GitHub App alles weet en doen wat 'n gebruiker kan nie.
-- **Moet nie** '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_ as 'n GitHub user wil optree 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 namens die gebruiker autentiseer met 'n OAuth token wat die `workflow` scope insluit. Die gebruiker moet admin of write-permissie hê tot die repository 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)."
+- 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 autentiseer nie**, maar 'n **kwaadwillige** Github Action kan **ongemagtigde toegang tot github kry** en, afhangend van die **privileges** wat aan die Action gegee word, kan verskeie **verskillende aanvalle** uitgevoer word. Sien hieronder vir meer inligting.
+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 kode wat uitgevoer word **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 nie geheimenhede bevat nie).
+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).
 
-### Konfigurasie
+### 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 benodig om 'n Github Action te laat loop** en die **permissies van die GITHUB_TOKEN** van 'n Github Action wanneer dit uitgevoer word.
+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 soort geheime om met github of derdeparty-toepassings te kommunikeer. Om te **voorkom dat hulle in duidelike teks in die repo geplaas word**, laat github toe om hulle as **Secrets** te stoor.
+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 **vir die repo of vir die hele organization** gekonfigureer word. Dan, sodat die **Action die secret kan benader**, moet jy dit verklaar soos:
+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
@@ -168,11 +168,11 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **kan slegs vanaf die Github Actions verkry word** wat dit gedeklarer het.
+> Secrets **kan slegs deur die Github Actions** wat hulle gedeclareer het, benader word.
 
-> Sodra dit in die repo of die organisasie gekonfigureer is, **sal gebruikers van github dit nie weer kan toegang kry nie**, hulle sal net in staat wees om dit te **verander**.
+> 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 gedefinieer is).
+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
 
@@ -183,75 +183,75 @@ deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Jy kan 'n omgewing konfigureer sodat dit deur **alle branches** (default), **slegs beskermde** branches of deur **spesifiseer** watter branches toegang tot dit het.\  
-Verder sluit omgewingsbeskerming in:
-- **Required reviewers**: hou gate jobs wat op die omgewing gemik is totdat dit goedgekeur is. Skakel **Prevent self-review** aan om 'n behoorlike vier‑oë‑beginsel op die goedkeuring self af te dwing.
-- **Deployment branches and tags**: beperk watter branches/tags na die omgewing kan deploy. Kies by voorkeur spesifieke branches/tags en verseker dat daardie branches beskerm is. Nota: die "Protected branches only" opsie geld vir klassieke branch protections en mag nie soos verwag werk as jy rulesets gebruik nie.
-- **Wait timer**: vertraag deployments vir 'n konfigureerbare periode.
+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 **aantal vereiste resensies** stel voordat 'n **action** wat 'n **omgewing** gebruik, **uitgevoer** word of eers 'n **tyd** te **wag** voordat deployments toegelaat word om voort te gaan.
+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
 
-'n Github Action kan **binne die Github-omgewing uitgevoer word** of in 'n **derdeparty‑infrastruktuur** wat deur die gebruiker gekonfigureer is.
+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 om Github Actions in 'n **derdeparty‑infrastruktuur** te laat loop aangesien dit dikwels **goedkoper** is.
+Verskeie organisasies sal toelaat dat Github Actions in 'n **third party infrastructure** loop omdat dit gewoonlik **goedkoper** is.
 
-Jy kan die **self-hosted runners** van 'n organisasie lys in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+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 in nie-Github‑infrastruktuur uitgevoer word** is om vir `runs-on: self-hosted` in die Github Action-konfigurasie yaml te soek.
+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 **nie moontlik om 'n Github Action van een organisasie binne 'n self hosted box van 'n ander organisasie te laat loop nie**, omdat **'n unieke token gegenereer word vir die Runner** wanneer dit geconfigureer word sodat dit weet waar die runner behoort.
+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 aangepaste **Github Runner op 'n masjien binne AWS of GCP** byvoorbeeld gekonfigureer is, kan die Action **toegang hê tot die metadata endpoint** en **die token van die service account** steel waarmee die masjien loop.
+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 **kwaadwillig** is en die **kontainer** waarin dit uitgevoer word, **kompromiseer**.
+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 **Kwaadwillige Github Action** run kan deur die aanvaller **misbruik** word om:
+> 'n **malicious Github Action** run kan deur die aanvaller misbruik word om:
 >
-> - **Steal all the secrets** waartoe die Action toegang het
-> - **Move laterally** indien die Action binne 'n **derdeparty‑infrastruktuur** uitgevoer word waar die SA token wat gebruik word om die masjien te bedryf, bekom kan word (waarskynlik via die metadata service)
-> - **Abuse the token** wat deur die **workflow** gebruik word om **die kode van die repo** waar die Action uitgevoer word te **steel** of **selfs te wysig**.
+> - **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**.
 
-## Takbeskerming
+## Branch Protections
 
-Takbeskermings is ontwerp om gebruikers nie die volle beheer oor 'n repository te gee nie. Die doel is om verskeie beskermingsmetodes in plek te hê voordat iemand kode in 'n tak kan skryf.
+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 **takbeskerming van 'n repository** kan gevind word by _https://github.com/\<orgname>/\<reponame>/settings/branches_
+Die **branch protections of a repository** kan gevind word by _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> Dit is **nie moontlik om 'n takbeskerming op organisasie‑vlak te stel nie**. Dus moet dit op elke repo verklaar word.
+> 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 (bv. op master):
+Verskeie beskermings kan op 'n tak toegepas word (soos op master):
 
-- Jy kan **require a PR before merging** (sodat jy nie direk kode na die tak kan merge nie). As dit gekies is kan verskeie ander beskermings geaktiveer wees:
-- **Require a number of approvals**. Dit is algemeen om 1 of 2 ander mense te vereis om jou PR goed te keur sodat 'n enkele gebruiker nie direk kode kan merge nie.
-- **Dismiss approvals when new commits are pushed**. Indien nie, kan 'n gebruiker aanvanklik legitime kode goedkeur en later kwaadwillige veranderinge byvoeg en merge.
-- **Require approval of the most recent reviewable push**. Verseker dat enige nuwe commits ná 'n goedkeuring (insluitend pushes deur ander medewerkers) die hersiening heraktiveer 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 "lukraak" gebruikers dit nie kan goedkeur nie)
-- **Restrict who can dismiss pull request reviews.** Jy kan persone of spanne spesifiseer wat pull request‑resensies mag intrek.
-- **Allow specified actors to bypass pull request requirements**. Hierdie gebruikers sal vorige beperkings kan omseil.
-- **Require status checks to pass before merging.** Sekere checks moet slaag voordat die commit gemerge kan word (bv. 'n GitHub App wat SAST‑resultate rapporteer). Wenke: bind vereiste checks aan 'n spesifieke GitHub App; anders kan enige app die check spoog via die Checks API, 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 gemerge kan word.
+- 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 dat merge commits na ooreenstemmende takke gepus word.
+- **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 na ooreenstemmende takke kan push.
+- **Restrict who can push to matching branches**. Beperk wie 'n PR kan stuur.
 
 > [!NOTE]
-> Soos jy kan sien, selfs al kry jy sommige gebruikersbewyse, **mag repos beskerm wees sodat jy nie kode na master kan push** byvoorbeeld om die CI/CD‑pyplyn te kompromitteer.
+> 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.
 
-## Tagbeskerming
+## Tag Protections
 
-Tags (bv. latest, stable) is standaard veranderlik. Om 'n vier‑oë‑proses op tag‑opdaterings af te dwing, beskerm tags en koppel beskermings deur omgewings en takke:
+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) Op die tag‑beskermingsreël, skakel **Require deployments to succeed** aan en vereis 'n suksesvolle deployment na 'n beskermde omgewing (bv. prod).
-2) In die teiken‑omgewing, beperk **Deployment branches and tags** tot die release‑tak (bv. main) en konfigureer opsioneel **Required reviewers** met **Prevent self-review**.
-3) Op die release‑tak, konfigureer takbeskerming om **Require a pull request** te vereis, stel goedkeurings op ≥ 1, en skakel beide **Dismiss approvals when new commits are pushed** en **Require approval of the most recent reviewable push** aan.
+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 voorkom dat 'n enkele medewerker release tags herbemerk of geforseer publiseer deur workflow YAML te wysig, aangesien deployment‑hekke buite workflows afgedwing word.
+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