5a480a3c2a
Some checks failed
AOC Guard CI / aoc-guard (push) Has been cancelled
AOC Guard CI / aoc-verify (push) Has been cancelled
Docs CI / lint-and-preview (push) Has been cancelled
Export Center CI / export-ci (push) Has been cancelled
Findings Ledger CI / build-test (push) Has been cancelled
Findings Ledger CI / migration-validation (push) Has been cancelled
Findings Ledger CI / generate-manifest (push) Has been cancelled
Lighthouse CI / Lighthouse Audit (push) Has been cancelled
Lighthouse CI / Axe Accessibility Audit (push) Has been cancelled
Policy Lint & Smoke / policy-lint (push) Has been cancelled
Reachability Corpus Validation / validate-corpus (push) Has been cancelled
Reachability Corpus Validation / validate-ground-truths (push) Has been cancelled
Scanner Analyzers / Discover Analyzers (push) Has been cancelled
Scanner Analyzers / Validate Test Fixtures (push) Has been cancelled
Signals CI & Image / signals-ci (push) Has been cancelled
Signals Reachability Scoring & Events / reachability-smoke (push) Has been cancelled
Reachability Corpus Validation / determinism-check (push) Has been cancelled
Scanner Analyzers / Build Analyzers (push) Has been cancelled
Scanner Analyzers / Test Language Analyzers (push) Has been cancelled
Scanner Analyzers / Verify Deterministic Output (push) Has been cancelled
Signals Reachability Scoring & Events / sign-and-upload (push) Has been cancelled
- Introduced `all-edge-reasons.json` to test edge resolution reasons in .NET. - Added `all-visibility-levels.json` to validate method visibility levels in .NET. - Created `dotnet-aspnetcore-minimal.json` for a minimal ASP.NET Core application. - Included `go-gin-api.json` for a Go Gin API application structure. - Added `java-spring-boot.json` for the Spring PetClinic application in Java. - Introduced `legacy-no-schema.json` for legacy application structure without schema. - Created `node-express-api.json` for an Express.js API application structure.
79 lines
7.5 KiB
Markdown
79 lines
7.5 KiB
Markdown
# Scanner Feature Comparison — StellaOps vs Snyk CLI
|
||
|
||
_Reference snapshot: Snyk CLI commit `7ae3b11642d143b588016d4daef0a6ddaddb792b` 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-SNYK-001, COMP-SNYK-002, COMP-SNYK-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 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`
|