Outils et plateformes de sécurité de la chaîne d'approvisionnement logicielle (2026)

À qui s'adresse cette page

Vous êtes chargé de « sécuriser notre chaîne d'approvisionnement logicielle » et devez décider où va le budget. Les outils ci-dessous agissent à différents endroits : sur vos dépôts et vos pipelines, sur le runner de build, au niveau du registre de paquets, ou sur l'artefact final. Nous développons CRACI, qui est en concurrence directe dans cette catégorie : tenez-en compte. Nous décrivons chaque outil d'après sa propre documentation et disons où un autre outil convient mieux.

Qu'est-ce que la sécurité de la chaîne d'approvisionnement logicielle ?

Pour le guide complet, voir qu'est-ce que la sécurité de la chaîne d'approvisionnement logicielle, et la checklist des bonnes pratiques.

Votre logiciel, c'est votre propre code plus tout ce dont il dépend : paquets open source, images de base, outils de build, actions CI tierces et le pipeline qui transforme le tout en release. La sécurité de la chaîne d'approvisionnement logicielle est le travail qui consiste à savoir ce que sont ces éléments, à contrôler d'où ils viennent et à prouver ce qui est entré dans chaque release. La sécurité applicative recherche les failles du code que vous écrivez ; la sécurité de la chaîne d'approvisionnement couvre ce qui l'entoure.

Les attaquants s'en prennent à chaque maillon. Trois incidents récents montrent où :

• Une dépendance. En mars 2024, du code malveillant a été découvert dans les versions 5.6.0 et 5.6.1 de xz utils, une bibliothèque de compression livrée dans les distributions Linux (CVE-2024-3094).
• Le pipeline CI. En mars 2025, la GitHub Action tj-actions/changed-files a été compromise (CVE-2025-30066), exposant des secrets tels que des clés d'accès, des personal access tokens GitHub et des tokens npm des workflows qui l'utilisaient.
• Le registre de paquets. En septembre 2025, le ver auto-réplicatif Shai-Hulud a compromis plus de 500 paquets npm. Il a volé des identifiants de développeurs, dont des tokens GitHub et des clés cloud, et s'en est servi pour publier d'autres paquets infectés.

1:53

Quels types d'outils de sécurité de la chaîne d'approvisionnement logicielle existe-t-il ?

Aucun produit ne couvre à lui seul tous les maillons, et les éditeurs ci-dessous n'entendent pas la même chose par « sécurité de la chaîne d'approvisionnement ». La plupart des solutions relèvent de l'un des sept types suivants, définis par l'endroit où elles agissent.

Comment choisir une plateforme de sécurité de la chaîne d'approvisionnement logicielle ?

Partez de la question à laquelle vous ne savez pas répondre aujourd'hui, puis choisissez l'outil qui agit là où se trouve la réponse. Six questions départagent rapidement les options.

• Avez-vous besoin d'étendue ou de profondeur ? Une plateforme de gestion de la posture de sécurité des applications (ASPM) se connecte à vos dépôts, pipelines et scanners et priorise les risques sur l'ensemble. Un outil au niveau du build va plus loin sur un point : ce qui s'est passé pendant la construction du logiciel.
• Voulez-vous garder vos runners ? Des agents tels que StepSecurity Harden-Runner et Cimon de Cycode ajoutent de la surveillance aux runners que vous utilisez déjà. CRACI remplace le runner pour GitHub Actions.
• Le risque se situe-t-il dans vos entrées ? Si les paquets malveillants ou les images de base pleines de CVE vous inquiètent le plus, les outils qui filtrent ou durcissent les entrées s'y attaquent directement.
• Livrez-vous des logiciels que vous n'avez pas construits ? Seule l'analyse de binaires peut examiner l'intérieur d'un paquet sans son build.
• Quels systèmes CI utilisez-vous ? La plupart des outils présentés ici en couvrent plusieurs. CRACI prend en charge uniquement GitHub Actions aujourd'hui, et GitLab CI et Jenkins figurent sur la roadmap.
• Que devrez-vous prouver, et à qui ? Les clients, les auditeurs et des réglementations telles que le Cyber Resilience Act de l'UE demandent de plus en plus une SBOM par release et un enregistrement de la façon dont les vulnérabilités ont été traitées. Un tableau de bord de résultats n'est pas la même chose qu'une preuve de ce qui a été livré.

