Add OpenSslLegacyShim to ensure OpenSSL 1.1 libraries are accessible on Linux
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
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.
This commit is contained in:
32
docs/benchmarks/scanner/deep-dives/java.md
Normal file
32
docs/benchmarks/scanner/deep-dives/java.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 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`
|
||||
Reference in New Issue
Block a user