- 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.1 KiB
1.1 KiB
Entry-Point Runtime — Deno
Signals to gather
argv0equalsdenoor path ends with/bin/deno.- Arguments include
run,task,serve, orcompileoutputs. - Presence of
deno.json/deno.jsonc,import_map.json, or cached modules (/deno-dir). - Environment (
DENO_DIR,DENO_AUTH_TOKENS).
Implementation notes
- Resolve script URLs or local files; for remote sources record the URL as evidence.
- Distinguish between
deno compileexecutables and the Deno runtime invoking a script. - Recognise
deno task <name>by reading tasks fromdeno.json. - ShellFlow should already collapse Docker official entrypoint (
/usr/bin/env deno task start).
Evidence & scoring
- Boost for confirmed script/URL and config file presence.
- Add evidence for permissions flags (
--allow-net,--allow-env) to aid policy decisions. - Penalise when only the binary is present without scripts.
Edge cases
- Deno deploy shims or adapters may further wrap the runtime; rely on wrapper catalogue.
- When
deno compileemits a standalone binary, treat it as C/C++ unless metadata persists.