stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 1 Releases Wiki Activity
Files
40e7f827da764e39ca67fc27a74813a98e9a38d2
git.stella-ops.org/docs/benchmarks/scanner/deep-dives/nodejs.md
master 1d962ee6fc
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Details
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.
2025-11-02 21:41:03 +02:00

3.0 KiB
Raw Blame History

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