Du SBOM au contrôle des vulnérabilités : Syft et Grype dans la CI des MSP

Les prestataires de services managés qui exploitent des pipelines CI pour leurs clients peuvent combiner deux outils open source d'Anchore, Syft et Grype, en un seul contrôle de la chaîne d'approvisionnement logicielle : Syft répertorie chaque paquet d'un build dans une nomenclature logicielle (SBOM), et Grype confronte cet inventaire aux vulnérabilités connues avant de laisser passer le build. Ce guide explique ce que fait chaque outil, comment ils s'articulent et où la combinaison ne suffit pas à elle seule.

Générez d'abord l'inventaire, avec Syft

Syft, maintenu par Anchore sous licence Apache-2.0, génère une nomenclature logicielle SPDX ou CycloneDX à partir d'images de conteneurs, de systèmes de fichiers et de paquets. Anchore a publié syft v1.52.0 le 17 septembre, corrigeant deux bugs de cataloguage qui produisaient des inventaires inexacts : le cataloguage de la base RPM signalait une version de bibliothèque obsolète sur une image Rocky Linux 10 à une seule couche, et le cataloguage des archives Java renvoyait une version inconnue pour les uber-jars. La version apporte aussi une maintenance des dépendances : 52 changements corrigeant six vulnérabilités connues, dont une mise à jour de la bibliothèque grpc-go qui a clos plusieurs avis publiés. Ces corrections comptent surtout pour les équipes qui s'appuient sur des images RPM ou des uber-jars Java, où une version obsolète ou inconnue dans le SBOM finirait par masquer ce qu'un scanner en aval vérifie réellement.

Grype transforme l'inventaire en contrôle

Grype, également maintenu par Anchore, analyse les images de conteneurs, les systèmes de fichiers et les SBOM à la recherche de vulnérabilités connues. Au 23 septembre 2026, son dépôt GitHub affichait environ 12 900 étoiles et un commit vieux de deux jours, signe d'une maintenance active. Intégré à une pipeline CI juste après la génération du SBOM, Grype vous permet de faire échouer un build automatiquement dès qu'une CVE connue apparaît, plutôt que de compter sur quelqu'un pour vérifier plus tard. Le flux standard génère le SBOM pendant le build, souvent avec Syft, puis exécute Grype sur ce SBOM et, en option, directement sur l'image construite, en comparant chaque composant listé aux données de vulnérabilités connues. Un seuil de gravité décide si le job échoue : tout ce qui le dépasse bloque le merge, sauf dérogation nommée et limitée dans le temps.

Rendez les dérogations visibles, pas silencieuses

Un contrôle fail-closed n'est utile que si les dérogations sont visibles et attribuées à un responsable. Sans processus écrit, les équipes finissent soit par désactiver le contrôle dès qu'il bloque quelque chose d'urgent, soit par accumuler des contournements silencieux qui annulent l'intérêt même du scan. Une dérogation doit indiquer un responsable, un motif et une date d'expiration après laquelle le constat est réévalué, et non être accordée indéfiniment.

Ce que le contrôle ne fait pas

Grype vous indique ce qui est connu pour être vulnérable dans ce que vous vous apprêtez à livrer ; il ne corrige rien, n'impose pas le principe du moindre privilège et ne remplace pas la surveillance en production une fois la charge de travail déployée. Il dépend aussi de la fraîcheur de sa base de données de vulnérabilités, donc figer le scanner sur un flux obsolète en annule l'intérêt. Pour standardiser cette approche sur les pipelines de plusieurs clients, il est conseillé de tester d'abord les seuils de gravité sur une pipeline hors production, car un seuil trop agressif ne fera qu'apprendre aux équipes à contourner le contrôle. Archiver chaque SBOM avec son artefact de build transforme aussi ce même inventaire en dossier de preuves pour les clients ou les assureurs, sans coût de scan supplémentaire. Pour un accompagnement externe en tests d'intrusion, évaluation de vulnérabilités, réponse à incident ou conformité NIS2/DORA/RGPD, vous pouvez faire appel aux services de cybersécurité d'Altovar.

Ce qu'il faut faire

• Ajoutez Syft comme étape de build qui produit un SBOM SPDX ou CycloneDX pour chaque image ou artefact, et faites échouer le build si la génération renvoie une erreur.
• Exécutez Grype sur ce SBOM, et en option sur l'image construite, immédiatement après, avec un seuil de gravité testé au préalable sur une pipeline hors production.
• Rédigez le processus de dérogation avant la mise en production du contrôle : qui peut l'accorder, ce qu'il doit consigner et quand elle expire.
• Archivez chaque SBOM avec son artefact de build afin qu'il puisse servir plus tard de dossier de preuves pour les clients ou les assureurs.
• Maintenez à jour la base de données de vulnérabilités de Grype ; un flux obsolète laisse passer des builds que le contrôle aurait dû bloquer.
• Associez le contrôle à des correctifs et à une surveillance en production, car aucun des deux outils ne couvre ce qui se passe après le déploiement.

Sources : Grype sur GitHub, versions d'anchore/syft.