Posez ensuite les mêmes questions à chaque éditeur de votre liste restreinte :

• D'où vient votre liste de composants : manifestes, analyse des sources, build ou binaire final ?
• La SBOM m'indique-t-elle quand elle est incomplète, et s'exporte-t-elle en CycloneDX ou SPDX ?
• Pouvez-vous empêcher un build d'atteindre un hôte inattendu, ou seulement le signaler après coup ?
• Puis-je vérifier plus tard que l'artefact que je déploie est bien celui qui a été construit ?
• Quels systèmes de gestion de code source et de CI prenez-vous en charge aujourd'hui, et lesquels figurent sur la roadmap ?
• Quelle est l'unité de tarification : développeurs, contributeurs, images, builds ou devis ?

Comment les outils se comparent-ils ?

Les outils se répartissent en deux familles, d'où deux tableaux. Le premier compare les plateformes et les outils de sécurité du build sur la façon dont ils voient et contrôlent le pipeline. Le second compare les outils qui agissent sur les entrées et les sorties. « Non précisé » signifie que les pages des éditeurs que nous citons ne se prononcent pas.

Plateformes et sécurité du build

Entrées et sorties

Combien coûtent les outils de sécurité de la chaîne d'approvisionnement logicielle ?

Cinq des neuf outils ci-dessous facturent par développeur, et la plupart vendent leurs plans payants via leur équipe commerciale. CRACI ne facture que les minutes de build : le coût suit donc le volume de ce que vous construisez plutôt que le nombre de personnes qui commitent. Les prix sont ceux publiés par chaque éditeur en septembre 2026 ; Apiiro et Legit Security sont absents car leurs pages n'indiquent aucun tarif.

La tarification par développeur augmente avec votre équipe ; la tarification à la minute de build augmente avec vos pipelines. Le prix de CRACI inclut les minutes de runner, qui remplacent ce que vous payez pour les runners hébergés par GitHub. Voir les tarifs de CRACI et le comparatif des prix des runners. Pour des graphiques des prix publiés selon la taille de l'équipe, runner inclus, voir le comparatif des prix de la sécurité de la chaîne d'approvisionnement logicielle.

CRACI

CRACI est un runner pour GitHub Actions. Vous remplacez runs-on par craci et, pendant l'exécution de chaque job, un proxy qui comprend les paquets enregistre ce qu'il a récupéré, y compris les paquets restaurés depuis les caches CI. Chaque SBOM comporte un état de complétude par job et par cache, une politique de trafic sortant est validée avant le démarrage du job et bloque tout en cas d'échec, et CRACI continue de réévaluer les SBOM de ce qui a été livré. Idéal pour les équipes qui livrent des logiciels et doivent montrer ce qui est entré dans chaque release. Attention : pas de SAST, de scan de secrets ou d'IaC, de contrôles de posture ni d'analyse de binaires, et uniquement GitHub Actions aujourd'hui (GitLab CI et Jenkins figurent sur la roadmap). La génération de SBOM au build

Plateformes et ASPM

Apiiro

Apiiro est une plateforme ASPM. Deep Code Analysis cartographie votre architecture du code au runtime, et le Risk Graph corrèle les résultats des scanners d'Apiiro et d'outils tiers en « combinaisons toxiques ». Son module de chaîne d'approvisionnement inventorie les dépôts et les pipelines, y compris les pipelines fantômes, et signale les protections de branche faibles et les commits anormaux. Il se connecte via des API et ne nécessite aucune modification de la CI. Idéal pour les grands programmes AppSec qui veulent un contexte d'architecture sur de nombreux systèmes de gestion de code source. Attention : son inventaire vient de l'analyse du code, et non de l'observation des builds, et il ne contrôle pas ce qu'un build peut atteindre. CRACI vs Apiiro

Cycode

Cycode est une plateforme ASPM avec SAST, SCA, scan de secrets, de conteneurs et d'IaC, posture CI/CD et plus de 100 connecteurs. Sa brique de build, Cimon, est un agent eBPF qui s'exécute dans vos jobs CI. Il surveille les processus, le trafic réseau sortant et les accès aux fichiers, apprend le comportement normal d'un pipeline avant de l'appliquer, produit une SBOM observée au runtime et signe une provenance SLSA. Cycode indique que Cimon est gratuit et open source. Idéal pour une plateforme unique couvrant le code et de nombreux systèmes CI, avec une protection du build au runtime sur les runners que vous gardez. Attention : Cimon est un agent ajouté à vos runners, pas le runner lui-même. CRACI vs Cycode

