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