git.stella-ops.org/docs/benchmarks/scanner-feature-comparison-trivy.md

# Scanner Feature Comparison — StellaOps vs Trivy

_Reference snapshot: Trivy commit `012f3d75359e019df1eb2602460146d43cb59715`, cloned 2025-11-02._

## Verification Metadata

| Field | Value |
|-------|-------|
| **Last Updated** | 2025-12-15 |
| **Last Verified** | 2025-12-14 |
| **Next Review** | 2026-03-14 |
| **Claims Index** | [`docs/market/claims-citation-index.md`](../market/claims-citation-index.md) |
| **Claim IDs** | COMP-TRIVY-001, COMP-TRIVY-002, COMP-TRIVY-003 |
| **Verification Method** | Source code audit (OSS), documentation review, feature testing |

**Confidence Levels:**
- **High (80-100%)**: Verified against source code or authoritative documentation
- **Medium (50-80%)**: Based on documentation or limited testing; needs deeper verification
- **Low (<50%)**: Unverified or based on indirect evidence; requires validation

---

## TL;DR
- StellaOps Scanner stays focused on deterministic, tenant-scoped SBOM production with signed evidence, policy hand-offs, and Surface primitives that keep offline deployments first-class.[1](#sources)
- Trivy delivers broad, single-binary coverage (images, filesystems, repos, VMs, Kubernetes, SBOM input) with multiple scanners (vuln, misconfig, secret, license) and a rich plugin ecosystem, but it leaves provenance, signing, and multi-tenant controls to downstream tooling.[8](#sources)
- Opportunity: highlight StellaOps’ differentiators (attested evidence, Surface reuse, policy integration) while identifying where Trivy’s breadth suggests roadmap checkpoints (e.g., wider target ingestion or optional plugin bridges) without compromising determinism.

## Comparison Matrix

| Dimension | StellaOps Scanner | Trivy |
| --- | --- | --- |
| Architecture & deployment | WebService + Worker services with queue abstraction (Redis Streams/NATS), RustFS/S3 artifact store, PostgreSQL catalog, Authority-issued DPoP tokens, Surface.* libraries for env/fs/secrets, restart-only analyzer plugins.[1](#sources)[3](#sources)[4](#sources)[5](#sources) | Single Go binary CLI with optional server that centralises vulnerability DB updates; client/server mode streams scan queries while misconfig/secret scanning stays client-side; relies on local cache directories.[8](#sources)[15](#sources) |
| Scan targets & coverage | Container images & filesystem snapshots; analyser families:<br>• OS: APK, DPKG, RPM with layer fragments.<br>• Languages: Java, Node, Python, Go, .NET, Rust (installed metadata only).<br>• Native: ELF today (PE/Mach-O M2 roadmap).<br>• EntryTrace usage graph for runtime focus.<br>Outputs paired inventory/usage SBOMs plus BOM-index sidecar; no direct repo/VM/K8s scanning.[1](#sources) | Container images, rootfs, local filesystems, git repositories, VM images, Kubernetes clusters, and standalone SBOMs. Language portfolio spans Ruby, Python, PHP, Node.js, .NET, Java, Go, Rust, C/C++, Elixir, Dart, Swift, Julia across pre/post-build contexts. OS coverage includes Alpine, RHEL/Alma/Rocky, Debian/Ubuntu, SUSE, Amazon, Bottlerocket, etc. Secret and misconfiguration scanners run alongside vulnerability analysis.[8](#sources)[9](#sources)[10](#sources)[18](#sources)[19](#sources) |
| Evidence & outputs | CycloneDX (JSON + protobuf) and SPDX 3.0.1 exports, three-way diffs, DSSE-ready report metadata, BOM-index sidecar, deterministic manifests, explain traces for policy consumers.[1](#sources)[2](#sources) | Human-readable, JSON, CycloneDX, SPDX outputs; can both generate SBOMs and rescan existing SBOM artefacts; no built-in DSSE or attestation pipeline documented—signing left to external workflows.[8](#sources)[10](#sources) |
| Attestation & supply chain | DSSE signing via Signer → Attestor → Rekor v2, OpenVEX-first modelling, lattice logic for exploitability, provenance-bound digests, optional Rekor transparency, policy overlays.[1](#sources) | Experimental VEX repository consumption (`--vex repo`) pulling statements from VEX Hub or custom feeds; relies on external OCI registries for DB artefacts, but does not ship an attestation/signing workflow.[11](#sources)[14](#sources) |
| Policy & decisioning | Scanner reports facts; Policy Engine, Concelier, and Excititor consume SBOM + VEX to emit explainable verdicts; WebService streams policy previews and report links with tenant enforcement.[1](#sources)[7](#sources) | Built-in misconfiguration checks (OPA/Rego bundles) and severity filtering, but no integrated policy decisioning layer; consumers interpret results or bridge to Aqua commercial offerings.[8](#sources) |
| Offline & air-gap | Offline kits bundle Surface manifests, SBOM artefacts, secrets vault, and configuration; Surface.Env/Validation enforce deterministic prerequisites before work executes; RustFS supports air-gapped object storage.[3](#sources)[4](#sources)[6](#sources) | Supports offline scans by mirroring OCI-hosted vulnerability/Java/check databases, manual cache seeding, `--offline-scan`, and self-hosting VEX repositories; requires operators to keep mirrors fresh.[12](#sources)[13](#sources)[14](#sources) |
| Caching & performance | Layer CAS caching, Content-addressed Surface manifests, queue leasing with retries/dead-letter, EntryTrace reuse, analyzer restart-only plugins for reproducible hot-swaps.[1](#sources)[4](#sources) | Scan cache backends for filesystem, in-memory, or Redis (experimental); caches vulnerability/Java/misconfig bundles locally; BoltDB backend limits concurrent writers.[12](#sources) |
| Security & tenancy | Authority-scoped OpToks (DPoP/mTLS), tenant-aware storage prefixes, secret providers, validation pipeline preventing misconfiguration, DSSE signing for tamper evidence.[1](#sources)[3](#sources)[5](#sources)[6](#sources) | CLI/server intended for single-tenant use; docs emphasise network hardening but do not describe built-in tenant isolation or authenticated server endpoints—deployments rely on surrounding controls.[8](#sources)[15](#sources) |
| Extensibility & ecosystem | Analyzer plug-ins (restart-time), Surface shared libraries, BuildX SBOM generator, CLI orchestration, integration contracts with Scheduler, Export Center, Policy, Notify.[1](#sources)[2](#sources) | CLI plugin framework (`trivy plugin`), rich ecosystem integrations (GitHub Actions, Kubernetes operator, IDE plugins), community plugin index for custom commands.[8](#sources)[16](#sources) |
| Observability & ops | Structured logs, metrics for queue/cache/validation, policy preview traces, runbooks and offline manifest documentation embedded in module docs.[1](#sources)[4](#sources)[6](#sources) | CLI-/server-level logging; documentation focuses on usage rather than metrics/trace emission—operators layer external tooling as needed.[8](#sources) |
| Licensing | AGPL-3.0-or-later with sovereign/offline obligations (per project charter).[StellaOps LICENSE](../../LICENSE) | Apache-2.0; permissive for redistribution and derivative tooling.[17](#sources) |

## Coverage Deep Dive

### StellaOps Scanner
- **Targets**: container images and curated filesystem captures; workers read OCI layers via queue-driven jobs. Other asset types (git repos, clusters, VMs) stay outside current scope to preserve deterministic replay guarantees.[1](#sources)
- **OS ecosystems**: APK (Alpine/Wolfi), DPKG/APT (Debian/Ubuntu), RPM (RHEL, Fedora derivatives) analyzers extract authoritative package DB entries, with fragments persisted per layer for SBOM/diff assembly.[1](#sources)
- **Language analyzers**: Java (`pom.properties`, manifest), Node (`package.json`), Python (`*.dist-info`), Go (binary buildinfo), .NET (`*.deps.json`), Rust (embedded metadata/registry traces) recorded only when install evidence exists, avoiding lockfile speculation.[1](#sources)
- **Native & usage context**: ELF link graph, `bin:{sha256}` fallbacks, and EntryTrace shell/launcher resolution feed usage SBOM views and `usedByEntrypoint` bitmaps for downstream policy joins.[1](#sources)
- **Secrets posture**: Surface.Secrets provides tenant-scoped retrieval for CAS credentials, registry tokens, TLS material via pluggable providers (Kubernetes, file, inline) with validation/rotation controls; Scanner itself does not perform secret discovery within target artefacts.[5](#sources)

### Trivy
- **Targets**: CLI scans container images, rootfs exports, arbitrary filesystems, remote git repos, OCI and VM images, Kubernetes clusters, and accepts CycloneDX/SPDX SBOMs as inputs.[8](#sources)[10](#sources)
- **Language ecosystems**: Pre-build lockfiles and post-build package metadata across Ruby, Python, PHP, Node.js, .NET, Java, Go, Rust, C/C++, Elixir, Dart, Swift, Julia; availability varies by target type (image/rootfs/filesystem/repo).[9](#sources)
- **OS coverage**: Supports Alpine/Wolfi/Chainguard, RHEL/CentOS/Alma/Rocky, Debian/Ubuntu, SUSE family, Amazon/Azure Linux, Bottlerocket, and others with appropriate package manager adapters.[18](#sources)
- **Secret scanning**: Pattern-driven engine (builtin + custom regex rules) inspects plaintext files and `.pyc` bytecode, with allow/deny lists, custom rule packs, and options to limit scope for performance.[19](#sources)
- **Complementary scanners**: Misconfiguration (OPA/Rego bundles) and license analysis operate alongside vulnerability scanning, widening coverage beyond SBOM generation.[8](#sources)

### Secret Detection vs Secret Management
- **StellaOps**: Treats secrets as operational inputs. Surface.Secrets resolves tenant-scoped credentials from Kubernetes, file, or inline providers, caches handles securely, enforces validation/rotation, and packages encrypted archives for offline kits.[5](#sources) The scanner deliberately omits secret discovery in analysed artefacts to maintain deterministic SBOM focus.
- **Trivy**: Embeds secret detection within every scan, shipping extensive builtin rules (AWS/GCP/GitHub keys, private keys, etc.), allowlists, and configuration knobs (`--secret-config`, `enable-builtin-rules`). Secrets are reported with file/line context and severity, and features can be scoped or disabled per workload.[19](#sources)

## Ecosystem Deep Dives
- **Feature matrix overview** – see [scanner/deep-dives/matrix.md](scanner/deep-dives/matrix.md).
- **OS package managers** – see [scanner/deep-dives/os-packages.md](scanner/deep-dives/os-packages.md).
- **Node.js & package managers** – see [scanner/deep-dives/nodejs.md](scanner/deep-dives/nodejs.md).
- **Python ecosystem** – see [scanner/deep-dives/python.md](scanner/deep-dives/python.md).
- **Java / JVM artifacts** – see [scanner/deep-dives/java.md](scanner/deep-dives/java.md).
- **Go modules & binaries** – see [scanner/deep-dives/golang.md](scanner/deep-dives/golang.md).
- **.NET / NuGet** – see [scanner/deep-dives/dotnet.md](scanner/deep-dives/dotnet.md).
- **Rust ecosystem** – see [scanner/deep-dives/rust.md](scanner/deep-dives/rust.md).
- **SAST (application code)** – see [scanner/deep-dives/sast.md](scanner/deep-dives/sast.md).
- **Secret handling posture** – see [scanner/deep-dives/secrets.md](scanner/deep-dives/secrets.md).

## Observations
- StellaOps’ DSSE + Rekor attestation chain, Surface libraries, and tenant-aware controls are clear differentiators for regulated or offline-first estates; highlight these when positioning against broad scanners.
- Trivy’s breadth (targets, scanners, plugins) sets user expectations for “one tool covers everything.” Decide which scenarios (e.g., file system repos, IaC misconfig) we must support directly versus document integration paths.
- VEX remains a common thread: StellaOps emphasises OpenVEX + lattice logic; Trivy’s VEX Hub is experimental. Opportunity to showcase production-ready workflows and governance around VEX ingestion/waivers.
- Trivy ships no built-in SAST; Snyk remains the only compared scanner offering code analysis, so we should continue framing StellaOps around deterministic evidence and document recommended SAST partners for customers needing both.

## Opportunities for StellaOps
1. Publish a concise decision guide contrasting deterministic evidence (StellaOps) with generalist coverage (Trivy) for buyers evaluating scanners.
2. Evaluate lightweight adapters (or documentation) that re-use Trivy SBOM output when a customer already mandates it, while keeping StellaOps as the source of attested truth.
3. Track Trivy ecosystem additions (e.g., new target types) to inform backlog triage—capture deltas in this comparison doc when significant features land.

---

### Sources
1. `docs/modules/scanner/architecture.md`
2. `docs/modules/scanner/implementation_plan.md`
3. `docs/modules/scanner/design/surface-env.md`
4. `docs/modules/scanner/design/surface-fs.md`
5. `docs/modules/scanner/design/surface-secrets.md`
6. `docs/modules/scanner/design/surface-validation.md`
7. `docs/modules/platform/architecture-overview.md`
8. Trivy README — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/README.md>
9. Scanning coverage — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/coverage/index.md>
10. SBOM scanning — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/target/sbom.md>
11. VEX repository — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/supply-chain/vex/repo.md>
12. Cache configuration — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/configuration/cache.md>
13. Air-gap guidance — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/advanced/air-gap.md>
14. Self-hosting databases — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/advanced/self-hosting.md>
15. Client/server mode — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/references/modes/client-server.md>
16. Plugin system — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/plugin/index.md>
17. Trivy LICENSE — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/LICENSE>
18. OS coverage — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/coverage/os/index.md>
19. Secret scanning — <https://github.com/aquasecurity/trivy/blob/012f3d75359e019df1eb2602460146d43cb59715/docs/docs/scanner/secret.md>