OX Security

OX Security est une plateforme ASPM avec ses propres scanners, l'agrégation de résultats tiers issus d'outils tels que Checkmarx, Snyk et Black Duck, et des politiques de posture CI/CD qui signalent les actions non épinglées, les permissions de workflow excessives et les webhooks risqués. Son Pipeline Bill of Materials (PBOM) est un enregistrement signé par build des définitions de pipeline, de l'identité du runner, des arguments de build et des signatures d'artefacts. Idéal pour les politiques de posture et le contrôle des pull requests sur GitHub Actions, GitLab, Jenkins, Azure Pipelines et CircleCI. Attention : sa SBOM est collectée à partir des sources connectées, et ses politiques vérifient la configuration du pipeline au lieu de limiter ce qu'un job en cours d'exécution peut atteindre. CRACI vs OX Security et Alternatives à OX Security

Legit Security

Legit Security cartographie tout votre cycle de développement : un inventaire mis à jour en continu des systèmes SDLC, des pipelines et de leurs contrôles de sécurité, avec des centaines de politiques couvrant la gestion de code source, la CI et les registres. Il orchestre des scanners tels que Snyk, Checkmarx et GitHub Advanced Security, ajoute du SAST et du SCA natifs, trouve des secrets dans les logs de build, Slack et Confluence aussi bien que dans le code, et crée des SBOM et des attestations signées. Idéal pour une équipe sécurité qui a hérité de nombreux dépôts et de plusieurs systèmes CI et a besoin d'une seule couche de gouvernance. Attention : il lit la configuration et les sorties des scanners via des API et ne voit donc pas le trafic réseau d'un job pendant son exécution. CRACI vs Legit Security et Alternatives à Legit Security

Kusari

Kusari vient de l'équipe qui a cocréé GUAC, le graphe OpenSSF des métadonnées de la chaîne d'approvisionnement. Sa plateforme construit un graphe de connaissances à partir de vos SBOM, documents VEX et sorties de scanners, montre le rayon d'impact d'une nouvelle vulnérabilité, analyse l'atteignabilité et ouvre des pull requests AutoFix qu'elle valide d'abord. Kusari Inspector examine les pull requests pour y trouver des paquets malveillants, des secrets et des workflows non sécurisés, et Kusari indique qu'il est gratuit à installer. Idéal pour un graphe unique couvrant de nombreuses sources de SBOM et de nombreux scanners. Attention : un graphe reflète les SBOM qu'on lui fournit, et celles de Kusari viennent d'un générateur (son kit waybill ou votre propre outil) plutôt que du build. CRACI vs Kusari et Alternatives à Kusari

Endor Labs

Endor Labs est construit autour de l'atteignabilité au niveau des fonctions : l'analyse statique de programme détermine si votre code peut appeler une fonction vulnérable dans une dépendance directe ou transitive, ce qui, selon Endor Labs, réduit les résultats SCA de 92 %. L'analyse d'impact des mises à niveau, les pull requests automatisées et les Endor Patches, qui rétroportent les correctifs sur la version que vous exécutez, gèrent la remédiation. Il couvre aussi AI SAST, les secrets, les conteneurs, un Package Firewall devant vos registres et un SBOM Hub avec VEX basé sur l'atteignabilité. Idéal pour les équipes dont le principal problème est le volume d'alertes. Attention : son inventaire vient de l'analyse du code source, et il n'exécute ni ne restreint vos builds. CRACI vs Endor Labs

Sécurité du build et des runners

StepSecurity

StepSecurity Harden-Runner est, parmi les produits de sécurité, celui qui recoupe le plus CRACI. C'est un agent sur les runners GitHub Actions que vous utilisez déjà, y compris ceux hébergés par GitHub, et il relie chaque connexion sortante, chaque processus et chaque écriture de fichier à l'étape de workflow qui en est à l'origine. Il peut d'abord auditer, en construisant une référence par job, puis bloquer le trafic sortant vers tout ce qui ne figure pas sur une liste d'autorisation. StepSecurity vend aussi Secure Registry, des pull requests de durcissement de dépôts et Dev Machine Guard. Idéal pour les équipes qui veulent garder des runners hébergés par GitHub ou auto-hébergés, ou qui utilisent GitLab CI ou Azure DevOps. Attention : sa liste d'autorisation est une liste d'endpoints, et il enregistre des destinations plutôt qu'une SBOM au niveau des paquets. CRACI vs StepSecurity

