I explicitly raise that point in the post. Hardening one aspect of something does not preclude you from hardening others. Also: if I was trying to somehow draw attention away from that fact, I probably wouldn't write a blog post that mentions it 2 weeks later.

I mean, of course it does. Most people run their development environments as their own user, and most package management systems have post-install script support.

Installing random software from the internet is problematic.

I'd be interested in running my dev environment with a dedicated user account -with no access to the main account's personal files, credentials, etc-, do you know of any guides for doing so?

(I could just give it a shot, but I reckon there will be gotchas)

What I do is use a VM as my development environment, managed by Vagrant. Any dependencies stay on the VM image.

What platform? GUI or shell?

Docker/LXD or a dev VM lets you access both simultaneously. Or create a separate user, but not as secure or convenient.

macOS. Not much interested in VMs, for efficiency.

Yeah I was playing with a separate user account, could get some basics working but I wonder how far could I get with that.

What are the bigger security risks for that approach? Assuming constrained file permissions, and that no secrets are in ENV (https://gist.github.com/telent/9742059 )

A normal user has full access to the kernel API. Always kernel info leaks, occasional easy exploits.

On macos you can use Apple's native sandboxing. See for example http://mybyways.com/blog/creating-a-macos-sandbox-to-run-kod...

Yes, that's what this was. An elaborate attempt to shield npm from scrutiny. We know where our bread is buttered.

Is that not true of most dependency manager + build systems? To focus on maven as an example, maybe it doesn't have a post-install hook for dependencies it downloads, but any build or test dependencies downloaded while building a project are going to be immediately executed unsandboxed.

At least npm has the package-lock.json feature that lets you lock down the entire dependency graph. If the package-lock.json was created with a safe set of dependencies, then any dependencies compromised in the future won't affect you (because already released versions can't be modified). Maven and gradle both seem to entirely lack a comparable feature as far as I know; if they do have that functionality as an obscure feature or plugin, then I still criticize them for not making it more prominent. (Npm generates and uses package-lock.json by default!)

Technically, other systems are vulnerable to the same. In practice, there's something about the node/js ecosystem that encourages the proliferation of dependencies, increasing the attack surface.