CRACI vs Harness

En bref

Harness, fondé en 2017 et basé à San Francisco, vend une plateforme pour tout ce qui suit l'écriture du code : intégration continue, livraison continue, feature flags, gestion des coûts cloud, chaos engineering et tests de sécurité. Son module Supply Chain Security (SCS) ajoute la génération de SBOM, la provenance SLSA, des garde-fous de politique OPA et des contrôles de posture pour les dépôts et les pipelines. Si vous voulez un seul fournisseur pour tout le pipeline de livraison, sur plusieurs fournisseurs Git, Harness est conçu pour cela.

CRACI est plus ciblé et va plus loin dans le build. C'est un runner GitHub Actions : pendant l'exécution de chaque job, il enregistre chaque dépendance externe récupérée par le build, applique une politique de trafic sortant au réseau du build, et produit à partir de cet enregistrement des SBOM, des données de provenance et une surveillance des vulnérabilités. Harness ajoute des étapes de chaîne d'approvisionnement à un pipeline ; CRACI fait du runner lui-même l'enregistrement de sécurité.

Un point pratique avant tout. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. Les pipelines Harness CI devraient passer sur GitHub Actions pour s'exécuter sur CRACI.

En un coup d'œil

Ce que Harness fait bien

Une seule plateforme pour la livraison. Harness couvre la CI, la CD, GitOps, les feature flags, l'infrastructure as code, le chaos engineering et la gestion des coûts cloud, avec une application des politiques fondée sur OPA sur l'ensemble. Il fonctionne avec GitHub, GitLab, Bitbucket, Azure Repos et ses propres dépôts Harness Code, et indique servir plus de 1 000 clients enterprise avec plus de 1 200 employés.

Le choix de l'infrastructure de build. Harness Cloud exécute les builds sur des machines Linux, Windows et macOS gérées par Harness : Linux AMD64 de 2 à 96 cœurs, ARM64 de 2 à 64 cœurs au même tarif, et macOS sur Apple M4. La virtualisation imbriquée est disponible sur Linux AMD64. Vous pouvez aussi exécuter les builds sur vos propres clusters Kubernetes, VM ou serveurs bare metal. Test Intelligence n'exécute que les tests concernés par un changement, et Build Intelligence et les fonctions de cache réutilisent les sorties et dépendances inchangées.

Des fonctionnalités de chaîne d'approvisionnement dans le pipeline. L'étape SBOM Orchestration du module SCS génère une SBOM pour une image de conteneur ou un dépôt de code avec Syft ou cdxgen, en SPDX ou CycloneDX, et peut ingérer des SBOM provenant d'autres outils. Harness indique générer et mettre à jour les SBOM à chaque build. Les politiques OPA peuvent bloquer les builds et les déploiements en fonction des composants, des licences ou de la provenance, et un outil de suivi de la remédiation suit les artefacts vulnérables.

La provenance SLSA. Harness documente les SLSA Build Level 1, 2 et 3 selon SLSA v1.0, avec une provenance signée via des attestations in-toto et cosign. Sa documentation précise que le Level 3 nécessite une infrastructure de build renforcée ou Harness Cloud, qui isole les processus de build les uns des autres.

Les contrôles de posture et de pipeline. SCS audite les dépôts et les pipelines au regard de l'OWASP Top 10 CI/CD Security Risks et des benchmarks CIS, et signale les GitHub Actions non épinglées, non vérifiées ou dotées de permissions excessives. Harness propose aussi ses étapes SCS sous forme de GitHub Actions et de composants GitLab CI/CD : le module n'est donc pas lié à Harness CI ; ces étapes nécessitent un compte Harness avec une licence SCS.

Ce qui distingue CRACI

La SBOM vient du build, pas d'un scan de sa sortie

Syft et cdxgen sont des scanners : ils lisent une image ou un dépôt après coup et en déduisent le contenu à partir des lockfiles, des manifestes et des bases de données de paquets. Cela fonctionne bien lorsque ces fichiers disent tout. Les builds en font souvent davantage : des scripts d'installation téléchargent du code, des scripts de build Rust récupèrent des éléments au moment du build, et des caches restaurent des paquets qu'aucun lockfile ne mentionne.

