CRACI vs Syft et Grype

La réponse courte

Syft est un générateur de SBOM open source populaire, et Grype est son scanner de vulnérabilités associé. Ensemble, ils couvrent la génération et le rapprochement gratuitement, dans n'importe quel pipeline. CRACI est un runner GitHub Actions qui enregistre ce que chaque build a récupéré, indique si cet enregistrement est complet, contrôle où le build peut se connecter et continue de surveiller ce qui a été livré. La différence en une ligne : Syft reconstitue la SBOM à partir de fichiers, et ce qu'il trouve dépend de sa configuration et de ce qui se trouve sur le disque au moment de son exécution. CRACI l'observe et suit les vulnérabilités de ce qu'il a enregistré : un seul produit fait donc le travail des deux.

Ce que Syft et Grype font bien

Syft est "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Il reconnaît des dizaines de systèmes de paquets, d'Alpine, Debian et RPM à Go, Python, Java, JavaScript, Ruby, Rust, PHP et .NET. Il écrit CycloneDX, SPDX et son propre format Syft JSON, convertit entre les formats et peut créer des attestations de SBOM signées selon la spécification in-toto.

Grype scanne les images de conteneurs, les systèmes de fichiers et les SBOM à la recherche de vulnérabilités connues. Il priorise les résultats avec EPSS, KEV et un score de risque, prend en charge OpenVEX pour filtrer les résultats, et son option --fail-on fait échouer un pipeline lorsqu'il trouve des vulnérabilités d'une sévérité égale ou supérieure à celle que vous choisissez. Anchore note que Grype "runs entirely locally and doesn't send any data to external services", hormis le téléchargement de sa base de données.

Tous deux sont sous Apache-2.0 et sponsorisés par Anchore, dont la plateforme commerciale, Anchore Enterprise, "builds on open source Syft and Grype." Cette page porte sur les outils open source.

Syft est performant lorsqu'il a les bons fichiers sous les yeux. Pointé vers une arborescence source qui commite ses dépendances, comme ollama/ollama, son scan par défaut les résout avec les versions, les package URL et les relations de dépendance entre elles.

Un flag change la réponse

Syft choisit ses catalogers selon le type de scan, et sa documentation explique pourquoi : "files that hint at the intent to install software do not have enough information in them to determine the exact version." Les catalogers portent des tags tels que declared, installed, image et directory, et des flags comme --select-catalogers et --override-default-catalogers modifient l'ensemble.

Dans syft cataloger list en v1.51.1, le cataloger JavaScript qui lit node_modules est tagué pour les scans d'images et d'éléments installés, et ne fait pas partie de l'ensemble par défaut pour un scan de répertoire. Ainsi, sur un checkout installé, un seul flag décide si les paquets npm de node_modules sont lus ou non. Même outil, même version, même arborescence.

Le revers de la médaille compte tout autant. Aucune configuration ne convient partout :

• Sur un checkout propre d'express 5.2.1, qui n'a pas de lockfile, le scan par défaut n'a aucune dépendance npm à résoudre et renvoie ce qu'il reconnaît par ailleurs, comme GitHub Actions et les fichiers de workflow.
• Activez les catalogers d'éléments installés et pointez-les vers des arborescences source telles que commitées, où rien n'a encore été installé : ils n'ont presque rien à lire.
• Un dépôt sans aucun manifeste de dépendances ne donne au scan aucun fichier de dépendances à lire, quelle que soit la configuration.

Rien de tout cela n'est un bug. Syft signale ce que permettent les fichiers qu'il a sous les yeux, comme prévu. La conséquence pratique est que la SBOM dépend de deux décisions que quelqu'un doit prendre correctement dans chaque pipeline : quels catalogers s'exécutent, et si les dépendances ont été installées avant le scan. Et Grype ne peut rapprocher que ce que Syft a listé. Un composant absent de la SBOM n'atteint jamais la recherche de vulnérabilités : le scan revient donc sans résultat pour lui.

Ce qui distingue CRACI

CRACI n'a pas de catalogers à choisir, car il ne lit pas l'arborescence après coup. Vous remplacez runs-on par craci, et un proxy qui comprend les paquets enregistre ce que le job récupère depuis les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les paquets restaurés depuis un cache CI conservent leurs preuves. Le résultat, en CycloneDX ou SPDX, comprend les dépendances transitives que le build a réellement utilisées.

• La complétude est explicite. Chaque job et chaque cache sont marqués Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.
• Le build est contrôlé. Une politique de trafic sortant (refus ou autorisation par défaut, 24 presets de sources logicielles intégrés) est validée avant le démarrage du job et bloque tout en cas d'échec.
• Données de provenance. L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance ; une attestation Syft signe la SBOM.
• Surveillance. Les SBOM surveillées sont réévaluées en continu, et les résultats sont agrégés sur l'ensemble des builds et des dépôts.

Grype fait encore des choses que CRACI ne fait pas. Le filtrage VEX et le scan d'images que vous n'avez pas construites sont le terrain de Grype. Les policy gates de CRACI peuvent faire échouer le build ; ses alertes à seuil figurent sur la roadmap.

Un inventaire de ce qui est déployé et où

La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée au lieu de le reconstituer à partir de notes de version et de tableurs.

Quitter Syft et Grype

Sur CRACI, il n'y a ni SBOM à générer ni étape de scan à maintenir. Le runner enregistre la SBOM pendant l'exécution du build, et CRACI continue d'y rechercher les nouvelles vulnérabilités une fois le build terminé. Syft et Grype restent les outils pour les images et les logiciels tiers que vous n'avez pas construits, et pour les pipelines en dehors de GitHub Actions.

Pour le Cyber Resilience Act

Le CRA demande aux fabricants de documenter les composants de chaque produit, y compris par une SBOM, et d'en gérer les vulnérabilités. Syft et Grype peuvent produire et vérifier cette SBOM, et la piste de preuves de chaque release jusqu'à sa SBOM est à votre charge. CRACI enregistre la SBOM par build et l'exporte en CycloneDX ou SPDX. Il automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement logicielle dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA. Voir ce qu'est le CRA et la génération de SBOM au build.