CRACI vs Timesys Vigiles

En bref

Vigiles est le produit de SBOM et de gestion des vulnérabilités de Timesys, société rachetée par Lynx Software Technologies en décembre 2023 ; Lynx le vend désormais sous le nom de Lynx Vigiles. Il est conçu pour le Linux embarqué : une couche Yocto, meta-timesys, collecte des métadonnées sur les paquets de votre image et les envoie, puis Vigiles les rapproche d'une base de données de CVE qualifiée, suit les décisions de tri et exporte des rapports SBOM, VEX et de vulnérabilités.

CRACI est un runner GitHub Actions. Votre build BitBake s'exécute dessus et, pendant ce temps, CRACI enregistre chaque paquet et chaque source que le build a récupérés, limite où le build peut se connecter et continue de surveiller les vulnérabilités de la SBOM. Les deux produits vous donnent une SBOM et une surveillance des CVE pour une image Yocto ; ils diffèrent par l'origine de la SBOM. Vigiles lit ce que les métadonnées de BitBake disent de l'image. CRACI enregistre ce que le build a réellement récupéré.

En un coup d'œil

Ce que Vigiles fait bien

Conçu pour le Linux embarqué. Vigiles s'intègre à Yocto via meta-timesys, ainsi qu'à Buildroot, OpenWrt, Timesys Factory et FreeRTOS, et importe des SBOM en SPDX 2.2 à 3.0.1, CycloneDX 1.1 à 1.7 et CSV pour tout le reste. Lynx indique que Vigiles, lancé en 2019, a traité plus de 90 000 SBOM.

Moins de bruit sur les CVE. Vigiles rapproche les composants d'une base de données de CVE qualifiée plutôt que de données publiques brutes, ce qui, selon Lynx, élimine la plupart des faux positifs que produisent les données publiques. Son scanner peut envoyer vos fichiers .config complets du noyau Linux et de U-Boot, afin de filtrer les CVE des fonctionnalités que vous ne construisez pas. C'est important sur le Linux embarqué : dans le rapport d'exemple du README de meta-timesys, 60 des 62 CVE non corrigées se trouvent dans le noyau.

Des décisions qui perdurent d'une release à l'autre. Les équipes enregistrent si chaque CVE est affected, fixed, deferred ou not exploitable, et Vigiles conserve ces décisions par release, met en avant les CISA Known Exploited Vulnerabilities et exporte des SBOM en CycloneDX, SPDX et SPDX Lite, ainsi que des rapports VEX et de vulnérabilités. Ses rapports montrent aussi les CVE déjà corrigées par des patchs de votre build et les patchs disponibles dans la couche meta-timesys-security. Lynx cite le CRA de l'UE et l'EO 14028 parmi les normes que Vigiles aide à respecter, et Vigiles se connecte à Jira et Okta.

Ce qui distingue CRACI

La SBOM de Vigiles n'est jamais plus complète que la vue de BitBake sur l'image. Le README de meta-timesys la décrit comme une collecte de métadonnées sur les paquets à installer, et les paquets construits hors de BitBake, ou construits par lui mais absents du manifeste du système de fichiers racine, doivent être listés à la main. CRACI ne lit pas de métadonnées. C'est la machine sur laquelle le build s'exécute.

Ce que la SBOM de Yocto laisse de côté

Nous n'avons pas comparé une SBOM Vigiles à celle de CRACI. Nous avons comparé celle de CRACI à la SBOM SPDX intégrée de Yocto, elle aussi générée à partir des métadonnées de BitBake. Dans un build comparatif de core-image-sato sur un runner ARM64 à 32 vCPU, la SBOM de CRACI contenait tous les composants de celle de Yocto, plus 88 qu'elle avait manqués : des paquets de l'hôte sur la machine de build tels que le cpio d'Ubuntu, des sources GitHub et la GitHub Action actions/upload-artifact, ainsi que d'autres sources et outils récupérés pendant le build. Aucun d'eux n'est installé dans l'image, et tous se trouvent sur le chemin critique du build.