Sécurité des paquets et des entrées

Socket

Socket analyse le comportement des paquets open source : scripts d'installation, accès au réseau et au système de fichiers, code obfusqué, malwares connus et typosquats. Il signale les ajouts risqués dans les pull requests, et Socket Firewall bloque les paquets malveillants à l'installation, avec une version gratuite pour npm, yarn, pnpm, pip, uv et cargo. Il propose aussi l'analyse d'atteignabilité. Idéal pour arrêter les mauvais paquets avant qu'ils n'arrivent, y compris ceux qui n'ont pas encore d'avis de sécurité. Attention : il lit le manifeste et les lockfiles déclarés par un projet, et son pare-feu filtre les installations de paquets, pas le reste du trafic réseau d'un job. CRACI vs Socket

Chainguard

Chainguard construit des logiciels open source à partir des sources et les livre durcis : des images de conteneur qu'il qualifie de zéro CVE, des bibliothèques Java, Python et JavaScript reconstruites à partir de sources vérifiées, des images de VM et des GitHub Actions durcies, chacune avec une SBOM signée et une provenance SLSA. Pour les clients ayant passé commande, il s'engage à remédier aux CVE critiques sous 7 jours et aux CVE d'autres sévérités sous 14 jours après un correctif éligible. Idéal pour les équipes dont les scanners ne cessent de signaler des CVE dans les images de base. Attention : ses SBOM et sa provenance décrivent les artefacts de Chainguard. Votre propre build a toujours besoin de son propre enregistrement, et c'est pourquoi il se combine bien avec un outil au niveau du build. CRACI et Chainguard

Analyse de binaires

ReversingLabs

ReversingLabs Spectra Assure analyse les paquets logiciels finaux sans code source, à l'aide de l'analyse statique de binaires, de 16 moteurs de détection de malwares et d'une analyse différentielle qui signale les changements suspects entre les versions. Il exporte des SBOM CycloneDX et SPDX à partir du binaire et peut évaluer des logiciels commerciaux et tiers avant que vous ne les déployiez. Idéal pour un contrôle de release contre les malwares et les altérations, et pour les logiciels que vous n'avez pas construits. Attention : il travaille à rebours à partir de la sortie et ne voit donc pas les outils de build ni les dépendances de test que le build a récupérés sans les livrer. CRACI vs ReversingLabs

Les cadres et réglementations derrière la catégorie

Une grande partie de la demande pour ces outils vient de cadres et de règles qui exigent un inventaire des composants, un enregistrement de la façon dont le logiciel a été construit et un processus de traitement des vulnérabilités.

• SLSA (Supply-chain Levels for Software Artifacts) est un ensemble de recommandations adoptables progressivement, maintenu dans le cadre d'une collaboration intersectorielle sous l'égide de la Linux Foundation. Son Build track évalue le degré de fiabilité de la provenance d'un build.
• Le NIST SSDF (SP 800-218, version 1.1, février 2022) définit des pratiques de développement logiciel sécurisé pour réduire les vulnérabilités des logiciels publiés.
• L'Executive Order 14028 américain, section 4(e), a ordonné l'élaboration de recommandations sur la chaîne d'approvisionnement logicielle qui prévoient notamment de remettre à l'acheteur une SBOM pour chaque produit. Il oriente les recommandations fédérales en matière d'achats plutôt que de contraindre directement chaque éditeur.
• La CISA, la NSA et l'ODNI ont publié « Securing the Software Supply Chain: Recommended Practices Guide for Customers » en 2023, qui couvre les achats, les tests, le déploiement, les correctifs et les SBOM.
• Le Cyber Resilience Act de l'UE (règlement (UE) 2024/2847) rend ses obligations de signalement effectives le 11 septembre 2026 et s'applique pleinement à partir du 11 décembre 2027.
• NIS2, à l'article 21, paragraphe 2, cite la sécurité de la chaîne d'approvisionnement et le traitement des vulnérabilités parmi les mesures qu'elle exige, et la FDA américaine exige une SBOM des fabricants de cyber devices.

