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/python.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

2.7 KiB
Raw Blame History

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