- 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.
		
			
				
	
	
	
		
			1.3 KiB
		
	
	
	
	
	
	
	
			
		
		
	
	
			1.3 KiB
		
	
	
	
	
	
	
	
Entry-Point Runtime — Go
Signals to gather
- Statically linked ELF with .note.go.buildid.
- .gopclntabsection (function name table) or- Go build IDstrings.
- Minimal dynamic dependencies (often none) and musl/glibc loader differences.
- GODEBUG,- GOMAXPROCS,- GOENVenvironment variables.
- Go module artefacts: go.mod,go.sum.
Implementation notes
- Use ELF parsing to locate .note.go.buildid; fallback to scanning the first few MB forGo build ID.
- Distinguish from Rust/C by checking .dynsymcount, presence of Go-specific section names, and the absence ofGLIBCXX.
- For distroless images, rely solely on ELF traits since no package metadata is present.
- Record binary path and module files as evidence.
Evidence & scoring
- Strong boost for .note.go.buildidor.gopclntab.
- Add evidence for module files or env variables.
- Penalise binaries with high numbers of shared libraries (likely C/C++).
Edge cases
- TinyGo or stripped binaries may lack build IDs—fall back to heuristics (symbol patterns, text section).
- CGO-enabled binaries include glibc dependencies; still treat as Go but mention CGO in evidence if detected.
- Supervisors wrapping Go services (e.g., envoy) should be handled upstream by wrapper detection.