Comparaison
Stella Ops vs Trivy
Trivy est un scanner : il produit des résultats sur presque tout ce sur quoi vous le pointez. Stella Ops est un plan de contrôle de version pour les domaines non-Kubernetes : il transforme les résultats concernant les résumés de conteneurs en décisions de version fermées, signées et rejouables. De nombreux domaines gèrent les deux.
Remarque sur la portée : cette comparaison couvre également les scanners de classe Grype – la même différence de catégorie s'applique aux pipelines basés sur Grype et Syft.
Dernière révision : 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
Différentes catégories : conclusions versus décisions
- Trivy — répond "qu'est-ce qu'il y a à l'intérieur de cet artefact, et qu'est-ce qui est connu comme vulnérable ?". Sa sortie est une liste de résultats que vous triez ailleurs.
- Stella Ops — répond "ce résumé peut-il être promu dans cet environnement, et pouvons-nous prouver pourquoi ?". Son résultat est une décision liée à des preuves signées.
Les deux peuvent être vrais dans une seule pile. Stella importe des SBOM produits par Trivy, Syft et Grype, donc adopter l'un ne signifie pas rejeter l'autre.
Comparaison des fonctionnalités
| Capacité | Trivy | Stella Ops |
|---|---|---|
| Modele de deploiement | Scanner monobinaire pour les images de conteneurs, les systèmes de fichiers, les référentiels Git, les images de VM, les clusters Kubernetes et l'entrée SBOMSoftware Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel. L’orchestration du déploiement est hors de portée. | Plan de contrôle de version auto-hébergé pour les domaines non Kubernetes : Docker Compose, hôtes SSH/WinRM. Il analyse les images de conteneurs et les SBOM importés; il n'analyse pas les référentiels, les machines virtuelles ou les clusters. |
| Modele de preuve | Rapports pour les humains et les pipelines : sortie JSON, SARIF et SBOM (CycloneDXUn format standard ouvert pour les SBOM utilisé dans toute l'industrie, SPDXSoftware Package Data Exchange – un autre format standard ouvert pour les SBOMs, largement utilisé en open source). | Artefacts DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques signés : graphiques d'accessibilité, verdicts et bundles Decision CapsuleUn ensemble de preuves signé et exportable qui scelle chaque entrée et sortie d'une décision de release pour l'audit hors ligne et la relecture déterministe exportables. |
| Rejouabilite | N/S — un manifeste de rediffusion qui réexécute une décision passée sur des entrées épinglées n'est pas indiqué dans la documentation publique de Trivy. Dans notre examen des sources de Trivy v0.55, les résultats ont suivi l'état de la base de données consultative au moment de l'analyse. | Les manifestes de relecture déterministe épinglent les versions d'instantané consultatif, de politique et d'analyseur, de sorte qu'un verdict passé peut être réexécuté et comparé bit par bit. |
| Capacite hors ligne | Oui : la base de données de vulnérabilités peut être mise en miroir pour une analyse déconnectée. | Oui : instantanés d'avis scellés; chaque verdict enregistre l'instantané à partir duquel il a été calculé, donnant ainsi la parité entre les propriétés isolées et celles connectées. |
| Modele de politique | Seuils de gravité et codes de sortie; Les instructions VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte filtrent les résultats des rapports. | Les portes combinent la décision ReachabilityAnalyse qui prouve si le code vulnérable est réellement appelé par votre application — filtrant les faux positifs du bruit des scanners et VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contexte avec les règles de promotion. Les déclarations contradictoires des émetteurs se résolvent selon K4 — la logique quadrivalente de Belnap, où une affirmation vaut True, False, Unknown ou Conflict — de sorte qu’une contradiction est consignée comme conflit au lieu qu’un camp l’emporte en silence. Les inconnues sont un état suivi et budgétisé, jamais caché. |
Oui = fonctionnalité native | Partielle = portée limitée | Non = non fournie | N/S = non indiqué dans la documentation publique
Résultats mesurés : quatre scanners, 872 projets
872 projets issus d'un manifeste open source de 1 002 projets, chacun construit depuis les sources en image de conteneur puis analysé par les quatre outils à partir d'entrées identiques. Dernière notation le 3 juillet 2026. L'étiquetage de vérité des détections et les exclusions sont décrits dans la note méthodologique en bas de page.
96,3 % des vulnérabilités déclarées par les avis détectées — Trivy en a détecté 54,6 %.
Quand un avis publié désigne votre version comme affectée, Stella Ops la signale. Moins de problèmes connus atteignent la production sans être vus.
476 865 paquets identifiés sur l'ensemble du corpus — Trivy en a identifié 304 230.
Un paquet qu'aucun scanner ne voit est un paquet que personne ne peut vérifier. Stella Ops voit davantage de ce que contient réellement l'image.
| Mesure | Stella Ops | Trivy | Grype | osv-scanner |
|---|---|---|---|---|
| Vulnérabilités déclarées par les avis détectées* L'avis publié désigne exactement cette version comme affectée. L'outil l'a-t-il signalée ? | 96,3 % | 54,6 % | 70,3 % | 89,2 % |
| Paquets détectés dans l'image Paquets OS, langage et binaires distincts (PURL) identifiés sur l'ensemble du corpus. | 476 865 | 304 230 | non noté | non noté |
* Les étiquettes de vérité de cette mesure proviennent du même magasin d'avis que lit le moteur de correspondance de Stella Ops : ce palier favorise donc Stella Ops par construction — notre code de benchmark le classe ainsi. Le corpus et les règles de notation sont publiés, l'exécution peut donc être reproduite.
Le contrôle des faux positifs s'achève à 1,00 pour les quatre outils : aucun n'a produit de faux positif confirmé. La découverte de paquets n'a été notée, dans cette exécution, que pour Stella Ops et Trivy.
Snyk ne faisait pas partie de cette exécution ; nous n'avons aucune comparaison mesurée avec Snyk. Le corpus, les règles de notation, les règles d'audit et les artefacts par projet sont publiés dans le dépôt du produit sous tools/benchmarks/stella-vs-trivy/.
Quand utiliser lequel
Quand Trivy est le meilleur choix
Choisissez Trivy – ou conservez-le – lorsque la largeur de numérisation est requise :
- Vous voulez un binaire qui analyse les images de conteneurs, les systèmes de fichiers, les référentiels git, les images de VM, les clusters Kubernetes et les SBOM existants.
- Vous devez analyser une mauvaise configuration, un secret ou une licence au cours de la même exécution.
- Vous appréciez un vaste écosystème de plugins et d’IDE avec de larges exemples de CI.
- Vous préférez la licence Apache-2.0. (Stella Ops est BUSL-1.1, source disponible.)
Stella Ops n’analyse pas les référentiels git, les images de machines virtuelles ou les clusters Kubernetes, et il n’effectue pas de découverte secrète à l’intérieur des artefacts. Pour cette couverture, vous avez besoin d’un scanner comme Trivy – avec ou sans Stella derrière.
Quand Stella Ops est le meilleur choix
Choisissez Stella lorsque la question n'est pas « qu'est-ce qui est vulnérable ? » mais "ce navire peut-il être livré, et pouvons-nous prouver pourquoi ?" :
- Les verdicts doivent pouvoir être réexécutés : une relecture déterministe manifeste chaque entrée, de sorte qu'une décision prise il y a des mois peut être reproduite et vérifiée.
- Les résultats doivent être classés par exploitabilité : des graphes d'accessibilité signés (
DSSEDead Simple Signing Envelope – un standard simple et flexible pour signer des données arbitraires avec des signatures cryptographiques) attestent si le code vulnérable se trouve sur un chemin que votre application peut exécuter. VEXVulnerability Exploitability eXchange – déclarations lisibles par machine indiquant si les vulnérabilités sont réellement exploitables dans votre contextedoit décider, pas supprimer : une résolution de conflit pondérée par la confiance garde visibles les déclarations divergentes au lieu de supprimer les résultats.- L’incertitude doit rester visible : les inconnues constituent un État budgétisé de premier ordre, et non un vide silencieux.
- Les domaines isolés ont besoin de parité : les instantanés consultatifs scellés produisent les mêmes verdicts hors ligne qu’en ligne.
Utilisez les deux : Trivy pour la largeur, Stella pour les décisions
Le remplacement n’est pas la seule histoire. Conservez Trivy pour la couverture du référentiel, de la VM, de Kubernetes, des secrets et des erreurs de configuration. Exportez son SBOMSoftware Bill of Materials – une liste complète de tous les packages et dépendances de votre logiciel et laissez Stella calculer le verdict filtré en fonction de l'accessibilité et soumis à des règles (et les preuves signées) pour les résumés dont vous faites la promotion.
Importez un SBOM généré par Trivy dans une analyse Stella :
$ stella sbom check --sbom trivy.json
Commandes telles qu'affichées dans la console du produit (v1.0-RC1).
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. Les déclarations de rejouabilité sont basées sur un examen des sources de Trivy v0.55; d'autres cellules Trivy reflètent la documentation publique de Trivy.
Si vous pensez qu’une information est obsolète ou incorrecte, contactez hello@stella-ops.org.
Comparez sur l'un de vos propres résumés
Numérisez la même image avec les deux outils. Placez la liste des résultats à côté du verdict filtré en fonction de l'accessibilité et de ses preuves exportées, et jugez la différence sur votre propre artefact.