CRACI vs Kusari

En bref

Kusari est une plateforme de sécurité de la chaîne d'approvisionnement logicielle créée par l'équipe qui a cocréé GUAC, le graphe open source pour les métadonnées de la chaîne d'approvisionnement. Elle construit un graphe de connaissances mis à jour en continu à partir de votre code source, de vos SBOM, de vos documents VEX et de la sortie de vos scanners existants, classe ce qui est exploitable, passe en revue les pull requests et propose des correctifs. CRACI est un runner GitHub Actions. Il enregistre ce que chaque build récupère pendant son exécution, contrôle ce que le build peut joindre et continue de surveiller ce qui a été livré. Tout graphe reflète les SBOM qu'on lui fournit ; CRACI produit les SBOM à partir du build lui-même. Les deux se disputent le même budget de chaîne d'approvisionnement. Pour les logiciels que vous construisez vous-même, CRACI couvre la CI, la SBOM et le suivi des vulnérabilités dans un seul produit.

En un coup d'œil

Kusari et GUAC, précisément

GUAC (Graph for Understanding Artifact Composition) est un projet en incubation de l'OpenSSF, rattaché au groupe de travail Supply Chain Integrity et sous licence Apache 2.0. Il agrège les métadonnées de sécurité logicielle dans une base de données orientée graphe. Ses entrées documentées incluent les SBOM CycloneDX et SPDX, les attestations in-toto et SLSA, les documents OpenVEX et CSAF, les résultats d'OpenSSF Scorecard, ainsi que les données d'OSV et de deps.dev. GUAC agrège des métadonnées produites par d'autres outils ; il n'exécute pas de builds.

Les cofondateurs de Kusari ont cocréé GUAC avec Google, et un cofondateur de Kusari en est le mainteneur principal. Kusari indique utiliser GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined et d'autres projets open source dans ses produits commerciaux et en assurer la curation. GUAC compte aussi d'autres contributeurs, dont Google, Red Hat, l'université Purdue et Citi. Kusari est la plateforme commerciale ; GUAC est le projet communautaire.

Ce que Kusari fait bien

Un graphe construit à partir de standards ouverts. La plateforme de Kusari ingère le code source, les artefacts de build, les SBOM CycloneDX et SPDX, le VEX et la sortie des scanners existants, y compris les résultats de Snyk, Black Duck, Prisma Cloud, Dependabot et GitHub Advanced Security. Elle cartographie les dépendances directes et transitives avec leur provenance et leur lignée, et montre le rayon d'impact d'une nouvelle vulnérabilité sur l'ensemble de votre parc.

Moins de résultats, et de meilleurs. L'analyse d'atteignabilité et d'exploitabilité recherche des preuves que le code vulnérable est réellement appelé : la file d'attente contient ainsi ce qui compte. AutoFix génère des pull requests de correction et les valide avant qu'elles n'atteignent votre dépôt.

Des vérifications au niveau de la pull request. Kusari Inspector passe en revue chaque pull request sur GitHub ou GitLab à la recherche de vulnérabilités transitives, de secrets divulgués, de paquets malveillants ou typosquattés, de risques de licence, de dépendances en fin de vie, de workflows GitHub Actions non sécurisés et de faiblesses de code courantes. Kusari indique qu'Inspector s'installe gratuitement, sans passer par un commercial.

Standards et cadres. Kusari produit des SBOM et des attestations aux formats SPDX, CycloneDX et in-toto, et annonce la prise en charge de cadres tels que le CRA de l'UE, FDA 524B, SSDF, IEC 62443 et DORA. Son outil d'envoi fonctionne avec GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines et TeamCity.

Ce qui distingue CRACI

Kusari décrit son graphe comme construit à partir du code source et des systèmes de build au moment où le logiciel est créé, plutôt que reconstitué à partir de binaires finis. C'est la bonne intuition, et c'est aussi là que les deux produits divergent. Les SBOM de Kusari viennent d'un générateur : sa documentation décrit leur génération avec waybill, sa boîte à outils SBOM open source, lors de la fusion des pull requests, ou l'utilisation de votre propre outil. Un générateur lit les lockfiles, les manifestes, les caches et les images. CRACI ne lit pas les fichiers du build pour en déduire ce qu'il a utilisé. Il est la machine sur laquelle le build s'exécute.

Un enregistrement, pas une reconstitution

Une modification d'une ligne sur runs-on suffit pour que votre workflow s'exécute sur CRACI. Un proxy qui comprend les paquets enregistre ce que chaque job télécharge depuis les sources de paquets, et les paquets restaurés depuis les caches CI sont reportés. Chaque SBOM indique son niveau de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. La surveillance part de ce que le build a réellement récupéré, et elle sait où se trouvent les lacunes.

Du contrôle pendant le build

Un graphe vous aide à trouver ce qui est touché après coup. Une politique de trafic sortant sur le runner décide, pendant l'exécution du job, quels hôtes il peut joindre. Les politiques de CRACI sont en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, et elles sont validées avant le démarrage du job et bloquent tout en cas d'échec.

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. Il continue de réévaluer les SBOM surveillées.

CRACI ne fait pas ce qui distingue Kusari : il n'ingère pas les résultats d'autres scanners, n'analyse pas l'atteignabilité et ne passe pas en revue les pull requests à la recherche de paquets malveillants et de faiblesses de code. Il ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins 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 reconstituer l'information à partir de notes de version et de tableurs.

Remplacer Kusari par CRACI

Pour les logiciels que vous construisez et livrez, CRACI couvre ce pour quoi une plateforme de graphe est généralement achetée. Il exécute le build, enregistre la SBOM avec une complétude indiquée, continue de réévaluer les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, agrège les résultats de l'ensemble des builds et des dépôts, et permet aux équipes sécurité de les trier et d'envoyer chacun à l'équipe chargée de la correction. La politique de trafic sortant limite d'emblée ce qu'un build peut joindre, ce qu'aucun graphe ne peut faire.

Soyez clair sur ce à quoi vous renoncez. Kusari relie un seul graphe à de nombreux scanners et sources de SBOM, ingère le VEX, analyse l'atteignabilité et passe en revue les pull requests à la recherche de paquets malveillants, de secrets divulgués et de faiblesses de code. CRACI ne fait rien de tout cela aujourd'hui, et il ne prend en charge que GitHub Actions pour le moment, avec GitLab CI et Jenkins sur la roadmap. Si votre besoin principal est de corréler les résultats de nombreux outils existants, Kusari reste le meilleur choix.

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 tant qu'un produit est pris en charge. Le signalement des vulnérabilités activement exploitées s'applique à partir de septembre 2026. Kusari relie les SBOM, le VEX et les résultats dans un seul graphe, et cite le CRA parmi les cadres qu'il prend en charge. CRACI produit les preuves par build et continue de les surveiller : ce à partir de quoi chaque release a été construite, avec la provenance, une surveillance continue et l'export des SBOM en CycloneDX ou SPDX. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA ; aucun des deux outils ne rend un produit conforme à lui seul. Lire ce qu'exige le CRA.

Passer à CRACI

Définissez runs-on: craci sur les workflows qui construisent ce que vous livrez. CRACI remplace le runner, pas GitHub Actions, et les exécutions apparaissent toujours dans l'interface GitHub. En savoir plus sur la génération de SBOM au build et le suivi des vulnérabilités.

Vous comparez plus de deux outils ? Alternatives à Kusari compare neuf options côte à côte.