4 posts tagged “sandbox”.
@jagreehal/sandbox-node runs your npm install in a throwaway container that can see your project and the registry, and nothing else.
Install scripts still run. node-gyp still builds. Your SSH keys, npm token, cloud credentials, and .env are not in the box, so a malicious dependency has nothing to steal and nowhere to send it.
Get the sandbox command, run one setup step, and put sandbox in front of the commands you already run.
New to Node, or not sure why npm install is risky in the first place? Start with why install-time code is a trust decision, then what running it in a throwaway container buys you. Otherwise, read on.
The most-recommended npm defence right now is a cooldown: refuse to install any version published more recently than a few days ago. pnpm shipped it as minimumReleaseAge, Aikido Safe Chain turns it on by default, and after the recent Shai-Hulud-style npm worms, it became the advice everyone repeats.
It is good advice. It closes the window these worms detonate in. But "set a cooldown" is being sold as if it were the whole answer, and it is not. A cooldown knows one thing about a package: how old it is. There are at least three reasons it is not enough on its own, and for those, age is the wrong question to ask.
Read More →You run npm install without thinking. It looks like a download step. It is a trust decision.
Every package that resolves into your tree can run code the moment it installs, with the same access you have: your SSH keys, the npm token in ~/.npmrc, your cloud credentials, your .env. Not the package you typed. Any of the hundreds underneath it. You approved none of them by name, and the package manager never asked.
The fix is not to read more or trust less. It is to run that install somewhere your secrets are not.
Read More →