Sicurezza Cloud: Audit con Prowler e Trivy, 12 Passi [2026]

Un bucket S3 lasciato con lettura pubblica per una svista. Un ruolo IAM con permessi amministrativi assegnato a una funzione che doveva solo leggere un file di log. Una porta 3389 aperta a tutto internet invece che alla sola rete aziendale. Non servono exploit sofisticati per violare un sistema cloud: spesso basta una configurazione lasciata così com’era, senza che nessuno la controllasse.

Questo tutorial ti guida passo per passo nell’audit di un ambiente cloud con due strumenti open source, Prowler e Trivy, più un terzo, Checkov, come controllo aggiuntivo sul codice Infrastructure as Code. Alla fine avrai anche una pipeline GitHub Actions che blocca in automatico i deploy con errori critici, pronta da adattare al tuo progetto reale.

Il percorso è pensato per chi gestisce infrastruttura su AWS, Azure o GCP e non ha mai avuto il tempo di mettere in piedi un controllo sistematico. Non serve essere un esperto di sicurezza: servono un terminale, un account cloud di test e circa un’ora per arrivare dal primo scan alla pipeline automatica funzionante. Gli esempi di comandi usano AWS, ma la logica resta identica se il tuo stack gira su Azure o GCP.

Perché la sicurezza cloud dipende dalla configurazione, non dal provider

AWS, Azure e Google Cloud proteggono l’infrastruttura fisica, la rete e i data center. Tutto quello che costruisci sopra, dai bucket di storage alle policy IAM, resta responsabilità tua. È il cosiddetto modello di responsabilità condivisa. Nella pratica significa che l’anello debole della sicurezza cloud raramente è il provider: è ogni singola configurazione che qualcuno ha lasciato com’era.

Il problema non è teorico. Secondo IBM, una violazione dannosa su quattro nel 2025 è ormai “AI-enabled”, con un costo medio di 6 milioni di dollari per l’azienda colpita. Tra le cause più comuni di questi incidenti, le misconfigurazioni cloud che espongono i carichi di lavoro AI pesano quanto le API compromesse: il 27% dei casi ciascuna (IBM Newsroom, 29 luglio 2026).

Il quadro più ampio non è più incoraggiante. Il costo medio globale di una violazione dati nel 2025 è sceso a 4,44 milioni di dollari, il primo calo in cinque anni, ma negli Stati Uniti la media resta la più alta al mondo con 10,22 milioni di dollari (IBM, Cost of a Data Breach Report 2025). In Europa, l’ENISA ha analizzato 4.875 incidenti in un solo anno, da luglio 2024 a giugno 2025: un volume che rende la scansione manuale delle configurazioni cloud semplicemente impraticabile su scala.

Il modello di responsabilità condivisa cambia leggermente da provider a provider, ma il principio resta identico su AWS, Azure e GCP: il fornitore certifica e mette in sicurezza i data center, l’hypervisor e la rete fisica, mentre identità, dati, configurazione delle risorse e crittografia restano sotto il tuo controllo diretto. Nessuno strumento del provider ti impedisce, per esempio, di rendere pubblico un bucket con un clic distratto nella console.

C’è anche una ragione più prosaica per cui queste configurazioni restano sbagliate così a lungo. Molte impostazioni di default dei provider cloud privilegiano la comodità in fase di sviluppo, non la sicurezza in produzione: un bucket che accetta subito connessioni, un security group aperto per non perdere tempo a debuggare una connessione rifiutata. Chi lo crea raramente torna indietro a chiudere quella porta una volta che il progetto funziona, e la configurazione provvisoria diventa permanente per inerzia.

Le prossime sezioni mostrano come automatizzare quello che nessun team può fare a mano: un controllo sistematico delle configurazioni, ripetuto ogni volta che qualcosa cambia.

Prerequisiti: gli strumenti e i permessi che ti servono

Prima di lanciare il primo scan, prepara l’ambiente. La tabella riassume cosa serve e a cosa serve: nessuno di questi strumenti richiede una licenza a pagamento per seguire questo tutorial.

