Architecture comparison
No reviewed product builds NIS2, DORA and CRA evidence from deployments.*
Seven vendors come closest. Each is below with a first-party source and an access date, the strongest thing it genuinely does, and the exact point its documentation stops.
A survey of the field, not a head-to-head. One counter-example changes this page.
* Based on the public documentation of Anchore, Aqua, Chainguard, JFrog, Sonatype, Vanta and Drata, read in English and accessed 2026-07-28. No hands-on evaluation and no vendor briefings.
Last reviewed: 2026-07-28
The claim, precisely
Plenty of vendors publish DORA content, and the GRC platforms genuinely automate DORA programmes today. The claim on this page is narrower:
- No reviewed product documents NIS2, DORA and CRA evidence packs built from deployment evidence — what is running, under which digest, promoted by whom, gated by which policy.
- No reviewed supply-chain or release product documents signing release evidence with GOST or SM2 — the Russian and Chinese national algorithms.
- None does both. That is the ground this page covers.
An English-language review may under-cover the Chinese domestic market: the SM2 finding is high-confidence for Western vendors and moderate globally.
A marketing page is not a shipped pack
Many vendors publish DORA, NIS2 or CRA pages. That's not a fault — but it is a different kind of document, and the difference matters. Every source below is labelled with the kind of document it is:
product documentation
Describes shipped, configurable behaviour. The strongest public evidence a capability exists.
product page
The vendor's own description of what they sell. A real commitment, short of documentation.
guidance content
Explains the regulation and says the product helps. Not, by itself, evidence of a shipped pack.
The closest players — and what each one genuinely does
Each of these vendors is good at what it documents, and several cover compliance needs we don't touch. The last column stays narrow on purpose: it names what their public documentation does not cover on the access date — never what a vendor "cannot do".
| Vendor and sources | What they provide (sourced) | Not documented |
|---|---|---|
Anchore Enterprise
| The deepest US-federal pack library here: seven documented policy packs — Secure, FedRAMP, NIST, CIS, DoD, CMMC and ASD Essential 8 — shipped as importable bundles with rule sets and mappings. | None of the seven is NIS2, DORA or CRA. |
Aqua Security
| A broad cloud-native security platform: SBOM generation, supply-chain security, runtime context for prioritisation. Publishes DORA and NIS2 guidance saying the platform aligns with both, and with the CRA to come. | A documented NIS2, DORA or CRA evidence pack or regulator export. The published material is guidance about the regulations, not documentation of packs. |
Chainguard
| Hardened minimal images with FIPS-validated variants, build-time SBOMs and signed attestations — strong raw material for a compliance program: fewer CVEs to explain, validated crypto to build on. | A NIS2, DORA or CRA evidence pack — its published compliance material is guidance. Its signing runs on Sigstore, whose specification mandates ECDSA-P256 support and mentions neither GOST nor SM2. |
JFrog
| Evidence Management: signed attestations — "a verifiable digital passport for your binaries", in their words — that can gate promotion through the release lifecycle. The closest functional match to evidence-gated promotion among the vendors reviewed here. | Regulation-specific shape. No NIS2, DORA or CRA export profile, no regulator-oriented artefact format — mapping evidence to a regulation is left to you. |
Sonatype
| SBOM Manager: SBOM ingestion, VEX and licence management at scale, plus some of the most substantive CRA guidance around. The product page says it "helps you stay ahead of DORA, NIS2, and PCI". | Anything documented beyond the SBOM: no CRA technical file or conformity dossier, no NIS2 or DORA evidence pack. An SBOM is one input to a CRA technical file — not the file. |
Vanta
| A documented DORA product: automated control tests, pre-built policies, and evidence reuse across ISO 27001, SOC 2 and NIS 2. For organisation-level compliance automation, this class delivers today — we don't. | Deployment-derived evidence. Controls are monitored through integrations at the organisational level; nothing attests what is deployed, under which digest, gated by which policy. |
Drata
| NIS 2 and DORA frameworks with pre-mapped controls, continuous monitoring and automated evidence collection across hundreds of integrations — the same genuinely useful class as Vanta. | The same boundary: organisational control evidence, not release evidence. No signed, replayable verdict that a specific artifact reached a specific environment under a specific policy. |
All vendor sources on this page were accessed on 2026-07-28.
Where they win: US-federal packs (Anchore), platform breadth (Aqua), FIPS-validated images (Chainguard), evidence-gated promotion (JFrog), SBOM operations at scale (Sonatype), organisation-level DORA and NIS2 automation today (Vanta, Drata). We don't do any of these as well as the vendor named — and we don't do organisational GRC at all.
Regional crypto: no reviewed product signs with GOST or SM2
The signing toolchain this market standardised on is Sigstore's cosign, and its signature specification mandates ECDSA-P256 support — GOST and SM2 appear nowhere in it. Build on Sigstore and you inherit that boundary: sovereign algorithms aren't a feature these vendors declined, they're one the shared foundation doesn't offer. No reviewed supply-chain or release product documents signing release evidence with either.
github.com/sigstore/cosign — SIGNATURE_SPEC.md · All vendor sources on this page were accessed on 2026-07-28.
Stella Ops ships regional crypto as code — with its limits in plain sight:
- Four regional profiles declared in source beside the international default: eIDAS, FIPS, GOST and SM.
- GOST R 34.10-2012 signing and R 34.11-2012 hashing are implemented; CAdES signature building and EU Trusted List validation back the eIDAS evidence path.
- The eIDAS and FIPS profiles run on the international ECDSA stack today — profile labels, not FIPS-validated modules or qualified signatures.
- Production GOST signing needs a CryptoPro or HSM-backed provider we don't supply — the built-in software harness refuses to load GOST private keys, and "GOST-GCM" is served by 28147-89 CBC, a stated compliance non-goal. Production SM signing likewise needs an OSCCA-certified SM HSM. Rather than silently fall back to ES256, production refuses to sign.
If a product signs release evidence with SM2 — in the Chinese domestic market or anywhere else — we want to hear about it.
Crypto profiles in detail → · Availability and sanctions notice →
What Stella Ops ships
In Stella Ops, a compliance regime is code, not a label. The tenant validator accepts exactly four regimes — CRA, DORA, NIS2 and standards mapping (ISO/IEC 27001, IEC 62443, ETSI) — and the export service registers eight regulator-oriented profiles:
nis2.statement-of-applicabilitynis2.effectiveness-reportdora.roidora.major-incident-reportdora.info-sharingdora.tlpt-evidence-packcra.technical-filecra.conformity-dossier
Exports fail closed, with the cause named: a DORA register-of-information export with a missing register source refuses to produce a bundle and says why. Retention follows the regimes — TLPT packs kept ten years minimum, seven by default elsewhere, and shortening any period takes a named approver.
Claim boundary
Enabling starts evidence collection in conservative evidence-only mode; it does not claim regulatory compliance.
Stella Ops helps an obligated operator or manufacturer assemble and sign the artefacts a regulator wants. It never files, never certifies, and never makes you compliant — the operator always remains the regulated decision-maker.
Product status: v1.0-RC1, release candidate.
See per-regulation pack coverage, ownership labels, and known gaps →
Methodology: 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. For this page: vendor statements come from the public sources linked above, all accessed 2026-07-28; no vendor was evaluated hands-on. Pack libraries and product scopes change without notice — verify against each vendor's current documentation before deciding. A "no direct rival" claim ages faster than any other; treat this page as a dated snapshot, not a standing fact.
If you believe any information is outdated or incorrect, please contact hello@stella-ops.org.
Prove us wrong
Every vendor line above carries its source and its date. If you know a product that builds NIS2, DORA and CRA evidence packs from deployment evidence — or signs release evidence with GOST or SM2 — write to hello@stella-ops.org and this page changes. Until then, your options for this pillar are Stella Ops or building it yourself.