CRACI voit ce trafic, car il est le runner. Un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les sources de paquets, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement, et les preuves de dépendances suivent les caches CI. Il enregistre les dépendances cachées que les outils fondés sur les lockfiles manquent, et chaque SBOM indique son niveau de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Une politique sur le réseau du build, pas une détection après coup

Harness indique que son module détecte les comportements anormaux des runners CI, notamment les appels réseau et l'élévation de privilèges. CRACI suit l'autre voie : une politique de trafic sortant sur le runner décide quels hôtes un job peut joindre. Les politiques 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, sont validées avant le démarrage du job et bloquent tout en cas d'échec. Comme une politique de refus par défaut n'autorise que ce dont le build a besoin, au lieu de rechercher des hôtes connus comme malveillants, elle bloque l'exfiltration vers le serveur d'un attaquant, même pour une attaque que personne n'a encore vue. Les violations déclenchent une alerte.

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 et ne revendique aucun niveau SLSA ; Harness signe sa provenance et documente les Levels 1 à 3, et si une provenance signée ou un niveau SLSA est une exigence d'achat, cela joue en faveur de Harness. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, continue de réévaluer les SBOM surveillées à mesure que paraissent les avis de sécurité, et montre quels builds passés contenaient une dépendance vulnérable : vous connaissez ainsi la période pendant laquelle vous avez été exposé.

Des tarifs lisibles

CRACI ne facture que les minutes de build : $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), décompté à la seconde, sans abonnement mensuel ni frais par SBOM. Harness publie ses tarifs Harness Cloud, $0.005 par minute pour une machine Linux à 2 cœurs avec 7 Go et $0.080 pour 32 cœurs, arrondis à la minute la plus proche, tandis que ses plans payants et le module SCS sont tarifés via l'équipe commerciale. Le prix catalogue de CRACI est inférieur de 20 % par minute aux deux tailles ($0.004 contre $0.005, $0.064 contre $0.080) ; les machines Harness disposent de plus de mémoire par cœur.

Lequel choisir

• Restez sur Harness si vous voulez la CI, la CD, les feature flags et la gestion des coûts auprès d'un seul fournisseur, si votre code se trouve sur GitLab, Bitbucket ou Azure Repos, si vous avez besoin de Windows, de macOS ou de votre propre matériel de build, ou si un SLSA Build Level 3 documenté est une exigence.
• Choisissez CRACI si votre code est sur GitHub, que vous utilisez ou prévoyez d'utiliser GitHub Actions, et que vous voulez que la SBOM, la politique réseau et la provenance viennent du runner qui a effectué le build, avec une facturation à la minute de build.

Soyez clair sur ce à quoi vous renoncez en choisissant CRACI. Il ne déploie pas de logiciels, ne gère pas de feature flags et ne gère pas les coûts cloud, et il ne vérifie pas les dépôts et les pipelines au regard de benchmarks de posture et ne scanne pas le code source. Il n'exécute que des jobs Linux aujourd'hui, avec Windows et macOS sur la roadmap, et les runners hébergés par le client figurent sur la roadmap pour Enterprise.

Pour les produits réglementés

Des cadres tels que le Cyber Resilience Act de l'UE attendent des fabricants qu'ils sachent ce que contient chaque release et qu'ils en traitent les vulnérabilités, avec des obligations de signalement à partir de septembre 2026. Harness fournit des SBOM, une provenance et des résultats de politiques à partir de ses étapes de pipeline. CRACI produit les preuves à partir de l'enregistrement du build et exporte les SBOM en CycloneDX ou SPDX. Il automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont une entreprise a besoin pour sa démarche CRA plus large ; aucun des deux outils ne rend un produit conforme à lui seul.

Migrer un pipeline vers CRACI

CRACI remplace le runner, pas GitHub Actions, et les exécutions apparaissent toujours dans l'interface GitHub. Dès qu'un pipeline s'exécute sous forme de workflow GitHub Actions, il s'exécute sur CRACI avec une seule ligne :

runs-on: craci

En savoir plus sur la génération de SBOM au build, comparer les plateformes CI/CD, voir les alternatives à Harness ou consulter les tarifs.