StepSecurity vs CRACI

La réponse courte

StepSecurity est une plateforme de sécurité de la chaîne d'approvisionnement logicielle qui couvre quatre points de contrôle : les machines des développeurs, les registres de paquets, les dépôts de code et la CI/CD. Son produit CI/CD, Harden-Runner, est un agent qui surveille chaque connexion sortante, chaque processus et chaque écriture de fichier d'un job, rattache chacun à l'étape du workflow qui l'a provoqué et peut bloquer le trafic sortant vers tout ce qui ne figure pas sur une liste d'autorisation. Enterprise coûte $16 par développeur contributeur et par mois, et les dépôts publics sur des runners hébergés par GitHub sont gratuits.

CRACI remplace le runner lui-même : sa politique de trafic sortant est appliquée par la plateforme de runners et validée avant le démarrage du job, et ce même job produit une SBOM au niveau des paquets. C'est le recoupement le plus étroit de CRACI avec un éditeur de sécurité, car tous deux restreignent ce qu'un build peut atteindre. La différence tient à l'endroit où se trouve le contrôle. Harden-Runner sécurise les runners que vous gardez, y compris ceux hébergés par GitHub. La politique de CRACI découle du fait qu'il est le runner, et il enregistre des paquets plutôt que de simples destinations.

En un coup d'œil

« Non précisé » signifie que nous n'avons pas pu le confirmer sur les pages publiques de StepSecurity.

Ce que StepSecurity fait bien

Harden-Runner

• Visibilité au niveau des étapes. Chaque connexion sortante, opération sur fichier et exécution de processus est rattachée à l'étape, au job et au workflow exacts où elle a eu lieu. L'offre Enterprise ajoute les arguments des processus, les chemins d'écriture des fichiers et des alertes par e-mail, Slack, Microsoft Teams ou votre SIEM.
• Auditer d'abord, bloquer ensuite. En mode egress-policy: audit, Harden-Runner établit une référence des appels sortants normaux de chaque job et signale toute nouveauté. Vous pouvez ensuite passer en mode blocage avec une liste d'autorisation de points de terminaison. Une liste de blocage globale de domaines réputés malveillants, tenue par StepSecurity, s'applique même en mode audit.
• Détection d'altération. Il alerte en cas de modification inattendue du code source pendant le build.
• Large couverture. Prise en charge complète sur les runners Linux hébergés par GitHub, mode audit sur Windows et macOS hébergés par GitHub et, sur l'offre Enterprise, VM auto-hébergées, bare metal et Actions Runner Controller. StepSecurity cite aussi GitLab CI, Azure DevOps et des runners tiers tels que Blacksmith, Depot et Namespace. Sur les runners auto-hébergés, l'agent est intégré à l'image du runner : les workflows n'ont donc pas besoin d'être modifiés.
• Références. StepSecurity indique que Harden-Runner a détecté la compromission de tj-actions/changed-files (CVE-2025-30066) et le paquet npm axios compromis, et qu'il sécurise plus de 25 millions d'exécutions de workflows par semaine. L'agent de l'offre Community est open source sous Apache 2.0.

Où s'exécute Harden-Runner

La matrice de prise en charge de StepSecurity pour GitHub Actions, en septembre 2026 :

Il n'est pas pris en charge lorsqu'un job entier s'exécute dans un conteneur sur des runners hébergés par GitHub, ni sur ubuntu-slim. Sur Actions Runner Controller, seuls les jobs Linux sont pris en charge.

Le reste de la plateforme

• Gouvernance des actions : un inventaire des actions tierces et des workflows réutilisables que vous utilisez, des workflows d'approbation pour les nouveaux, et StepSecurity Maintained Actions, des remplacements directs vérifiés.
• Secure Registry : délais de carence pour les nouvelles versions de paquets, blocage des versions réputées compromises, protection contre le typosquatting et listes de blocage à l'échelle de l'organisation, avec une seule politique pour les portables et la CI.
• Code Repo Security : contrôles sur les pull requests, et Orchestrate Security, qui ouvre des pull requests qui épinglent les actions sur des SHA de commit, définissent des permissions GITHUB_TOKEN au moindre privilège et déploient des configurations Dependabot.
• Dev Machine Guard : un inventaire des agents de code IA, des serveurs MCP, des extensions d'IDE et des paquets sur les machines des développeurs.