Les deux SBOM listaient les mêmes 653 versions de crates Rust, mais celle de Yocto ne les liste que par nom de fichier et URL de téléchargement, sans package URL. Le rapprochement des vulnérabilités s'appuie sur les package URL : ces crates ne peuvent donc pas être surveillées à partir de la SBOM de Yocto. CRACI enregistre chacune d'elles avec une package URL pkg:cargo.

Le contrôle de ce que le build peut atteindre

Une politique de trafic sortant au niveau du runner décide à quels hôtes un job peut se connecter. Elle est validée avant le démarrage du job, bloque tout en cas d'échec et envoie une alerte en cas de violation. Pour Yocto, elle ajoute une seconde couche au BB_ALLOWED_NETWORKS de BitBake, et une politique de refus par défaut empêche un outil de build compromis d'envoyer des secrets vers un hôte dont le build n'a pas besoin.

Provenance et surveillance à partir du même enregistrement

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, continue de réévaluer les SBOM surveillées à mesure que paraissent les avis de sécurité, permet aux équipes sécurité de trier les résultats et de les envoyer à l'équipe chargée de la correction, et montre quels builds passés contenaient une dépendance vulnérable : vous connaissez ainsi la période pendant laquelle vous étiez concerné. CRACI prend en charge VEX et peut soumettre les notifications de vulnérabilités CRA en votre nom.

Le build lui-même, sur de plus gros runners

Vigiles n'exécute pas votre build ; CRACI, si. Les builds Yocto s'exécutent sur des runners allant jusqu'à 32 vCPU et 96 Go de RAM, décomptés à la seconde à $0.002 par minute vCPU ($0.004 pour un runner 2 vCPU par défaut). Dans la même comparaison de core-image-sato, le build sans la génération de SBOM de Yocto a pris 43 % de temps en moins que le build avec.

Remplacer Vigiles par CRACI

Pour les images Yocto construites dans GitHub Actions, CRACI couvre ce pour quoi on achète Vigiles : une SBOM pour chaque build, la surveillance des CVE après la release, les décisions de tri et VEX. Il ajoute ce qu'une SBOM fondée sur les métadonnées ne peut pas vous donner : les paquets de l'hôte, les sources GitHub et les Actions utilisés par le build, et une politique de trafic sortant pendant son exécution.

Soyez au clair sur ce à quoi vous renoncez. Les données CVE qualifiées de Vigiles et ses filtres de configuration du noyau et de U-Boot réduisent le bruit des CVE d'une façon que CRACI ne propose pas. Vigiles indique quelles CVE les patchs de votre build corrigent déjà, ce que CRACI n'enregistre pas ; le SPDX de Yocto porte aussi ces métadonnées de recette : gardez donc create-spdx activé si vous en dépendez. Vigiles couvre aussi Buildroot, OpenWrt et FreeRTOS, s'exécute dans n'importe quelle CI et importe des SBOM dans de nombreux formats. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap : les pipelines Jenkins ou GitLab devraient donc d'abord migrer vers GitHub Actions.

Pour le CRA

Le Cyber Resilience Act demande aux fabricants de documenter les composants de leurs produits, notamment au moyen d'une SBOM, et de gérer les vulnérabilités aussi longtemps qu'un produit est pris en charge, avec des obligations de signalement dès septembre 2026. Vigiles aide en conservant les SBOM, les décisions sur les CVE et les rapports par release. CRACI produit, pour chaque build, les preuves de ce qui est entré dans le firmware, avec la provenance, une surveillance continue et l'export des SBOM en CycloneDX ou SPDX. Il automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont un fabricant a besoin pour sa démarche plus large relative au CRA ; aucun des deux outils ne rend un produit conforme à lui seul. Lire ce qu'exige le CRA.

Migrer un build Yocto vers CRACI

Indiquez runs-on: craci sur le job BitBake et choisissez une taille de runner ; le workflow continue de s'exécuter dans GitHub Actions. L'exemple Yocto de la documentation CRACI construit core-image-sato sur la plus grande taille. Découvrez comment CRACI fonctionne pour l'IoT industriel et l'électronique grand public.