NodeShield: Runtime Protection for Node.js

• NodeShield is a runtime protection mechanism for Node.js that uses SBOMs and CBOM to define and enforce dependency and capability hierarchies.
• It employs code outlining and vm-based isolation to enforce security policies at module granularity without modifying the original application code.
• Empirical evaluations show NodeShield prevents up to 98.51% of supply-chain attacks while maintaining compatibility and minimal performance overhead.

NodeShield is a runtime protection mechanism for Node.js that enforces an application's dependency hierarchy and controls access to system resources through security-enhanced software bills of materials. It treats the SBOM as the source of truth for the dependency hierarchy and extends it with a Capability Bill of Materials, or CBOM, that records the required capabilities of each component. Enforcement is performed at module granularity via code outlining and vm-based isolation, without modifying the original application code or the Node.js runtime. Within the paper’s scope, NodeShield addresses software supply-chain attacks in Node.js applications, especially attacks in which packages introduce undeclared dependencies, invoke privileged APIs, or modify other packages at runtime (Cornelissen et al., 19 Aug 2025).

1. Security scope and threat model

NodeShield targets software supply-chain attacks in the Node.js ecosystem. The motivating premise is that Node.js applications commonly depend on many packages and large transitive dependency trees, while third-party packages often execute with the same privileges as the host application. In that setting, a malicious update or compromised package can introduce undeclared dependencies at runtime, abuse privileged Node.js APIs, modify other packages, exfiltrate data, or establish persistence (Cornelissen et al., 19 Aug 2025).

The paper illustrates this threat model with the rate-map example. A malicious update covertly loads an undeclared package, dl-tar, and uses fs to patch it. The attack is therefore detectable through either an unexpected dependency import or new privileged API use. This duality is central to NodeShield’s design: dependency transparency and least-privilege enforcement are treated as complementary runtime invariants rather than separate controls (Cornelissen et al., 19 Aug 2025).

The system’s stated design goals are compatibility with vanilla Node.js programs, automation, minimal overhead, policy conciseness, robustness against bypasses and sandbox breakout, support for both CommonJS and ESModules, and operation without modifications to the original application code or the Node.js runtime. This places NodeShield in the class of deployable runtime confinement mechanisms rather than language redesigns or custom runtimes (Cornelissen et al., 19 Aug 2025).

A common misconception is that NodeShield is merely an SBOM checker. The paper describes a stronger mechanism: the SBOM is used operationally at runtime to define what each module may import, while the CBOM defines which privileged resources that module may access. This suggests that NodeShield is intended not only to expose risky dependencies for review, but also to block behavior that diverges from declared structure or declared privilege requirements.

2. SBOM hierarchy and the CBOM capability model

NodeShield uses the SBOM as the authoritative record of the application’s dependency graph. The paper emphasizes that this hierarchy matters: a module may import its own files, packages explicitly listed in its SBOM dependency tree, unprivileged built-in modules, and privileged built-ins only when permitted by capability policy. This prevents a package from stealthily importing undeclared dependencies, including cases obscured by runtime tricks or obfuscation (Cornelissen et al., 19 Aug 2025).

The CBOM extends the SBOM with a package-granular capability inventory. A capability is defined as a group of related privileged operations. The purpose of this grouping is policy conciseness: instead of enumerating each API individually, the CBOM records a small set of capability labels that summarize privileged behavior (Cornelissen et al., 19 Aug 2025).

Capability	Representative surfaces
addon	native .node addons
code	eval, Function, node:vm
command	node:child_process, node:worker_threads, spawn, spawn_sync
crypto	node:crypto, Crypto, SubtleCrypto, crypto, CryptoKey
file-system	node:fs, node:fs/promises
network	node:net, node:http, node:https, node:dns, node:tls, fetch
system	node:os, node:process, global process

The paper distinguishes an enforced view from a presented view. The enforced view is the least-privilege runtime policy for each module. The presented view is a review-oriented view that may include transitive dependencies’ needs, with the stated purpose of reducing confused-deputy issues during human review. This distinction is significant because it separates runtime confinement from human-facing policy comprehension (Cornelissen et al., 19 Aug 2025).

The seven capabilities also delimit NodeShield’s notion of privileged behavior. File access, network access, subprocess creation, dynamic code evaluation, cryptographic operations, native addon loading, and system or environment access are treated as the main privilege groups relevant to supply-chain malware in Node.js. A plausible implication is that NodeShield’s expressiveness depends less on API-level completeness than on whether these seven categories adequately capture the privileged actions that matter operationally.

3. Runtime enforcement by code outlining

