Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Sicurezza di Gitblit
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Che cos'è Gitblit
+
+Gitblit è un server Git self‑hosted scritto in Java. Può essere eseguito come JAR standalone o in servlet containers e include un servizio SSH incorporato (Apache MINA SSHD) per Git over SSH.
+
+## Argomenti
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Riferimenti
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Sommario
+
+CVE-2024-28080 è un bypass di autenticazione nel servizio SSH embedded di Gitblit dovuto a una gestione incorretta dello stato di sessione nell'integrazione con Apache MINA SSHD. Se un account utente ha almeno una SSH public key registrata, un attaccante che conosce lo username e una delle public key dell'utente può autenticarsi senza la private key e senza la password.
+
+- Affetti: Gitblit < 1.10.0 (osservato su 1.9.3)
+- Corretto: 1.10.0
+- Requisiti per l'exploit:
+- Git over SSH abilitato sull'istanza
+- L'account vittima ha almeno una SSH public key registrata in Gitblit
+- L'attaccante conosce lo username della vittima e una delle sue public key (spesso reperibile, es. https://github.com/<username>.keys)
+
+## Causa principale (state leaks between SSH methods)
+
+Nel RFC 4252, la public‑key authentication procede in due fasi: il server prima verifica se una public key fornita è accettabile per uno username, e solo dopo un challenge/response con una signature autentica l'utente. In MINA SSHD, il PublickeyAuthenticator viene invocato due volte: al momento dell'accettazione della key (ancora senza signature) e più tardi dopo che il client ritorna la signature.
+
+Il PublickeyAuthenticator di Gitblit mutava il contesto di sessione nella prima chiamata pre‑signature legando lo UserModel autenticato alla sessione e restituendo true ("key acceptable"). Quando l'autenticazione successivamente ricadeva sulla password, il PasswordAuthenticator si è fidato di quello stato di sessione mutato e ha scavalcato la verifica, restituendo true senza validare la password. Di conseguenza, qualsiasi password (inclusa vuota) veniva accettata dopo una precedente "acceptance" della public‑key per lo stesso utente.
+
+Flusso difettoso ad alto livello:
+
+1) Client offre username + public key (ancora nessuna signature)
+2) Server riconosce la key come appartenente all'utente e associa prematuramente l'utente alla sessione, restituendo true ("acceptable")
+3) Il client non può firmare (nessuna private key), quindi l'autenticazione ricade sulla password
+4) L'autenticazione via password vede un utente già presente nella sessione e restituisce success senza condizioni
+
+## Sfruttamento passo‑per‑passo
+
+- Raccogliere lo username della vittima e una delle sue public key:
+- GitHub espone le public key su https://github.com/<username>.keys
+- I server pubblici spesso espongono authorized_keys
+- Configurare OpenSSH per presentare solo la metà pubblica così la generazione della signature fallisce, forzando il fallback alla password mentre si innesca comunque il percorso di acceptance della public‑key sul server.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Connettiti e premi Invio al prompt della password (o digita qualsiasi stringa):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+Nota: Se ControlMaster multiplexing è abilitato nella tua SSH config, i comandi Git successivi possono riutilizzare la connessione autenticata, aumentando l'impatto.
+
+## Impact
+
+- Impersonificazione completa di qualsiasi utente Gitblit con almeno una SSH public key registrata
+- Accesso in lettura/scrittura ai repository in base ai permessi della vittima (source exfiltration, push non autorizzati, rischi per la supply‑chain)
+- Potenziale impatto amministrativo se si prende di mira un utente admin
+- Exploit puramente di rete; nessuna brute force o private key richiesta
+
+## Detection ideas
+
+- Esaminare i log SSH per sequenze in cui un tentativo publickey è seguito da una password authentication riuscita con una password vuota o molto corta
+- Cercare flussi: publickey method che offre materiale di chiave non supportato/non corrispondente seguito da un successo immediato di password per lo stesso username
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Until upgraded:
+- Disabilitare Git over SSH su Gitblit, oppure
+- Restringere l'accesso di rete al servizio SSH, e
+- Monitorare la presenza dei pattern sospetti descritti sopra
+- Ruotare le credenziali degli utenti interessati se si sospetta un compromesso
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: Se il public‑key authenticator di un server muta lo stato utente/sessione durante la fase pre‑signature "key acceptable" e altri authenticators (es., password) si fidano di quello stato, puoi bypassare l'autenticazione tramite:
+
+- Presentare una public key legittima per l'utente target (nessuna private key)
+- Forzare il client a fallire la signing così il server ricade su password
+- Fornire qualsiasi password mentre il password authenticator si short‑circuits sul leaked state
+
+Consigli pratici:
+
+- Public key harvesting su larga scala: recuperare public keys da fonti comuni come https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forzare la signature failure (client‑side): impostare IdentityFile solo sul .pub, settare IdentitiesOnly yes, mantenere PreferredAuthentications per includere publickey poi password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) non deve allegare stato utente/sessione fino a quando il percorso di verifica post‑signature non conferma la signature
+- PasswordAuthenticator.authenticate(...) non deve inferire il successo da alcuno stato mutato durante un metodo di authentication precedente e incompleto
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS sta per **Version Control System**, questi sistemi consentono agli sviluppatori di **gestire il loro codice sorgente**. Il più comune è **git** e di solito troverai aziende che lo utilizzano in una delle seguenti **piattaforme**:
+VCS sta per **Version Control System**, questo sistema permette agli sviluppatori di **manage their source code**. Quello più comune è **git** e di solito troverai le aziende che lo usano su una delle seguenti **piattaforme**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Fornitori di cloud (offrono le proprie piattaforme VCS)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## Pipeline CI/CD
 
