CRACI vs Mend.io

En bref

Mend.io est une plateforme de sécurité applicative. Mend AppSec associe Mend SAST pour votre propre code à Mend SCA pour les dépendances open source et les conteneurs, et Mend Renovate maintient les dépendances à jour avec des pull requests automatisées. 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. Mend est un scanner. CRACI est un enregistreur. Si vous utilisez Mend aujourd'hui, CRACI ajoute une couche plutôt que d'en remplacer une.

En un coup d'œil

Ce que Mend.io fait bien

Prioriser ce qui est atteignable. Mend SCA trace le graphe d'appels depuis votre code à travers les dépendances directes et transitives pour déterminer si votre application invoque réellement une fonction vulnérable. Cela réduit la liste des résultats à traiter par une équipe. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, mais il ne réalise pas d'analyse d'atteignabilité.

Le code autant que les dépendances. Mend SAST couvre plus de 30 langages, et la CLI Mend scanne les composants open source, le code personnalisé, les images de conteneur et l'infrastructure as code. CRACI ne fait rien de tout cela.

Maintenir les dépendances à jour. Mend Renovate ouvre des pull requests pour les paquets obsolètes sur plus de 90 gestionnaires de paquets. Les éditions Renovate CLI et Community sont gratuites ; Enterprise ajoute des fonctionnalités de sécurité et du support.

Licences, paquets malveillants et SBOM. Mend SCA détecte les licences des dépendances directes et transitives et applique des politiques, comme le blocage d'AGPL dans les produits commerciaux. Il signale le typosquatting, la confusion de dépendances et les paquets contenant des portes dérobées ou du code d'exfiltration de données. Il produit des SBOM SPDX et CycloneDX, ingère des SBOM tierces et applique des données VEX.

Ce qui distingue CRACI

L'observation plutôt que la reconstitution

La documentation de Mend elle-même recommande de scanner après l'étape de build, car c'est le build qui donne au scanner l'accès aux registres privés et aux artefacts externes, et un scan sans build peut donner des résultats inexacts. C'est une bonne intuition. CRACI va un cran plus loin : au lieu de lire le projet une fois le build terminé, il enregistre le build lui-même.

Un proxy qui comprend les paquets, sur le runner CRACI, observe le trafic vers les sources de paquets pendant l'exécution du job, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : les paquets restaurés depuis un cache restent donc comptabilisés. Chaque SBOM indique sa complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Le contrôle du réseau du build

Comme CRACI exécute le job, il peut limiter les destinations du job. Les politiques de trafic sortant sont 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. Mend détecte un paquet malveillant une fois qu'il se trouve dans votre arbre de dépendances. Une politique de trafic sortant limite d'emblée les sources qu'un build peut joindre. Les deux couches interviennent à des moments différents.

Des preuves issues du build

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance.

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.

Lequel choisir

• Votre principal problème est un arriéré de résultats dans le code et les dépendances. Mend, avec le SAST, l'atteignabilité et Renovate, est conçu pour cela.
• Vous devez prouver ce qui est entré dans chaque release. CRACI l'enregistre par build et indique le niveau de complétude de l'enregistrement.
• Vos builds font plus qu'installer à partir d'un lockfile. Les téléchargements de chaînes d'outils, les images de base et les récupérations curl sont les domaines où l'observation apporte le plus.
• Vos pipelines sont sur Azure DevOps, Bitbucket ou CircleCI. Mend convient aujourd'hui. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap.

Pour le Cyber Resilience Act

Mend.io publie un guide de conformité au CRA et une page de conformité qui fait correspondre ses produits au règlement : Mend AppSec pour les SBOM CycloneDX et SPDX et la priorisation par atteignabilité, Mend Renovate pour le traitement continu des vulnérabilités via les mises à jour de dépendances, et la conformité des licences documentée aux côtés de la posture de sécurité.

CRACI apporte des preuves issues du build : une SBOM pour chaque release avec sa complétude indiquée, 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 les entreprises ont besoin pour leur démarche plus large de conformité au CRA. Aucun outil ne rend à lui seul un produit conforme. Voir la conformité au CRA et ce qu'est le CRA.

Ajouter CRACI en complément de Mend.io

CRACI remplace le runner, pas GitHub Actions. Définissez runs-on sur craci dans un workflow et les exécutions apparaissent toujours dans l'interface GitHub. Votre étape CLI Mend reste où elle est, après le build. Exécutez un pipeline de release sur CRACI et comparez sa SBOM à l'inventaire de Mend pour le même commit.