Trivy vs Grype: Scanner Container, 30% più Veloce [2026]

Il 19 marzo 2026 qualcuno con le credenziali giuste ha pubblicato una versione compromessa di Trivy, uno dei due scanner di vulnerabilità container più usati al mondo. Per qualche giorno, milioni di pipeline CI/CD in giro per l’Europa hanno scaricato senza saperlo un pacchetto malevolo al posto di uno strumento di sicurezza. È il tipo di episodio che cambia il modo in cui i team DevSecOps guardano ai propri scanner, e rende il confronto tra Trivy e Grype molto più interessante di un semplice elenco di funzionalità. Entrambi sono open source, entrambi scansionano immagini container e SBOM, ma le somiglianze finiscono presto. Trivy, sviluppato da Aqua Security, punta tutto sull’ampiezza: un binario solo per vulnerabilità, configurazioni sbagliate, segreti e licenze. Grype, di Anchore, resta concentrato sul matching puro delle vulnerabilità, con una velocità che diversi benchmark indipendenti confermano superiore in scenari ripetuti. Questo confronto mette in fila dati di specifica, benchmark di tre fonti diverse, prezzi, casi d’uso reali e una guida alla migrazione, per chi deve scegliere quale scanner integrare nella propria pipeline nella seconda metà del 2026.

Cos’è Trivy: lo scanner all-in-one di Aqua Security

Trivy nasce come progetto open source di Aqua Security e si è affermato negli anni come lo scanner cloud-native più citato nelle community DevSecOps, complice un approccio “tutto in un binario”. La versione più recente disponibile è la v0.71.2, rilasciata il 19 giugno 2026, distribuita con licenza Apache-2.0. Il repository su GitHub mostra oltre 88 release pubblicate e più di 513 contributori secondo le rassegne di settore del 2026, con un conteggio di stelle che le fonti consultate collocano tra 31.000 e 36.500, a seconda di quando è stato fatto lo snapshot.

Quello che distingue Trivy non è un singolo motore di scansione, ma la copertura. Lo stesso binario analizza immagini container, filesystem locali, repository Git, immagini VM e cluster Kubernetes attivi. Sul fronte infrastruttura-come-codice copre Terraform, CloudFormation, Helm chart, Dockerfile e persino workflow di GitHub Actions, cercando configurazioni pericolose oltre alle CVE nei pacchetti. A questo si aggiungono uno scanner di segreti (chiavi API, token, credenziali finite per errore in un repository) e uno scanner di licenze open source, utile per chi deve rispettare policy di compliance interne. Trivy genera inoltre SBOM in modo nativo, un requisito sempre più centrale con l’avvicinarsi delle scadenze del Cyber Resilience Act europeo.

Cos’è Grype: lo scanner di vulnerabilità di Anchore

Anchore mantiene Grype con una filosofia opposta: fare una cosa sola, il matching delle vulnerabilità, e farla con la massima precisione possibile. La release più recente è la v0.118.0, datata 27 agosto 2026, sempre sotto licenza Apache-2.0. Il repository su GitHub conta oltre 201 release e uno storico di stelle che le fonti 2026 riportano tra 12.440 e 12.735, quindi circa un terzo di Trivy in termini di visibilità sulla piattaforma, pur con uno sviluppo molto attivo (l’ultimo commit tracciato risale al 27 agosto 2026, lo stesso giorno della release).

Grype scansiona immagini container, filesystem e SBOM già generati (in formati Docker, OCI e Singularity), coprendo un numero ampio di ecosistemi di pacchetto: a livello di sistema operativo Alpine, Debian, Ubuntu, RHEL, Oracle Linux e Amazon Linux, e a livello applicativo Ruby, Java, JavaScript, Python, .NET, Go, PHP e Rust. La caratteristica che lo distingue da Trivy è la prioritizzazione del rischio: Grype integra punteggi EPSS (probabilità di sfruttamento) e la lista CISA KEV (vulnerabilità note sfruttate attivamente) per aiutare i team a capire quali CVE aggredire per prime, oltre al supporto per OpenVEX, lo standard che permette di dichiarare se una vulnerabilità è realmente sfruttabile nel proprio contesto. Non fa scansione di Kubernetes dal vivo, non tocca IaC e non cerca segreti: resta uno strumento a fuoco stretto.