Strumento	Versione consigliata	A cosa serve
Python	3.9 o successiva	Eseguire Prowler e Checkov via pipx/pip
Docker	Ultima stabile	Eseguire Prowler e Trivy in container, senza installare dipendenze locali
AWS CLI	v2	Configurare le credenziali IAM di sola lettura per lo scan
Prowler	Serie 5.x (verifica con prowler --version)	Audit dell’account cloud live contro CIS Benchmark e altri framework
Trivy	v0.67 o successiva	Scansione di file Terraform e altri manifest IaC prima del deploy
Checkov	Ultima disponibile via pip install checkov	Secondo livello di controllo statico su Infrastructure as Code
Account AWS di test	Free tier, mai produzione	Ambiente isolato su cui esercitarsi senza rischi

Un avvertimento su Prowler e Trivy: entrambi ricevono aggiornamenti frequenti, con nuovi controlli aggiunti quasi a ogni release. Verifica sempre la versione installata con prowler --version e trivy --version prima di iniziare, invece di fidarti di un numero scritto in una guida di qualche mese fa, compresa questa.

Un dettaglio tecnico utile: il supporto alla scansione IaC dentro Prowler è arrivato con la CLI 5.8.0 e con Prowler Cloud 5.14.0. Se usi una versione precedente, aggiornala prima di seguire i passi 7 e 8.

Un’ultima cosa prima di iniziare: attiva un budget alert sull’account AWS di test, per esempio a 5 dollari, tramite AWS Budgets. Non userai risorse costose in questo tutorial, ma un allarme configurato in anticipo evita brutte sorprese se dimentichi di eliminare qualcosa alla fine. È un’abitudine che vale la pena portarsi dietro anche fuori da questo esercizio.

Non serve un intero team di sicurezza per seguire questa guida. Nella maggior parte delle aziende che adottano questo tipo di controllo, a occuparsene è chi già gestisce l’infrastruttura o la pipeline di deploy: un DevOps engineer, un tech lead, a volte lo stesso sviluppatore che scrive i moduli Terraform. La curva di apprendimento sta più nel capire cosa fare con i risultati che nel far girare i tool stessi.

Le misconfigurazioni cloud più comuni: una mappa dei rischi

Non tutte le misconfigurazioni pesano allo stesso modo, e non tutte richiedono la stessa urgenza di intervento. La tabella qui sotto raggruppa le categorie che Prowler, Trivy e Checkov intercettano più spesso, insieme al rischio reale che rappresentano, così puoi dare priorità a quelle in alto quando il primo report restituisce più righe di quante tu ne possa correggere in un giorno.

Categoria	Esempio tipico	Rischio principale	Chi la rileva
Storage pubblico	Bucket S3 o blob con accesso “public read”	Esfiltrazione diretta dei dati	Prowler
IAM troppo permissivo	Policy con “Action”: “*” e “Resource”: “*”	Movimento laterale, escalation di privilegi	Prowler, Trivy
Security group aperti	Porta 22 o 3389 aperta a 0.0.0.0/0	Accesso remoto non autorizzato	Prowler
Logging disattivato	CloudTrail o audit log non abilitati	Nessuna visibilità in caso di incidente	Prowler
Cifratura mancante	Volumi o bucket senza cifratura at-rest	Esposizione dei dati da snapshot o accesso fisico	Prowler, Checkov
IaC senza controlli	Modulo Terraform che crea risorse insicure di default	L’errore nasce nel codice, prima ancora del deploy	Trivy, Checkov

Nota l’ultima riga: è diversa dalle altre. Una misconfigurazione che nasce nel codice Infrastructure as Code si moltiplica a ogni deploy, perché quel codice viene riusato. Un singolo modulo Terraform scritto male può generare decine di risorse insicure in produzione prima che qualcuno se ne accorga. Per questo il tutorial copre sia lo scan dell’account live sia lo scan del codice che lo genera.

Le prime tre categorie della tabella condividono un’altra caratteristica: sono quasi sempre visibili dall’esterno, senza bisogno di credenziali rubate. Un bucket pubblico, una porta aperta o un log mancante si scoprono con una scansione passiva, lo stesso tipo di ricognizione che un attaccante automatizzato esegue su migliaia di account cloud ogni giorno, cercando esattamente questi pattern. Arrivarci prima con Prowler non è un esercizio accademico: è una corsa contro strumenti che fanno la stessa cosa dall’altra parte.

