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:
		
							
								
								
									
										94
									
								
								docs/modules/scanner/operations/entrypoint-problem.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										94
									
								
								docs/modules/scanner/operations/entrypoint-problem.md
									
									
									
									
									
										Normal file
									
								
							| @@ -0,0 +1,94 @@ | ||||
| # Entry-Point Detection — Problem & Architecture | ||||
|  | ||||
| ## 1) Why this exists | ||||
|  | ||||
| Container images rarely expose their *real* workload directly. Shell wrappers, init shims, supervisors, or language launchers often sit between the Dockerfile `ENTRYPOINT`/`CMD` values and the program you actually care about. Stella Ops needs a deterministic, explainable way to map any container image (or running container) to a single logical entry point that downstream systems can reason about. | ||||
|  | ||||
| We define the target artefact as the tuple below: | ||||
|  | ||||
| ```jsonc | ||||
| { | ||||
|   "type": "java|dotnet|go|python|node|ruby|php-fpm|c/c++|rust|nginx|supervisor|other", | ||||
|   "resolvedBinary": "/app/app.jar | /app/app.dll | /app/server | /usr/local/bin/node", | ||||
|   "args": ["..."], | ||||
|   "confidence": 0.00..1.00, | ||||
|   "evidence": [ | ||||
|     "why we believe this" | ||||
|   ], | ||||
|   "chain": [ | ||||
|     {"from": "/bin/sh -c", "to": "/entrypoint.sh", "why": "ENTRYPOINT shell-form"}, | ||||
|     {"from": "/entrypoint.sh", "to": "java -jar orders.jar", "why": "exec \"$@\" with java default"} | ||||
|   ] | ||||
| } | ||||
| ``` | ||||
|  | ||||
| Constraints: | ||||
|  | ||||
| - Static first: no `/proc`, no `ptrace`, no customer code execution when scanning images. | ||||
| - Honour Docker/OCI precedence (`ENTRYPOINT` vs `CMD`, shell- vs exec-form, Windows `Shell` overrides). | ||||
| - Work on distroless and multi-arch images as well as traditional distro bases. | ||||
| - Emit auditable evidence and reduction chains so policy decisions are explainable. | ||||
|  | ||||
| ## 2) Dual-mode architecture | ||||
|  | ||||
| The scanner exposes a single façade but routes to two reducers: | ||||
|  | ||||
| ``` | ||||
| Scanner.EntryTrace/ | ||||
|   Common/ | ||||
|     OciImageReader.cs | ||||
|     OverlayVfs.cs | ||||
|     Heuristics/ | ||||
|     Models/ | ||||
|   Dynamic/ProcReducer.cs   // running container | ||||
|   Static/ImageReducer.cs   // static image inference | ||||
| ``` | ||||
|  | ||||
| Selection logic: | ||||
|  | ||||
| ```csharp | ||||
| IEntryReducer reducer = container.IsRunning | ||||
|   ? new ProcReducer() | ||||
|   : new ImageReducer(); | ||||
| var result = reducer.TraceAndReduce(ct); | ||||
| ``` | ||||
|  | ||||
| Both reducers publish a harmonised `EntryTraceResult`, allowing downstream modules (Policy Engine, Vuln Explorer, Export Center) to consume the same shape regardless of data source. | ||||
|  | ||||
| ## 3) Pipeline overview | ||||
|  | ||||
| ### 3.1 Static images | ||||
|  | ||||
| 1. Pull or load OCI image. | ||||
| 2. Compose final argv (`ENTRYPOINT ++ CMD`), respecting shell overrides. | ||||
| 3. Overlay layers with whiteout support via a lazy virtual filesystem. | ||||
| 4. Resolve paths, shebangs, wrappers, and scripts until a terminal candidate emerges. | ||||
| 5. Classify runtime family, identify application artefact, score confidence, and emit evidence. | ||||
|  | ||||
| ### 3.2 Running containers | ||||
|  | ||||
| 1. Capture real exec / fork events and build an exec graph. | ||||
| 2. Locate steady-state processes (long-lived, owns listeners, not a shim). | ||||
| 3. Collapse wrappers using the same catalogue as static mode. | ||||
| 4. Cross-check with static heuristics to tighten confidence. | ||||
|  | ||||
| ### 3.3 Shared components | ||||
|  | ||||
| - **ShellFlow static analyser** handles script idioms (`set --`, `exec "$@"`, branch rewrites). | ||||
| - **Wrapper catalogue** recognises shells, init shims, supervisors, and package runners. | ||||
| - **Runtime detectors** plug in per language/framework (Java, .NET, Node, Python, PHP-FPM, Ruby, Go, Rust, Nginx, C/C++). | ||||
| - **Score calibrator** turns detector raw scores into a unified 0..1 confidence. | ||||
|  | ||||
| ## 4) Document map | ||||
|  | ||||
| The entry-point playbook is now split into focused guides: | ||||
|  | ||||
| | Document | Purpose | | ||||
| | --- | --- | | ||||
| | `entrypoint-static-analysis.md` | Overlay VFS, argv composition, wrapper reduction, scoring. | | ||||
| | `entrypoint-dynamic-analysis.md` | Observational Exec Graph for running containers. | | ||||
| | `entrypoint-shell-analysis.md` | ShellFlow static analyser and script idioms. | | ||||
| | `entrypoint-runtime-overview.md` | Detector contracts, helper utilities, calibration, integrations. | | ||||
| | `entrypoint-lang-*.md` | Runtime-specific heuristics (Java, .NET, Node, Python, PHP-FPM, Ruby, Go, Rust, C/C++, Nginx, Deno, Elixir/BEAM, Supervisor). | | ||||
|  | ||||
| Use this file as the landing page; each guide can be read independently when implementing or updating a specific component. | ||||
		Reference in New Issue
	
	Block a user