Files
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
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

33 lines
2.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 Snyks 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 Syfts SBOM plus Anchores 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`