Aucun de ces cadres ne cite une catégorie de produits. Ce qu'ils ont en commun, c'est la preuve : une liste de composants exacte par release, un enregistrement de la façon dont elle a été construite et la preuve que les vulnérabilités ont été suivies.

Quelle est la place de CRACI ?

CRACI est un runner pour GitHub Actions. Vous remplacez runs-on par craci et, pendant l'exécution de chaque job, un proxy qui comprend les paquets enregistre ce qu'il a récupéré, y compris les paquets restaurés depuis les caches CI. Chaque SBOM comporte un état de complétude par job et par cache. Une politique de trafic sortant, en refus par défaut ou en autorisation par défaut, est validée avant le démarrage du job et bloque tout en cas d'échec. CRACI continue de réévaluer les SBOM de ce qui a été livré. La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Le résultat : une SBOM par build, un enregistrement de ce que chaque build a atteint et des données de provenance via l'API, ce qui automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont votre démarche de conformité au CRA a besoin.

CRACI n'est pas le bon choix si vous avez besoin de SAST, de scan de secrets ou d'IaC, de contrôles de posture sur vos dépôts, d'un mode audit avant blocage, de listes de blocage de paquets (sur la roadmap), d'analyse de binaires ou de systèmes CI autres que GitHub Actions aujourd'hui (GitLab CI et Jenkins figurent sur la roadmap). De nombreuses équipes l'associent à un outil ci-dessus : une plateforme ASPM pour le code et la posture, Socket ou Chainguard pour les entrées, ReversingLabs pour la sortie. En savoir plus sur la génération de SBOM au build, l'intégration CI/CD et les tarifs, ou réservez une démo pour voir un build enregistré de bout en bout.

Comparez les outils pour chaque partie de la chaîne d'approvisionnement

Cette page est la vue d'ensemble. Chaque domaine a ses propres comparatifs et guides détaillés.

• SBOM : le comparatif des outils SBOM, la génération de SBOM au build, pourquoi des SBOM au build et comment générer une SBOM dans GitHub Actions.
• Runners et sécurité CI/CD : les fournisseurs de runners GitHub Actions, les outils de sécurité des runners, la checklist de sécurité des pipelines CI/CD et la politique de trafic sortant pour GitHub Actions.
• Dépendances : le comparatif des outils SCA, les dépendances transitives expliquées et ce qu'est l'analyse de la composition logicielle.
• Réglementation : les outils de conformité au CRA.
• Pourquoi le build : pourquoi la sécurité de la chaîne d'approvisionnement a sa place dans la CI, la sécurité de la chaîne d'approvisionnement logicielle avec CRACI et pourquoi les logiciels internes et à faible risque en ont aussi besoin.

CRACI comparé à chaque outil

• CRACI face à Apiiro Un graphe de risques issu du code face aux preuves issues du build.
• CRACI face à Cycode ASPM plus un agent de build face au runner de build lui-même.
• CRACI face à OX Security Un PBOM issu d'outils connectés face à un enregistrement fait par le runner.
• CRACI face à Legit Security Sécuriser le SDLC face à enregistrer le build.
• CRACI face à Kusari Graphe de la chaîne d'approvisionnement face à des SBOM de build avec surveillance.
• CRACI face à ReversingLabs Analyse binaire du résultat face aux preuves issues du build.
• CRACI face à Socket Analyse du comportement des paquets face à l'observation du build.
• CRACI face à Chainguard Des intrants sécurisés face à un build sécurisé et enregistré.
• CRACI face à Xygeni Plateforme AppSec avec attestations de build face au runner de build lui-même.
• CRACI face à Wiz Constats de posture des workflows face à une application des règles dans le job.
• CRACI face à Safeguard Scan et correction automatique par IA face à l'enregistrement du build lui-même.

Sécurité de la chaîne d'approvisionnement logicielle : FAQ

Des réponses courtes aux questions les plus posées par les acheteurs

Que sont les solutions de sécurité de la chaîne d'approvisionnement logicielle ?

Des outils qui protègent tout ce qui entre dans votre logiciel entre le premier commit et la release : dépendances open source, images de base, outils de build, pipelines CI et artefacts que vous livrez. Les principaux types sont les plateformes ASPM qui cartographient les risques sur le cycle de développement, l'analyse de la composition logicielle pour les dépendances, la sécurité du build et des runners, les pare-feu de paquets, les images durcies, l'analyse de binaires et les outils de SBOM et de provenance.

