1d962ee6fc
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
This commit introduces the OpenSslLegacyShim class, which sets the LD_LIBRARY_PATH environment variable to include the directory containing OpenSSL 1.1 native libraries. This is necessary for Mongo2Go to function correctly on Linux platforms that do not ship these libraries by default. The shim checks if the current operating system is Linux and whether the required directory exists before modifying the environment variable.
61 lines
6.8 KiB
Markdown
61 lines
6.8 KiB
Markdown
# 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`
|