Perché la velocità di scansione conta così tanto nel 2026

Un paio d’anni fa la velocità di uno scanner era un dettaglio da appassionati di benchmark. Oggi non lo è più, per un motivo semplice: il numero di scansioni per pipeline è esploso. Un team che adotta pratiche di shift-left security non scansiona più un’immagine una volta prima del rilascio, la scansiona a ogni commit, a ogni pull request, spesso più volte nello stesso giorno sulla stessa base image con solo un layer applicativo cambiato. In questo scenario, la differenza tra 1,2 e 0,7 secondi per scansione, che sembra trascurabile su un singolo test, si moltiplica per centinaia di esecuzioni giornaliere e diventa un fattore reale nei tempi di attesa degli sviluppatori e nei costi di calcolo dei runner CI.

La ragione tecnica dietro il divario di velocità osservato nei benchmark ha a che fare con l’ampiezza di ciò che ciascuno strumento controlla a ogni esecuzione. Trivy, dovendo verificare anche configurazioni IaC, segreti e licenze oltre alle CVE, esegue più passaggi sullo stesso set di file, anche quando l’utente ha bisogno solo del controllo vulnerabilità. Grype, concentrato su un solo compito, salta quei passaggi aggiuntivi per costruzione. È lo stesso compromesso che si vede in molti strumenti di sicurezza: più moduli attivi in un solo binario significano più copertura, ma anche più lavoro da fare a ogni esecuzione, a meno di disattivare manualmente i moduli non necessari, cosa che Trivy permette di fare tramite flag dedicati ma che in pratica pochi team configurano di default.

Trivy e Grype nel contesto normativo europeo: CRA e NIS2

Per i lettori europei la scelta dello scanner non è solo una questione tecnica, ma sempre più anche una questione di conformità. Il Cyber Resilience Act impone, dall’11 settembre 2026, obblighi di segnalazione delle vulnerabilità sfruttate attivamente entro 24 ore per i prodotti con componenti digitali immessi sul mercato UE, e richiede la disponibilità di un inventario del software leggibile da macchina. Uno scanner che genera SBOM in modo nativo, come Trivy, semplifica la prima metà di quell’obbligo, ma non lo esaurisce: serve comunque un processo che colleghi l’SBOM alle vulnerabilità scoperte, aggiorni l’inventario a ogni release e mantenga una traccia storica delle versioni.

La direttiva NIS2, già recepita in Italia, aggiunge un ulteriore livello di pressione per le organizzazioni classificate come essenziali o importanti, che devono dimostrare processi di gestione del rischio della catena di approvvigionamento software. In questo contesto, l’incidente di Trivy di marzo 2026 assume un peso particolare: un’organizzazione soggetta a NIS2 che aveva integrato lo scanner compromesso nella propria pipeline di produzione avrebbe dovuto, in teoria, includere quell’evento nella propria valutazione del rischio di supply chain e documentare la risposta adottata. Per i team che operano in settori regolamentati (energia, trasporti, sanità, finanza), questo genere di precedente pesa quanto un benchmark di velocità, se non di più, nella scelta finale dello strumento.

Trivy vs Grype: la tabella comparativa completa

Ecco il confronto riga per riga tra le due specifiche, utile per chi deve motivare la scelta a un team di piattaforma o a un cliente in fase di audit di sicurezza.

Caratteristica	Trivy	Grype
Ente sviluppatore	Aqua Security	Anchore
Licenza	Apache-2.0	Apache-2.0
Versione più recente (ago. 2026)	v0.71.2 (19 giu. 2026)	v0.118.0 (27 ago. 2026)
Stelle GitHub (fonti 2026)	31.000 – 36.500 circa	12.440 – 12.735 circa
Scansione immagini container	Sì	Sì
Scansione filesystem/repo Git	Sì	Solo filesystem
Scansione Kubernetes live	Sì	No
Scansione IaC (Terraform, Helm, CloudFormation)	Sì	No
Scansione segreti	Sì	No
Scansione licenze open source	Sì	No
Generazione SBOM	Sì, nativa	Consuma SBOM, output CycloneDX
Prioritizzazione rischio EPSS/KEV	No nativa	Sì
Supporto OpenVEX	Parziale	Sì
Interfaccia	CLI, nessuna dashboard OSS	CLI, nessuna dashboard OSS
Incidenti di sicurezza noti nel 2026	Sì, marzo 2026	Nessuno rilevato

