[APPS-2792] Add: runtime network/subprocess guard for local execution

[tyffical]

Motivation

• Part of APPS-2792 — local Node execution for App Builder backend functions. Runtime half of Milestone 5 (sandboxing) in the Kickoff doc, stacked on Milestone 1 ([APPS-2792] Add: harden the in-process local execution path #480) since that's where local-execution.ts lives.
• [APPS-2792] Add: reject Node built-in imports in backend files #476 already rejects Node-builtin imports and bare fetch/XMLHttpRequest/WebSocket/EventSource references — but only in the customer's own .backend.ts file. A third-party dependency (e.g. a Postgres or Redis client) that itself calls net/http/fetch internally is invisible to that static scan, since it never inspects node_modules.
• Local execution runs in-process (no Deno, no forked child — see [APPS-2792] Add: in-process local execution for backend functions #479's design), so unlike production there's no OS-level boundary to fall back on for that gap. Confirmed directly in wf-actions-worker's deno.ts: production's Deno sandbox never grants --allow-net, under any code path — this PR closes the equivalent gap at the module level for local execution.

Architecture

net.Socket.prototype.connect, globalThis.fetch, and child_process's spawn/exec/execSync are real, process-wide singletons — network-guard.ts monkey-patches them directly rather than sandboxing the customer's module, since there's no process boundary to sandbox with. That makes the guard a single shared piece of mutable state (allowDepth + the saved originals) threaded through one execution's lifetime:

runScriptLocally
      │
      ▼
┌───────────────────────────────┐
│ runBlocked(fn)                │  applyPatches()
│ BLOCKED: net.Socket.connect,  │  → net.Socket.connect   throws
│ fetch, child_process all      │  → fetch                rejects
│ throw/reject                  │  → spawn/exec/execSync  throw
└───────────────┬────────────────┘
                │  customer's fn() runs
                ▼
  fn() calls $.Actions.a() and $.Actions.b() concurrently (Promise.all)
                │
      ┌─────────┴──────────┐
      ▼                    ▼
 runAllowed(a)         runAllowed(b)
 allowDepth 0→1        allowDepth 1→2
 restorePatches()      (already restored — no-op)
      │                    │
      ▼                    ▼
┌────────────────────────────────────┐
│ ALLOWED (allowDepth > 0)           │
│ real net/fetch/spawn restored —    │
│ only inside executeAction          │
└──────┬───────────────────────┬─────┘
       │ b resolves first      │ a still in flight
       ▼                       │
 allowDepth 2→1                │
 (still > 0 → stays ALLOWED) ──┘
       │
       │ a resolves
       ▼
 allowDepth 1→0 → applyPatches() → BLOCKED again
       │
       │  fn() returns
       ▼
 runBlocked's finally: restorePatches()
       │
       ▼
   UNBLOCKED (real functions, for whatever
   the dev server does next)

The ref-count (allowDepth), not a boolean, is what makes the overlap safe: two concurrent $.Actions calls each bump it on entry and drop it on exit, and the guard only re-blocks once the last one exits — a boolean would re-block the instant the faster of two overlapping calls finished, breaking the slower one mid-flight.

runBlocked/runAllowed's own try/finally only unwinds when fn actually settles. runScriptLocally's timeout wraps the whole thing in Promise.race([run(), timeout]), which abandons rather than cancels the loser — a customer function that never resolves means run() (and the runBlocked inside it) never reaches its finally, so without a separate backstop the block would stay applied for the rest of the process once the timeout fires. forceReset() is that backstop: called directly from the timer callback (unconditionally restoring the real functions and zeroing allowDepth) the moment the timeout fires, independently of whether the abandoned run() ever settles. The same function is used as a Jest afterEach in network-guard.test.ts/local-execution.test.ts, for the identical reason at the test level — these are real Node singletons, not per-test-file sandboxed state, so a test that leaves them patched leaks into every test that runs after it in the same Jest worker, including unrelated test files.

Changes

What changed	File
New runBlocked(fn): monkey-patches net.Socket.prototype.connect, fetch, and child_process's spawn/exec/execSync to throw/reject for the duration of fn, restoring the real implementations in a finally regardless of how fn completes.	network-guard.ts
New runAllowed(fn): temporarily restores real network access for the duration of fn, ref-counted (not a boolean) so two $.Actions calls overlapping within a single execution (e.g. inside a Promise.all) don't re-block network on each other mid-flight.	network-guard.ts
New forceReset(): unconditionally restores the real functions and zeroes allowDepth, independent of runBlocked/runAllowed's own finally — the backstop for a fn that's abandoned (timeout) or a test that fails to clean up after itself.	network-guard.ts
runScriptLocally now wraps the customer's function call (only — not the loadModule/registration calls before it, which need no network) in runBlocked, and calls forceReset() from the timeout timer itself so an abandoned, still-running hung function can't leave network/subprocess access blocked for the rest of the process.	local-execution.ts
makeActionsProxy's apply trap now wraps its executeAction call in runAllowed — the one sanctioned network path, exempted from the block.	local-execution.ts
Unit tests for every patched target and both directions (block + restore, restore-on-throw, no state leak across separate runBlocked calls, nested runAllowed exemption, concurrent-overlap ref-counting, re-block-on-throw). A Jest afterEach calls forceReset() unconditionally as a hard safety net, independent of any test's own cleanup.	network-guard.test.ts
Integration tests confirming the guard is actually wired into executeScriptLocally: a customer function using raw net/fetch/child_process is rejected; a real $.Actions call still succeeds; network is restored after the execution finishes, including after a timeout abandons a hung function; two real $.Actions calls made concurrently via Promise.all keep network allowed through the entire overlap, exercised through the real executeScriptLocally → makeActionsProxy path (not just the unit-level runAllowed). Same afterEach safety net as above.	local-execution.test.ts

QA Instructions

yarn install

yarn test:unit packages/plugins/apps/src/vite/network-guard.test.ts
# Expected: Test Suites: 1 passed / Tests: 11 passed ✅ VERIFIED

yarn test:unit packages/plugins/apps/src/vite/local-execution.test.ts
# Expected: Test Suites: 1 passed / Tests: 27 passed ✅ VERIFIED

yarn test:unit
# Full monorepo suite, including the previously-flaky rollupConfig.test.ts —
# run --runInBand to force worst-case single-worker scheduling (this is how
# the leak this PR fixes was reproduced).
# Expected: Test Suites: 82 passed / Tests: 1923 passed, 1 skipped ✅ VERIFIED

yarn workspace @dd/apps-plugin run typecheck
# Expected: no output, clean exit ✅ VERIFIED

npx eslint packages/plugins/apps/src/vite/network-guard.ts packages/plugins/apps/src/vite/network-guard.test.ts packages/plugins/apps/src/vite/local-execution.ts packages/plugins/apps/src/vite/local-execution.test.ts --quiet
# Expected: no output, clean exit ✅ VERIFIED

Coverage note: this repo's Jest collectCoverageFrom CLI flag didn't produce a usable per-file report for either new/changed file in this environment (pre-existing tooling quirk, not introduced by this change — the coverage table only ever listed _jest helper files regardless of the glob passed). Manually verified every branch in network-guard.ts is exercised by at least one test.

No manual local/staging QA beyond the automated tests above: this module still isn't reachable from a real npm run dev session (that's #481, already merged into this stack's ancestry but not yet released).

Blast Radius

• No behavior change for any currently-shipping code path — same as [APPS-2792] Add: in-process local execution for backend functions #479/[APPS-2792] Add: harden the in-process local execution path #480, this stack isn't released yet.
• Scoped precisely to the duration of a local execution's customer-function call; the dev server's own network use (before/after that window, and anything unrelated to local-execution.ts) is never touched.
• forceReset() on timeout narrows, rather than eliminates, an existing gap: the abandoned (not cancelled) hung function keeps running with real network access restored early rather than staying blocked forever — bounded to that one already-abandoned execution, versus the alternative of leaving every future execution in the same dev server process permanently blocked until restart.
• Risk: low. Additive, defense-in-depth only — closes a gap that only matters for local-dev-loop safety/prod-parity, not a new production security boundary (production's own Deno sandbox is unaffected and remains the real boundary).

Out of Scope / Follow-ups

Item	Status	Next step
Native addon bypassing Node's JS-level net stack entirely	Accepted residual gap	Narrower and rarer than the pure-JS case this closes (most native modules are for CPU-bound work, not networking) — not worth the false-positive risk of blocking native addon loading outright
dns.lookup interception	Out of scope	Low realistic benefit for this threat model (dev-loop safety, not defending against deliberate DNS-tunneling exfiltration) — would risk breaking legitimate hostname validation for no real gain
A hung customer function is abandoned, not cancelled, on timeout — it keeps running in the background with real network access restored (see Blast Radius)	Accepted residual gap	Would need real cancellation (e.g. an AbortSignal threaded through the customer's own function, which we don't control) or re-architecting local execution onto a worker thread that can be killed outright — bigger change than this PR's scope

Documentation

• RFC: Confluence page 7012712651 — Security section
• Kickoff doc: Confluence page 7025394455 — Milestone 5

[datadog-prod-us1-6]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 7d6f536 | Docs | Datadog PR Page | Give us feedback!}