Dagli SBOM al gate delle vulnerabilità: Syft e Grype nella CI degli MSP

I managed service provider che gestiscono pipeline CI per i clienti possono combinare due strumenti open source di Anchore, Syft e Grype, in un unico gate per la supply chain software: Syft cataloga ogni pacchetto di una build in una distinta base software (SBOM), e Grype confronta quell'inventario con le vulnerabilità note prima di far passare la build. Questa guida spiega cosa fa ciascuno strumento, come si combinano e dove la coppia non basta da sola.

Genera prima l'inventario, con Syft

Syft, mantenuto da Anchore con licenza Apache-2.0, genera una distinta base software SPDX o CycloneDX da immagini container, filesystem e pacchetti. Anchore ha rilasciato syft v1.52.0 il 17 settembre, correggendo due bug dei cataloger che producevano inventari imprecisi: il cataloger del database RPM segnalava una versione di libreria obsoleta da un'immagine Rocky Linux 10 a singolo layer, e il cataloger degli archivi Java restituiva una versione sconosciuta per gli uber-jar. La release porta anche manutenzione delle dipendenze: 52 modifiche che risolvono sei vulnerabilità note, incluso un aggiornamento della libreria grpc-go che ha chiuso diversi advisory pubblicati. Le correzioni ai cataloger contano soprattutto per i team che usano immagini basate su RPM o uber-jar Java, dove una versione obsoleta o sconosciuta nella SBOM finirebbe per mascherare ciò che uno scanner a valle sta davvero controllando.

Grype trasforma l'inventario in un gate

Grype, anch'esso mantenuto da Anchore, analizza immagini container, filesystem e SBOM alla ricerca di vulnerabilità note. Al 23 settembre 2026, il suo repository GitHub mostrava circa 12.900 stelle e un commit di due giorni prima, segno di una manutenzione attiva. Integrato in una pipeline CI subito dopo la generazione della SBOM, Grype ti permette di far fallire automaticamente una build quando compare una CVE nota, invece di affidarti a chi dovrebbe ricordarsi di controllare più tardi. Il flusso standard genera la SBOM durante la build, di solito con Syft, poi esegue Grype su quella SBOM e, facoltativamente, direttamente sull'immagine creata, verificando ogni componente elencato rispetto ai dati sulle vulnerabilità note. Una soglia di gravità decide se il job fallisce: tutto ciò che la supera blocca il merge, a meno che non esista una deroga registrata con responsabile e scadenza.

Rendi le deroghe visibili, non silenziose

Un gate fail-closed serve a qualcosa solo se le deroghe sono visibili e hanno un responsabile. Senza un processo scritto, i team disattivano il gate la prima volta che blocca qualcosa di urgente, oppure accumulano override silenziosi che vanificano il senso stesso della scansione. Una deroga deve indicare un responsabile, un motivo e una data di scadenza dopo la quale il rilievo viene rivalutato, non derogato a tempo indeterminato.

Cosa non fa il gate

Grype ti dice cosa risulta vulnerabile in ciò che stai per rilasciare; non applica patch, non impone il principio del privilegio minimo e non sostituisce il monitoraggio a runtime una volta distribuito un carico di lavoro. Dipende inoltre dall'aggiornamento del suo database delle vulnerabilità, quindi bloccare lo scanner su un feed obsoleto vanifica lo scopo. Se standardizzi questo approccio tra le pipeline dei clienti, la mossa pratica è testare prima le soglie di gravità in una pipeline non di produzione, perché una soglia troppo aggressiva insegnerà solo ai team ad aggirare il gate. Archiviare ogni SBOM insieme al suo artefatto di build trasforma inoltre lo stesso inventario in un pacchetto di evidenza per clienti o assicurazioni, senza costi di scansione aggiuntivi. Se ti serve supporto esterno per penetration test, vulnerability assessment, incident response o conformità NIS2/DORA/GDPR, puoi rivolgerti ai servizi di cybersecurity di Altovar.

Cosa fare

• Aggiungi Syft come step di build che emette una SBOM SPDX o CycloneDX per ogni immagine o artefatto, e fai fallire la build se la generazione va in errore.
• Esegui Grype su quella SBOM, e facoltativamente sull'immagine creata, subito dopo, con una soglia di gravità testata prima in una pipeline non di produzione.
• Scrivi il processo di deroga prima che il gate vada in produzione: chi può concederla, cosa deve registrare e quando scade.
• Archivia ogni SBOM insieme al suo artefatto di build, così può servire in seguito come pacchetto di evidenza per clienti o assicurazioni.
• Mantieni aggiornato il database delle vulnerabilità di Grype; un feed obsoleto lascia passare build che il gate avrebbe dovuto bloccare.
• Abbina il gate a patching e monitoraggio a runtime, perché nessuno dei due strumenti copre ciò che accade dopo il deployment.

Fonti: Grype su GitHub, release di anchore/syft.