Glass Cage 2.0

Threat model: code you installed can still cross a boundary

A host application legitimately needs secrets, files, and network access. Its third-party packages do not necessarily need the same privileges. A compromised dependency can execute inside that trusted process and attempt to read configuration or contact an unauthorized destination.

Glass Cage 2.0 is my runtime supply-chain security project for Node.js and Python. I built and deployed a dependency firewall combining asynchronous package attribution, per-package access policies, Linux seccomp/eBPF mechanisms, and a React/Three.js investigation dashboard.

The difficult part is attribution

A process ID tells you which application acted. It does not identify which dependency caused the action. Package-level policy needs a more precise answer, especially when work continues through asynchronous callbacks.

The attribution layer connects runtime activity to package context. Stack-trace inspection supports investigation of the initiating code. This is a different responsibility from the operating-system boundary: observing a syscall and explaining its package origin are related, but distinct, problems.

Observation, policy, and enforcement have different jobs

Observation exposes sensitive-file and network activity. Policy describes which resources a package may access. Enforcement restricts actions at the implemented boundary. Investigation helps a human understand why an action was flagged or restricted.

The project combines Linux seccomp/eBPF with application-level attribution. These technologies are not interchangeable: seccomp filters system calls, while eBPF capabilities depend on the hooks and program types used. Neither automatically understands an npm package identity. Ordinary seccomp filters also cannot dereference a pathname pointer to make a complete file-path decision on their own.

That distinction matters when explaining the design: a package-aware file rule requires context beyond a syscall number. The map above separates responsibilities instead of implying a single kernel feature solves the entire problem. See the Linux kernel seccomp documentation for the underlying mechanism and its limits.

Signals should support a decision, not replace it

Canary honeytokens make unexpected access to decoy resources visible. DNS-entropy alerts identify unusually random-looking domain names for review. These signals complement per-package access policies; they are not equivalent to a confirmed compromise.

High-entropy names can occur in legitimate systems. GeoIP provides approximate destination context, not evidence that a connection is malicious. The dashboard combines connection visibility, stack-trace inspection, and approval controls so an operator can investigate the behavior behind a signal.

What I owned

My implementation spans the Node.js/Python runtime security system, package attribution and access policies, honeytoken and DNS signals, and the React/Three.js dashboard. The dashboard is an inspection surface for the security work; the central engineering contribution is connecting runtime behavior to an attributable, reviewable access decision.

Boundaries and what to verify

Coverage depends on the instrumented execution paths, Linux mechanisms, and policy configuration. Native code, subprocesses, asynchronous context loss, and missing attribution are important boundary cases to examine before treating a deployment as a complete sandbox.

An evaluation should inspect both allowed and denied actions: a legitimate dependency must keep working, an unauthorized access must be restricted at the intended boundary, and an operator should be able to explain the decision from the evidence. Missing package attribution needs an explicit handling policy rather than a guessed identity.

No latency benchmark, detection-rate percentage, or exhaustive coverage result is claimed here. The walkthrough is illustrative; it does not execute untrusted packages in your browser.