CRACI vs OX Security

En bref

OX Security est une plateforme de gestion de la posture de sécurité applicative (ASPM) dotée de ses propres scanners (SAST, SCA, secrets, IaC et conteneurs), de l'agrégation de résultats tiers, de politiques de posture CI/CD et d'un contexte d'exécution et cloud. Pour la sécurité de la chaîne d'approvisionnement, elle propose le Pipeline Bill of Materials (PBOM) : un enregistrement signé de la façon dont chaque artefact a été construit, du commit à la production en passant par la CI/CD.

CRACI est en concurrence pour le même budget consacré à la chaîne d'approvisionnement. La différence tient au point de vue. OX se connecte à la gestion de code source, aux systèmes CI et aux registres que vous utilisez déjà, et construit son tableau à partir d'eux. CRACI est le runner de build pour GitHub Actions : il enregistre ce que chaque job a réellement récupéré, applique une politique de trafic sortant pendant son exécution, surveille ce qui a été livré et produit des preuves pour le CRA. OX est bien plus large ; CRACI est le build lui-même.

En un coup d'œil

Ce qu'OX Security fait bien

• Un enregistrement de build qui va au-delà de la SBOM. Le PBOM d'OX capture les définitions de pipeline, l'identité du runner, les arguments de build, les signatures d'artefacts et la lignée des versions, et OX indique qu'il contient chaque composant open source résolu dans chaque build. Il est signé par build. OX génère aussi des SBOM en SPDX et CycloneDX.
• La posture CI/CD. Les politiques d'OX signalent les fichiers de workflow non sécurisés, les actions tierces non épinglées, les commandes GitHub Actions obsolètes, les permissions de workflow excessives, les secrets en clair et les webhooks à risque, et peuvent signaler les systèmes CI non approuvés pour les builds.
• L'application des règles dans le pipeline. La GitHub Action OX Security Scan exécute des scans de secrets, SAST, SCA et IaC et fait échouer le workflow lorsqu'elle trouve un problème bloquant au regard de vos politiques OX.
• L'agrégation. OX récupère les résultats de scanners tels que Checkmarx, Veracode, SonarQube, Snyk, Black Duck et JFrog Xray, en plus des siens.
• Une large couverture d'intégrations. Côté CI, il cite GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines, CircleCI et Drone CI, ainsi que huit systèmes de gestion de code source et dix registres de conteneurs.
• Des fonctionnalités pour l'ère de l'IA. OX VibeSec couvre le code et les dépendances générés par IA avec un AI Bill of Materials, et la remédiation par IA suggère des correctifs de code dans les pull requests et l'IDE.

Ce qui distingue CRACI

Enregistré par le runner, pas collecté depuis des outils connectés

La documentation d'OX indique que sa SBOM collecte des données depuis des sources connectées, notamment la gestion de code source, les pipelines CI/CD, les images de conteneur et les fichiers importés. Cela donne une vue large de votre parc. CRACI adopte une vue plus étroite et plus profonde de chaque build : un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant l'exécution du job, sur npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et sources Git, ainsi que des presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache est donc toujours pris en compte.

Chaque SBOM CRACI porte un état de complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Lorsque l'enregistrement présente une lacune, il le dit.

Le contrôle pendant l'exécution du build

Les politiques de posture d'OX vérifient la configuration d'un pipeline. CRACI limite ce que le build peut atteindre. Les politiques de trafic sortant fonctionnent en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git, et des règles TLS, TCP, UDP et ICMP explicites. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec, et CRACI peut vous alerter en cas de violation.

Provenance et surveillance à partir d'un seul enregistrement

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA. Il continue de réévaluer les SBOM de ce que vous avez livré à mesure que de nouvelles vulnérabilités sont publié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.

Là où OX a l'avantage

Disons-le clairement : CRACI ne propose ni SAST, ni scan de secrets, d'IaC ou de conteneurs, ni vérifications de posture CI/CD, ni agrégation de scanners tiers, ni contexte d'exécution ou cloud. Les policy gates de CRACI peuvent bloquer un build en fonction des résultats, mais CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. Si vous avez besoin d'une seule plateforme couvrant tous vos pipelines et tous vos scanners, OX couvre bien plus.

Lequel choisir

OX Security convient mieux si

• Vous voulez une seule plateforme ASPM qui agrège de nombreux scanners et priorise leurs résultats.
• Vous avez besoin de politiques de posture CI/CD sur GitLab, Jenkins, Azure Pipelines ou CircleCI.
• Vous voulez dès aujourd'hui un contrôle des pull requests sur les résultats de code, de secrets et d'IaC.

CRACI convient mieux si

• Vous construisez sur GitHub Actions et voulez le runner, la politique de trafic sortant et l'enregistrement des dépendances au même endroit.
• Vous avez besoin d'une SBOM de ce que chaque build a récupéré, avec un état de complétude à présenter à un auditeur.
• Vous voulez la surveillance de ce qui a été livré et des preuves pour le CRA à partir du même enregistrement.

Utiliser les deux

CRACI remplace le runner, pas GitHub Actions : l'action OX Security Scan s'exécute donc sur un runner CRACI comme n'importe quelle autre étape. OX peut importer des SBOM au format CycloneDX : CRACI peut donc lui fournir la SBOM enregistrée à partir du build.

Pour le Cyber Resilience Act

Le Cyber Resilience Act demande aux fabricants de connaître les composants de chaque produit, d'en gérer les vulnérabilités et de conserver des preuves. Les SBOM, le PBOM et les politiques de posture d'OX soutiennent le développement sécurisé et un inventaire de votre parc. 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 : SBOM de build exportées en CycloneDX ou SPDX, suivi des vulnérabilités et provenance via l'API. Aucun des deux outils ne vous rend conforme à lui seul. Voir les preuves pour le CRA et la conformité au CRA.

Ajouter CRACI

Installez la GitHub App CRACI sur votre organisation, puis remplacez le label du runner d'un job par runs-on: craci. Les exécutions apparaissent toujours dans l'interface GitHub. Commencez par un workflow qui produit un artefact de release et comparez la SBOM de CRACI avec celle qu'OX affiche pour le même dépôt. En savoir plus sur l'intégration CI/CD, la génération de SBOM au build et les tarifs.

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