Quelle est la meilleure plateforme de sécurité de la chaîne d'approvisionnement logicielle ?

Il n'y en a pas une seule, car chacune couvre un maillon différent. Les plateformes ASPM telles qu'Apiiro, Cycode, OX Security et Legit Security excellent par leur étendue sur les dépôts et les systèmes CI. Endor Labs se concentre sur l'atteignabilité des résultats sur les dépendances, Socket sur les paquets malveillants, Chainguard sur les entrées durcies et ReversingLabs sur les binaires finaux. CRACI est le choix à faire lorsque vous avez besoin d'un enregistrement de ce que chaque build GitHub Actions a réellement récupéré, avec un contrôle du trafic sortant et des données de provenance.

En quoi la sécurité de la chaîne d'approvisionnement logicielle diffère-t-elle de la sécurité applicative ?

La sécurité applicative recherche les failles du code écrit par votre équipe, avec des outils tels que le SAST et le DAST. La sécurité de la chaîne d'approvisionnement logicielle couvre ce qui entoure ce code : composants tiers, système de build, pipeline CI et chemin du build à la release. La porte dérobée de xz utils, la compromission de tj-actions/changed-files et le ver npm Shai-Hulud sont tous passés par la chaîne d'approvisionnement, et non par un bug dans le code des victimes.

Par quel outil de sécurité de la chaîne d'approvisionnement logicielle commencer ?

Partez de la question à laquelle vous ne savez pas répondre aujourd'hui. Si vous ne savez pas quelles dépendances vulnérables vous livrez, commencez par le SCA. Si les paquets malveillants vous inquiètent le plus, tournez-vous vers un pare-feu de paquets. Si vous devez prouver ce qui est entré dans chaque release, pour vos clients ou pour le Cyber Resilience Act de l'UE, il vous faut un enregistrement réalisé pendant le build. Les grands programmes comptant de nombreux dépôts et systèmes CI y ajoutent souvent une plateforme ASPM.

Ai-je besoin d'une SBOM pour la sécurité de la chaîne d'approvisionnement logicielle ?

De plus en plus, oui. Le Cyber Resilience Act de l'UE demande aux fabricants d'identifier les composants de leurs produits, notamment en établissant une SBOM, et de gérer leurs vulnérabilités. La FDA américaine exige une SBOM pour les cyber devices, et l'Executive Order 14028 américain a façonné des recommandations fédérales qui en demandent une aux fournisseurs. Une SBOM n'est utile que si elle est complète : demandez donc à chaque éditeur d'où vient sa liste de composants et s'il vous dit quand elle est incomplète.

En quoi CRACI diffère-t-il d'un scanner de sécurité de la chaîne d'approvisionnement ?

Les scanners lisent des fichiers après coup : un manifeste, un lockfile, du code source ou un binaire final. CRACI est un enregistreur. C'est le runner de vos jobs GitHub Actions et, pendant l'exécution de chaque job, il enregistre les paquets que le job a réellement récupérés, y compris les paquets restaurés depuis les caches CI. Chaque SBOM indique sa propre complétude, une politique de trafic sortant contrôle ce que le build peut atteindre, et l'API renvoie les SBOM, les traces réseau et la provenance.

Quels systèmes CI CRACI prend-il en charge ?

GitHub Actions aujourd'hui ; d'autres systèmes CI figurent sur la roadmap, dont GitLab CI et Jenkins. Les runners sont sous Linux en x86-64 et ARM64, et Windows et macOS figurent sur la roadmap. La plupart des plateformes de cette page couvrent plusieurs systèmes CI : tenez-en compte si vous utilisez aussi Jenkins ou Azure Pipelines.

Combien coûtent les outils de sécurité de la chaîne d'approvisionnement logicielle ?

La plupart facturent par développeur. En septembre 2026, StepSecurity Enterprise coûte $16 par développeur contributeur et par mois et Socket Team $25 par développeur et par mois, tandis que Cycode, OX Security et Endor Labs vendent leurs plans payants via leur équipe commerciale. ReversingLabs Community+ est à $500 par mois au forfait, Chainguard offre jusqu'à cinq images gratuites, et CRACI ne facture que les minutes de build, $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), sans frais mensuels.