Database delle vulnerabilità: da dove arrivano i dati

La qualità di uno scanner dipende in gran parte da quanto sono aggiornate le fonti su cui si basa. Secondo confronti di settore pubblicati nel 2026, Trivy attinge a un mix di feed che comprende il NVD statunitense, le GitHub Security Advisories (GHSA), il database OSV di Google, gli avvisi OVAL di Red Hat e le notifiche di sicurezza Ubuntu (USN). Grype segue un approccio simile ma con un componente dedicato, il repository grype-db, che aggrega NVD, GHSA e i feed delle principali distribuzioni Linux in un database scaricabile separatamente dal binario principale.

Nessuna delle due aziende pubblica una cadenza di aggiornamento garantita e verificabile in modo indipendente, quindi qualunque cifra specifica in ore va presa con cautela. Quello che è verificabile è la struttura: entrambi gli strumenti separano il motore di scansione dal database delle vulnerabilità, che viene scaricato e aggiornato a parte, un design che permette aggiornamenti frequenti senza dover rilasciare una nuova versione del binario ogni volta che arriva una CVE.

Questo disaccoppiamento tra motore e database ha un’implicazione pratica che molti team scoprono solo dopo aver iniziato a usare uno dei due strumenti in produzione: la versione del binario indicata nella tabella comparativa di questo articolo dice poco sulla freschezza effettiva dei dati usati in una scansione specifica, perché quella dipende da quando è stato scaricato l’ultimo aggiornamento del database sulla macchina che esegue lo scanner. In una pipeline CI che gira su runner effimeri, questo significa che ogni esecuzione scarica il database da zero, mentre in un ambiente con caching persistente il database può restare fermo per giorni se nessuno lo forza ad aggiornarsi, con il rischio di scansioni che sembrano pulite solo perché non conoscono ancora le CVE pubblicate nelle ultime ore.

Benchmark di velocità e accuratezza: cosa dicono tre fonti indipendenti

Qui è dove il confronto smette di essere teorico. Vale una premessa: i numeri che seguono arrivano da benchmark pubblicati da blog di settore nel 2026, non da studi accademici peer-reviewed. Vanno letti come indicazioni pratiche di tendenza, non come verità assolute, perché la metodologia (immagini testate, hardware, versione del database al momento del test) cambia da una fonte all’altra.

Il confronto pubblicato da SafeGuard.sh nel 2026, condotto su un set interno di 500 immagini enterprise, ha trovato che Trivy produce in media il 18% in più di risultati rispetto a Grype, ma circa il 60% di quei risultati aggiuntivi risultano falsi positivi legati a backport di patch che Trivy non riconosce correttamente su alcune distribuzioni. Sulla velocità, lo stesso test riporta circa 8 secondi per Trivy contro 9 per Grype sulla prima scansione di un’immagine da 500 MB, ma il rapporto si inverte sulle scansioni ripetute con cache calda: circa 1,2 secondi per Trivy contro 0,7 per Grype.

Un secondo benchmark, pubblicato da AppSec Santa come parte di una serie chiamata “Candyshop Benchmark 2026”, ha misurato precisione e richiamo sulle stesse immagini di test: Trivy ha ottenuto un punteggio F1 di 0,783, con precisione pari a 1,000 ma richiamo più basso a 0,662, mentre Grype si è fermato a un F1 di 0,528 nello stesso test. In altre parole, in questo specifico benchmark Trivy ha segnalato meno falsi positivi in proporzione ma ha mancato più vulnerabilità reali rispetto a Grype.

Un terzo confronto, pubblicato su Lucaberton.com, ha misurato i tempi di scansione su cinque immagini campione, trovando Grype sistematicamente più veloce di Trivy in ogni caso: 2,1 contro 1,4 secondi, 3,8 contro 2,9, 8,2 contro 5,1, 2,4 contro 1,8 e 9,7 contro 6,3 secondi. Infine, l’analisi pubblicata da Jacar segnala che Trivy e Grype individuano le stesse CVE in oltre il 95% dei casi su scenari tipici, con Grype generalmente più rapido sulle scansioni successive alla prima. Il quadro complessivo che emerge da queste quattro fonti è coerente: Grype tende a essere più veloce, specialmente su scansioni ripetute, mentre Trivy tende a segnalare più risultati, con un tasso di falsi positivi più alto in almeno uno dei test citati.

