# Scanner Feature Comparison — StellaOps vs Snyk CLI

_Reference snapshot: Snyk CLI commit `7ae3b11642d143b588016d4daef0a6ddaddb792b` cloned 2025-11-02._

## TL;DR
- StellaOps delivers a self-hosted, multi-service scanning plane with deterministic SBOMs, attestation (DSSE + Rekor), and tenant-aware Surface controls, while the Snyk CLI is a Node.js tool that authenticates against Snyk’s SaaS to analyse dependency graphs, containers, IaC, and code.[1](#sources)[s1](#snyk-sources)
- Snyk’s plugin ecosystem covers many package managers (npm, yarn, pnpm, Maven, Gradle, NuGet, Go modules, Composer, etc.) and routes scans through Snyk’s cloud for policy, reporting, and fix advice; however it lacks offline operation, deterministic evidence, and attestation workflows that StellaOps provides out of the box.[1](#sources)[s1](#snyk-sources)[s2](#snyk-sources)
- Opportunity: Lean on StellaOps’ strengths (offline parity, provenance, policy) while tracking Snyk-only ecosystems (for example, SwiftPM, CocoaPods) and SaaS conveniences (IaC, Snyk Code) that may influence backlog priorities.

## Comparison Matrix

| Dimension | StellaOps Scanner | Snyk CLI |
| --- | --- | --- |
| Architecture & deployment | WebService + Worker services, queue backbone, RustFS/S3 artifact store, Mongo catalog, Authority-issued OpToks, Surface libs, restart-only analyzers.[1](#sources)[3](#sources)[4](#sources)[5](#sources) | Node.js CLI; users authenticate (`snyk auth`) and run commands (`snyk test`, `snyk monitor`, `snyk container test`) that upload project metadata to Snyk’s SaaS for analysis.[s2](#snyk-sources) |
| Scan targets & coverage | Container images/filesystems, analyzers for APK/DPKG/RPM, Java/Node/Python/Go/.NET/Rust, native ELF, EntryTrace usage graph.[1](#sources) | Supports Snyk Open Source, Container, Code (SAST), and IaC; plugin loader dispatches npm/yarn/pnpm, Maven/Gradle/SBT, pip/poetry, Go modules, NuGet/Paket, Composer, CocoaPods, Hex, SwiftPM.[s1](#snyk-sources)[s2](#snyk-sources) |
| Evidence & outputs | CycloneDX JSON/Protobuf, SPDX 3.0.1, deterministic diffs, BOM-index sidecar, explain traces, DSSE-ready report metadata.[1](#sources)[2](#sources) | CLI prints human-readable tables and supports JSON/SARIF outputs for Snyk Open Source/Snyk Code; results originate from cloud analysis, not deterministic SBOM fragments.[s3](#snyk-sources) |
| Attestation & supply chain | DSSE signing via Signer → Attestor → Rekor v2, OpenVEX-first modelling, policy overlays, provenance digests.[1](#sources) | No DSSE/attestation workflow; remediation guidance and monitors live in Snyk SaaS.[s2](#snyk-sources) |
| Policy & decisioning | Central Policy Engine (stella-dsl), lattice logic, VEX-first decisioning, API streaming of policy previews.[1](#sources)[7](#sources) | Policy controls managed in Snyk platform (org/project settings); CLI can gate on severity (`--severity-threshold`) and push projects for monitoring.[s2](#snyk-sources) |
| Offline & air-gap | Offline kits with Surface manifests, secrets bundles, RustFS; no external connectivity required after provisioning.[3](#sources)[4](#sources)[6](#sources) | Requires internet connectivity for authentication and analysis; no offline mode documented.[s2](#snyk-sources) |
| Caching & performance | Layer CAS caches, queue leasing, EntryTrace reuse, deterministic ordering.[1](#sources)[4](#sources) | Dependency graphs are resolved locally, but vulnerability analysis happens in the cloud; no local cache beyond CLI conveniences.[s1](#snyk-sources)[s2](#snyk-sources) |
| Security & tenancy | OpTok enforcement (DPoP/mTLS), tenant-aware storage, Surface.Secrets providers, validation pipeline.[1](#sources)[5](#sources)[6](#sources) | Authentication scoped per Snyk org; registry credentials handled via config/secret stores but no tenant isolation inside the CLI itself.[s2](#snyk-sources) |
| Extensibility & ecosystem | Analyzer plug-ins, BuildX SBOM generator, CLI/Worker integration, attested exports.[1](#sources)[2](#sources) | Plugin architecture for package managers (Node.js legacy + external plugins); integrations for CI/IDE rely on Snyk platform APIs.[s1](#snyk-sources) |
| Observability & ops | Structured logs, metrics, explain traces, offline manifests, runbooks.[1](#sources)[4](#sources)[6](#sources) | CLI logs to stdout/stderr; deeper analytics available via Snyk SaaS dashboards rather than local instrumentation.[s2](#snyk-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).
- **Secret handling posture** – see [scanner/deep-dives/secrets.md](scanner/deep-dives/secrets.md).
- **SAST (application code)** – see [scanner/deep-dives/sast.md](scanner/deep-dives/sast.md).

## Observations
- Snyk’s cloud-first workflow simplifies policy management and monitoring for hosted users, but it prevents fully offline operation—StellaOps should continue emphasising sovereign/offline parity while documenting bridge options (e.g., exporting SBOMs for Snyk ingestion).[s2](#snyk-sources)
- Plugin breadth (SwiftPM, CocoaPods, Hex) exceeds current StellaOps coverage; backlog items for these ecosystems may become higher priority if customer demand aligns.[s1](#snyk-sources)
- Secret detection and SAST are available via Snyk Code, yet require uploading code; StellaOps can differentiate with deterministic, self-hosted evidence plus attestation.

## Opportunities for StellaOps
1. Evaluate demand for additional package managers (SwiftPM, CocoaPods, Hex) supported by Snyk plugins and scope analyzer roadmap accordingly.[s1](#snyk-sources)
2. Provide guidance on integrating with external SaaS tools (including Snyk) using StellaOps SBOM exports for hybrid workflows.
3. Continue to highlight DSSE/attestation, offline kits, and tenant isolation as differentiators versus cloud-only scanners.

---

### 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`

#### Snyk sources
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
- [s2] `/tmp/snyk-cli/README.md`
- [s3] `/tmp/snyk-cli/src/lib/plugins/sast/format/output-format.ts`