Ce qui distingue CRACI

Être le runner, pas un agent dessus

Sur les runners hébergés par GitHub, Harden-Runner est installé par une étape que vous ajoutez en première position de chaque job, et sa portée dépend de ce que l'infrastructure de GitHub autorise. Ce n'est pas un défaut du produit : cela découle du fait qu'il s'exécute sur une infrastructure appartenant à quelqu'un d'autre.

La politique de CRACI fait partie du runner. Elle est validée avant le démarrage du job, rejette les champs inconnus et bloque tout en cas d'échec : une politique qui ne peut pas être appliquée ne produit donc pas d'exécution non protégée. Les exécutions apparaissent toujours dans GitHub, et migrer un job revient à changer son label runs-on.

Des paquets, pas seulement des destinations

La liste d'autorisation de Harden-Runner est une liste de points de terminaison, et ses informations réseau montrent les hôtes contactés par chaque étape. Les sources de CRACI sont typées par écosystème, avec 24 presets intégrés de sources logicielles, des sources personnalisées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git via HTTPS et SSH, et des règles explicites TLS, TCP, UDP et ICMP. Un proxy qui comprend les paquets enregistre les paquets récupérés par chaque job, y compris ceux restaurés depuis les caches CI, et produit une SBOM CycloneDX ou SPDX avec un état de complétude par job et par cache.

Après le build

• Les données de provenance sont renvoyées par l'API avec les SBOM et les traces réseau. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA.
• La surveillance réévalue les SBOM de ce que vous avez livré à mesure que de nouvelles vulnérabilités apparaissent, et les équipes sécurité trient les résultats et les envoient aux équipes chargées de la correction.
• L'inventaire montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale : une nouvelle vulnérabilité renvoie donc directement aux produits qui exécutent la version concernée.

Prix

En septembre 2026, l'offre Community de StepSecurity est gratuite pour un nombre illimité de dépôts publics sur des runners hébergés par GitHub. L'offre Enterprise coûte $16 par mois et par développeur contributeur, c'est-à-dire toute personne ayant contribué à un dépôt sécurisé au cours des 90 derniers jours, et inclut Dev Machine Guard et Secure Registry. Dev Machine Guard seul coûte $8 par appareil et par mois. Les dépôts privés et les runners auto-hébergés nécessitent Enterprise, les deux offres payantes comportent un essai gratuit de 14 jours, et StepSecurity propose des remises sur volume. Harden-Runner sécurise des runners que vous payez déjà : les minutes de runner sont donc un coût distinct.

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. Comme CRACI est le runner, ce prix couvre la puissance de calcul comme les preuves. Consultez les tarifs de CRACI pour les conditions actuelles.

Lequel choisir

StepSecurity convient mieux lorsque

• vous voulez garder des runners hébergés par GitHub, y compris Windows et macOS.
• vous utilisez des runners auto-hébergés, GitLab CI ou Azure DevOps.
• vous voulez observer le trafic en mode audit avant de bloquer quoi que ce soit.
• vous avez besoin d'une visibilité au niveau des processus et des fichiers pour la réponse aux incidents.
• votre projet open source s'exécute sur des runners hébergés par GitHub et a besoin d'une option gratuite.

CRACI convient mieux lorsque

• vous voulez le runner et la politique de trafic sortant au même endroit, sans agent à déployer.
• vous avez besoin d'une SBOM de chaque build au niveau des paquets, avec un état de complétude.
• vous voulez surveiller ce qui a été livré.
• vous avez besoin de preuves pour le CRA, ou de la résidence des données dans l'UE sur le plan Enterprise de CRACI.

Ce à quoi vous renoncez en migrant des jobs vers CRACI

Soyons clairs : CRACI n'a pas encore de mode audit ou de surveillance (il figure sur la roadmap), ne surveille ni les processus ni les écritures de fichiers, ne s'exécute pas encore sur des runners hébergés par GitHub ni sur d'autres systèmes CI (GitLab CI et Jenkins figurent sur la roadmap), n'a de listes de blocage de paquets que sur sa roadmap, et ses alertes ne couvrent que les violations de politique, sans intégration Slack, Teams ou SIEM. Si ce sont vos priorités, StepSecurity les couvre aujourd'hui.