Falsi positivi e falsi negativi: come leggere i benchmark senza farsi ingannare

I numeri della sezione precedente possono sembrare contraddittori a prima vista: come può Trivy avere sia più falsi positivi secondo SafeGuard.sh sia una precisione perfetta secondo AppSec Santa? La risposta sta nella differenza tra i due concetti. Un test di precisione misura quanti dei risultati segnalati sono corretti (pochi falsi positivi in proporzione), mentre un test di richiamo misura quante vulnerabilità reali vengono effettivamente trovate (pochi falsi negativi). Uno scanner può avere precisione alta e richiamo basso allo stesso tempo, cioè sbagliare raramente quando segnala qualcosa, ma anche perdersi diverse vulnerabilità reali che non arriva a segnalare affatto. È esattamente il profilo che il benchmark di AppSec Santa attribuisce a Trivy in quel test specifico: precisione 1,000 ma richiamo 0,662.

Per un team di sicurezza questo significa una cosa molto pratica: nessuno dei due numeri, preso da solo, dice se uno scanner è “migliore”. Un team che tollera qualche falso positivo pur di non perdersi vulnerabilità critiche dovrebbe guardare più al richiamo che alla precisione, e viceversa un team che vuole ridurre al minimo il rumore nelle notifiche di sicurezza (per non abituare gli sviluppatori a ignorare gli alert) dovrebbe pesare di più la precisione. La raccomandazione più prudente resta comunque quella emersa più volte in questo confronto: usare entrambi gli scanner sulle stesse immagini per un periodo di prova, guardare dove effettivamente divergono sul proprio parco applicativo specifico, e decidere di conseguenza invece di fidarsi ciecamente di un singolo benchmark pubblicato online, per quanto dettagliato.

SBOM: CycloneDX, SPDX e interoperabilità tra i due scanner

Con l’avvicinarsi delle scadenze del Cyber Resilience Act europeo, la capacità di generare e leggere SBOM è diventata un criterio di scelta tanto importante quanto il rilevamento delle CVE. Trivy include un generatore di SBOM integrato, richiamabile direttamente dalla CLI, pensato per produrre un inventario del software leggibile da macchina a partire da un’immagine o da un repository. Grype lavora in modo complementare: non genera SBOM da zero ma può analizzarne uno già prodotto (anche da Trivy o da Syft, l’altro strumento di Anchore), restituendo un report di vulnerabilità basato su quell’inventario, con output leggibile in formato CycloneDX secondo le recensioni di settore consultate.

Questo rende i due strumenti più complementari che concorrenti su questo fronte specifico: molti team generano l’SBOM con Trivy o Syft e poi lo passano a Grype per un secondo controllo di vulnerabilità, ottenendo di fatto una doppia verifica incrociata. Chi deve scegliere un solo formato di riferimento tra CycloneDX e SPDX per la conformità normativa dovrebbe comunque verificare i requisiti specifici del proprio settore, perché la scelta del formato SBOM è indipendente dallo scanner di vulnerabilità usato a valle.

Prezzi: strumenti gratuiti, piattaforme enterprise a pagamento

Sul fronte prezzo la scelta è meno complicata: entrambi gli scanner da riga di comando sono completamente gratuiti e open source, senza limiti di scansioni, senza paywall e senza necessità di account. La differenza emerge quando un’organizzazione ha bisogno di funzionalità enterprise: dashboard centralizzate, policy as code, integrazione con sistemi di ticketing, supporto commerciale e SLA. Aqua Security offre una piattaforma commerciale che include Trivy come motore di scansione ma aggiunge funzionalità di runtime protection e gestione centralizzata; Anchore offre allo stesso modo Anchore Enterprise, costruito attorno a Grype e Syft. In entrambi i casi il prezzo non è pubblicato apertamente e viene negoziato caso per caso in base al numero di immagini scansionate e ai servizi richiesti.

