The runtime signals that give a malicious install away

Installing a package should be unremarkable: resolve a version, download it, maybe compile something. A poisoned install does extra things — and those extra things are observable, even when the code that triggers them is hidden. Here are the behaviors that separate the two.

Signals worth watching

• Unexpected process spawns. A formatting or logging library has no business launching a shell or a second runtime while it installs.
• Outbound connections to unfamiliar hosts. A package reaching a server it has no reason to contact — especially mid-install — is one of the loudest signals there is.
• Reading secrets. Touching ~/.npmrc, .env, SSH keys, cloud or CI tokens, wallet files: legitimate installers rarely need them; credential stealers always do.
• Writing to sensitive paths. Edits to startup files, shell profiles or lifecycle hooks are classic persistence moves.
• Second-stage downloads. The install fetches and runs more code — the first stage was just a loader.
• Self-cleaning. Erasing logs and artifacts to defeat later forensics; if you only look afterward, there's often nothing left to find.

Why “what it looks like” isn't enough

Attackers have gotten good at hiding the code: obfuscation, dynamically constructed payloads, even invisible Unicode characters that slip malicious logic past human review and source-level tooling. The code can hide. The behavior can't — a connection is a connection, a secret read is a secret read.

You can disguise what a package looks like. It's much harder to disguise what it does.

depgaze is built on that asymmetry: it watches how a package actually behaves, turns it into a plain-language verdict and a concrete fix, and does it before anything lands on your machine. How it watches is our edge — the signals above are what it's looking for.