Wettbewerbsumfeld
Die meisten Organisationen kombinieren einen Scanner (Ergebnisse), ein CD-Tool (Bereitstellungen) und Tickets/Tabellen (Genehmigungen + Prüfung).
Stella verfolgt ein Release entlang einer Nachweiskette: Source → Build → Scan → Verdict → Decision → Deploy → Watch. Jede Stufe trägt einen von drei Zuständen – MISSING, RECORDED oder SIGNED. MISSING ist ein gemeldeter Zustand, keine Lücke.
Technische Entscheidungskriterien dieser Gegenueberstellung
Matrix und Vendor-Seiten bewerten den operativen Fit, nicht Slogans.
- - Deployment-Modell: Self-Hosted-Optionen, Zielabdeckung, Betriebsannahmen
- - Evidence-Modell: Umgang mit SBOM und VEX, signierte Artefakte, Exportierbarkeit
- - Replaybarkeit: Unterstuetzung fuer deterministische Wiederholung und Pruefung mit eingefrorenen Eingaben
- - Offline-Faehigkeit: Air-Gap-Betrieb und Update-Workflows
- - Policy-Modell: Tiefe von policy-as-code, Gate-Integration und Erklaerbarkeit
Verwandte Evidenz: Evidenz und Audit | Decision Capsule-Spezifikation | Betrieb und Deployment
Zuletzt geprüft: 2026-07-29 Jede Wettbewerberzelle nennt die Quellseite und das Datum, an dem wir sie gelesen haben. Wo wir keine Erstquelle in die eine oder andere Richtung fanden, sagt die Zelle das, statt zu raten. Vanta und Drata sind Plattformen zur Compliance-Automatisierung und keine Release-Werkzeuge — ihre N/S-Zellen markieren eine andere Kategorie, keine verschwiegene Lücke. Breite Tabellen scrollen seitwärts in ihrem eigenen Rahmen; die Seite selbst nie. Die Tabelle öffnet mit einer ausgewählten Gruppe von Plattformen — wählen Sie „Alle Anbieter“ oder einen einzelnen Anbieter, um das zu ändern. Weniger Spalten entfernen die Scrollleiste vollständig. Ohne JavaScript wird die vollständige Tabelle mit achtzehn Spalten angezeigt. „Nicht bewertet“ heißt nicht „nicht angeboten“. Es heißt, dass diese Prüfung keine öffentliche Erstquelle in die eine oder andere Richtung gefunden hat — Aquas Deployment- und Identitätsdokumentation liegt hinter einem Kunden-Login, also bleiben diese Zellen leer statt geraten. Methodik: Wettbewerberzellen zitieren öffentliche Anbieterdokumentation, gelesen am 28.–29. Juli 2026; Stella-Ops-Zellen sind gegen den Produkt-Quellcode geprüft, nicht gegen dessen Dokumentation. Kein Pack auf beiden Seiten macht jemanden compliant. Anbieterfähigkeiten ändern sich — prüfen Sie vor der Entscheidung die offizielle Dokumentation. Ungenauigkeiten bitte an hello@stella-ops.org. Quellen für jede Wettbewerberzelle — Alle Seiten abgerufen am 28.–29. Juli 2026. Diese Zeilen sind das, was Stella Ops ausliefert, geprüft gegen den Produkt-Quellcode. Wettbewerberspalten fehlen hier bewusst: Jede Zelle, die wir eintragen könnten, wäre eine unbelegte Behauptung über Dritte, und solche veröffentlicht diese Seite nicht. Was die nächstgelegenen Anbieter abdecken — mit Quellen — steht unter der Tabelle. * Teilweise: Die Zustandsmaschine für Meldefristen von 24h/72h/14d läuft heute mit Betreiberübergabe – Stella bereitet das Berichtspaket vor, der Betreiber reicht es ein. Die automatische Übermittlung an die Aufsichtsbehörde wartet auf offizielle Schemata. † Die vier Profile sind ausgelieferter Code, mit benannten Grenzen: GOST und SM verifizieren überall, aber Signieren in der Produktion erfordert einen zertifizierten externen Provider — CryptoPro CSP, ein PKCS#11-HSM oder ein OSCCA-zertifiziertes SM-HSM — und der Host weigert sich, auf ES256 zurückzufallen, statt die Souveränitätsgarantie zu brechen. Die eIDAS- und FIPS-Profile werden heute vom internationalen ECDSA-Stack bedient: Profilbezeichnungen, keine validierten Module. Durch die Aktivierung wird die Beweiserhebung im konservativen Nur-Beweis-Modus gestartet. Es wird kein Anspruch auf Einhaltung gesetzlicher Vorschriften erhoben. Der Betreiber bleibt stets der regulierte Entscheidungsträger. Sehen Sie sich die Abdeckung pro Regulierungspaket, die Eigentumskennzeichnungen und bekannte Lücken an → · Availability and sanctions notice → Mit Stand 28.–29. Juli 2026 dokumentiert keine geprüfte Plattform NIS2-, DORA- oder CRA-Evidenzpakete zusammen mit regionaler Kryptografie. Anchores dokumentierte Pack-Tabelle listet sieben Packs — Secure, NIST, CIS, FedRAMP, DoD, CMMC, ASD Essential 8 — und keines davon ist NIS2, DORA oder CRA;5 die DORA-Seite ist Marketing, und eine Landingpage ist kein ausgeliefertes Pack.18 Keine geprüfte Plattform dokumentiert GOST- oder SM-Signierung von Release-Evidenz; die Signaturspezifikation von cosign, der De-facto-Toolchain hier, verlangt ECDSA-P256 und nennt kein GOST- oder SM-Verfahren.22 Dies war eine englischsprachige Dokumentationsprüfung: hohe Zuversicht für westliche Anbieter, mittlere weltweit. Pack-Bibliotheken ändern sich — prüfen Sie vor der Entscheidung. Das kostenlose Kontingent umfasst 3 Umgebungen und 100 Scans neuer Digests pro gleitende 24 Stunden.Plattformvergleich: Stella Ops gegen siebzehn Release- und Security-Plattformen
Entscheidungsdimension Stella Ops Anchore Enterprise Aqua Security Kosli Chainloop Octopus Deploy Argo CD Harness GitLab GitHub Jenkins Snyk Trivy Docker Scout JFrog AWS Vanta Drata Deployment und Release-Kontrolle Deployment-Modell Stella Ops installiert auf Hardware, die Sie kontrollieren, und deployt auf Compose-, Docker-, SSH-, WinRM-, Ansible-, Nomad- und ECS-Ziele. Die Zellen ohne klares Ja sind Dokumentation, die vor einer selbst gehosteten Installation endet: Kosli ist SaaS mit On-Prem für Enterprise-Kunden laut Preis-FAQ, und AWS CodeDeploy erreicht On-Premises-Instanzen, während die Control Plane ein Region-Dienst bleibt. Snyk dokumentiert regionales Hosting statt Self-Hosting; Docker Scout wird über Docker Hub, die CLI und sein Dashboard erreicht; Vanta und Drata sind gehostete Plattformen. Aquas Deployment-Seiten liegen hinter einem Kunden-Login, daher ist diese Zelle nicht bewertet. Ja Ja1 Nicht bewertet Teilweise16,17 Ja81,82 Ja26,23 Ja71,70 Ja30 Ja41 Ja47 Ja48 N/A53,51 Ja54,55 N/A75,77 Ja64 Teilweise68,65 N/A86,88 N/A89,90 Führt die Promotion aus (ist der Deployment-Pfad) Bei Stella sind Gate und Deployment ein System: Das Gate läuft im Orchestrator, der die Promotion ausführt. Koslis eigene Dokumentation entscheidet seine Zelle — es ist ein Flugschreiber, der „das Flugzeug nicht steuert“. JFrog ist teilweise, weil es ein signiertes Release Bundle zwischen Stages promotet, also ein Artefakt bewegt und kein Deployment. Chainloop, Docker Scout, Vanta und Drata nennen auf den geprüften Seiten keine Deployment-Funktion. Ja N/A2 N/A10 Nein11 N/A19,82 Ja24,25 Ja70 Ja29 Ja35,40 Ja42 Teilweise50 N/A51 N/A54 N/A75,80 Teilweise59 Ja68 N/A86 N/A89 Policy-Modell und Ausdruckskraft der Gates Stellas Gate verbindet Reachability auf Funktionsebene, fünfstufigen VEX-Konsens und Promotion-Regeln in einer Entscheidung, und das erzeugte Verdict ist signiert und wiederholbar. Die teilweisen Zellen markieren Steuerung, die keine Policy-Sprache ist: Argo CDs Sync Windows sind cron-basierte Erlaubnis-/Sperrzeiten und sein RBAC ist Zugriffskontrolle, während Octopus und Jenkins einen menschlichen Freigabeschritt dokumentieren. Snyk, Trivy, AWS, Vanta und Drata nennen auf den geprüften Seiten kein Gate-Policy-Modell. Ja Ja4 Ja10 Ja13 Ja84 Teilweise28 Teilweise73,74 Ja31 Ja38 Ja42 Teilweise50 N/A51 N/A54,56 Ja76 Ja62 N/A65 N/A87 N/A89 Schwachstellen und Priorisierung Schwachstellen-Scan von Container-Images Stellas Scanner analysiert OS-Paketmanager, Sprach-Ökosysteme, native Binaries, Secrets und Kryptografie im Image. Koslis dokumentierte Attestierungstypen tragen Ergebnisse anderer Werkzeuge, statt eine eigene Analyse zu erzeugen, und Container-Image-Scanning steht nicht auf den geprüften GitHub-Seiten — Dependabot deckt dort Abhängigkeits-Manifeste ab. Ja Ja3 Ja9 N/A12 N/A84 N/A25 N/A70 Ja32 Ja36 N/A45,46 N/A50 Ja51 Ja54 Ja75,78 Ja60 Ja67,66 N/A86,87 N/A89 Priorisierung von Schwachstellen, einschließlich Erreichbarkeit Stella berechnet Reachability auf Funktionsebene aus dem deployten Binary und gibt einen hashbaren Beweis aus. Die teilweisen Zellen sind verwandte Arbeit auf einer anderen Achse: GitLab zeigt EPSS und Known-Exploit-Kennzeichen, Harness dedupliziert und priorisiert Scanner-Ausgaben, Trivy filtert mit VEX-Aussagen, Docker Scout aggregiert EPSS und den CISA-KEV-Katalog und nimmt VEX-Ausnahmen als Attestierungen, und Amazon Inspector passt den NVD-Basiswert über Netzwerk-Erreichbarkeit an — nichts davon ist Code-Reachability. Ja N/A2,3 Ja9 N/A11,12 N/A84 N/A25 N/A70 Teilweise32 Teilweise36 N/A45 N/A50 Ja52 Teilweise56,57 Teilweise78,79 Ja61 Teilweise65 N/A86 N/A89 Unknowns als eigenständiger Zustand Unbekannte Komponenten sind ein gerankter, budgetierter Zustand mit eigenem Dienst und Nachweis-Records, sodass eine Lücke als Befund geführt und nicht verworfen wird. Auf den geprüften Seiten der anderen siebzehn Plattformen fanden wir kein vergleichbares Konzept; das Fehlen des Begriffs beweist nicht das Fehlen des Verhaltens. Ja N/A2,4 N/A9,10 N/A11,12 N/A83,84 N/A25 N/A70 N/A32,33 N/A36 N/A45 N/A50 N/A52 N/A56 N/A76 N/A61 N/A65 N/A87 N/A89 Nachweise, Replay und Offline Nachweise signiert und ohne den Anbieter prüfbar Stella-Evidence-Cards sind DSSE-signiert und verifizieren offline gegen einen lokalen Trust Root, inklusive Rekor-Belegen. Die teilweisen Zellen markieren Signierung, die mit einer Grenze dokumentiert ist: Anchores Exportformate sind dokumentiert, eine Signatur dieser Dokumente steht aber nicht auf der geprüften Seite; GitLab Runner erzeugt ein in-toto-SLSA-Statement, dessen Signierung nicht angegeben ist; AWS Signer signiert Container-Images über Notation und verwaltet das Schlüsselmaterial selbst; Kosli dokumentiert SHA256-Fingerprint-Identität und Audit-Paket-Downloads, ohne eine Signatur des Pakets anzugeben; Chainloops eigene Signing-Referenz führt die Prüfung über die Chainloop-CLI und verlangt die CA-Kette auf separatem Weg. Argo CD verifiziert GnuPG-signierte Git-Commits, nicht Evidenz, die es selbst ausgibt. Ja Teilweise6 Ja10 Teilweise12,14 Teilweise83,85 N/A25 N/A72 Ja34 Teilweise39 Ja43,44 N/A50 N/A51 Ja58 N/A79,76 Ja20 Teilweise69 N/A87 N/A89 Führt eine frühere Entscheidung mit fixierten Eingaben erneut aus Stella pinnt Feed-Snapshot, Policy, VEX-Dokumente, Toolchain und Seed, spielt dann zweimal ab und prüft Determinismus. Anchore dokumentiert bewusst ein anderes Modell: Der Compliance-Status bleibt fortlaufend aktuell und wird neu bewertet, wenn sich Assets, Policy oder Schwachstellendaten ändern. Keine andere Plattform in dieser Prüfung dokumentiert das erneute Ausführen einer vergangenen Entscheidung aus gepinnten Eingaben. Ja N/A8 N/A10 N/A12 N/A83 N/A24,25 N/A70 N/A29,33 N/A35,39 N/A42,43 N/A50 N/A52 N/A55,58 N/A75 N/A59 N/A68,65 N/A87 N/A89 Signiertes Risiko-Delta zwischen zwei Releases (Smart-Diff) Stella gibt ein signiertes Delta-Verdict zwischen zwei Releases aus, damit der Prüfaufwand auf die wesentliche Änderung geht. Auf den geprüften Seiten der anderen siebzehn Plattformen nicht angegeben. Ja Teilweise2 N/A9,10 N/A11,12 N/A83 N/A25 N/A70 N/A33,34 N/A36,39 N/A43 N/A50 N/A51,52 N/A56,58 N/A75,76 N/A20,59 N/A65,69 N/A87 N/A89 Offline- und Air-Gap-Betrieb Stellas Sealed Mode erzwingt eine Egress-Allowlist im Code und verweigert den Start bei einem veralteten Offline-Zeitanker. Die teilweisen Zellen decken etwas Engeres ab als eine Air-Gap-Installation: Octopus dokumentiert einen Offline Package Drop für nicht erreichbare Ziele statt eines Air-Gapped-Servers, GitHub dokumentiert die Offline-Prüfung von Attestierungen, und Chainloops Plattform-Deployment-Leitfaden beschreibt das Verlagern von Helm-Charts und Images in Ihre eigene Registry, während der Open-Source-Installationsleitfaden Offline-Betrieb nicht erwähnt. Docker Scouts Data-Handling-Seite gibt an, dass Image- und SBOM-Metadaten an Server in US East übertragen werden, und dokumentiert keinen Offline-Modus; Argo CDs Installationsleitfaden behandelt keine Air-Gapped-Installationen; Koslis dokumentierte Antwort auf Nichterreichbarkeit ist ein Dry-Run-Modus, dessen Befehle die Attestierung überspringen und mit null enden. Aquas Deployment-Dokumentation liegt hinter einem Kunden-Login, daher ist diese Zelle nicht bewertet. Ja Ja7 Nicht bewertet N/A15,16,17 Teilweise82,81 Teilweise27,26 N/A71 Ja30 Ja37 Teilweise44,47 Ja49 N/A53,51 Ja55 N/A77 Ja63 N/A65,67 N/A88,86 N/A90 Regulatorische Beweise und souveräne Krypto
CRA Export der technischen Dokumentation Anhang VII Ja CRA Konformitätsdossier (Modul A / B+C / H) Ja NIS2-Steuerregister + SoA mit Vollständigkeitstor Ja NIS2 Effektivitäts-KPI-Telemetrie (13 Bereiche) Ja DORA-Informationsregister-Export, gebunden an die gepinnte offizielle EBA-Taxonomie Ja DORA TLPT-Beweispaket (10-Jahresaufbewahrung) Ja Statusmaschine für die Frist zur Vorfallmeldung (24h/72h/14d) Teilweise* Standards-Mapping-Evidenzpaket (ISO/IEC 27001, IEC 62443-4-1/-4-2, ETSI EN 303 645) Ja Signierte, fail-closed Meldekanäle an Regulierer (ENISA CRA, NIS2 CSIRT, DORA) Ja Auditor-Nachprüfung eines exportierten Bundles ohne laufende Instanz Ja Offline-Zeitanker mit Staleness-Budget Ja Richtlinien-Engine zur behördlichen Beweisaufbewahrung Ja Regionale Kryptoprofile ( FIPSFederal Information Processing Standards – kryptographische Standards der US-Regierung für sichere Systeme-aligned, eIDASElectronic IDentification, Authentication and trust Services – EU-Verordnung für elektronische Signaturen und Vertrauensdienste, GOST, SM; HSM PKCS#11)†Ja Signieren mit mehreren Profilen (Dual-Stack). Ja CBOM-Analyse und Bewertung der Post-Quanten-Bereitschaft Ja EU-Trusted-List-Validierung und CAdES-Signaturerstellung (eIDAS) Ja SM-Remote-Signaturdienst (OSCCA-zertifiziertes HSM-Backend) Ja Kein direkter Wettbewerber — Stand 28.–29. Juli 2026
Direktvergleiche