Add OpenSslLegacyShim to ensure OpenSSL 1.1 libraries are accessible on Linux
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
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.
This commit is contained in:
master
63
docs/benchmarks/scanner-feature-comparison-grype.md
Normal file
63
docs/benchmarks/scanner-feature-comparison-grype.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# Scanner Feature Comparison — StellaOps vs Grype
|
||||
|
||||
_Reference snapshot: Grype commit `6e746a546ecca3e2456316551673357e4a166d77` cloned 2025-11-02._
|
||||
|
||||
## TL;DR
|
||||
- StellaOps runs as a multi-service platform with deterministic SBOM generation, attestation (DSSE + Rekor), and tenant-aware controls, whereas Grype is a single Go CLI that leans on Syft to build SBOMs before vulnerability matching.[1](#sources)[g1](#grype-sources)
|
||||
- Grype covers a broad OS and language matrix via Syft catalogers and Anchore’s aggregated vulnerability database, but it lacks attestation, runtime usage context, and secret management features found in StellaOps’ Surface/Policy ecosystem.[1](#sources)[g2](#grype-sources)[g3](#grype-sources)
|
||||
- Opportunity: position StellaOps’ strengths (evidence provenance, policy orchestration, offline kits) while tracking high-demand ecosystems that Grype already supports (e.g., Ruby, PHP) and could inform StellaOps backlog priorities.
|
||||
|
||||
## Comparison Matrix
|
||||
|
||||
| Dimension | StellaOps Scanner | Grype |
|
||||
| --- | --- | --- |
|
||||
| Architecture & deployment | WebService + Worker services, queue backbones, RustFS/S3 artifact store, Mongo catalog, Authority-issued OpToks, Surface libraries, restart-only analyzers.[1](#sources)[3](#sources)[4](#sources)[5](#sources) | Go CLI that invokes Syft to construct an SBOM from images/filesystems and feeds Syft’s packages into Anchore matchers; optional SBOM ingest via `syft`/`sbom` inputs.[g1](#grype-sources) |
|
||||
| Scan targets & coverage | Container images & filesystem captures; analyzers for APK/DPKG/RPM, Java/Node/Python/Go/.NET/Rust, native ELF, EntryTrace usage graph (PE/Mach-O roadmap).[1](#sources) | Images, directories, archives, and SBOMs; OS feeds include Alpine, Ubuntu, RHEL, SUSE, Wolfi, etc., and language support spans Ruby, Java, JavaScript, Python, .NET, Go, PHP, Rust.[g2](#grype-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) | Outputs table, JSON, CycloneDX (XML/JSON), SARIF, and templated formats; evidence tied to Syft SBOM and JSON report (no deterministic replay artifacts).[g4](#grype-sources) |
|
||||
| Attestation & supply chain | DSSE signing via Signer → Attestor → Rekor v2, OpenVEX-first modelling, policy overlays, provenance digests.[1](#sources) | Supports ingesting OpenVEX for filtering but ships no signing/attestation workflow; relies on external tooling for provenance.[g2](#grype-sources) |
|
||||
| Policy & decisioning | Central Policy Engine (stella-dsl), VEX-first decisioning, lattice logic, API streaming of policy previews, fail-fast validation pipelines.[1](#sources)[7](#sources) | CLI gating via `--fail-on`, ignore rules, and allow/deny lists; no multi-tenant policy service.[g4](#grype-sources) |
|
||||
| Offline & air-gap | Offline kits bundle artifacts, manifests, secrets; Surface.Env/Validation enforce prerequisites; RustFS supports air-gapped object storage.[3](#sources)[4](#sources)[6](#sources) | Local SQLite vulnerability DB auto-managed; supports offline by disabling auto-update and importing Anchore DB archives manually.[g3](#grype-sources) |
|
||||
| Caching & performance | Layer CAS caches, queue leasing, EntryTrace reuse, deterministic sorting for replay.[1](#sources)[4](#sources) | SBOM caching handled by Syft; vulnerability DB stored under `$XDG_CACHE_HOME`; no layer caches or queue orchestration.[g3](#grype-sources) |
|
||||
| Security & tenancy | OpTok enforcement (DPoP/mTLS), tenant-aware storage prefixes, Surface.Secrets providers, validation pipeline for misconfiguration, DSSE for tamper evidence.[1](#sources)[5](#sources)[6](#sources) | Single-user CLI; registry credentials handled via config secrets; no tenant isolation or secret provider abstraction.[g3](#grype-sources) |
|
||||
| Extensibility & ecosystem | Analyzer plug-ins, BuildX SBOM generator, CLI/Worker integration, Surface libraries, attested exports.[1](#sources)[2](#sources) | Template-based reporters, external Maven lookup, GitHub Actions integrations; cataloging delegated to Syft (extensible separately).[g2](#grype-sources)[g4](#grype-sources) |
|
||||
| Observability & ops | Structured logs, metrics, explain traces, offline manifests, runbooks.[1](#sources)[4](#sources)[6](#sources) | CLI logging and exit codes; no built-in metrics/traces beyond verbose logs.[g4](#grype-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
|
||||
- Grype’s reliance on Syft provides broad package coverage quickly, but it inherits Syft’s metadata limits (no runtime usage or deterministic replay). StellaOps can continue emphasizing provenance and policy orchestration while considering backlog for ecosystems where Grype today has parity (Ruby/PHP).[g1](#grype-sources)[g5](#grype-sources)
|
||||
- Anchore’s aggregated vulnerability DB offers fast setup, though it introduces dependency on Anchore services; StellaOps’ approach keeps attestation and evidence self-hostable, which remains a differentiator for regulated tenants.[1](#sources)[g3](#grype-sources)
|
||||
- Secret detection, SAST, and runtime attestation remain gaps for both Trivy and Grype—opportunity for StellaOps to lead with Surface policies, recommend SAST partners, and emphasise DSSE/EntryTrace integration.
|
||||
|
||||
## Opportunities for StellaOps
|
||||
1. Prioritize analyzers for ecosystems currently supported by Grype (Ruby, PHP, Composer) to close parity gaps without sacrificing determinism.[g5](#grype-sources)
|
||||
2. Publish guidance on integrating Anchore DB feeds (where allowed) while keeping StellaOps’ provenance guarantees, or offer curated feeds with DSSE-backed provenance for air-gapped users.[g3](#grype-sources)
|
||||
3. Evaluate optional syft/grype compatibility layers (importing Syft SBOMs) so customers can transition while retaining StellaOps attestation benefits.
|
||||
|
||||
---
|
||||
|
||||
### 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`
|
||||
|
||||
#### Grype sources
|
||||
- [g1] `grype/pkg/syft_provider.go`
|
||||
- [g2] `grype/README.md` (Features list: OS & language coverage, external sources, integrations)
|
||||
- [g3] `grype/README.md` (Vulnerability DB management, offline workflow)
|
||||
- [g4] `grype/README.md` (Output formats, CLI controls)
|
||||
- [g5] `grype/grype/matcher/javascript/matcher.go`
|
||||
60
docs/benchmarks/scanner-feature-comparison-snyk.md
Normal file
60
docs/benchmarks/scanner-feature-comparison-snyk.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# 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`
|
||||
90
docs/benchmarks/scanner-feature-comparison-trivy.md
Normal file
90
docs/benchmarks/scanner-feature-comparison-trivy.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# Scanner Feature Comparison — StellaOps vs Trivy
|
||||
|
||||
_Reference snapshot: Trivy commit `012f3d75359e019df1eb2602460146d43cb59715`, cloned 2025-11-02._
|
||||
|
||||
## 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, Mongo 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>
|
||||
31
docs/benchmarks/scanner/deep-dives/dotnet.md
Normal file
31
docs/benchmarks/scanner/deep-dives/dotnet.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# .NET / NuGet Ecosystem
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.DotNet/DotNetLanguageAnalyzer.cs` orchestrates package collection through `Internal/DotNetDependencyCollector.cs`.
|
||||
- Aggregates data from `*.deps.json`, `*.runtimeconfig.json`, and assemblies, merging multiple sources via `DotNetPackageAggregator`.
|
||||
- Metadata includes RID lists, serviceable flags, target frameworks, runtimeconfig origins, and authenticode signer details (via optional `IDotNetAuthenticodeInspector`).
|
||||
- Evidence records SHA512 hashes, file paths, and runtime config references; EntryTrace hints mark assemblies tied to runtime entrypoints.
|
||||
|
||||
## Trivy implementation
|
||||
- `pkg/fanal/analyzer/language/dotnet/nuget/nuget.go` parses `packages.lock.json` and `packages.config`, populating `types.Application` via parsers in `pkg/dependency/parser/nuget`.
|
||||
- Optionally resolves licenses by inspecting local `*.nuspec` files if the NuGet packages directory is present.
|
||||
- Focuses on dependency graph reconstruction (direct vs transitive) but does not analyse runtime asset maps or signing metadata.
|
||||
|
||||
## Snyk implementation
|
||||
- `src/lib/plugins/index.ts` routes NuGet and Paket projects to `snyk-nuget-plugin`.[s1]
|
||||
- CLI scans require authenticated access to Snyk’s SaaS backend; results reflect dependency tree analysis without runtimeconfig/signing metadata.[s2]
|
||||
- No offline mode or per-assembly evidence is provided beyond the vulnerability list returned.
|
||||
|
||||
## Grype implementation
|
||||
- Syft collects .NET packages and assemblies before matching (`grype/pkg/syft_provider.go`).
|
||||
- The .NET matcher targets `syftPkg.DotnetPkg` entries and invokes ecosystem/CPE matching (`grype/matcher/dotnet/matcher.go`); no authenticode or RID enrichment is propagated.
|
||||
- Outputs mirror SBOM inventory without runtimeconfig correlation or signing metadata.
|
||||
|
||||
## Key differences
|
||||
- **Runtime-aware metadata**: StellaOps correlates deps.json, runtimeconfig, and authenticode signatures; Trivy, Snyk, and Grype limit themselves to dependency catalogs.
|
||||
- **Evidence richness**: StellaOps stores per-assembly hashes and source file paths; Trivy, Snyk, and Grype output dependency lists without file-level provenance.
|
||||
- **Usage insights**: StellaOps applies EntryTrace flags to mark runtime use; Trivy, Snyk, and Grype do not differentiate runtime vs build-time packages.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
31
docs/benchmarks/scanner/deep-dives/golang.md
Normal file
31
docs/benchmarks/scanner/deep-dives/golang.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Go Modules & Binaries
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Go/GoLanguageAnalyzer.cs` scans executables for Go build info (`module.Version`, `build Settings`) and reads DWARF metadata when available.
|
||||
- Captures full module graphs (main + dependencies) with PURLs; for stripped binaries, falls back to hashed component keys via `GoBinaryScanner.TryClassifyStrippedBinary`.
|
||||
- Metadata records Go toolchain settings, build IDs, and replacements; evidence references binary paths and entrypoint usage (`LanguageAnalyzerContext.UsageHints`).
|
||||
- Ensures deterministic ordering and retains hashed fallback components for binaries lacking Go metadata.
|
||||
|
||||
## Trivy implementation
|
||||
- Analyzer registry includes `pkg/fanal/analyzer/language/golang/binary/binary.go` (Go binaries) and `.../mod/mod.go` (`go.mod` + `go.sum`).
|
||||
- Binary parser utilises `pkg/dependency/parser/golang/binary` to extract module data; non-Go or unrecognised binaries return nil without fallback components.
|
||||
- Module analyzer parses dependency requirements and classifies direct vs indirect modules but does not capture runtime usage or binary hashes.
|
||||
|
||||
## Snyk implementation
|
||||
- `src/lib/plugins/index.ts` dispatches Go projects to `snyk-go-plugin` (golangdep, gomodules, govendor).[s1]
|
||||
- CLI scans require authenticated connectivity and send dependency graphs to Snyk’s SaaS backend (`snyk test`, `snyk monitor`) for analysis; binaries are not inspected locally.[s2]
|
||||
- No fallback hashing or runtime usage metadata accompanies the results.
|
||||
|
||||
## Grype implementation
|
||||
- SBOM generation via Syft feeds Go modules/binaries into Grype (`grype/pkg/syft_provider.go`).
|
||||
- The Go matcher consumes `syftPkg.GoModulePkg`, applying ecosystem+/-CPE logic and skipping binaries with pseudo-version metadata when build info is insufficient (`grype/matcher/golang/matcher.go`).
|
||||
- No fallback hashing beyond Syft’s catalog; runtime usage and DWARF metadata are not surfaced.
|
||||
|
||||
## Key differences
|
||||
- **Fallback handling**: StellaOps emits explicit hashed components when build info is missing; Trivy and Grype skip binaries without usable metadata.
|
||||
- **Runtime linkage**: StellaOps ties modules to binary paths and EntryTrace usage; Trivy, Snyk, and Grype output inventory without execution context.
|
||||
- **Build metadata**: StellaOps records DWARF/VCS settings; Trivy, Snyk, and Grype rely on module info exposed by their parsers without extended metadata.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
32
docs/benchmarks/scanner/deep-dives/java.md
Normal file
32
docs/benchmarks/scanner/deep-dives/java.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Java / JVM Ecosystem
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Java/JavaLanguageAnalyzer.cs` normalises JAR/WAR/EAR/PAR archives within the scan root.
|
||||
- Extracts `META-INF/maven/**/pom.properties` alongside `MANIFEST.MF`, building Maven PURLs and capturing manifest metadata (implementation info, main class) per component.
|
||||
- Evidence locators encode archive-relative paths (`archive.jar!META-INF/...`) and include cryptographic hashes; EntryTrace usage hints mark archives referenced by runtime entrypoints.
|
||||
- Focuses on installed artifacts; build-time descriptors (Gradle/SBT) are out of scope for the core analyzer.
|
||||
|
||||
## Trivy implementation
|
||||
- `pkg/fanal/analyzer/language/java/jar/jar.go` registers a post-analyzer parsing archives via `pkg/dependency/parser/java/jar`, leveraging the Java DB client for supplemental metadata.
|
||||
- Additional analyzers handle Gradle lockfiles, Maven `pom.xml`, and SBT lockfiles, expanding pre-build coverage.
|
||||
- Results populate `types.Application` with dependency graphs and optional license data; relies on external Java DB availability.
|
||||
- Does not track runtime usage or per-layer provenance.
|
||||
|
||||
## Snyk implementation
|
||||
- Java projects are handled by plugins such as `snyk-mvn-plugin`, `snyk-gradle-plugin`, and `snyk-sbt-plugin` loaded via `src/lib/plugins/index.ts`.[s1]
|
||||
- CLI commands (`snyk test`, `snyk monitor`) require authentication and network connectivity; dependency graphs are evaluated by Snyk’s SaaS service.[s2]
|
||||
- Archive-level hashes or EntryTrace usage are not exposed—results focus on vulnerability listings returned by the service.
|
||||
|
||||
## Grype implementation
|
||||
- Syft builds the SBOM before matching (`grype/pkg/syft_provider.go`), supplying Java packages and metadata.
|
||||
- The Java matcher accepts `syftPkg.JavaPkg` and Jenkins plugin packages; it can query Maven by SHA when POM metadata is missing and falls back to ecosystem/CPE matching (`grype/matcher/java/matcher.go`).
|
||||
- No deterministic archive hashing or EntryTrace linkage; provenance mirrors Syft’s SBOM plus Anchore’s upstream lookups.
|
||||
|
||||
## Key differences
|
||||
- **Archive evidence**: StellaOps captures archive path, hashes, and manifest data for deterministic attestation; Trivy, Snyk, and Grype derive dependency graphs without preserving per-entry evidence.
|
||||
- **Build-tool coverage**: Trivy supports Gradle/SBT lockfiles; Snyk uses dedicated Maven/Gradle/SBT plugins; Grype augments matches via Maven SHA searches; StellaOps intentionally scopes to observed artifacts.
|
||||
- **Usage insights**: StellaOps records EntryTrace linkage from executables to archives; Trivy, Snyk, and Grype omit runtime usage metadata.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
28
docs/benchmarks/scanner/deep-dives/matrix.md
Normal file
28
docs/benchmarks/scanner/deep-dives/matrix.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Ecosystem Feature Matrix — StellaOps vs Trivy / Grype / Snyk
|
||||
|
||||
| Lang / Ecosystem | Feature | Winner | StellaOps gaps | Trivy gaps | Grype gaps | Snyk gaps | Backlog follow-up (suggested) | Doc |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| .NET | Dependency retrieval | Snyk | No pre-build lock/config ingestion (installed `deps.json` only). | No runtime graph; ignores `runtimeconfig`/installed assemblies. | Relies on Syft `deps.json` catalogs; no layer-aware runtime context. | Requires authenticated SaaS analysis; projects often need restore/build before scanning. | Evaluate adding lockfile analyzer parity (track via Scanner .NET guild tasks). | [dotnet.md](dotnet.md) |
|
||||
| .NET | Runtime metadata & signing | StellaOps | Authenticode inspection optional; Windows-only coverage pending. | Does not capture signer metadata or assembly hashes. | No authenticode or RID metadata captured; package fields only. | No runtimeconfig/authenticode data; focuses on dependency manifests. | Harden Authenticode integration & document Windows variants. | [dotnet.md](dotnet.md) |
|
||||
| Node.js | Workspace & pnpm resolution | Tie (StellaOps / Snyk) | Lack of pnpm lock validator tooling for CLI users. | pnpm virtual store resolved only via lockfile semantics; skips actual installs. | Depends on Syft catalogers; lacks pnpm workspace policy controls or dedupe tuning. | Manifest-based plugins (npm/yarn/pnpm) send dependency graphs to Snyk API; offline unsupported. | Add pnpm validator CLI story; share results with Surface Env guild. | [nodejs.md](nodejs.md) |
|
||||
| Node.js | Usage tracking | StellaOps | EntryTrace launcher catalog requires regular updates. | No runtime usage model; inventory-only. | No runtime usage modelling; reports inventory only. | No runtime usage modelling (inventory only). | Establish cadence for launcher catalog review (EntryTrace TASKS). | [nodejs.md](nodejs.md) |
|
||||
| Python | Evidence source | Tie (StellaOps / Trivy) | Build-only repos need supplemental workflow. | Accepts stale lockfiles; installed evidence optional. | Leverages Syft-installed metadata; build-only projects need external flow. | Requires language environment & build; manifest graph sent to Snyk service. | Scope CLI guidance for build-only repos in docs backlog. | [python.md](python.md) |
|
||||
| Python | Usage awareness | StellaOps | EntryTrace hints dependent on shell heuristic coverage. | Missing runtime usage context entirely. | No runtime usage awareness. | No runtime usage metadata. | Expand EntryTrace shell heuristic coverage. | [python.md](python.md) |
|
||||
| Java | Archive evidence | Tie (StellaOps / Snyk) | Gradle/SBT lockfiles out of scope; relies on observed archives. | No archive hash locators; depends on Java DB availability. | Relies on Syft archive metadata without manifest hashing/attestation. | Relies on Maven/Gradle plugins; no archive hashing or offline support. | Track Gradle/SBT ingestion feasibility (Java analyzer task board). | [java.md](java.md) |
|
||||
| Go | Stripped binaries | StellaOps | Fallback components limited to hash + binary metadata. | Drops binaries lacking build info; no fallback reporting. | Skips pseudo-version binaries without build info; no hashed fallback. | Go plugin inspects modules via manifests; binaries without modules not analysed. | Investigate richer fallback metadata (Go analyzer backlog). | [golang.md](golang.md) |
|
||||
| Rust | Binary heuristics | StellaOps | Fingerprint coverage incomplete for niche toolchains. | Unmatched binaries ignored; no fallback crates. | No fallback for binaries lacking Cargo metadata; depends on Syft crate data. | No Rust/Cargo support in CLI plugins. | Expand fingerprint signatures; note in Rust analyzer tasks. | [rust.md](rust.md) |
|
||||
| OS packages | Linux distro coverage & provenance | Tie (StellaOps / Grype) | Requires RustFS/object store deployment for full replay; Windows packaging still out of scope. | No per-layer fragment storage; provenance limited; Windows support likewise minimal. | No per-layer provenance; shares Syft catalog and Anchore DB only. | Snyk Container scanning depends on SaaS API; no per-layer provenance. | Document RustFS dependency & offline alternatives in ops backlog; evaluate Windows pkg roadmap. | [os-packages.md](os-packages.md) |
|
||||
| OS packages | Linux flavor support (Alpine/Wolfi/Chainguard, Debian/Ubuntu, RHEL/Alma/Rocky, SUSE, Amazon/Bottlerocket) | Tie (Trivy / Snyk) | Windows/macOS package ecosystems still pending. | Coverage relies on package DB adapters; per-distro nuances (e.g., Chainguard signatures) not attested. | Supports major Linux feeds but no Windows/macOS package analyzers. | Supports documented distro list via Snyk Container but requires cloud connectivity. | Track demand for non-Linux package analyzers; document distro mapping in os-packages deep dive. | [os-packages.md](os-packages.md) |
|
||||
| OS packages | Windows/macOS coverage | — | No Windows/macOS analyzer; backlog item for offline parity. | Coverage docs enumerate Linux distributions only; Windows/macOS packages unsupported. | Syft matchers focus on Linux ecosystems; Windows/macOS packages unsupported. | Coverage depends on Snyk’s SaaS service; no offline assurance for Windows/macOS packages. | Capture demand for Windows/macOS analyzers and scope feasibility. | [os-packages.md](os-packages.md) |
|
||||
| Secrets | Handling posture | StellaOps | No leak scanning by design; Surface.Secrets manages retrieval/rotation with tenant scopes. | Leak detections lack governance hooks; operators must track rule updates. | No secret management abstraction; credentials configured manually. | Requires SaaS backend for secret scanning; no offline posture or secret storage guidance. | Document governance patterns for Surface.Secrets users and recommended companion tooling. | [secrets.md](secrets.md) |
|
||||
| Secrets | Detection technique | Trivy | No content scanning; relies on Surface.Secrets integrations. | Regex/entropy detectors with configurable allow/deny lists across files/bytecode. | No detector available; Syft/Grype skip leak scanning entirely. | Snyk Code/Snyk secrets require uploading code to SaaS; offline detection unavailable. | Provide guidance on pairing Surface with third-party leak scanners; evaluate optional plugin strategy. | [secrets.md](secrets.md) |
|
||||
| EntryTrace | Runtime command resolution | StellaOps | Shell/language launcher coverage needs continuous tuning. | Not supported. | Not available. | Not available. | Continue EntryTrace backlog (SURFACE-ENTRYTRACE stories). | — |
|
||||
| DSSE / Rekor | Attested SBOM/report signing | StellaOps | Rekor v2 adoption requires operator enablement guidance. | Not supported. | No attestation or transparency log integration. | No attestation workflow. | Add operator playbook updates in Export Center backlog. | — |
|
||||
| Ruby | Language analyzer parity | Snyk | No Ruby analyzer implementation yet. | Lacks runtime usage/EntryTrace integration. | Supports Ruby via matcher but lacks runtime usage/attestation. | Supported through rubygems plugin (SaaS dependency graph). | Prioritise Ruby analyzer work (see `src/Scanner/StellaOps.Scanner.Analyzers.Lang.Ruby/TASKS.md`). | — |
|
||||
| PHP | Language analyzer parity | Snyk | No PHP analyzer implementation yet. | No usage or evidence beyond lockfiles. | Composer handled via generic matcher; no runtime evidence. | Supported through PHP Composer plugin (requires Snyk API). | Track PHP analyzer backlog (`...Lang.Php/TASKS.md`). | — |
|
||||
| Deno | Language analyzer parity | Trivy | Analyzer not yet implemented (tasks pending). | None (lockfile support limited but present). | No Deno support. | No Deno plugin. | Execute Deno analyzer epics in `...Lang.Deno/TASKS.md`. | — |
|
||||
| Dart | Language analyzer parity | Trivy | No Dart support. | Provides Dart lockfile parsing. | No Dart support. | No Dart plugin. | Create backlog item for Dart coverage feasibility study. | — |
|
||||
| Swift | Language analyzer parity | Snyk | No Swift support today. | Supports Package.resolved parsing but no runtime usage. | No Swift support. | Supported via swift plugin but SaaS-only. | Evaluate need for Swift analyzer based on customer demand. | — |
|
||||
| SAST | Application code analysis | Snyk | No built-in SAST engine. | No SAST engine (focus on vuln & config). | No SAST support (SBOM matching only). | Requires SaaS upload of code; privacy considerations. | Evaluate integration points with existing SAST tooling / document partner options. | [sast.md](sast.md) |
|
||||
| IaC / Misconfiguration | Built-in scanning | Snyk | No misconfiguration analyzer (policy engine focuses on runtime evidence). | Ships IaC scanning but lacks deterministic replay. | No IaC or misconfiguration scanners (vulnerability-only). | Handled via Snyk IaC (`snyk iac test`) with SaaS policy engine. | Coordinate with Policy/Surface guild on IaC roadmap assessment. | — |
|
||||
| Kubernetes / VM targets | Target coverage breadth | Tie (Trivy / Snyk) | Scanner limited to images/filesystems; relies on other modules for runtime posture. | Supported but lacks attestation pipeline. | Scans images/filesystems; no live cluster or VM state analysis. | Snyk Container/K8s scanning available but cloud-managed; no offline runtime attestation. | Document complementary modules (Zastava/Runtime) in comparison appendix. | — |
|
||||
33
docs/benchmarks/scanner/deep-dives/nodejs.md
Normal file
33
docs/benchmarks/scanner/deep-dives/nodejs.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Node.js & Package Managers
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Node/NodeLanguageAnalyzer.cs` drives analysis, delegating filesystem traversal to `Internal/NodePackageCollector.cs`.
|
||||
- Workspace-aware: respects monorepo manifests and PNPM virtual store layout while de-duplicating package paths.
|
||||
- Emits components only when concrete `package.json` evidence is present, sorted deterministically and annotated with usage hints from EntryTrace (via `LanguageAnalyzerContext`).
|
||||
- Metadata captures resolved workspace membership, install locations, lock-derived provenance, and npm package type; evidence records exact file locators for `package.json` entries.
|
||||
|
||||
## Trivy implementation
|
||||
- Post-analyzers under `pkg/fanal/analyzer/language/nodejs` cover npm, Yarn, pnpm, and Bun lockfiles.
|
||||
- `.../npm/npm.go` parses `package-lock.json`, optionally harvesting license data by walking `node_modules` and re-reading `package.json`.
|
||||
- Each analyzer registers via `analyzer.RegisterPostAnalyzer`, translating lockfile dependency graphs into `types.Application` without runtime usage linkage.
|
||||
- License attribution depends on `node_modules` material being present (`npm install`/`pnpm install` executed) but does not emit per-file evidence.
|
||||
|
||||
## Snyk implementation
|
||||
- The CLI selects language plugins (legacy Node.js, `snyk-nodejs-plugin`) from `src/lib/plugins/index.ts`, covering npm, yarn, and pnpm manifests via dedicated parsers.[s1]
|
||||
- Dependency trees are resolved locally (lockfile/workspace parsing) then sent to Snyk’s SaaS API (`snyk test`, `snyk monitor`) for vulnerability assessment; CLI requires authenticated network access.[s2]
|
||||
- No per-file evidence or runtime usage information is emitted beyond the dependency graph returned by the API.
|
||||
|
||||
## Grype implementation
|
||||
- SBOM creation is handled by Syft before matching; `grype/pkg/syft_provider.go` retrieves sources and constructs the catalog used for scanning.
|
||||
- The JavaScript matcher advertises support for `syftPkg.NpmPkg` and performs ecosystem/CPE matching via Anchore’s vulnerability provider (`grype/matcher/javascript/matcher.go`).
|
||||
- No workspace- or usage-aware enrichment beyond what Syft records in the SBOM; pnpm/yarn nuances depend on Syft catalogers.
|
||||
|
||||
## Key differences
|
||||
- **Evidence vs lockfiles**: StellaOps grounds every component in observed filesystem evidence, while Trivy prioritises lockfile graphs (falling back to installed metadata for licensing only).
|
||||
- **Usage awareness**: StellaOps propagates EntryTrace hints to mark packages used by runtime entrypoints; Trivy and Snyk/Grype do not track usage.
|
||||
- **PNPM handling**: StellaOps crawls the virtual store to resolve flattened packages; Trivy and Snyk lean on pnpm lockfile semantics supplied by their parsers.
|
||||
- **Output richness**: StellaOps records workspace context and per-file evidence suitable for deterministic replay, whereas Trivy, Snyk, and Grype surface inventory-only dependency lists.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
35
docs/benchmarks/scanner/deep-dives/os-packages.md
Normal file
35
docs/benchmarks/scanner/deep-dives/os-packages.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# OS Package Managers (APK / DPKG / RPM)
|
||||
|
||||
## StellaOps implementation
|
||||
- Analyzer implementations reside under `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.OS.*` (e.g., `...OS.Dpkg/DpkgPackageAnalyzer.cs`, `...OS.Rpm/RpmPackageAnalyzer.cs`, `...OS.Apk/ApkPackageAnalyzer.cs`).
|
||||
- Each analyzer reads authoritative package databases (`/var/lib/dpkg/status`, RPMDB headers, `lib/apk/db/installed`) and emits content-addressed fragments per layer.
|
||||
- Metadata includes source package, maintainer, vendor fields, dependencies/provides, license strings, and CVE hint extraction; file evidence captures configuration files and checksums.
|
||||
- Results feed SBOM assembly with deterministic ordering and layer attribution, enabling replayable diff/manifests and provenance binding.
|
||||
- Windows/macOS package ecosystems remain out of scope; analyzer backlog tracks feasibility for future releases.
|
||||
|
||||
## Trivy implementation
|
||||
- Package analyzers live under `pkg/fanal/analyzer/pkg` (apk, dpkg, rpm). Parsers translate distro databases into `types.Package` records for vulnerability matching.
|
||||
- RPM analyzers leverage distro-specific metadata (e.g., Red Hat content manifests) when available; dpkg/apk analyzers enumerate package lists and file paths for licensing purposes.
|
||||
- Layer attribution is implicit via artifact walkers; outputs prioritise package inventories for scanning rather than deterministic fragment storage.
|
||||
- Supported operating systems are catalogued in `docs/docs/coverage/os/index.md`, which maps Alpine/Wolfi/Chainguard/MinimOS (apk), RHEL and rebuilds (dnf/yum/rpm), SUSE families (zypper), Photon/Azure/Amazon variants, Debian/Ubuntu, Bottlerocket, and Conda-based images to their package managers with per-distro version ranges (e.g., `docs/docs/coverage/os/rhel.md`, `.../ubuntu.md`, `.../suse.md`, `.../amazon.md`, `.../bottlerocket.md`).[t1]
|
||||
- Container image profiles such as Google Distroless and Bitnami are tracked in the same coverage table, highlighting Trivy’s ability to repurpose cached feeds across common base images.[t1]
|
||||
|
||||
## Snyk implementation
|
||||
- The CLI exposes container scanning (`snyk container test`) that uploads image metadata to Snyk’s SaaS backend for analysis; supported distribution lists are maintained in Snyk SaaS documentation rather than the CLI itself.[s1]
|
||||
- Requires authentication and network connectivity; no per-layer fragments or offline workflow beyond SaaS-managed results, and coverage expands as the SaaS service updates its advisory backends rather than local catalogers.[s1]
|
||||
|
||||
## Grype implementation
|
||||
- Source enumeration flows through Syft (`grype/pkg/syft_provider.go`), after which distro-specific matchers operate (e.g., `grype/matcher/apk/matcher.go`, `grype/matcher/dpkg/matcher.go`).
|
||||
- Matchers combine ecosystem lookups, upstream package indirection, and Anchore’s vulnerability DB; fixes and NAK handling (e.g., Alpine SecDB) are embedded in matcher logic.
|
||||
- OS support mirrors Syft’s catalogers: dedicated matchers exist for APK (Alpine/Wolfi/Chainguard), DPKG/APT (Debian/Ubuntu), RPM (RHEL/Alma/Rocky/Amazon/SUSE), Portage, Bitnami stacks, and stock package inventories, all under `grype/matcher/**`. The matcher set delegates to Anchore’s feed service to stay current with distro advisories.[g1]
|
||||
- Per-layer provenance is not retained; results align with Syft’s catalog and Anchore’s aggregated feeds.
|
||||
|
||||
## Key differences
|
||||
- **Layer fragments**: StellaOps persists per-layer fragments tied to content-addressed storage, whereas Trivy, Snyk, and Grype maintain package inventories without explicit fragment artifacts.
|
||||
- **Metadata depth**: StellaOps records extensive vendor metadata and file evidence for replay; Trivy, Snyk, and Grype focus on match-relevant fields from their feeds.
|
||||
- **Provenance**: StellaOps’ outputs integrate directly with attestation/diff pipelines, while Trivy, Snyk, and Grype assume downstream tools consume package lists without replay requirements.
|
||||
|
||||
### References
|
||||
- [t1] `/tmp/trivy-src/docs/docs/coverage/os/index.md`
|
||||
- [s1] `/tmp/snyk-cli/README.md`
|
||||
- [g1] `/tmp/grype-data/grype/matcher/apk/matcher.go`, `/tmp/grype-data/grype/matcher/dpkg/matcher.go`, `/tmp/grype-data/grype/matcher/rpm/matcher.go`
|
||||
32
docs/benchmarks/scanner/deep-dives/python.md
Normal file
32
docs/benchmarks/scanner/deep-dives/python.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Python Ecosystem
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Python/PythonLanguageAnalyzer.cs` enumerates `*.dist-info` directories (using deterministic traversal options) and loads metadata through `PythonDistributionLoader`.
|
||||
- Components are emitted only when authoritative installed metadata is available (`METADATA`, `RECORD`, `entry_points.txt`), guaranteeing observed-state accuracy across layers and virtual environments.
|
||||
- EntryTrace usage hints flag distributions whose scripts appear in runtime paths, enabling “usage vs inventory” SBOM differentiation.
|
||||
- Evidence payloads capture file locators (path + hash) so downstream diff/attestation pipelines can replay findings deterministically.
|
||||
|
||||
## Trivy implementation
|
||||
- Multiple analyzers under `pkg/fanal/analyzer/language/python` target packaging formats (`packaging`, `egg`, `wheel`) and lockfiles (`pip`, `poetry`, `pipenv`, `uv`).
|
||||
- Lockfile analyzers parse dependency graphs via language parsers (e.g., `pkg/dependency/parser/python/poetry`), classifying direct vs transitive packages for vulnerability matching.
|
||||
- Packaging analyzers walk archives to populate `types.Application`, enriching license data by inspecting declared license files.
|
||||
- Outputs prioritise dependency relationships; runtime usage and per-file evidence are not tracked.
|
||||
|
||||
## Snyk implementation
|
||||
- The CLI selects `snyk-python-plugin` for `pip` and `poetry` projects (`src/lib/plugins/index.ts`).[s1]
|
||||
- Users must authenticate and often build or prepare their Python environment before running `snyk test`; dependency graphs are uploaded to Snyk’s SaaS backend for analysis.[s2]
|
||||
- No runtime usage metadata or per-file evidence is surfaced beyond the API response.
|
||||
|
||||
## Grype implementation
|
||||
- SBOM extraction relies on Syft (`grype/pkg/syft_provider.go`), which catalogs Python packages from `dist-info`/egg metadata.
|
||||
- The Python matcher accepts `syftPkg.PythonPkg` entries and performs ecosystem/CPE matching via Anchore’s provider (`grype/matcher/python/matcher.go`).
|
||||
- No runtime or usage annotations beyond Syft’s inventory; lockfile vs installed distinctions follow Syft’s behavior.
|
||||
|
||||
## Key differences
|
||||
- **Source of truth**: StellaOps confines itself to installed artefacts for determinism; Trivy, Snyk, and Grype accommodate SBOM/lockfile inventory generated by their parsers.
|
||||
- **Usage metadata**: StellaOps propagates EntryTrace usage, supporting policy decisions on runtime reach; Trivy, Snyk, and Grype emit inventory without runtime context.
|
||||
- **Evidence granularity**: StellaOps stores per-file evidence hashes; Trivy, Snyk, and Grype focus on dependency graphs and CPE matching, not replay artefacts.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
29
docs/benchmarks/scanner/deep-dives/rust.md
Normal file
29
docs/benchmarks/scanner/deep-dives/rust.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Rust Ecosystem
|
||||
|
||||
## StellaOps implementation
|
||||
- `src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.Lang.Rust/RustLanguageAnalyzer.cs` coordinates collection via `Internal/RustAnalyzerCollector.cs`.
|
||||
- Collector ingests Cargo.lock, cargo fingerprint caches, and compiled binaries, merging data into three record sets: crate (authoritative), heuristic (fingerprints), and fallback (hashed binaries).
|
||||
- License metadata is sourced through `RustLicenseScanner`; binaries retain SHA256 hashes and usage indicators derived from EntryTrace.
|
||||
- Results are deduplicated and sorted to guarantee deterministic replay; each record includes evidence pointing to lockfile paths or binary locations.
|
||||
|
||||
## Trivy implementation
|
||||
- `pkg/fanal/analyzer/language/rust/cargo/cargo.go` parses Cargo.lock/TOML to classify direct, workspace, and transitive dependencies, removing dev dependencies where possible.
|
||||
- `pkg/fanal/analyzer/language/rust/binary/binary.go` inspects ELF binaries, returning nil when crate metadata is missing; no hashed fallback component is emitted.
|
||||
- License attribution relies on Cargo metadata; runtime usage is not tracked.
|
||||
|
||||
## Snyk implementation
|
||||
- The plugin dispatcher in `src/lib/plugins/index.ts` does not list a Rust/Cargo plugin, so Rust projects are currently unsupported by the Snyk CLI.[s1]
|
||||
- Users must resort to other tooling or Snyk SaaS capabilities outside the CLI for Rust coverage.
|
||||
|
||||
## Grype implementation
|
||||
- Syft provides Rust packages for Grype’s matchers (`grype/pkg/syft_provider.go`).
|
||||
- The Rust matcher consumes `syftPkg.RustPkg` and matches via ecosystem/CPE lookups (`grype/matcher/rust/matcher.go`); there is no fallback for binaries without Cargo metadata.
|
||||
- Runtime usage, fingerprinting, or hashed binary fallbacks are not emitted.
|
||||
|
||||
## Key differences
|
||||
- **Fallback strategy**: StellaOps preserves components for binaries lacking metadata; Trivy and Grype drop or ignore binaries without Cargo linkage, while Snyk lacks Rust support entirely.
|
||||
- **Evidence breadth**: StellaOps aggregates lockfile, fingerprint, and binary evidence into a deterministic record; Trivy and Grype primarily consume Cargo descriptors, and Snyk provides no CLI coverage.
|
||||
- **Usage insight**: StellaOps propagates EntryTrace usage flags; Trivy and Grype outputs are inventory-only; Snyk has no runtime data due to lack of support.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/index.ts`
|
||||
21
docs/benchmarks/scanner/deep-dives/sast.md
Normal file
21
docs/benchmarks/scanner/deep-dives/sast.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# SAST (Application Code Scanning)
|
||||
|
||||
## StellaOps implementation
|
||||
- No first-party SAST engine; platform focuses on deterministic SBOM, vulnerability ingestion, and policy evaluation rather than static code analysis.
|
||||
|
||||
## Trivy implementation
|
||||
- Trivy does not ship a SAST analyzer; scanning targets container images, filesystems, SBOMs, and misconfiguration/secret detection only.
|
||||
|
||||
## Grype implementation
|
||||
- Grype is limited to SBOM-driven vulnerability matching; static code analysis is out of scope.
|
||||
|
||||
## Snyk implementation
|
||||
- The CLI routes SAST requests through Snyk Code (`snyk code test`), leveraging the SAST plugin stack under `src/lib/plugins/sast` and emitting SARIF/JSON outputs.[s1]
|
||||
- Code is uploaded to Snyk’s SaaS backend for analysis, producing issue listings, severities, and remediation guidance; offline execution is unsupported.[s2]
|
||||
|
||||
## Key differences
|
||||
- Only Snyk provides integrated SAST capabilities via Snyk Code; StellaOps, Trivy, and Grype would require external tooling for static analysis.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/sast`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
32
docs/benchmarks/scanner/deep-dives/secrets.md
Normal file
32
docs/benchmarks/scanner/deep-dives/secrets.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Secret Handling
|
||||
|
||||
## StellaOps approach
|
||||
- Secrets treated as operational inputs delivered through Surface.Secrets (`src/Scanner/__Libraries/StellaOps.Scanner.Surface.Secrets` and documented in `docs/modules/scanner/design/surface-secrets.md`).
|
||||
- Providers support Kubernetes Secrets, file-based bundles, and inline definitions; configuration resolved via Surface.Env with validation gates from Surface.Validation.
|
||||
- Secret placeholders (`secret://type/name`) are resolved before analyzers execute, with results wrapped in secure handles and rotation metadata checked at startup.
|
||||
- Scanner deliberately avoids scanning artefacts for secret disclosure to preserve deterministic SBOM pipelines and avoid exposing sensitive payloads.
|
||||
|
||||
## Trivy approach
|
||||
- Secret scanning integrated as an analyzer under `pkg/fanal/secret`, applying regex-based detectors across plaintext files and certain bytecode (e.g., `.pyc`).
|
||||
- Builtin rule sets detect common credentials (AWS, GCP, GitHub PATs, private keys) with allow/deny configurations (`pkg/fanal/secret/builtin-allow-rules.go`) and support custom rule packs via `trivy-secret.yaml`.
|
||||
- Findings include file path, line number, severity, and match; operators fine-tune via CLI options (`--secret-config`, `--skip-dirs`, `enable-builtin-rules`).
|
||||
- Secret storage/rotation is outside Trivy scope; deployments manage credentials independently.
|
||||
|
||||
## Snyk approach
|
||||
- Secret detection is available through Snyk Code scans (`snyk code test`), invoked from the CLI via the Snyk Code plugin stack (`src/lib/plugins/sast`).[s1]
|
||||
- CLI usage requires authentication and uploads code to Snyk’s SaaS backend (per README guidance), so offline workflows are not supported.[s2]
|
||||
- Results focus on issue listings from the service; operational secret management is not part of the CLI.
|
||||
|
||||
## Grype approach
|
||||
- Grype does not ship a secret-scanning analyzer; secrets surface only as credentials for registry access (`cmd/grype/cli/options/secret.go`, README sections on mounting Kubernetes secrets).
|
||||
- Operators must rely on external tooling for leak detection while Grype focuses exclusively on vulnerability matching.[g1]
|
||||
|
||||
## Key differences
|
||||
- **Purpose**: StellaOps focuses on secure retrieval/validation of operational secrets; Trivy and Snyk Code detect leaked secrets, whereas Grype omits secret detection entirely.
|
||||
- **Workflow**: StellaOps’ secret lifecycle is pre-scan configuration; Trivy and Snyk analyse content at scan time (Snyk requiring SaaS connectivity), and Grype requires external tooling for leak detection.
|
||||
- **Determinism**: StellaOps avoids non-deterministic leak scans; Trivy and Snyk’s detectors may evolve with rule updates; Grype remains deterministic by not attempting secret discovery.
|
||||
|
||||
### References
|
||||
- [s1] `/tmp/snyk-cli/src/lib/plugins/sast`
|
||||
- [s2] `/tmp/snyk-cli/README.md`
|
||||
- [g1] `/tmp/grype/README.md`
|
||||
Reference in New Issue
Block a user