NodeShield enforces policy through code outlining rather than inlining. The original code is not rewritten in place, and the Node.js runtime is not modified. Instead, NodeShield clones the project and evaluates each JavaScript file inside a controlled vm context. The paper contrasts this with inlining, which would insert checks directly into source code; outlining wraps the original code in enforcement scaffolding and evaluates it from the outside in a managed environment (Cornelissen et al., 19 Aug 2025).

The workflow described in the paper is: clone the project, build a module-granular policy from SBOM and CBOM, transform each JavaScript file using outlining, and execute the transformed program under vanilla Node.js. The clone includes JavaScript source files, JSON files, and native extensions, while other files are handled via working directory adjustments and path rewrites in Node.js APIs (Cornelissen et al., 19 Aug 2025).

NodeShield builds three core policy objects:

• I = [...Ia, ...Ib, ...Ic, ...Id], the import allowlist
• B = [...Ba, ...Bb], the binding allowlist
• G = {...Ga, ...Gb}, the global namespace for the guest context

The paper further specifies their contents. Ia covers files in the module, Ib packages according to the SBOM, Ic allowed-by-default built-ins, and Id privileged built-ins according to the CBOM. Ba contains non-privileged bindings and Bb privileged bindings according to the CBOM. Ga contains non-privileged globals and Gb privileged globals according to the CBOM. The enforcement pseudocode checks require(s) against I, mediates process.binding through B, and constructs a vm context from G (Cornelissen et al., 19 Aug 2025).

The same framework handles CommonJS and ESModules. The implementation intercepts require, ES module import syntax, and dynamic import(). It also provides CommonJS-specific handling for exports, module, require, __dirname, and __filename, while native ES module syntax is handled via vm.Link and dynamic import hooks (Cornelissen et al., 19 Aug 2025).

The paper describes several hardening techniques against bypasses: primordials, null prototypes, object freezing, and lexical scoping. Sensitive globals are captured and removed from globalThis, then rebound as local variables; some globals are made one-time-accessible through getters that delete themselves; and per-module vm contexts are used to prevent privilege escalation through cross-context eval. These details indicate that NodeShield is not merely a resource filter but a confinement mechanism that attempts to preserve policy integrity under hostile JavaScript metaprogramming (Cornelissen et al., 19 Aug 2025).

4. Policy semantics, capability inference, and enforcement modes

The effective semantics of the policy model are module-centric. A module may import files in its own package, packages listed in the SBOM, unprivileged built-ins, and privileged built-ins only when the relevant capability is granted. It may access only those globals and bindings granted through the CBOM. The paper therefore frames NodeShield as enforcing both dependency integrity and capability integrity at runtime (Cornelissen et al., 19 Aug 2025).

NodeShield supports three enforcement modes: log, throw, and exit. In log mode, violations are reported and execution continues. In throw mode, a violation raises an error. In exit mode, the system terminates immediately on the first violation. This tiering provides an operational progression from observation to strict enforcement (Cornelissen et al., 19 Aug 2025).

When no CBOM is provided, NodeShield can infer one either statically or dynamically. Static inference scans source for imports and constructs such as eval, process, and fetch; the paper characterizes it as conservative and imprecise. Dynamic inference runs with an incomplete CBOM and inspects violations; it is described as more precise but potentially risky. The paper notes a specific limitation: the code capability cannot be inferred in log mode because vm code-generation behavior is involved, so exit mode may be required (Cornelissen et al., 19 Aug 2025).

The assumptions section further delimits the policy model. NodeShield assumes that JavaScript eval accesses only current lexical scope; that the only module-loading mechanisms are require, import syntax, and import(); that vm correctly traps imports and prevents code generation when configured; and that vm provides a fresh context without implicit access to host scope. These assumptions are operationally important because the system’s security argument is tied to Node.js vm semantics rather than to language-level proof obligations (Cornelissen et al., 19 Aug 2025).

A common misunderstanding is that capability review is fully automated. The paper is explicit that human review is still required, especially for new dependencies or suspicious capability additions. This suggests that NodeShield reduces policy authoring burden and constrains runtime behavior, but does not eliminate governance or change review.

5. Empirical evaluation

The evaluation uses an AMD Ryzen 7 3700X machine with 32 GB RAM, with SBOMs generated using npm sbom. Where applicable, NodeShield is compared against ndg (Npm Dependency Guardian) (Cornelissen et al., 19 Aug 2025).

For malware prevention, the paper reports a benchmark of 67 evaluated supply-chain attacks. NodeShield prevented 98.51% (66/67) of these attacks. The comparison point reported for ndg is 83.58% (56/67), with compatibility issues on some cases. The paper further notes that SBOM enforcement alone is often insufficient and that CBOM adds substantial protection. The main exception reported is node-ipc, which was not prevented because the benign version already used the same capabilities as the malicious one (Cornelissen et al., 19 Aug 2025).

