feat(docs): Add comprehensive documentation for Vexer, Vulnerability Explorer, and Zastava modules
- Introduced AGENTS.md, README.md, TASKS.md, and implementation_plan.md for Vexer, detailing mission, responsibilities, key components, and operational notes. - Established similar documentation structure for Vulnerability Explorer and Zastava modules, including their respective workflows, integrations, and observability notes. - Created risk scoring profiles documentation outlining the core workflow, factor model, governance, and deliverables. - Ensured all modules adhere to the Aggregation-Only Contract and maintain determinism and provenance in outputs.
This commit is contained in:
		
							
								
								
									
										29
									
								
								docs/modules/scanner/operations/entrypoint-lang-java.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										29
									
								
								docs/modules/scanner/operations/entrypoint-lang-java.md
									
									
									
									
									
										Normal file
									
								
							| @@ -0,0 +1,29 @@ | ||||
| # Entry-Point Runtime — Java | ||||
|  | ||||
| ## Signals to gather | ||||
| - `argv0` equals `java` / `javaw` or resides under `*/bin/java`. | ||||
| - `-jar <app.jar>` argument with the jar present in the VFS. | ||||
| - Manifest metadata (`META-INF/MANIFEST.MF`) containing `Main-Class` or `Start-Class`. | ||||
| - Spring Boot layout (`BOOT-INF/**`). | ||||
| - Classpath form (`-cp/-classpath`) followed by a main class token. | ||||
| - Presence of an embedded JRE (`lib/modules`, `jre/bin/java`). | ||||
| - `JAVA_OPTS`, `JAVA_TOOL_OPTIONS`, or `JAVA_HOME` environment hints. | ||||
| - `EXPOSE` ports often associated with Java servers (`8080`, `8443`). | ||||
|  | ||||
| ## Implementation notes | ||||
| - Expand env variables before resolving jar/class paths (supports `${VAR}`, `${VAR:-default}`). | ||||
| - For classpath mode, open a subset of jars to corroborate `Main-Class`. | ||||
| - Track when the app is started through shell wrappers (`exec java -jar "$APP_JAR"`); ShellFlow should already collapse these. | ||||
| - Distinguish between installers (e.g., `java -version`) and actual app launches by checking for jar/class arguments. | ||||
| - When multiple jars/classes are possible, prefer manifest-backed artefacts but record alternates in evidence. | ||||
|  | ||||
| ## Evidence & scoring | ||||
| - Reward concrete artefacts (jar exists, manifest resolved). | ||||
| - Add evidence entries for each heuristic (`"MANIFEST Main-Class=com.example.Main"`, `"Spring Boot BOOT-INF detected"`). | ||||
| - Penalise missing artefacts or ambiguous classpaths. | ||||
| - Surface runtime-specific env/ports as supplementary clues, but keep their weight low to avoid false positives. | ||||
|  | ||||
| ## Edge cases | ||||
| - Launcher scripts that eventually run `java` — ensure ShellFlow surfaces the final command. | ||||
| - Multi-module fat jars: only expose the main entry jar in evidence; keep supporting jars as context. | ||||
| - Native image (`native-image` / GraalVM) should fall through to Go/Rust/C++ detectors when `java` binary is absent. | ||||
		Reference in New Issue
	
	Block a user