Passo 1-3: prepara un ambiente di test isolato

Passo 1. Crea un account AWS dedicato ai test, separato da quello di produzione. Il free tier basta per le poche risorse che userai in questo tutorial. Non collegare mai uno scanner di sicurezza alle credenziali del tuo account personale o di produzione durante l’apprendimento.

Passo 2. Crea un utente IAM dedicato con permessi di sola lettura, pensato solo per l’audit. AWS offre una policy gestita apposta, SecurityAudit, che concede accesso in lettura a quasi tutti i servizi senza permettere modifiche. È la stessa policy che consiglia la documentazione ufficiale di Prowler, e usarla invece di una policy amministrativa riduce da subito il danno possibile se le chiavi dell’utente venissero esposte per errore, per esempio finendo in un commit pubblico.

aws iam create-user --user-name audit-readonly
aws iam attach-user-policy --user-name audit-readonly \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit
aws iam create-access-key --user-name audit-readonly

Passo 3. Installa Python 3.9 o successivo, pipx e Docker. Pipx isola ogni tool Python nel proprio ambiente virtuale, evitando conflitti di dipendenze con altri progetti sulla stessa macchina.

python3 -m pip install --upgrade pip pipx
pipx ensurepath

# Ubuntu/Debian
sudo apt update && sudo apt install -y docker.io
docker --version

Passo 4-5: installa Prowler e lancia il primo scan

Passo 4. Installa Prowler con pipx, oppure eseguilo via Docker se preferisci non installare nulla in locale. Prowler si descrive come il tool open source per la sicurezza cloud più diffuso al mondo, e copre AWS, Azure, GCP e Kubernetes dalla stessa interfaccia a riga di comando. La via Docker è comoda soprattutto in CI/CD, dove installare un pacchetto Python a ogni esecuzione allunga inutilmente i tempi della pipeline.

pipx install prowler
prowler --version

# In alternativa, via Docker
docker run --rm -v $(pwd)/report:/home/prowler/output \
  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
  toniblyx/prowler:latest aws

Passo 5. Configura le credenziali dell’utente readonly creato al passo 2, poi lancia il primo scan. Il comando seguente salva i risultati in tre formati: CSV per un’occhiata rapida, JSON-ASFF per l’integrazione con altri strumenti, HTML per condividere il report con chi non usa la riga di comando.

export AWS_ACCESS_KEY_ID="la-tua-access-key"
export AWS_SECRET_ACCESS_KEY="la-tua-secret-key"
export AWS_DEFAULT_REGION="eu-south-1"

prowler aws --output-formats csv json-asff html \
  --output-directory ./report-audit

Su un account free tier con poche risorse, lo scan completo richiede in genere pochi minuti. Su un account aziendale con centinaia di risorse in più region, può richiedere molto più tempo: il passo 11 mostra come automatizzarlo invece di aspettare davanti al terminale.

Se vuoi limitare il primo scan a un solo servizio, per esempio solo S3, aggiungi il flag --services s3 al comando. È un buon modo per imparare a leggere l’output senza essere sommerso da centinaia di righe già al primo tentativo, ed è utile anche più avanti, quando vorrai isolare un servizio specifico dopo aver corretto un problema per verificare che la fix abbia funzionato.

Tieni d’occhio anche il codice di uscita del comando, non solo il report. Prowler restituisce un exit code diverso da zero quando trova almeno un FAIL, un dettaglio che tornerà utile al passo 11, quando lo stesso comando gira dentro una pipeline automatica e deve poter far fallire una build senza che nessuno legga il log riga per riga.

Passo 6: leggi e interpreta il report di Prowler

Passo 6. Apri il report e cerca prima le righe con stato FAIL e severità CRITICAL o HIGH. Ogni controllo di Prowler è mappato al CIS Benchmark corrispondente, così capisci subito se un errore riguarda lo storage, l’IAM, la rete o il logging.

Provider: aws   Account: 123456789012

