Files
git.stella-ops.org/docs/modules/scanner/operations/entrypoint-lang-deno.md
master 7b5bdcf4d3 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.
2025-10-30 00:09:39 +02:00

1.1 KiB

Entry-Point Runtime — Deno

Signals to gather

  • argv0 equals deno or path ends with /bin/deno.
  • Arguments include run, task, serve, or compile outputs.
  • 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 compile executables and the Deno runtime invoking a script.
  • Recognise deno task <name> by reading tasks from deno.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 compile emits a standalone binary, treat it as C/C++ unless metadata persists.