Add OpenSslLegacyShim to ensure OpenSSL 1.1 libraries are accessible on Linux

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.

docs/benchmarks/scanner/deep-dives/dotnet.md

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

docs/benchmarks/scanner/deep-dives/golang.md

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

docs/benchmarks/scanner/deep-dives/java.md

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

docs/benchmarks/scanner/deep-dives/matrix.md

@@ -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. | — |

docs/benchmarks/scanner/deep-dives/nodejs.md

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

docs/benchmarks/scanner/deep-dives/os-packages.md

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

docs/benchmarks/scanner/deep-dives/python.md

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

docs/benchmarks/scanner/deep-dives/rust.md

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

docs/benchmarks/scanner/deep-dives/sast.md

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

docs/benchmarks/scanner/deep-dives/secrets.md

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