FAIL  eu-west-1   s3_bucket_public_access                 CRITICAL
      Bucket "backup-clienti-2026" consente accesso di lettura pubblico

FAIL  eu-south-1  iam_policy_allows_privilege_escalation  HIGH
      La policy "LambdaFullAccess" concede iam:PassRole senza restrizioni

PASS  global      iam_root_mfa_enabled                    CRITICAL
      L'account root ha l'MFA attivo

Non tutti i controlli restituiscono PASS o FAIL. Alcuni, marcati come MANUAL, richiedono una verifica umana perché dipendono da scelte organizzative che uno scanner non può giudicare da solo, per esempio se un accesso amministrativo condiviso sia effettivamente autorizzato dal tuo processo interno. Tratta questi casi come una lista di domande da porre al team, non come rumore da ignorare: spesso nascondono proprio le decisioni che nessuno ha mai messo per iscritto.

Esporta sempre il report anche in JSON-ASFF, non solo in HTML. È il formato che userai al passo 11 per collegare Prowler alla pipeline automatica, e ti risparmia di dover rilanciare lo scan più avanti.

Un’altra colonna utile del report, spesso ignorata, è quella dei framework di conformità. Prowler mappa gran parte dei controlli anche su standard come ISO 27001, oltre al CIS Benchmark citato negli esempi. Se la tua azienda deve già rispondere a un audit di conformità, filtrare i risultati per framework invece che per severità ti dà direttamente la lista di priorità che chiederà il revisore, senza doverla ricostruire a mano da un report generico.

Passo 7-8: scansiona il codice Infrastructure as Code con Trivy

Passo 7. Installa Trivy. Il progetto lo descrive come uno scanner unico per vulnerabilità CVE e misconfigurazioni IaC, capace di analizzare repository di codice, immagini container e cluster Kubernetes con lo stesso comando. È mantenuto da Aqua Security e distribuito con licenza Apache 2.0, quindi anche in questo caso non c’è nessun costo di licenza da considerare.

# macOS
brew install trivy

# Ubuntu/Debian
sudo apt-get install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy
trivy --version

Passo 8. Punta Trivy sulla cartella che contiene i file Terraform, CloudFormation o Kubernetes del tuo progetto, prima ancora di eseguire un deploy. Questa è la differenza pratica con Prowler: Trivy trova l’errore nel codice sorgente, quando costa ancora poco correggerlo.

trivy config ./infrastructure --severity CRITICAL,HIGH

Filtra per severità con --severity CRITICAL,HIGH nelle prime scansioni, altrimenti il volume di segnalazioni a bassa priorità rischia di nascondere i problemi che contano davvero.

Trivy fa più di quello che usi in questo tutorial. Lo stesso binario scansiona anche immagini container per vulnerabilità CVE note, genera un SBOM (Software Bill of Materials) e controlla i manifest Kubernetes già applicati a un cluster live. In questo tutorial ci concentriamo sulla scansione IaC perché è il punto in cui una misconfigurazione costa meno correggerla, ma vale la pena sapere che lo stesso strumento copre molto altro il giorno in cui ne avrai bisogno, senza dover imparare un secondo tool per la scansione delle immagini Docker che probabilmente già usi in produzione.

Passo 9: aggiungi Checkov come secondo livello di controllo

Passo 9. Checkov analizza lo stesso tipo di file di Trivy, ma con un motore di regole indipendente e un forte focus su Terraform. Il progetto aveva già superato le 7.500 stelle su GitHub ad aprile 2025, secondo l’analisi di K9 Security, ed è mantenuto da Bridgecrew. Oltre alle regole predefinite, Checkov permette di scrivere policy personalizzate in Python, utile se la tua azienda ha requisiti interni che nessuno scanner generico conosce in anticipo.

pip install checkov
checkov -d ./infrastructure --compact

Non è ridondanza inutile. Due strumenti con regole diverse trovano problemi diversi, e in un progetto Infrastructure as Code la sovrapposizione è il prezzo minimo da pagare per non fidarsi di un solo motore di scansione. A questo punto hai installato tutti e tre gli strumenti del tutorial: la tabella seguente riassume quando usare ciascuno.