Livello	Trivy / Aqua Security	Grype / Anchore
CLI open source	Gratuito, nessun limite	Gratuito, nessun limite
Licenza	Apache-2.0	Apache-2.0
Dashboard centralizzata OSS	Non inclusa	Non inclusa
Piattaforma commerciale	Aqua Security Platform	Anchore Enterprise
Prezzo piattaforma commerciale	Su richiesta (quotazione custom)	Su richiesta (quotazione custom)
Supporto SLA	Solo su piano commerciale	Solo su piano commerciale

Ecosistema di integrazione: CI/CD, Kubernetes e IDE

Trivy ha un’impronta più ampia nell’ecosistema di integrazione, coerente con il suo posizionamento all-in-one. È disponibile come azione ufficiale per GitHub Actions (aquasecurity/trivy-action), come comando setup-trivy per installarlo in qualunque runner, ed è citato come default in molte configurazioni GitLab CI e Jenkins. Il supporto a Kubernetes va oltre la semplice scansione da riga di comando: esiste un Trivy Operator che gira dentro il cluster e genera report di vulnerabilità come risorse custom native di Kubernetes, aggiornati in automatico quando cambiano i workload.

Grype si integra prevalentemente via CLI all’interno di pipeline CI/CD, con output in formato SARIF che permette di popolare la scheda “Code scanning” di GitHub in modo nativo. Non offre un operator per Kubernetes né plugin IDE ufficiali documentati nelle fonti consultate: il suo posto naturale è come step veloce di una pipeline, spesso subito dopo la generazione di un SBOM con Syft.

Sul fronte dei registry container, entrambi gli strumenti funzionano a riga di comando contro qualunque registry compatibile OCI, quindi Docker Hub, Amazon ECR, Google Artifact Registry, Azure Container Registry o un’installazione self-hosted di Harbor sono tutti target validi per lo stesso comando di scansione, senza bisogno di configurazioni specifiche per provider cloud. La differenza pratica sta più a monte, nella scelta se far girare lo scanner come step di pipeline, come admission controller che blocca il deploy di immagini non conformi, o come job schedulato che scansiona periodicamente le immagini già presenti in un registry per intercettare CVE scoperte dopo il build originale, uno scenario sempre più comune dato che una CVE può essere pubblicata mesi dopo che un’immagine è già in produzione.

Ecco un esempio semplificato di come i due scanner appaiono tipicamente in un workflow GitHub Actions, uno di seguito all’altro per un doppio controllo:

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

      - name: Scansione con Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'registry.esempio.it/app:latest'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

      - name: Scansione con Grype
        uses: anchore/scan-action@v5
        with:
          image: 'registry.esempio.it/app:latest'
          fail-build: true
          severity-cutoff: high

L’incidente di sicurezza di Trivy del marzo 2026

Il 19 marzo 2026 Aqua Security ha comunicato che un soggetto malevolo, utilizzando credenziali compromesse, era riuscito a pubblicare una release contraffatta identificata come Trivy v0.69.4, insieme a modifiche ai tag di trivy-action e setup-trivy, i due componenti più usati per integrare Trivy nelle pipeline CI/CD. L’episodio è stato classificato come CVE-2026-33634 (tracciato anche come GHSA-69fq-xp46-6×23), e report successivi hanno indicato che anche alcune immagini pubblicate su Docker Hub con i tag v0.69.5 e v0.69.6 risultavano compromesse. Microsoft ha pubblicato una guida di risposta all’incidente per i propri clienti che usavano Trivy nelle pipeline Azure DevOps e GitHub Actions, confermando la portata del problema.

La risposta di Aqua Security ha incluso la rotazione delle chiavi di firma del progetto e la rimozione dei trigger di workflow considerati vulnerabili all’origine della compromissione. È un episodio che va inserito nel confronto con Grype non per gettare discredito su Trivy, che resta un progetto maturo e ampiamente adottato, ma perché nessun incidente comparabile risulta documentato per Grype nello stesso periodo. Per i team che scelgono uno scanner anche in base al rischio di supply chain, è un dato di fatto da includere nella valutazione, non un dettaglio marginale: uno strumento di sicurezza compromesso è, per definizione, il peggior tipo di vulnerabilità possibile in una pipeline.

Cinque casi d’uso reali: dove ciascuno scanner rende meglio

