Comparaison
Aucun produit examiné ne construit la preuve NIS2, DORA et CRA depuis les déploiements.*
Sept éditeurs s'en approchent le plus. Chacun figure ci-dessous avec une source de première main et une date de consultation, ce qu'il fait réellement de mieux, et le point précis où sa documentation s'arrête.
Un tour d'horizon du marché, pas un face-à-face. Un seul contre-exemple change cette page.
* Sur la base de la documentation publique d'Anchore, Aqua, Chainguard, JFrog, Sonatype, Vanta et Drata, lue en anglais, consultée le 2026-07-28. Pas d'évaluation pratique ni d'échange avec les éditeurs.
Dernière révision : 2026-07-28
L'affirmation, précisément
Beaucoup d'éditeurs publient du contenu DORA, et les plateformes GRC automatisent réellement des programmes DORA aujourd'hui. L'affirmation de cette page est plus étroite :
- Aucun produit examiné ne documente de packs de preuves NIS2, DORA et CRA construits à partir de la preuve de déploiement — ce qui tourne, sous quel digest, promu par qui, contrôlé par quelle politique.
- Aucun produit supply chain ou release examiné ne documente la signature de preuves de release en GOST ou SM2 — les algorithmes nationaux russe et chinois.
- Aucun ne fait les deux. C'est le terrain que couvre cette page.
Un examen en anglais peut couvrir incomplètement le marché intérieur chinois : le constat SM2 est très fiable pour les éditeurs occidentaux, moyen à l'échelle mondiale.
Une page marketing n'est pas un pack livré
Beaucoup d'éditeurs publient des pages DORA, NIS2 ou CRA. Ce n'est pas un défaut — mais c'est un autre type de document, et la différence compte. Chaque source ci-dessous porte l'étiquette de son type de document :
documentation produit
Décrit un comportement livré et configurable. La preuve publique la plus forte qu'une capacité existe.
page produit
La description, par l'éditeur, de ce qu'il vend. Un engagement réel, en deçà de la documentation.
contenu de guidance
Explique la réglementation et dit que le produit aide. Pas, en soi, la preuve d'un pack livré.
Les acteurs les plus proches — et ce que chacun fait vraiment
Chacun de ces éditeurs est bon dans ce qu'il documente, et plusieurs couvrent des besoins de conformité que nous ne touchons pas. La dernière colonne reste volontairement étroite : elle nomme ce que leur documentation publique ne couvre pas à la date de consultation — jamais ce qu'un éditeur « ne sait pas faire ».
| Éditeur et sources | Ce qu'ils apportent (avec source) | Non documenté |
|---|---|---|
Anchore Enterprise
| La bibliothèque de packs US-federal la plus profonde ici : sept packs de politique documentés — Secure, FedRAMP, NIST, CIS, DoD, CMMC et ASD Essential 8 — livrés en bundles importables avec règles et correspondances. | Aucun des sept n'est NIS2, DORA ou CRA. |
Aqua Security
| Une large plateforme de sécurité cloud-native : génération de SBOM, sécurité de la chaîne d'approvisionnement, contexte runtime pour la priorisation. Publie des guides DORA et NIS2 affirmant que la plateforme s'aligne sur les deux, et sur le CRA à venir. | Un pack de preuve NIS2, DORA ou CRA documenté, ou un export réglementaire. Le matériel publié consiste en guides sur les réglementations, pas en documentation de packs. |
Chainguard
| Des images minimales durcies avec variantes validées FIPS, SBOM à la construction et attestations signées — une excellente matière première pour un programme de conformité : moins de CVE à expliquer, une crypto validée comme base. | Un pack de preuve NIS2, DORA ou CRA — son matériel de conformité publié est du guide. Sa signature repose sur Sigstore, dont la spécification exige ECDSA-P256 et ne mentionne ni GOST ni SM2. |
JFrog
| Evidence Management : des attestations signées — « un passeport numérique vérifiable pour vos binaires », selon leurs mots — qui peuvent contrôler la promotion dans le cycle de release. La correspondance fonctionnelle la plus proche de la promotion contrôlée par la preuve parmi les éditeurs examinés ici. | La forme propre à chaque réglementation. Aucun profil d'export NIS2, DORA ou CRA, aucun format d'artefact orienté régulateur — relier la preuve à une réglementation reste à votre charge. |
Sonatype
| SBOM Manager : ingestion de SBOM, gestion VEX et licences à grande échelle, plus l'un des guides CRA les plus substantiels du marché. La page produit dit qu'il « aide à garder une longueur d'avance sur DORA, NIS2 et PCI ». | Tout ce qui est documenté au-delà du SBOM : pas de dossier technique CRA ni de dossier de conformité, pas de pack NIS2 ou DORA. Un SBOM est un intrant du dossier technique CRA — pas le dossier. |
Vanta
| Un produit DORA documenté : tests de contrôle automatisés, politiques prédéfinies, réutilisation des preuves entre ISO 27001, SOC 2 et NIS 2. Pour l'automatisation de la conformité au niveau de l'organisation, cette classe livre aujourd'hui — pas nous. | La preuve issue du déploiement. Les contrôles sont surveillés par intégrations au niveau organisationnel ; rien n'atteste ce qui est déployé, sous quel digest, contrôlé par quelle politique. |
Drata
| Des référentiels NIS 2 et DORA avec contrôles pré-mappés, surveillance continue et collecte automatisée de preuves sur des centaines d'intégrations — la même classe, réellement utile, que Vanta. | La même frontière : preuve de contrôle organisationnelle, pas preuve de release. Aucun verdict signé et rejouable qu'un artefact précis a atteint un environnement précis sous une politique précise. |
Toutes les sources éditeurs de cette page ont été consultées le 2026-07-28.
Là où ils gagnent : packs US-federal (Anchore), largeur de plateforme (Aqua), images validées FIPS (Chainguard), promotion contrôlée par la preuve (JFrog), opérations SBOM à grande échelle (Sonatype), automatisation DORA et NIS2 au niveau organisationnel disponible aujourd'hui (Vanta, Drata). Nous ne faisons rien de tout cela aussi bien que l'éditeur nommé — et nous ne faisons pas de GRC organisationnel du tout.
Crypto régionale : aucun produit examiné ne signe en GOST ou SM2
La chaîne de signature sur laquelle ce marché s'est standardisé est cosign, de Sigstore — et sa spécification de signature exige ECDSA-P256 ; GOST et SM2 n'y figurent nulle part. Construire sur Sigstore, c'est hériter de cette frontière : les algorithmes souverains ne sont pas une fonctionnalité que ces éditeurs ont refusée, mais une que le socle commun n'offre pas. Aucun produit supply chain ou release examiné ne documente la signature de preuves de release avec l'un ou l'autre.
github.com/sigstore/cosign — SIGNATURE_SPEC.md · Toutes les sources éditeurs de cette page ont été consultées le 2026-07-28.
Stella Ops livre la crypto régionale sous forme de code — avec ses limites en pleine lumière :
- Quatre profils régionaux déclarés dans le code, à côté du défaut international : eIDAS, FIPS, GOST et SM.
- La signature GOST R 34.10-2012 et le hachage R 34.11-2012 sont implémentés ; la construction de signatures CAdES et la validation EU Trusted List soutiennent le chemin de preuve eIDAS.
- Les profils eIDAS et FIPS tournent aujourd'hui sur la pile ECDSA internationale — des étiquettes de profil, pas des modules validés FIPS ni des signatures qualifiées.
- La signature GOST en production exige un fournisseur CryptoPro ou adossé à un HSM que nous ne livrons pas — le harnais logiciel intégré refuse de charger des clés privées GOST, et « GOST-GCM » est servi par du 28147-89 CBC, un non-objectif de conformité assumé. La signature SM en production exige de même un HSM SM certifié OSCCA. Plutôt que de se replier en silence sur ES256, la production refuse de signer.
Si un produit signe des preuves de release en SM2 — sur le marché intérieur chinois ou ailleurs — nous voulons le savoir.
Les profils cryptographiques en détail → · Availability and sanctions notice →
Ce que Stella Ops livre
Dans Stella Ops, un régime de conformité est du code, pas une étiquette. Le validateur de tenant accepte exactement quatre régimes — CRA, DORA, NIS2 et la correspondance aux normes (ISO/IEC 27001, IEC 62443, ETSI) — et le service d'export enregistre huit profils orientés régulateur :
nis2.statement-of-applicabilitynis2.effectiveness-reportdora.roidora.major-incident-reportdora.info-sharingdora.tlpt-evidence-packcra.technical-filecra.conformity-dossier
Les exports échouent fermés, cause nommée : un export du registre d'informations DORA sans source de registre refuse de produire le bundle et dit pourquoi. La rétention suit les régimes — packs TLPT conservés dix ans minimum, sept par défaut ailleurs, et tout raccourcissement exige un approbateur nommé.
Limite de l'affirmation
L'activation lance la collecte de preuves dans un mode prudent limité aux preuves; elle ne prétend pas établir la conformité réglementaire.
Stella Ops aide un opérateur ou fabricant soumis à obligation à réunir et à signer les artefacts attendus par un régulateur. Il ne les dépose jamais, ne délivre aucune certification et ne vous rend jamais conforme — l'opérateur reste toujours le décideur réglementé.
Statut du produit : v1.0-RC1, release candidate.
Méthodologie : Feature statements come from each vendor's public documentation plus a source review of the release named on this page. Measured statements come from our own scanner benchmark, last scored on 3 July 2026: 872 scored projects from a 1,002-project open-source manifest, each built from source into a container image and scanned by Stella Ops, Trivy, Grype and osv-scanner from identical inputs. Scoring is against a rule-derived truth label — the advisory's own affected version range, or agreement between independent advisory lineages — never against another scanner's output. Findings the rules cannot resolve are excluded from precision and recall and reported as coverage instead; projects that failed to build, and scans that failed to run, are excluded rather than counted as wins. On that run Stella Ops led advisory-range recall and package discovery, and tied on confirmed false positives. We have no measured comparison against Snyk. The corpus, the scoring rules and the raw counts are published in the product repository under tools/benchmarks/stella-vs-trivy/. Capabilities change; verify current behaviour with each vendor. Pour cette page : les affirmations sur les éditeurs proviennent des sources publiques liées ci-dessus, toutes consultées le 2026-07-28 ; aucun éditeur n'a été évalué en pratique. Les bibliothèques de packs et les périmètres produits changent sans préavis — vérifiez la documentation actuelle de chaque éditeur avant de décider. Une affirmation « aucun rival direct » vieillit plus vite que toute autre ; lisez cette page comme un instantané daté, pas comme un fait permanent.
Si vous pensez qu’une information est obsolète ou incorrecte, contactez hello@stella-ops.org.
Prouvez-nous le contraire
Chaque ligne d'éditeur ci-dessus porte sa source et sa date. Si vous connaissez un produit qui construit des packs de preuve NIS2, DORA et CRA à partir de la preuve de déploiement — ou qui signe des preuves de release en GOST ou SM2 — écrivez à hello@stella-ops.org et cette page changera. D'ici là, vos options pour ce pilier sont Stella Ops ou le construire vous-même.