-Le pipeline CI/CD consentono agli sviluppatori di **automatizzare l'esecuzione del codice** per vari scopi, inclusi la costruzione, il test e il deployment delle applicazioni. Questi flussi di lavoro automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o attività programmate. Sono utili per semplificare il processo dallo sviluppo alla produzione.
+## CI/CD Pipelines
 
-Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per distribuire codice o accedere a informazioni sensibili**.
+CI/CD pipelines consentono agli sviluppatori di **automate the execution of code** per vari scopi, inclusi build, test e deployment delle applicazioni. Questi workflow automatici vengono **triggered by specific actions**, come push di codice, pull request o attività pianificate. Sono utili per snellire il processo dallo sviluppo alla produzione.
 
-## Metodologia di Pentesting VCS
+Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **privileged credentials to deploy code or access sensitive information**.
+
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Anche se alcune piattaforme VCS consentono di creare pipeline, in questa sezione analizzeremo solo i potenziali attacchi al controllo del codice sorgente.
+> Anche se alcune piattaforme VCS permettono di creare pipelines, in questa sezione analizzeremo solo attacchi potenziali al controllo del source code.
 
-Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni tra le piattaforme VCS che un attaccante potrebbe sfruttare:
+Le piattaforme che contengono il source code del tuo progetto custodiscono informazioni sensibili e bisogna essere molto cauti con i permessi concessi all'interno di queste piattaforme. Ecco alcuni problemi comuni nelle piattaforme VCS che un attacker potrebbe abusare:
 