La scelta tra Trivy e Grype dipende molto da dove si inserisce lo scanner nel flusso di lavoro. Ecco cinque scenari concreti in cui la scelta cambia in base alle esigenze specifiche.

• Pipeline CI/CD pre-deploy: un team che deve bloccare il rilascio di un’immagine con vulnerabilità critiche prima del push su un registry privato spesso preferisce Grype per la velocità sulle scansioni ripetute, soprattutto quando il flusso gira decine di volte al giorno su ogni pull request.
• Audit continuo di un cluster Kubernetes in produzione: qui Trivy resta l’unica opzione tra i due, grazie al Trivy Operator che scansiona i workload live e genera report come risorse Kubernetes native, senza bisogno di rieseguire manualmente la scansione a ogni deploy.
• Conformità al Cyber Resilience Act per un produttore di dispositivi connessi: un’azienda che vende hardware con componenti software nell’UE genera l’SBOM con Trivy o Syft e lo fa verificare da Grype per un secondo controllo di vulnerabilità, ottenendo un inventario più difendibile in caso di audit.
• Revisione di configurazioni IaC prima del merge: un team che vuole intercettare Dockerfile, Helm chart o file Terraform con configurazioni pericolose (porte esposte, permessi troppo ampi) usa Trivy nella stessa scansione che copre anche le CVE, evitando di aggiungere un tool separato.
• Prioritizzazione del backlog di vulnerabilità: un team di sicurezza applicativa con centinaia di CVE aperte usa i punteggi EPSS e la lista CISA KEV integrati in Grype per decidere quali patch applicare per prime, invece di affrontare le vulnerabilità in ordine di sola severità CVSS.
• Sviluppo locale con hook pre-commit: un singolo sviluppatore che vuole un controllo rapido prima di ogni push, senza aspettare l’intera pipeline CI, tende a preferire Grype per i tempi di scansione più bassi sulle esecuzioni ripetute con cache calda.
• Scansione periodica del registry per CVE scoperte dopo il deploy: un job notturno schedulato che riscansiona tutte le immagini già in produzione con Grype permette di individuare rapidamente le immagini esposte a una nuova CVE pubblicata dopo il build originale, senza dover ricostruire nulla per sapere quali workload sono a rischio.
• Doppio controllo prima di un audit esterno di sicurezza: in vista di un audit di conformità o di una certificazione, alcuni team eseguono sia Trivy sia Grype sullo stesso set di immagini e confrontano i risultati manualmente, per presentare all’auditor una copertura incrociata invece di affidarsi a un solo strumento.

Questi sei scenari non sono mutuamente esclusivi: la maggior parte dei team maturi finisce per combinarne almeno tre o quattro contemporaneamente, con scanner diversi attivi in punti diversi della stessa organizzazione a seconda della fase del ciclo di vita del software in cui si trovano.

Trivy: pro e contro

Trivy resta lo strumento più completo tra i due, ma quell’ampiezza ha un costo in termini di rumore e, dopo marzo 2026, anche di fiducia da ricostruire.

• Pro: un solo binario copre vulnerabilità, IaC, segreti, licenze e Kubernetes live
• Pro: community più ampia e maggiore visibilità nell’ecosistema CNCF
• Pro: generazione SBOM nativa, utile per la conformità CRA
• Contro: tasso di falsi positivi più alto in almeno due benchmark indipendenti citati
• Contro: coinvolto in un incidente di supply chain documentato nel marzo 2026
• Contro: più lento di Grype sulle scansioni ripetute con cache calda

Grype: pro e contro

Grype punta sulla precisione e sulla velocità di un ambito più stretto, con il compromesso di dover essere affiancato ad altri strumenti per coprire ciò che non fa.

• Pro: generalmente più veloce, specialmente sulle scansioni ripetute
• Pro: prioritizzazione del rischio con EPSS e CISA KEV integrata
• Pro: nessun incidente di sicurezza documentato nel 2026
• Pro: supporto OpenVEX per dichiarare l’effettiva sfruttabilità di una CVE
• Contro: nessuna scansione di Kubernetes live, IaC o segreti
• Contro: nessuna scansione delle licenze open source integrata
• Contro: nessuna dashboard nella versione open source, solo CLI

Guida alla migrazione: passare da uno scanner all’altro

