Vergleich
Stella Ops vs. Trivy
Trivy ist ein Scanner: Er liefert Befunde für nahezu jedes Ziel, das Sie ihm übergeben. Stella Ops ist eine Release-Control-Plane für Nicht-Kubernetes-Umgebungen: Sie wandelt Container-Digest-Befunde in kontrollierte, signierte und wiederholbare Release-Entscheidungen um. Viele Systemlandschaften betreiben beides.
Hinweis zum Anwendungsbereich: Dieser Vergleich deckt auch Scanner der Grype-Klasse ab – der gleiche Kategorieunterschied gilt für Grype- und Syft-basierte Pipelines.
Zuletzt geprüft: 2026-07-26
Decision criteria
How this comparison is evaluated
Each vendor page is scored against the same five technical dimensions for consistent decision support.
- Deployment model: Target coverage, self-hosting posture, and runtime assumptions.
- Evidence model: How decisions are justified, signed, and exported for review.
- Replayability: Ability to re-run historical decisions with identical inputs.
- Offline capability: Behavior in disconnected or sovereign environments.
- Policy model: Gate expressiveness, explainability, and workflow integration.
Proof and methodology links: Full market matrix | Evidence and Audit | Operations and Deployment | Decision Capsule spec
Unterschiedliche Kategorien: Befunde gegenüber Entscheidungen
- Trivy — beantwortet: „Was befindet sich in diesem Artefakt, und was davon weist bekannte Schwachstellen auf?“ Die Ausgabe ist eine Befundliste, die Sie an anderer Stelle triagieren.
- Stella Ops — beantwortet: „Darf dieser Digest in diese Umgebung promotet werden, und können wir den Grund nachweisen?“ Die Ausgabe ist eine mit signierten Nachweisen verknüpfte Entscheidung.
Beides kann Teil derselben Toolchain sein. Stella importiert von Trivy, Syft und Grype erzeugte SBOMs. Die Einführung des einen Werkzeugs erfordert nicht, das andere zu ersetzen.
Funktionsvergleich
| Fähigkeit | Trivy | Stella Ops |
|---|---|---|
| Deployment-Modell | Single-Binary-Scanner für Container-Images, Dateisysteme, Git-Repositorys, VM-Images, Kubernetes-Cluster und SBOMSoftware Bill of Materials – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Software-Eingaben. Die Deployment-Orchestrierung liegt außerhalb des Bereichs. | Selbstgehostete Release-Control-Plane für Nicht-Kubernetes-Umgebungen: Docker Compose, SSH/WinRM-Hosts. Stella scannt Container-Images und importierte SBOMs, jedoch keine Repositorys, VMs oder Cluster. |
| Evidence-Modell | Berichte für Menschen und Pipelines: JSON-, SARIF- und SBOM-Ausgabe (CycloneDXEin offenes Standardformat für Software Bill of Materials (SBOM), das branchenweit eingesetzt wird, SPDXSoftware Package Data Exchange – ein weiteres offenes Standardformat für SBOMs, weit verbreitet in Open Source). | Signierte DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen-Artefakte: Erreichbarkeitsgraphen, Urteile und exportierbare Decision CapsuleEin signiertes, exportierbares Nachweispaket, das jeden Input und Output einer Release-Entscheidung für Offline-Audit und deterministische Wiedergabe versiegelt-Bundles. |
| Replaybarkeit | N/S – ein Replay-Manifest, das eine frühere Entscheidung mit fixierten Eingaben wiederholt, wird in der öffentlichen Trivy-Dokumentation nicht beschrieben. In unserer Quellprüfung von Trivy v0.55 hingen Befunde vom Zustand der Advisory-Datenbank zum Scanzeitpunkt ab. | Deterministische Replay-Manifeste fixieren Advisory-Snapshot, Richtlinien- und Analyseversionen, sodass ein früheres Urteil erneut ausgeführt und Byte für Byte verglichen werden kann. |
| Offline-Faehigkeit | Ja – die Schwachstellendatenbank kann für getrennte Scans gespiegelt werden. | Ja – versiegelte Advisory-Snapshots; jedes Urteil zeichnet den Snapshot auf, anhand dessen es berechnet wurde. Dadurch erhalten Air-Gap-Umgebungen dieselben Entscheidungen wie verbundene Umgebungen. |
| Policy-Modell | Schweregrad-Schwellenwerte und Exit-Codes; VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind-Aussagen filtern Befunde aus Berichten. | Gates kombinieren ReachabilityAnalyse, die beweist, ob verwundbarer Code tatsächlich von Ihrer Anwendung aufgerufen wird — und so Fehlalarme aus dem Scanner-Rauschen herausfiltert, VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sind-Entscheidungen und Promotionsregeln. Widersprüchliche Aussagen verschiedener Aussteller werden nach K4 aufgelöst – Belnaps vierwertige Logik, in der eine Aussage True, False, Unknown oder Conflict ist – sodass ein Widerspruch als Konflikt festgehalten wird, statt dass eine Seite stillschweigend gewinnt. Unbekannte sind ein erfasster, budgetierter Zustand – niemals verborgen. |
Ja = native Fähigkeit | Teilweise = eingeschränkter Umfang | Nein = nicht bereitgestellt | N/S = nicht in der öffentlichen Dokumentation angegeben
Gemessene Ergebnisse: vier Scanner, 872 Projekte
872 Projekte aus einem Open-Source-Manifest mit 1.002 Projekten, jedes aus dem Quellcode zu einem Container-Image gebaut und von allen vier Tools mit identischen Eingaben gescannt. Zuletzt bewertet am 3. Juli 2026. Wie Funde wahrheitsgelabelt werden und was ausgeschlossen wird, steht in der Methodik-Notiz am Ende dieser Seite.
96,3 % der im Advisory als betroffen erklärten Schwachstellen gefunden — Trivy fand 54,6 %.
Wenn ein veröffentlichtes Advisory Ihre Version als betroffen benennt, meldet Stella Ops sie. Weniger bekannte Probleme erreichen unbemerkt die Produktion.
476.865 Pakete im gesamten Korpus erkannt — Trivy erkannte 304.230.
Ein Paket, das kein Scanner sieht, kann niemand prüfen. Stella Ops sieht mehr von dem, was tatsächlich im Image steckt.
| Messgröße | Stella Ops | Trivy | Grype | osv-scanner |
|---|---|---|---|---|
| Gefundene, im Advisory als betroffen erklärte Schwachstellen* Das veröffentlichte Advisory benennt genau diese Version als betroffen. Hat das Tool sie gemeldet? | 96,3 % | 54,6 % | 70,3 % | 89,2 % |
| Im Image gefundene Pakete Eindeutige OS-, Sprach- und Binärpakete (PURLs), die im gesamten Korpus erkannt wurden. | 476.865 | 304.230 | nicht bewertet | nicht bewertet |
* Die Wahrheitslabels dieser Messgröße stammen aus demselben Advisory-Store, den Stella Ops' eigener Matcher liest; die Stufe begünstigt Stella Ops daher konstruktionsbedingt — unser Benchmark-Code stuft sie genau so ein. Korpus und Bewertungsregeln sind veröffentlicht, der Lauf lässt sich also reproduzieren.
Die Kontrolle der False Positives endete bei 1,00 im Gleichstand aller vier: kein Tool erzeugte einen bestätigten False Positive. Die Paketerkennung wurde in diesem Lauf nur für Stella Ops und Trivy bewertet.
Snyk war nicht Teil dieses Laufs; einen gemessenen Vergleich mit Snyk gibt es nicht. Korpus, Bewertungsregeln, Audit-Regeln und Artefakte je Projekt sind im Produkt-Repository unter tools/benchmarks/stella-vs-trivy/ veröffentlicht.
Wann was verwenden
Wenn Trivy die bessere Wahl ist
Wählen Sie Trivy – oder behalten Sie es – wenn die Scanbreite erforderlich ist:
- Sie benötigen eine Binärdatei, die Container-Images, Dateisysteme, Git-Repositorys, VM-Images, Kubernetes-Cluster und vorhandene SBOMs scannt.
- Sie benötigen im selben Lauf Prüfungen auf Fehlkonfigurationen, Secrets oder Lizenzen.
- Sie schätzen ein großes Plugin- und IDE-Ökosystem mit umfassenden CI-Beispielen.
- Sie bevorzugen die Lizenz Apache-2.0. (Stella Ops ist unter BUSL-1.1 Source-available.)
Stella Ops scannt keine Git-Repositorys, VM-Images oder Kubernetes-Cluster und führt keine Secret-Erkennung innerhalb von Artefakten durch. Für diese Abdeckung benötigen Sie einen Scanner wie Trivy – unabhängig davon, ob Stella anschließend verwendet wird.
Wenn Stella Ops die bessere Wahl ist
Wählen Sie Stella, wenn die Frage nicht „Was ist verwundbar?“, sondern „Darf dieses Release ausgeliefert werden, und können wir den Grund nachweisen?“ lautet:
- Urteile müssen erneut ausführbar sein: Deterministische Replay-Manifeste fixieren jede Eingabe, sodass eine Monate alte Entscheidung reproduziert und geprüft werden kann.
- Befunde müssen nach Ausnutzbarkeit priorisiert werden: Signierte Erreichbarkeitsgraphen (
DSSEDead Simple Signing Envelope – ein einfacher, flexibler Standard zum Signieren beliebiger Daten mit kryptographischen Signaturen) belegen, ob verwundbarer Code auf einem von Ihrer Anwendung ausführbaren Pfad liegt. VEXVulnerability Exploitability eXchange – maschinenlesbare Aussagen darüber, ob Schwachstellen in Ihrem Kontext tatsächlich ausnutzbar sindsoll entscheiden, nicht unterdrücken: Eine vertrauensgewichtete Konfliktauflösung hält widersprüchliche Aussagen sichtbar, statt Befunde zu löschen.- Unsicherheit muss sichtbar bleiben: Unbekannte sind ein eigenständiger, budgetierter Zustand, keine stille Lücke.
- Air-Gap-Umgebungen benötigen Parität: Versiegelte Advisory-Snapshots liefern offline dieselben Urteile wie online.
Verwenden Sie beides: Trivy für Breite, Stella für Entscheidungen
Ersetzen ist nicht die einzige Option. Nutzen Sie Trivy weiterhin für Repository-, VM-, Kubernetes-, Secret- und Fehlkonfigurationsabdeckung. Exportieren Sie die SBOMSoftware Bill of Materials – eine vollständige Liste aller Pakete und Abhängigkeiten in Ihrer Software und lassen Sie Stella das nach Erreichbarkeit gefilterte, richtliniengesteuerte Urteil sowie signierte Nachweise für die von Ihnen promoteten Digests berechnen.
Importieren Sie ein von Trivy generiertes SBOM in einen Stella-Scan:
$ stella sbom check --sbom trivy.json
Befehle wie in der Produktkonsole angezeigt (v1.0-RC1).
Methodik: Funktionsaussagen stammen aus der öffentlichen Dokumentation des jeweiligen Anbieters sowie aus einer Quellcode-Durchsicht der auf dieser Seite genannten Version. Messwerte stammen aus unserem eigenen Scanner-Benchmark, zuletzt ausgewertet am 3. Juli 2026: 872 bewertete Projekte aus einem Manifest von 1.002 Open-Source-Projekten, jeweils aus dem Quellcode als Container-Image gebaut und von Stella Ops, Trivy, Grype und osv-scanner aus identischen Eingaben gescannt. Bewertet wird gegen ein regelbasiertes Wahrheitslabel — den vom Advisory selbst angegebenen betroffenen Versionsbereich oder die Übereinstimmung unabhängiger Advisory-Quellen — niemals gegen die Ausgabe eines anderen Scanners. Befunde, die die Regeln nicht auflösen können, fließen nicht in Precision und Recall ein und werden als Abdeckung ausgewiesen; nicht baubare Projekte und fehlgeschlagene Scans werden ausgeschlossen statt als Erfolg gezählt. In diesem Lauf führte Stella Ops bei Advisory-Range-Recall und Paketerkennung und lag bei bestätigten Fehlalarmen gleichauf. Ein gemessener Vergleich mit Snyk liegt nicht vor. Korpus, Bewertungsregeln und Rohzahlen sind im Produkt-Repository unter tools/benchmarks/stella-vs-trivy/ veröffentlicht. Funktionsumfänge ändern sich; prüfen Sie das aktuelle Verhalten beim jeweiligen Anbieter. Aussagen zur Wiederspielbarkeit basieren auf einer Quellenüberprüfung von Trivy v0.55; Andere Trivy-Zellen spiegeln die öffentliche Dokumentation von Trivy wider.
Wenn Sie glauben, dass Informationen veraltet oder falsch sind, kontaktieren Sie hello@stella-ops.org.
Vergleichen Sie einen Ihrer eigenen Digests
Scannen Sie dasselbe Image mit beiden Werkzeugen. Stellen Sie die Befundliste dem nach Erreichbarkeit gefilterten Urteil und seinen exportierten Nachweisen gegenüber und beurteilen Sie den Unterschied anhand Ihres eigenen Artefakts.