For attack-surface reduction against code-injection exploits, the paper evaluates 24 relevant SecBench.js proof-of-concept cases and reports that NodeShield detected or prevented 87.50% (21/24). The interpretation offered is that capability enforcement reduces the usable attack surface of vulnerable packages, even when the underlying software defect remains present (Cornelissen et al., 19 Aug 2025).

For sandbox-breakout robustness, the benchmark consists of 27 snippets from SandDriller / related sandbox-breakout literature, with the caveat that some entries reflect prototype pollution only, which is outside the threat model. The reported result is that NodeShield blocked all but prototype-pollution-only cases; by contrast, ndg allowed 11/29 breakouts to succeed. The mismatch between the counts of 27 snippets and 2/29 prototype-pollution-only cases is present in the data as reported. The defensible claim is therefore that the paper presents NodeShield as substantially more robust than ndg on the breakout benchmark (Cornelissen et al., 19 Aug 2025).

For maintenance effort, the paper evaluates 143 CBOMs generated across experiments. It reports an average CBOM size of 78 dependencies and 64 capabilities total, corresponding to about 0.82 capabilities per dependency. In an analysis of 6 real Node.js server projects over the 1,000 most recent commits, the review burden for updated dependencies was less than 1 capability per dependency-changing commit on average. This is aligned with the abstract’s claim of a concise policy language consisting of at most 7 entries per dependency, since the capability vocabulary contains seven labels (Cornelissen et al., 19 Aug 2025).

For performance on long-lived server applications, the paper reports response overhead of less than 1 ms, specifically about 0.31%–1.99%; throughput reduction of up to 360 requests/sec, around 0%–11.84%; and memory overhead of 42.50%–250.74%. The interpretation given is that runtime overhead is low, while memory overhead varies more because vm contexts scale with dependency count. For short-lived CLI applications, startup or runtime overhead can be noticeable, sometimes up to 4× in one setup, while in a baseline-aligned setup it is usually much smaller (Cornelissen et al., 19 Aug 2025).

Compatibility is evaluated on 86 real-world packages and applications, of which 3 were incompatible, yielding a compatibility rate of 96.51%. The reported causes of incompatibility include undocumented API use through module._compile, instanceof Array across vm contexts, and other uncommon patterns. The false positive evaluation on 24 benign applications yields 387 true negatives and 18 false positives, corresponding to a false positive rate of 4.65% (Cornelissen et al., 19 Aug 2025).

6. Limitations, assumptions, and relation to adjacent Node.js defenses

The paper identifies several limitations. Language support is partial: instanceof can behave unexpectedly across vm contexts, some globally exposed objects cannot be overridden in the usual way, and undocumented Node.js APIs may break compatibility. Capability mapping is not formally complete; the implementation covers documented APIs and some undocumented ones, but the paper does not claim completeness. Capability overlap also remains: some categories, particularly addon and command, are broad and may overlap, and some dependency behavior may be surprising in review (Cornelissen et al., 19 Aug 2025).

Another limitation is dependency on SBOM quality. Missing components or missing hierarchy reduce enforcement effectiveness, and errors may cause false denials rather than silent security failures. This suggests that NodeShield inherits some of the epistemic limitations of software composition analysis: the runtime can only enforce what the bill of materials represents (Cornelissen et al., 19 Aug 2025).

The paper also situates NodeShield relative to prior static and dynamic work, including sandboxing, permission systems, and taint tracking. Within the Node.js literature represented in the data, HODOR offers a useful contrast. HODOR is a runtime protection system that constrains Node.js applications at the system-call layer through seccomp, using cross-language call-graph construction to derive main-thread and thread-pool syscall whitelists. It reduces the syscall attack surface to 19.42% on average with under 3% runtime overhead and primarily addresses post-exploitation abuse following arbitrary code execution or arbitrary command execution (Wang et al., 2023).

The distinction between the two systems is architectural. HODOR shrinks attack surface at the Linux syscall boundary, whereas NodeShield enforces dependency hierarchy and package-level capability constraints inside the Node.js execution environment. HODOR’s unit of control is the process and its threads; NodeShield’s unit of control is the module and its declared dependency context. This suggests that the two approaches are complementary rather than competing: one addresses least privilege in terms of syscalls, the other in terms of package imports, built-ins, globals, and bindings (Wang et al., 2023).

The paper finally suggests that NodeShield and CBOM ideas could extend to other JavaScript runtimes, browsers, and possibly other languages, while acknowledging that the present implementation is tailored to Node.js, its module systems, and its vm semantics (Cornelissen et al., 19 Aug 2025).