Secure Registry, Code Repo Security et Dev Machine Guard de StepSecurity protègent des points que CRACI ne touche pas : le registre d'où viennent vos paquets, vos dépôts et les portables des développeurs. Ils ne dépendent pas du runner : l'endroit où s'exécutent vos jobs ne les affecte donc pas.

Pour le Cyber Resilience Act

Le Cyber Resilience Act demande aux fabricants de connaître les composants de leurs produits, d'en traiter les vulnérabilités et de conserver des preuves. StepSecurity se concentre sur la prévention et la détection des attaques de la chaîne d'approvisionnement, et ses informations d'exécution aident lorsque vous enquêtez sur un incident en CI. 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 : des SBOM de build exportées en CycloneDX ou SPDX, le suivi des vulnérabilités et la provenance via l'API. Consultez les preuves pour le CRA.

Pour en savoir plus, consultez l'intégration CI/CD et la génération de SBOM au build, ou réservez une démo pour voir un job s'exécuter sous une politique de trafic sortant sur CRACI.

StepSecurity : vos questions, nos réponses

Qu'est-ce que StepSecurity ?

StepSecurity est une plateforme de sécurité de la chaîne d'approvisionnement logicielle. Son produit le plus connu, Harden-Runner, est un agent qui surveille le trafic réseau sortant, l'intégrité des fichiers et l'activité des processus sur les runners CI/CD et peut bloquer le trafic sortant hors d'une liste d'autorisation. La plateforme couvre aussi les registres de paquets (Secure Registry), les dépôts de code (Code Repo Security), les machines des développeurs (Dev Machine Guard) et le renseignement sur les menaces.

Combien coûte StepSecurity ?

En septembre 2026, l'offre Community est gratuite pour un nombre illimité de dépôts publics. Enterprise coûte $16 par développeur contributeur et par mois, un développeur contributeur étant toute personne ayant contribué à un dépôt sécurisé au cours des 90 derniers jours, et inclut Dev Machine Guard et Secure Registry. Dev Machine Guard seul coûte $8 par appareil et par mois. Les deux offres payantes comportent un essai gratuit de 14 jours, et les minutes de runner sont un coût distinct.

Harden-Runner est-il gratuit ?

Oui, pour les dépôts publics sur les runners hébergés par GitHub. Les dépôts privés et les runners auto-hébergés, y compris pour des dépôts publics, nécessitent l'offre Enterprise. L'agent de l'offre Community est open source sous licence Apache 2.0.

Quels runners Harden-Runner prend-il en charge ?

Les runners Linux hébergés par GitHub en mode audit et blocage, les runners Windows et macOS hébergés par GitHub en mode audit et, sur Enterprise, les VM auto-hébergées, le bare metal et Actions Runner Controller. StepSecurity cite aussi GitLab CI, Azure DevOps et des runners tiers tels que Blacksmith, Depot et Namespace. Il n'est pas pris en charge lorsqu'un job entier s'exécute dans un conteneur sur des runners hébergés par GitHub, ni sur ubuntu-slim.

Quelle est la différence entre StepSecurity et CRACI ?

Harden-Runner est un agent que vous ajoutez aux runners que vous gardez. CRACI est le runner : sa politique de trafic sortant est appliquée par la plateforme de runners, validée avant le démarrage du job et bloque tout en cas d'échec, et chaque job produit aussi une SBOM au niveau des paquets avec un état de complétude. StepSecurity est en avance sur le mode audit, la surveillance des processus et des fichiers, et la couverture des runners et des systèmes CI.

CRACI peut-il remplacer Harden-Runner ?

Pour les jobs GitHub Actions sous Linux, oui : migrer un job vers CRACI lui donne un contrôle du trafic sortant assuré par le runner lui-même, sans agent nécessaire sur ce job. Vous renoncez au mode audit (sur la roadmap de CRACI), à la surveillance des processus et des fichiers, et à la couverture des runners hébergés par GitHub, Windows, macOS et hors GitHub.

StepSecurity génère-t-il une SBOM ?

Harden-Runner enregistre les destinations, les processus et les fichiers touchés par un job, pas une SBOM du build au niveau des paquets. CRACI enregistre les paquets récupérés par chaque job, y compris ceux restaurés depuis les caches CI, et exporte du CycloneDX et du SPDX.