Suivi des vulnérabilités
Suivez chaque vulnérabilité connue dans les logiciels que vous livrez, du build qui l'a introduite à la release qui l'a corrigée. CRACI enregistre la SBOM de chaque build, la confronte en continu aux nouvelles données de vulnérabilités et transmet chaque résultat à l'équipe chargée de la correction.
Qu'est-ce que le suivi des vulnérabilités ?
Le suivi des vulnérabilités est l'enregistrement continu de chaque vulnérabilité connue qui touche votre logiciel, de sa découverte jusqu'à sa correction ou son exclusion. Pour chacune, il répond à quatre questions : où se trouve-t-elle, quels produits et releases l'incluent, qui est responsable de la correction, et quel est son statut.
De nombreux outils répondent à la première question en scannant après coup les fichiers manifestes et les lockfiles, et laissent le reste aux tableurs et aux tickets. CRACI intervient plus tôt. Vos jobs GitHub Actions s'exécutent sur les runners CRACI et, pendant leur exécution, CRACI enregistre chaque paquet que le build a réellement récupéré, y compris les paquets restaurés depuis les caches CI. C'est cette SBOM générée au build que CRACI surveille : les vulnérabilités que vous suivez sont celles de l'artefact que vous avez livré, pas celles d'un scan exécuté quelque part à côté.
Suivre les logiciels que vous livrez, pas seulement vos actifs IT
La plupart des outils de suivi des vulnérabilités sont conçus pour l'IT : ils scannent serveurs, ordinateurs portables et comptes cloud, et le correctif est un patch que quelqu'un installe. Un logiciel que vous construisez et vendez demande un autre type d'enregistrement. Le code vulnérable se trouve dans votre release, le correctif est un nouveau build, et clients comme autorités demandent quelles versions ont été touchées et pendant combien de temps.
C'est l'enregistrement que tient CRACI : la SBOM de chaque build, les produits et versions sur lesquels elle a été déployée, les composants fournisseurs que vous avez achetés, et le statut de chaque vulnérabilité sur l'ensemble.
Une réévaluation continue de ce que vous avez livré
CRACI enregistre la SBOM pendant l'exécution de chaque build, puis réévalue en continu les SBOM surveillées au regard des données de vulnérabilités. Une vulnérabilité publiée longtemps après une release apparaît quand même sur la release qu'elle touche, sans que personne ne relance de scan.
Une vue unique sur les builds et les dépôts
Les résultats sont agrégés sur l'ensemble des builds et des dépôts, avec des vues d'organisation sur la branche par défaut. La vue d'inventaire montre exactement quelles versions logicielles sont déployées sur quels produits, et l'historique des builds indique quels builds passés contenaient une dépendance vulnérable : vous savez quels produits ont été touchés et pendant combien de temps.
Tri et transmission à l'équipe responsable
Les équipes sécurité trient les vulnérabilités découvertes et les transmettent aux équipes chargées de la correction, pour que chaque résultat parvienne aux personnes qui peuvent agir. CRACI prend aussi en charge VEX pour consigner l'effet d'une vulnérabilité sur votre produit, et les policy gates peuvent bloquer tout build qui contient une CVE précise.
Les SBOM fournisseurs suivies aux côtés des vôtres
Ajoutez les SBOM de vos fournisseurs : les composants achetés sont surveillés aux côtés des logiciels que vous construisez. Le code tiers de votre produit est suivi au même endroit que vos propres dépendances.
Du résultat à la notification CRA
Pour le Cyber Resilience Act, CRACI soumet en votre nom les notifications de vulnérabilités : l'alerte précoce, la notification et le rapport final. Les SBOM s'exportent en CycloneDX ou SPDX avec les vulnérabilités trouvées dans leurs composants, pour les audits, les clients et vos propres archives.
Chaque paquet vulnérable, et ce qui l'apporte
Chaque build liste ses paquets avec leur version, leur package URL, leur licence et leur statut de vulnérabilité, et indique si sa SBOM est complète. Ouvrez un paquet pour voir ses avis de sécurité avec leur sévérité, ainsi que les paquets qui en dépendent.
Le cycle de suivi des vulnérabilités dans CRACI
- Découvrir. Chaque build produit une SBOM avec un état de complétude, exportée en CycloneDX ou SPDX avec les dépendances transitives. Les SBOM surveillées, les vôtres comme celles de vos fournisseurs, sont réévaluées en continu au regard des données de vulnérabilités.
- Localiser. Les vues d'organisation sur l'ensemble des builds et des dépôts, la vue d'inventaire et l'historique des builds montrent quels produits et versions sont touchés, et depuis quand.
- Prioriser et trier. Chaque avis de sécurité affiche sa sévérité. Les équipes sécurité trient chaque résultat, avec la prise en charge de VEX pour consigner l'effet d'une vulnérabilité sur votre produit.
- Corriger. Chaque résultat est transmis à l'équipe chargée de la correction, et « Required by » montre quel paquet apporte une vulnérabilité transitive. Les policy gates peuvent écarter une CVE précise des builds ultérieurs.
- Vérifier. La SBOM du build suivant montre si la version vulnérable a disparu : l'enregistrement va ainsi jusqu'à la release corrigée.
- Rendre compte. CRACI soumet en votre nom les notifications de vulnérabilités prévues par le CRA, et les SBOM s'exportent avec les vulnérabilités trouvées dans leurs composants.
Ce qu'il faut suivre pour chaque vulnérabilité
- Vulnérabilité
- L'avis de sécurité et ses identifiants (CVE, GHSA et autres), avec sa sévérité.
- Composant
- Le paquet et sa version exacte, et s'il s'agit d'une dépendance directe ou transitive.
- Chemin
- Les paquets qui apportent le paquet vulnérable, ce qui vous indique quoi mettre à jour.
- Exposition
- Les produits, releases et builds qui l'incluent, et depuis quand.
- Responsable
- L'équipe chargée de la correction.
- Statut
- Ouverte, en cours d'analyse, non concernée ou corrigée, idéalement consignée en VEX.
- Preuve
- Le build ou la release qui ne contient plus la version vulnérable.
Les indicateurs qui montrent si le suivi fonctionne
Les équipes sécurité suivent généralement quatre chiffres :
- Temps moyen de correction (MTTR) : le délai entre la découverte d'une vulnérabilité et une release qui ne la contient plus.
- Respect des délais de correction : la part des vulnérabilités corrigées dans le délai fixé par votre politique selon leur sévérité.
- Évolution du backlog : si le nombre de vulnérabilités ouvertes augmente ou diminue.
- Fenêtre d'exposition : pendant combien de temps chaque produit a livré une version vulnérable. L'historique des builds de CRACI montre quels builds contenaient une dépendance vulnérable : vous connaissez la période pendant laquelle vous étiez touché.
Ce que CRACI ne fait pas aujourd'hui
CRACI ne propose pas d'analyse d'atteignabilité : il ne classe donc pas les résultats selon que votre code appelle ou non la fonction vulnérable. Il n'affiche pas d'indicateurs de correction tels que le MTTR, le respect des délais ou l'évolution du backlog. Il n'envoie pas aujourd'hui d'alertes sur un seuil de sévérité, et ses alertes couvrent les violations de la politique de trafic sortant. Les commentaires sur les résultats, la comparaison entre releases, les alertes sur seuil et les webhooks de vulnérabilités figurent sur la roadmap.
VEX : les vulnérabilités qui touchent réellement votre produit
Un composant vulnérable dans votre SBOM ne signifie pas toujours un produit vulnérable. Le code concerné peut ne pas être inclus dans ce que vous livrez, ou ne pas être atteignable de la manière dont une attaque en a besoin. VEX (Vulnerability Exploitability eXchange) est un moyen lisible par machine de le dire : chaque déclaration VEX relie un produit, une vulnérabilité et un statut. Les statuts standard sont non concerné, concerné, corrigé et en cours d'analyse.
C'est important dès que clients et autorités confrontent vos SBOM aux bases de données de vulnérabilités. Sans déclaration VEX, chaque correspondance ressemble à un problème ouvert, et votre équipe finit par expliquer les mêmes faux positifs encore et encore. CRACI prend en charge VEX pour consigner l'effet d'une vulnérabilité sur votre produit, en complément du tri qui transmet chaque résultat à l'équipe chargée de la correction.
Vous vous demandez combien il y a à suivre ? Découvrez combien de CVE sont publiées chaque jour et comment le volume de vulnérabilités High et Critical a augmenté.
Le suivi des vulnérabilités, expliqué
Questions fréquentes sur le suivi des vulnérabilités dans les logiciels que vous construisez et achetez
Qu'est-ce que le suivi des vulnérabilités ?
Le suivi des vulnérabilités est l'enregistrement continu de chaque vulnérabilité connue qui touche votre logiciel, du moment où elle est découverte jusqu'à sa correction ou son exclusion : dans quel composant et quelle version elle se trouve, quels produits et releases l'incluent, qui est responsable de la correction et quel est son statut. Pour un logiciel que vous livrez, il part d'une liste exacte des composants, ce que fournit une SBOM.
Quelles sont les étapes de la gestion des vulnérabilités ?
Le cycle habituel compte cinq étapes : découvrir les vulnérabilités dans ce que vous exécutez ou livrez, les prioriser, les corriger, vérifier que le correctif les a supprimées, et rendre compte. Le suivi relie ces étapes, pour qu'un résultat ne se perde pas entre la découverte et une release corrigée. Dans CRACI, les étapes consistent à enregistrer la SBOM au build, trier chaque résultat, le transmettre à l'équipe responsable, confirmer qu'un build ultérieur ne contient plus la version vulnérable, et rendre compte via les exports de SBOM et les notifications CRA.
Comment suivre la correction des vulnérabilités ?
Attribuez à chaque vulnérabilité un responsable et un statut, et ne la clôturez que lorsqu'un build ou une release ne contient plus la version vulnérable. Mesurez le temps que prennent les corrections, si elles respectent vos délais et si le backlog ouvert diminue. Dans CRACI, la SBOM de chaque build montre si la version vulnérable est toujours présente, et un policy gate peut écarter une CVE précise des builds ultérieurs.
Qu'est-ce que la gestion des vulnérabilités basée sur la SBOM ?
La gestion des vulnérabilités basée sur la SBOM consiste à confronter les composants listés dans vos nomenclatures logicielles aux données de vulnérabilités, et à recommencer à mesure que de nouvelles vulnérabilités sont publiées. Le résultat ne vaut que ce que vaut la SBOM. CRACI enregistre la SBOM pendant l'exécution du build : la liste reflète donc ce que le build a réellement récupéré, y compris les paquets restaurés depuis les caches CI.
En quoi le suivi des vulnérabilités diffère-t-il du scan de vulnérabilités ?
Un scan est un instantané : il lit des fichiers, signale des résultats et s'arrête. Le suivi conserve les résultats, leurs responsables et leur statut dans le temps, et continue de vérifier les logiciels livrés à mesure que de nouvelles vulnérabilités apparaissent. CRACI est un enregistreur, pas un scanner : il enregistre chaque build, puis réévalue en continu les SBOM surveillées.
CRACI suit-il les vulnérabilités des logiciels tiers ?
Oui. Vous pouvez ajouter les SBOM de vos fournisseurs, et ces composants achetés sont surveillés aux côtés des logiciels que vous construisez sur CRACI.
CRACI peut-il bloquer un build qui contient une vulnérabilité connue ?
Oui. Les policy gates peuvent bloquer un build en fonction des résultats, y compris tout build qui contient une CVE précise, pour qu'une vulnérabilité que vous avez corrigée ne revienne pas dans un build ultérieur.
Comment CRACI me prévient-il des vulnérabilités ?
Les résultats apparaissent dans les vues d'organisation de CRACI, où les équipes sécurité les trient et les transmettent aux équipes responsables. Les alertes couvrent aujourd'hui les violations de la politique de trafic sortant. Les alertes sur seuil et les webhooks de vulnérabilités figurent sur la roadmap, tout comme les alertes Slack et Teams.
CRACI aide-t-il à déclarer les vulnérabilités au titre du CRA ?
Oui. CRACI soumet en votre nom les notifications de vulnérabilités prévues par le CRA : l'alerte précoce, la notification et le rapport final. Le respect du Cyber Resilience Act reste la démarche du fabricant ; CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont cette démarche a besoin.
CRACI prend-il en charge VEX ?
Oui. CRACI prend en charge VEX (Vulnerability Exploitability eXchange) pour consigner l'effet d'une vulnérabilité connue sur votre produit, en complément du tri et de la transmission à l'équipe chargée de la correction. Une déclaration VEX indique aux clients et aux autorités si une vulnérabilité détectée dans votre SBOM touche réellement le produit, pour qu'ils ne courent pas après des faux positifs. Réservez une démo pour voir comment cela s'intègre à votre processus de tri.
CRACI fait-il de l'analyse d'atteignabilité ?
Non. CRACI ne propose pas d'analyse d'atteignabilité (reachability analysis). Il montre lesquels de vos builds, dépôts et produits contiennent un composant vulnérable, et prend en charge VEX pour consigner l'effet d'une vulnérabilité sur votre produit.
Découvrez le suivi des vulnérabilités sur vos propres builds
Réservez une démo : nous vous montrerons quelles vulnérabilités atteignent les logiciels que vous livrez, et qui est responsable de chaque correctif
Réserver une démo