Caratteristica	Prowler	Trivy	Checkov
Cosa scansiona	Account cloud live (AWS, Azure, GCP)	Immagini container, IaC, repository, cluster Kubernetes	File IaC: Terraform, CloudFormation, Kubernetes manifest
Momento del controllo	Dopo il deploy (runtime)	Sia prima sia dopo il deploy	Prima del deploy (build-time)
Licenza	Open source	Open source	Open source
Punto di forza	Copertura molto ampia del CIS Benchmark multi-cloud	Un solo tool per CVE e misconfigurazioni IaC insieme	Regole personalizzabili e forte integrazione con Terraform

Passo 10: correggi le misconfigurazioni più comuni

Passo 10. Ogni finding trovato ai passi precedenti va corretto alla fonte, nel codice, non con un click nella console cloud che qualcuno dimenticherà di riportare nel repository. Una correzione fatta solo nella console dura fino al prossimo terraform apply, che la sovrascrive silenziosamente riportando la configurazione insicura originale. Tre esempi pratici, tra i più comuni nei report reali.

Il primo riguarda lo storage pubblico. Un bucket S3 creato senza restrizioni esplicite può restare accessibile in lettura a chiunque conosca l’URL.

# Prima: blocco pubblico disattivato per errore
resource "aws_s3_bucket_public_access_block" "backup" {
  bucket                  = aws_s3_bucket.backup.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

# Dopo: accesso pubblico bloccato esplicitamente
resource "aws_s3_bucket_public_access_block" "backup" {
  bucket                  = aws_s3_bucket.backup.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Il secondo riguarda l’IAM. Una policy che concede "Action": "*" su "Resource": "*" sembra comoda in fase di sviluppo, ma trasforma qualsiasi funzione compromessa in un accesso amministrativo completo. È il tipo di errore che Prowler segnala come rischio di privilege escalation, perché una policy così ampia permette quasi sempre di modificare anche i permessi di altri utenti.

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::backup-clienti-2026/*"
}

Il terzo esempio riguarda la rete. Un security group che accetta connessioni SSH da qualsiasi indirizzo è tra i finding CRITICAL più comuni nei primi scan, spesso ereditato da un tutorial o da un template copiato senza modifiche.

# Prima: SSH aperto a tutto internet
ingress {
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

# Dopo: SSH ristretto alla rete aziendale
ingress {
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["203.0.113.0/24"]
}

La regola generale, valida per tutti e tre gli esempi: parti sempre dal permesso minimo necessario, o dalla configurazione più chiusa possibile, e allarga solo quando un errore concreto te lo richiede. Mai il contrario, e mai “per sicurezza aggiungo qualche permesso in più così non devo tornarci”.

Passo 11-12: automatizza l’audit con GitHub Actions

Passo 11. Uno scan lanciato a mano una volta al mese serve a poco: le configurazioni cambiano a ogni deploy, e nessuno si ricorda di rilanciare un comando manuale con la stessa disciplina con cui lo farebbe una macchina. Il workflow seguente esegue Trivy e Checkov su ogni pull request che tocca la cartella Infrastructure as Code, più un audit Prowler completo ogni lunedì mattina. È un progetto completo, pronto da copiare nel tuo repository e adattare ai nomi reali delle tue cartelle.

name: audit-sicurezza-cloud

on:
  pull_request:
    paths:
      - "infrastructure/**"
  schedule:
    - cron: "0 6 * * 1"

jobs:
  scan-iac:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Trivy config scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: config
          scan-ref: infrastructure/
          severity: CRITICAL,HIGH
          exit-code: "1"

      - name: Checkov scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: infrastructure/
          soft_fail: false

  scan-live-account:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Prowler audit
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AUDIT_AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AUDIT_AWS_SECRET_ACCESS_KEY }}
        run: |
          pipx install prowler
          prowler aws --output-formats json-asff --output-directory ./report

Passo 12. Il parametro exit-code: "1" di Trivy e soft_fail: false di Checkov fanno fallire la pull request quando trovano un errore critico, bloccando il merge finché qualcuno non lo corregge. Salva le chiavi dell’utente readonly come secret del repository, mai come testo scritto nel workflow.

Il workflow separa volutamente i due job. scan-iac gira su ogni pull request ed è veloce, perché controlla solo file di testo senza toccare la rete. scan-live-account gira secondo un programma settimanale, perché interroga le API cloud reali e richiede più tempo. Tenerli distinti evita che un audit completo dell’account rallenti ogni singola modifica al codice, anche quella più piccola.

Da qui puoi estendere il workflow in diverse direzioni: aggiungere uno step che invia una notifica Slack quando un job fallisce, caricare il report Prowler come artifact scaricabile dalla pagina della Action, oppure ripetere il job scan-live-account per ogni account se lavori con AWS Organizations. La struttura di base resta la stessa.

Errori comuni da evitare durante un audit di sicurezza cloud

Alcuni errori tornano quasi sempre, anche in team con esperienza. Vale la pena conoscerli prima di trovarseli davanti, perché quasi tutti nascono da una scorciatoia presa con l’intenzione di sistemarla “più avanti”.

• Usare credenziali amministrative per lo scan. Serve sempre un utente readonly dedicato, mai le chiavi del tuo account personale o di produzione. Se quelle chiavi finiscono in un repository pubblico per errore, il danno potenziale è enormemente più grande con permessi amministrativi che con permessi di sola lettura.
• Ignorare i falsi positivi senza leggerli. Disattivare un controllo senza capirlo nasconde anche i veri problemi che arriveranno in futuro.
• Confondere lo scan live con lo scan del codice. Trivy e Checkov intercettano l’errore prima del deploy, Prowler lo trova dopo. Servono entrambi, non uno al posto dell’altro.
• Non aggiornare mai gli strumenti. Ogni release aggiunge nuovi controlli: una versione vecchia di sei mesi si perde le misconfigurazioni più recenti.
• Sottovalutare il rate limiting delle API cloud. Uno scan troppo aggressivo su un account con migliaia di risorse può far scattare il throttling e restituire un report incompleto senza errori visibili.
• Correggere in produzione senza test. Cambiare una policy IAM o un security group senza prima passare da staging può bloccare un servizio che dipendeva da quel permesso “eccessivo”.
• Considerare l’audit un progetto con una fine. Uno scan lanciato una volta, con tutti i finding corretti in una settimana di lavoro intenso, dà una falsa sensazione di sicurezza. Senza il passo 11 automatizzato, l’account torna a degradarsi al primo deploy successivo.

Risoluzione dei problemi più frequenti

Nove problemi che incontrerai quasi certamente nelle prime settimane, con la causa più probabile e come risolverli. Quasi tutti derivano da configurazione dell’ambiente, non da bug degli strumenti stessi.

• “AccessDenied” durante lo scan Prowler. L’utente IAM non ha la policy SecurityAudit collegata. Verifica con aws iam list-attached-user-policies --user-name audit-readonly.
• Lo scan Prowler impiega più di un’ora. Succede su account con migliaia di risorse in molte region. Limita le region con --region eu-south-1 eu-west-1 nei primi test, poi allarga gradualmente una volta capito quanto tempo richiede ogni region aggiuntiva.
• Trivy restituisce “unable to parse HCL”. Il file Terraform usa una sintassi più recente della versione di Trivy installata. Controlla trivy --version e confrontala con l’ultima release su GitHub.
• Docker restituisce “permission denied”. L’utente locale non è nel gruppo docker. Su Linux: sudo usermod -aG docker $USER, poi riavvia la sessione.
• Checkov e Trivy segnalano lo stesso errore due volte. È normale: i due motori hanno regole indipendenti che si sovrappongono. Non è un bug, è ridondanza voluta. Se il doppio output rende il report troppo lungo da leggere in pull request, valuta di mostrare solo l’output di Trivy nel commento automatico e tenere Checkov come controllo silenzioso in background.
• Il job GitHub Actions fallisce e il log non mostra le credenziali. È corretto: GitHub maschera automaticamente i secret nei log. Controlla piuttosto i permessi del secret nelle impostazioni del repository.
• Prowler segnala MANUAL invece di PASS o FAIL. Alcuni controlli richiedono una verifica umana, per esempio sulle policy organizzative, e non si possono automatizzare al 100%.
• Il numero di risultati critici cresce a ogni scan senza modifiche apparenti. Controlla se lo scan include nuove region o servizi prima esclusi, oppure se è arrivata una versione dello strumento con controlli aggiuntivi.
• Il job schedulato su GitHub Actions non parte mai al lunedì. Gli scheduled workflow di GitHub usano l’orario UTC, non l’orario locale. Verifica il fuso orario prima di dedurre che il cron sia sbagliato, e ricorda che GitHub può ritardare l’esecuzione di alcuni minuti nelle ore di punta.

Consigli avanzati per un programma di sicurezza cloud maturo

Una volta che lo scan gira da solo a ogni pull request, la sicurezza cloud smette di essere un controllo occasionale e diventa un processo continuo, con la stessa cadenza del resto del ciclo di sviluppo. Qualche consiglio per il passo successivo, pensato per chi ha già seguito i dodici passi precedenti e vuole consolidare il risultato.

• Scansiona tutti gli account insieme. Con AWS Organizations, Prowler supporta nativamente il multi-account: non serve ripetere il comando account per account.
• Mappa i controlli su un framework specifico. Non fermarti al solo CIS Benchmark di default se la tua azienda deve rispondere a un audit ISO 27001 o alla direttiva NIS2: Prowler permette di selezionare framework alternativi con il flag --compliance, così il report che produci parla già la lingua del tuo revisore.
• Inoltra i risultati critici a un SIEM. Uno strumento come Wazuh trasforma un finding critico in un alert nello stesso posto dove arrivano già gli altri eventi di sicurezza, invece di farti leggere un report a mano ogni settimana.
• Tieni una baseline dei rischi accettati. Documenta le eccezioni approvate per non essere sommerso dagli stessi falsi positivi a ogni scan.
• Ripeti lo scan Prowler anche senza modifiche visibili. Un servizio cloud può cambiare configurazione di default con un aggiornamento del provider, non solo con un tuo deploy.
• Separa gli account per ambiente. Un account dedicato solo alla produzione, isolato da sviluppo e test, riduce il raggio d’azione di qualsiasi errore di configurazione e rende più leggibile ogni singolo report.

Nessuno di questi accorgimenti richiede di ripartire da zero. Si innestano sullo stack già installato nei passi precedenti, un pezzo alla volta, nell’ordine che ha più senso per il tuo team.

NIS2 e Cyber Resilience Act: cosa cambia per le aziende italiane

In Italia e nel resto dell’Unione Europea, questo tipo di controllo non è più solo una buona pratica tecnica. La direttiva NIS2 estende gli obblighi di gestione del rischio a migliaia di aziende italiane, con sanzioni che arrivano fino a 10 milioni di euro per chi non dimostra un processo di sicurezza continuo.

Il Cyber Resilience Act aggiunge un secondo livello di obblighi, questa volta rivolto a chi sviluppa e vende software: gestione delle vulnerabilità e aggiornamenti diventano requisiti legali, non solo scelte interne.

Un audit come quello descritto in questo tutorial, con report esportabili e uno storico nelle Actions di GitHub, è esattamente il tipo di evidenza documentale che un revisore chiede in sede di conformità. Automatizzarlo oggi costa un pomeriggio. Ricostruirlo a posteriori, durante un’ispezione, costa molto di più.

Il contesto italiano rende il tema ancora più urgente. Il Clusit ha collocato l’Italia al primo posto in Europa per numero di attacchi registrati nel suo ultimo report, un dato che da solo giustifica il tempo speso a chiudere le porte più ovvie prima ancora di preoccuparsi degli scenari più sofisticati. Le misconfigurazioni cloud rientrano proprio in questa categoria: economiche da correggere, costose da ignorare.

Per i soggetti che rientrano nel perimetro NIS2, vale la pena anche chiarire chi risponde di cosa quando un fornitore cloud è coinvolto. La direttiva non permette di scaricare interamente la responsabilità sul fornitore anche quando l’incidente nasce da una sua configurazione predefinita: l’azienda che usa quel servizio resta comunque tenuta a dimostrare di aver fatto una due diligence ragionevole sulla propria configurazione, esattamente il tipo di evidenza che uno scan documentato come quello di questo tutorial fornisce.

Rileggendo i dodici passi nel loro insieme, il filo conduttore è sempre lo stesso: uno scanner non sostituisce il giudizio di chi progetta l’infrastruttura, lo velocizza. Prowler ti dice cosa è già esposto oggi, Trivy e Checkov impediscono che lo stesso errore riparta domani da un nuovo deploy, e la pipeline GitHub Actions garantisce che nessuno dei due controlli dipenda dal ricordarsene manualmente. Messi insieme, coprono l’intero ciclo di vita di una risorsa cloud, dal codice sorgente alla produzione.

Domande frequenti sulla sicurezza cloud

Prowler è gratuito?

Sì, Prowler è open source. Esiste anche una versione cloud a pagamento con dashboard e funzioni aggiuntive, ma la CLI usata in questo tutorial resta gratuita.

Qual è la differenza pratica tra Prowler e Trivy?

Prowler scansiona l’account cloud già attivo. Trivy scansiona soprattutto il codice, prima che diventi infrastruttura reale. Usali insieme, non in alternativa.

Serve un account AWS a pagamento per seguire questo tutorial?

No, il free tier di AWS basta per le poche risorse di test usate qui, come il bucket S3 e la policy IAM di esempio. Eliminale alla fine per evitare costi imprevisti, e ricontrolla la sezione fatturazione della console dopo un paio di giorni per essere sicuro che non sia rimasto nulla attivo.

Questi strumenti funzionano anche su Azure e GCP?

Sì. Prowler supporta AWS, Azure, GCP e Kubernetes. Trivy e Checkov lavorano su qualsiasi provider descritto in Terraform o in altri linguaggi IaC supportati.

Con che frequenza conviene fare un audit?

Lo scan IaC va eseguito a ogni pull request. Lo scan dell’account live va bene anche settimanale, più spesso se l’ambiente cambia frequentemente.

Cosa fare se trovo una misconfigurazione critica già in produzione?

Non correggerla d’impulso durante l’orario di punta. Valuta l’impatto reale, per esempio se i dati esposti erano effettivamente sensibili o solo file pubblici per progettazione, avvisa il team, e applica la correzione seguendo lo stesso processo di test che useresti per qualsiasi altro cambiamento infrastrutturale. Se sospetti un accesso non autorizzato già avvenuto, tratta la situazione come un incidente a parte, con la sua tempistica di notifica, non solo come una configurazione da sistemare.

Questi tool sostituiscono un penetration test?

No. Trovano configurazioni sbagliate note, catalogate in un set di regole predefinite, non scoprono logiche di business vulnerabili o catene di attacco complesse che combinano più errori minori in un unico exploit. Sono un livello di difesa complementare, non l’unico, e non eliminano il valore di un test manuale periodico condotto da chi sa cercare esattamente quel tipo di combinazione.

Come si collega tutto questo alla sicurezza cloud richiesta dalla NIS2?

La direttiva chiede alle aziende di dimostrare un processo di gestione del rischio continuo. Uno scan automatizzato e documentato come quello di questo tutorial è esattamente il tipo di evidenza richiesta in un audit di conformità.

Posso usare Prowler, Trivy e Checkov anche su un cluster Kubernetes self-hosted?

Sì. Prowler include controlli dedicati a Kubernetes, Trivy scansiona sia i manifest sia un cluster già in esecuzione, e Checkov analizza gli stessi manifest in fase di build. Il flusso di lavoro descritto in questo tutorial per AWS si applica con pochissime modifiche anche a un ambiente Kubernetes on-premise.

Approfondimenti correlati

• OWASP Top 10 2025 in Node.js: 10 Vulnerabilità, 12 Difese
• CSIRT: Piano di Incident Response in 12 Step
• Wazuh: Installazione e Configurazione SIEM/XDR
• Burp Suite Tutorial: Penetration Testing Web in 12 Step
• NIS2 in Italia: 20.000 Aziende sotto Ispezione ACN

Per una panoramica più ampia su violazioni, password e phishing, consulta la sezione Sicurezza di shattered.io.