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

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