Che la migrazione vada da Trivy verso Grype o viceversa, il processo pratico segue gli stessi passaggi di base, pensati per non interrompere una pipeline già in produzione. Il rischio più comune in questo tipo di migrazione non è tecnico ma organizzativo: interrompere bruscamente lo scanner precedente prima che il nuovo abbia dimostrato di coprire tutti i casi che il team considera critici, lasciando una finestra scoperta proprio nel momento in cui si sta cambiando strumento di sicurezza.

• Passo 1 – Inventario: elenca tutti i punti in cui lo scanner attuale è integrato: pipeline CI, admission controller Kubernetes, hook pre-commit, job schedulati.
• Passo 2 – Esecuzione parallela: installa il nuovo scanner accanto al vecchio per un periodo di due-quattro settimane, senza bloccare ancora le build sui suoi risultati.
• Passo 3 – Confronto dei falsi positivi: raccogli le differenze tra i risultati dei due strumenti sulle stesse immagini, per capire quante soppressioni (ignore-file) andranno riscritte nel nuovo formato.
• Passo 4 – Migrazione delle regole di esclusione: converti le regole di ignore da .trivyignore al formato YAML atteso da Grype, o viceversa, verificando riga per riga che gli ID CVE coincidano.
• Passo 5 – Aggiornamento della pipeline: sostituisci l’action nel workflow CI/CD, aggiorna le soglie di severità che bloccano la build e verifica che l’output (SARIF, JSON, CycloneDX) resti compatibile con gli strumenti a valle, inclusi eventuali sistemi di ticketing.
• Passo 6 – Ri-baseline delle policy: ridefinisci le soglie di rischio accettabile con il team di sicurezza, perché numeri di severità non sono sempre confrontabili 1:1 tra i due strumenti.
• Passo 7 – Dismissione: rimuovi il vecchio scanner dalla pipeline solo dopo aver validato per almeno un intero ciclo di rilascio che il nuovo strumento non genera falsi negativi critici.

Un dettaglio spesso trascurato riguarda la formazione del team: chi ha imparato a leggere l’output verboso di Trivy, con le sue sezioni separate per vulnerabilità, segreti e configurazioni, deve riabituarsi a un report di Grype più compatto e focalizzato solo sulle CVE. Vale anche il contrario per chi migra nella direzione opposta: passare da un output essenziale a uno molto più ricco di sezioni può inizialmente sembrare rumoroso, finché il team non impara a filtrare per severità e a ignorare le sezioni che non gli servono in quel contesto specifico.

Verdetto finale: quale scanner scegliere nel 2026

Non esiste un vincitore assoluto, e i dati raccolti in questo confronto lo confermano. Se un team ha bisogno di un solo strumento che copra vulnerabilità, configurazioni IaC, segreti, licenze e Kubernetes live in un’unica esecuzione, Trivy resta la scelta più pratica: nessun altro tool open source citato nelle fonti consultate offre la stessa ampiezza in un singolo binario. Se invece la priorità è la velocità su scansioni ripetute e una prioritizzazione del rischio più sofisticata grazie a EPSS e CISA KEV, i quattro benchmark citati (SafeGuard.sh, AppSec Santa, Lucaberton.com, Jacar) convergono tutti sulla stessa conclusione: Grype è generalmente più rapido, soprattutto quando la cache del database è già calda.

Riassumendo i dati raccolti in un’unica riga: Trivy vince su ampiezza di copertura, generazione SBOM nativa e maturità dell’ecosistema di integrazione; Grype vince su velocità nei test ripetuti, prioritizzazione del rischio con EPSS/KEV e assenza di incidenti di sicurezza documentati nel 2026. Nessuno dei due copre da solo l’intero perimetro di un programma di sicurezza container maturo, ed è per questo che la combinazione dei due, più che la sostituzione di uno con l’altro, resta l’opzione con il rapporto costo-beneficio migliore per la maggior parte dei team, dato che entrambi restano gratuiti a livello di CLI.

Il fattore che pesa di più sul lungo periodo, però, è quello meno tecnico: l’incidente di sicurezza di Trivy del marzo 2026 non invalida lo strumento, ma è un precedente che ogni team di sicurezza dovrebbe registrare nella propria valutazione del rischio di supply chain. Molte organizzazioni, di fatto, stanno risolvendo il dilemma non scegliendo, ma usando entrambi in punti diversi della pipeline: Trivy per la copertura ampia su IaC, segreti e Kubernetes, Grype come secondo controllo veloce e mirato sulle sole vulnerabilità prima del deploy finale.