-- **Leaks**: Se il tuo codice contiene leak nei commit e l'attaccante può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
-- **Accesso**: Se un attaccante può **accedere a un account all'interno della piattaforma VCS**, potrebbe guadagnare **maggiore visibilità e permessi**.
-- **Registrazione**: Alcune piattaforme consentiranno solo agli utenti esterni di creare un account.
-- **SSO**: Alcune piattaforme non consentiranno agli utenti di registrarsi, ma permetteranno a chiunque di accedere con un SSO valido (quindi un attaccante potrebbe usare il suo account github per entrare, ad esempio).
-- **Credenziali**: Nome utente + Pwd, token personali, chiavi ssh, token Oauth, cookie... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
-- **Webhook**: Le piattaforme VCS consentono di generare webhook. Se non sono **protetti** con segreti non visibili, un **attaccante potrebbe abusarne**.
-- Se non c'è alcun segreto in atto, l'attaccante potrebbe abusare del webhook della piattaforma di terze parti.
-- Se il segreto è nell'URL, succede la stessa cosa e l'attaccante ha anche il segreto.
-- **Compromissione del codice:** Se un attore malintenzionato ha qualche tipo di accesso **in scrittura** sui repo, potrebbe cercare di **iniettare codice malevolo**. Per avere successo, potrebbe dover **bypassare le protezioni dei branch**. Queste azioni possono essere eseguite con diversi obiettivi in mente:
-- Compromettere il branch principale per **compromettere la produzione**.
-- Compromettere il principale (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altre cose all'interno del repo sulle loro macchine).
-- **Compromettere la pipeline** (controlla la sezione successiva).
+- **Leaks**: Se il tuo code contiene leaks nei commit e l'attacker può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leaks.
+- **Access**: Se un attacker riesce ad avere accesso a un account dentro la VCS platform potrebbe ottenere **più visibilità e permessi**.
+- **Register**: Alcune piattaforme permettono semplicemente a utenti esterni di creare un account.
+- **SSO**: Alcune piattaforme non consentono la registrazione locale, ma permettono a chiunque di entrare con un SSO valido (quindi un attacker potrebbe usare ad esempio il suo account github per accedere).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
+- **Webhooks**: Le piattaforme VCS permettono di generare webhooks. Se non sono **protetti** con segreti non visibili un **attacker potrebbe abusarne**.
+- Se non è presente nessun segreto, l'attacker potrebbe abusare del webhook della piattaforma di terze parti
+- Se il segreto è nell'URL, succede la stessa cosa e l'attacker ha anche il segreto
+- **Code compromise:** Se un attore maligno ha qualche tipo di **write** access sui repo, potrebbe provare a **inject malicious code**. Per avere successo potrebbe essere necessario **bypassare branch protections**. Queste azioni possono essere effettuate con diversi obiettivi:
+  - Compromettere il main branch per **compromise production**.
+  - Compromettere il main (o altri branch) per **compromise developers machines** (dato che solitamente eseguono test, terraform o altre cose presenti nel repo sulle loro macchine).
+- **Compromise the pipeline** (vedi sezione successiva)
 
-## Metodologia di Pentesting delle Pipeline
+## Pipelines Pentesting Methodology
 
-Il modo più comune per definire una pipeline è utilizzare un **file di configurazione CI ospitato nel repository** che la pipeline costruisce. Questo file descrive l'ordine dei lavori eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
-Questi file di solito hanno un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML delle GitHub Actions situati sotto .github/workflows. Quando attivata, la job della pipeline **estrae il codice** dalla sorgente selezionata (ad es. commit / branch) e **esegue i comandi specificati nel file di configurazione CI** contro quel codice.
+Il modo più comune per definire una pipeline è usando un **CI configuration file hosted in the repository** che la pipeline costruisce. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
+Questi file tipicamente hanno un nome e un formato coerente, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions sotto .github/workflows. Quando viene triggerata, la pipeline job **pulls the code** dalla source selezionata (es. commit / branch), e **runs the commands specified in the CI configuration file** contro quel code.
 
-Pertanto, l'obiettivo finale dell'attaccante è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**.
+Quindi l'obiettivo finale dell'attacker è in qualche modo **compromise those configuration files** o i **commands they execute**.
 
-### PPE - Esecuzione di Pipeline Avvelenate
+### PPE - Poisoned Pipeline Execution
 
-Il percorso di Esecuzione di Pipeline Avvelenate (PPE) sfrutta i permessi in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i file di configurazione CI o altri file utilizzati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi malevoli.
+The Poisoned Pipeline Execution (PPE) path sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare il CI configuration file o altri file usati dal job della pipeline per includere comandi malevoli. Questo "poisons" la CI pipeline, portando all'esecuzione di questi comandi malevoli.
 
-Affinché un attore malintenzionato abbia successo nell'eseguire un attacco PPE, deve essere in grado di:
+Perché un attore maligno abbia successo in un attacco PPE deve poter:
 
-- Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline vengono attivate quando viene eseguito un push o una pull request. (Controlla la metodologia di pentesting VCS per un riepilogo dei modi per ottenere accesso).
-- Nota che a volte una **PR esterna conta come "accesso in scrittura"**.
-- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il file di configurazione CI o altri file su cui si basa la configurazione**.
-- Per questo, potrebbe dover essere in grado di **bypassare le protezioni dei branch**.
+- Avere **write access to the VCS platform**, dato che di solito le pipeline vengono triggerate quando viene eseguito un push o una pull request. (Vedi la VCS pentesting methodology per un riassunto dei modi per ottenere accesso).
+- Nota che a volte una **external PR** conta come "write access".
+- Anche avendo permessi di write, deve assicurarsi di poter **modify the CI config file or other files the config is relying on**.
+- Per fare ciò potrebbe essere necessario **bypass branch protections**.
 
 Ci sono 3 varianti di PPE:
 
-- **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il file di configurazione CI** che verrà eseguito.
-- **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'attore **modifica** un **file** su cui il file di configurazione CI che verrà eseguito **si basa** (come un file make o una configurazione terraform).
-- **Public PPE o 3PE**: In alcuni casi, le pipeline possono essere **attivate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non essere nemmeno parte dell'organizzazione) perché possono inviare una PR.
-- **3PE Command Injection**: Di solito, le pipeline CI/CD **impostano variabili di ambiente** con **informazioni sulla PR**. Se quel valore può essere controllato da un attaccante (come il titolo della PR) ed è **utilizzato** in un **luogo pericoloso** (come l'esecuzione di **comandi sh**), un attaccante potrebbe **iniettare comandi lì**.
+- **D-PPE**: Un attacco **Direct PPE** avviene quando l'attore **modifica il CI config** file che verrà eseguito.
+- **I-DDE**: Un attacco **Indirect PPE** avviene quando l'attore **modifica** un **file** su cui il CI config file che verrà eseguito **relies on** (come un make file o una terraform config).
+- **Public PPE or 3PE**: In alcuni casi le pipeline possono essere **triggered by users that doesn't have write access in the repo** (e che magari non fanno parte dell'org) perché possono inviare una PR.
+- **3PE Command Injection**: Di solito, le CI/CD pipelines impostano environment variables con **information about the PR**. Se quel valore può essere controllato da un attacker (ad esempio il title della PR) e viene **used** in un punto **dangerous** (come l'esecuzione di **sh commands**), un attacker potrebbe **inject commands in there**.
 
-### Vantaggi dell'Exploitation
+### Exploitation Benefits
 
-Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attaccante potrebbe ottenere dopo un'esploitazione riuscita:
+Conoscendo le 3 varianti per poisonare una pipeline, vediamo cosa potrebbe ottenere un attacker dopo un exploitation di successo:
 
-- **Segreti**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro lavori (recuperare il codice, costruirlo, distribuirlo...) e questi privilegi sono solitamente **concessi in segreti**. Questi segreti sono di solito accessibili tramite **variabili di ambiente o file all'interno del sistema**. Pertanto, un attaccante cercherà sempre di esfiltrare quanti più segreti possibile.
-- A seconda della piattaforma della pipeline, l'attaccante **potrebbe dover specificare i segreti nella configurazione**. Questo significa che se l'attaccante non può modificare la pipeline di configurazione CI (**I-PPE** per esempio), potrebbe **solo esfiltrare i segreti che quella pipeline ha**.
-- **Computazione**: Il codice viene eseguito da qualche parte, a seconda di dove viene eseguito, un attaccante potrebbe essere in grado di pivotare ulteriormente.
-- **On-Premises**: Se le pipeline vengono eseguite in sede, un attaccante potrebbe finire in una **rete interna con accesso a più risorse**.
-- **Cloud**: L'attaccante potrebbe accedere a **altre macchine nel cloud** ma potrebbe anche **esfiltrare** i token **IAM roles/service accounts** da esso per ottenere **ulteriore accesso all'interno del cloud**.
-- **Macchine della piattaforma**: A volte i lavori verranno eseguiti all'interno delle **macchine della piattaforma delle pipeline**, che di solito si trovano all'interno di un cloud con **nessun altro accesso**.
-- **Selezionalo:** A volte la **piattaforma delle pipeline avrà configurato diverse macchine** e se puoi **modificare il file di configurazione CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione, un attaccante probabilmente eseguirà una reverse shell su ogni possibile macchina per cercare di sfruttarla ulteriormente.
-- **Compromettere la produzione**: Se sei all'interno della pipeline e la versione finale viene costruita e distribuita da essa, potresti **compromettere il codice che andrà a finire in produzione**.
+- **Secrets**: Come accennato prima, le pipeline richiedono **privileges** per i loro job (recuperare il code, buildarlo, deployarlo...) e questi privilegi sono di solito **granted in secrets**. Questi secrets sono generalmente accessibili tramite **env variables or files inside the system**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secrets possibile.
+- A seconda della pipeline platform l'attacker **might need to specify the secrets in the config**. Questo significa che se l'attacker non può modificare la CI configuration pipeline (**I-PPE** per esempio), potrebbe **only exfiltrate the secrets that pipeline has**.
+- **Computation**: Il code viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe essere in grado di pivotare ulteriormente.
+- **On-Premises**: Se le pipeline vengono eseguite on premises, un attacker potrebbe trovarsi in una **internal network con accesso a più risorse**.
+- **Cloud**: L'attacker potrebbe accedere **ad altre macchine in cloud** ma anche **exfiltrate** IAM roles/service accounts **tokens** per ottenere **ulteriore accesso** dentro il cloud.
+- **Platforms machine**: A volte i job vengono eseguiti nelle **pipelines platform machines**, che di solito sono su cloud con **no more access**.
+- **Select it:** Talvolta la **pipelines platform** avrà configurato più macchine e se puoi **modify the CI configuration file** puoi **indicare dove vuoi che giri il codice malevolo**. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ciascuna macchina possibile per provare a sfruttarla ulteriormente.
+- **Compromise production**: Se sei dentro la pipeline e la versione finale viene buildata e deployata da essa, potresti **compromise the code that is going to end running in production**.
 
-## Maggiori informazioni rilevanti
+## More relevant info
 
-### Strumenti & Benchmark CIS
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per l'audit della tua catena di fornitura software per la conformità alla sicurezza basato su un nuovo [**benchmark CIS Software Supply Chain**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal momento del codice fino al momento del deployment.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua software supply chain stack in termini di compliance di sicurezza basato su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal code time al deploy time.
 
-### Top 10 Rischi di Sicurezza CI/CD
+### Top 10 CI/CD Security Risk
 
-Controlla questo interessante articolo sui 10 principali rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Consulta questo articolo interessante sui top 10 CI/CD risks secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Laboratori
+### Labs
 
-- Su ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente in modo da poterla configurare come desideri per testarla.
-- Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Per ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente così puoi configurarla come vuoi per fare i test
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Strumenti Automatici
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per l'infrastruttura come codice.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno static code analysis tool per infrastructure-as-code.
 
-## Riferimenti
+## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}