CRACI vs Sonatype

En bref

Sonatype excelle dans la gouvernance de l'open source : des politiques qui décident quels composants sont autorisés, un pare-feu qui arrête les mauvais paquets au niveau du dépôt et une analyse qui vous indique ce qui s'est retrouvé dans votre application. CRACI est un runner CI compatible avec GitHub Actions qui enregistre chaque dépendance externe récupérée par un build, et produit la SBOM, la provenance et les preuves de conformité à partir de cet enregistrement. Sonatype est un scanner et un gardien. CRACI est un enregistreur, dont les policy gates peuvent aussi bloquer un build en fonction des résultats. La plupart des équipes qui ont besoin des deux les utiliseraient côte à côte.

Quel produit Sonatype fait quoi

Sonatype vend plusieurs produits, et les noms comptent pour cette comparaison :

• Sonatype Lifecycle est le produit d'analyse de la composition logicielle (SCA) et de politiques, auto-hébergé ou en SaaS.
• Sonatype Repository Firewall bloque et met en quarantaine les composants qui ne respectent pas vos politiques avant qu'ils n'entrent dans vos dépôts. Il est conçu pour Sonatype Nexus Repository. Sonatype Firewall Pro couvre d'autres gestionnaires de dépôts, tels que JFrog Artifactory, Cloudsmith et GitHub Packages, pour npm, Maven, PyPI et NuGet.
• Sonatype SBOM Manager importe, surveille et partage les SBOM, avec un workflow VEX.

L'offre évolue. La page de tarifs de Sonatype indique que toutes les capacités de Lifecycle sont désormais incluses dans Sonatype Guide, que les nouveaux clients achètent Guide pour le SCA et la gouvernance, et que Guide inclut aussi les capacités de conformité de SBOM Manager.

En un coup d'œil

Ce que Sonatype fait bien

Les politiques à grande échelle. Lifecycle est livré avec 18 politiques par défaut et plus de 30 contraintes personnalisables couvrant des règles de sécurité, juridiques et d'architecture. Les politiques de licences couvrent plus de 2 000 licences open source. Il priorise les résultats à l'aide de données d'atteignabilité, de changements cassants et de disponibilité des mises à niveau, et peut ouvrir des Golden Pull Requests avec les mises à niveau suggérées.

L'examen de ce que le build a produit. Les intégrations Lifecycle utilisent par défaut Advanced Binary Fingerprinting, qui examine tout ce que contient l'application après le build, y compris les dépendances embarquées, et peut identifier les composants renommés ou modifiés. Ce n'est qu'ensuite qu'il se rabat sur les lockfiles et les manifestes. Chaque rapport de scan peut être exporté sous forme de SBOM CycloneDX ou SPDX.

L'arrêt des mauvais paquets à l'entrée. Repository Firewall applique vos normes de sécurité, de licence et de qualité au moment du téléchargement et met en quarantaine les composants suspects. CRACI n'a pas d'équivalent aujourd'hui : le blocage de paquets figure sur sa roadmap.

L'adaptation à tous les pipelines. Sonatype s'intègre à Jenkins, GitHub Actions, GitLab CI, Azure DevOps et Bamboo, ainsi qu'à Maven, Gradle et une CLI pour les autres serveurs CI. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap.

Ce qui distingue CRACI

Il enregistre le build au lieu d'analyser sa sortie

L'empreinte binaire vous dit ce que contient l'application finie. Elle ne vous dit pas ce que le build a téléchargé en cours de route : compilateurs et chaînes d'outils, scripts d'installation, images de base, binaires de release récupérés avec curl ou paquets restaurés depuis un cache. CRACI les voit parce qu'il est le runner. Un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant l'exécution du job : npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et sources Git, ainsi que des presets de sources ou de téléchargement. Les preuves de dépendances suivent les caches CI : les paquets en cache sont donc toujours pris en compte.

Chaque SBOM indique sa propre complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Lorsque l'enregistrement présente une lacune, vous le savez.

Il contrôle où le build peut aller

Repository Firewall contrôle ce qui passe par le dépôt. Une politique de trafic sortant CRACI contrôle ce que le build peut atteindre tout court. Les politiques fonctionnent en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git. Elles sont validées avant le démarrage du job et bloquent tout en cas d'échec. Ensemble, les deux vous permettent de vous assurer que les jobs de build ne récupèrent des paquets que depuis les sources que vous approuvez, et que ces sources ne servent que des paquets que vous autorisez.

Il continue de surveiller ce qui a été livré

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

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.

Quand utiliser les deux

• Vous utilisez déjà Nexus Repository avec Firewall. Gardez-le comme point de contrôle. Ajoutez CRACI pour que chaque build dispose d'un enregistrement de ce qu'il a récupéré, et d'une politique de trafic sortant qui maintient les builds sur vos sources approuvées.
• Votre équipe juridique s'appuie sur les politiques de licences de Lifecycle. Gardez-les. CRACI inclut les métadonnées de licence déclarées dans son export de SBOM et applique lui aussi une politique de licences.
• Vous collectez les SBOM dans SBOM Manager. SBOM Manager importe CycloneDX et SPDX, les mêmes formats que CRACI exporte : les SBOM de build peuvent donc cohabiter avec celles que vous gérez déjà.
• Vos pipelines sont sur Jenkins ou Azure DevOps. Sonatype convient aujourd'hui. CRACI nécessiterait d'abord de passer ces pipelines sur GitHub Actions ; Jenkins figure sur sa roadmap.

Pour le Cyber Resilience Act

Sonatype publie un guide d'utilisation du CRA et une checklist CRA, et positionne SBOM Manager comme son produit pour le CRA. Son guide met en avant la génération de fichiers VEX pour rendre compte des vulnérabilités connues dans les SBOM, et Nexus Repository comme site de mise à jour pour distribuer les mises à jour de sécurité.

CRACI couvre le volet des preuves à partir du build : une SBOM pour chaque release avec sa complétude indiquée, la provenance, une surveillance continue des vulnérabilités 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 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. Voir la conformité au CRA et ce qu'est le CRA.

Ajouter CRACI en complément de Sonatype

CRACI remplace le runner, pas GitHub Actions. Remplacez runs-on par craci dans un workflow, et les exécutions apparaissent toujours dans l'interface GitHub. Vos étapes Sonatype restent dans le workflow. Commencez par un pipeline de release, comparez la SBOM de CRACI avec votre rapport Lifecycle et regardez ce qu'un seul des deux a vu.