Per un team che deve scegliere un solo strumento con risorse limitate, la domanda pratica da porsi è questa: cosa costa di più al mio team, un falso positivo occasionale o un blind spot su Kubernetes e IaC? Chi lavora prevalentemente su microservizi containerizzati con un’infrastruttura Kubernetes complessa tende a rispondere con Trivy. Chi gestisce pipeline ad alta frequenza con centinaia di build al giorno e vuole il minor overhead possibile tende a rispondere con Grype. Non è una scelta che va presa una volta sola: vale la pena rivalutarla ogni sei-dodici mesi, dato quanto velocemente entrambi i progetti stanno evolvendo, con Grype che nell’ultimo anno ha pubblicato più del doppio delle release di Trivy.

Domande frequenti su Trivy e Grype

Trivy e Grype sono entrambi completamente gratuiti?

Sì, entrambi sono distribuiti con licenza Apache-2.0 e possono essere usati senza limiti di scansioni o costi nascosti. Le funzionalità a pagamento riguardano solo le piattaforme enterprise separate (Aqua Security Platform e Anchore Enterprise), non gli strumenti da riga di comando.

Qual è più veloce tra Trivy e Grype?

Secondo i quattro benchmark indipendenti citati in questo articolo (SafeGuard.sh, AppSec Santa, Lucaberton.com e Jacar), Grype risulta generalmente più veloce, soprattutto sulle scansioni ripetute con database già scaricato. Sulla prima scansione a freddo la differenza si riduce e in un test risulta persino invertita.

Grype può sostituire Trivy per scansionare un cluster Kubernetes?

No. Grype non ha un operator o una modalità di scansione live per cluster Kubernetes nelle fonti consultate. Per quel caso d’uso Trivy, con il suo Trivy Operator, resta l’unica opzione tra i due strumenti.

Cos’è successo esattamente con l’incidente di sicurezza di Trivy nel 2026?

Il 19 marzo 2026 un soggetto malevolo ha usato credenziali compromesse per pubblicare una release contraffatta (v0.69.4) e modificare i tag delle action trivy-action e setup-trivy. L’episodio è tracciato come CVE-2026-33634. Aqua Security ha risposto ruotando le chiavi di firma e rimuovendo i trigger di workflow vulnerabili.

Trivy e Grype generano entrambi SBOM?

Trivy genera SBOM in modo nativo direttamente dalla CLI. Grype non genera SBOM da zero ma può analizzarne uno già prodotto (anche da Trivy o da Syft) e restituire un report di vulnerabilità basato su quell’inventario.

Posso usare Trivy e Grype insieme nella stessa pipeline?

Sì, ed è una pratica sempre più comune. Molti team eseguono Trivy per la copertura ampia (IaC, segreti, licenze, Kubernetes) e Grype come secondo controllo rapido e mirato sulle sole vulnerabilità prima del deploy finale.

Serve una licenza commerciale per usare Trivy o Grype in un’azienda?

No, la licenza Apache-2.0 permette l’uso commerciale senza costi né restrizioni particolari. Una licenza a pagamento serve solo se l’azienda vuole le funzionalità aggiuntive delle piattaforme enterprise di Aqua Security o Anchore, come dashboard centralizzate e supporto con SLA.

Trivy e Grype funzionano anche in ambienti offline o air-gapped?

Entrambi separano il motore di scansione dal database delle vulnerabilità, che va scaricato a parte: questo rende possibile, in linea di principio, scaricare il database su una macchina connessa e trasferirlo manualmente su un ambiente isolato per eseguire scansioni offline. È un’opzione usata soprattutto da organizzazioni con requisiti di sicurezza molto stringenti, come quelle nei settori energia, trasporti e finanza soggette a NIS2, dove aggiornare il database resta comunque un’operazione periodica da pianificare manualmente invece che in automatico, e dove il rischio di lavorare con dati non aggiornati va bilanciato con attenzione contro il vantaggio di isolare completamente l’ambiente di scansione dalla rete pubblica.