Entry-Point Runtime — Deno

Heuristics the Stella Ops scanner uses to classify a container entry point as a Deno runtime invocation, plus the evidence it attaches and the edge cases it guards against. For the shared detector contracts, scoring, and calibration, see the Runtime Detector Overview.

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 the wrapper catalogue.
• When deno compile emits a standalone binary, treat it as C / C++ unless metadata persists.

Related

• Runtime Detector Overview — shared contracts, scoring, calibration.
• Entry-Point Runtime — Node.js — the closest sibling runtime.
• Entry-Point Runtime — C / C++ — fallback for deno compile standalone binaries.