Hacker News Reader

Comment by llmslave2 | Hacker News Reader

If one relies on the JS ecosystem to put food on the table and can't realistically make changes at their job to mitigate this, short of developing on a second airgapped work-only computer what can developers do to at least partially mitigate the risk? I've heard others mention doing all development in docker containers. Perhaps using a Linux VM?

View on HN

I was responsible for dev-ops, ci, workstation security at my previous position.

Containerize all of your dev environments and lock dependency files to only resolve to a specific version of a dependency that is known safe.

Never do global installs directly, ideally don't even install node outside of a container.

Lag dependency updates by a couple weeks, and enable automated security scans like dependabot on GH. Do not allow automated updates, and verify every dependency prior to updating.

If you work on anything remotely sensitive, especially crypto adjacent, expect to be a target and use a dedicated workstation that you wipe regularly.

Sounds tedious, but thats the job.

Alternatively you could find a job outside the JS ecosystem, you'll likely get a pay bump too.

> Alternatively you could find a job outside the JS ecosystem

In this economy? I'll take any job lol.

I think I'm gonna skip the containers and go straight for a VPS. And keep everything completely sandboxed. My editor's can work via SSH anyways.

That will work.

Containers are convenient because they work locally and you are likely using a containerized solution to deploy to production anyways.

But none of those would have helped in this case, where each dev/user intentionally installed the package specifically so it could retrieve data from the WhatsApp API.

What would have helped is if the dev/user had the ability for the dev/user to confirm before the code connected to a new domain or IP - api.WhatsApp.com? Approve. JoesServer.com or a random IP? Block. Such functionality could be at the OS or Docker level, etc.

I run incus os, which is an operating system that is made for spinning up containers and VMs. Whenever I have to work on a JS project I launch a new container for development and then ssh into it from my laptop. You can also run incus on your computer without installing it as an operating system.

Containers still have some risk since they share the host kernel, but they're a pretty good choice for protection against the types of attacks we see in the JS ecosystem. I'll switch to VM's when we start seeing container escape exploits being published as npm packages :)

When I first started doing development this way it felt like I was being a bit too paranoid, but honestly it's so fast and easy it's not at all noticeable. I often have to work on projects that use outdated package managers and have hundreds of top-level dependencies, so it's worth the setup in my opinion.

Amazing suggestion. So you're running it inside a Docker container or something? I'm going to try this out. I guess the alternative is a VPS if all else fails.

Incus uses LXC containers under the hood, which is better for development since the containers are made for running systems/os. Docker is best for running applications, but not that great for active development containers (imo).

With LXC any changes you make to the os/filesystem are persisted and there after the container boots up and shutsdown. So I don't have to worry about ephemeral storage or changes being lost. It feels more like a "computer" if that makes sense.

I do the same thing. Podman all the things.

I'm waiting for container escapes too, its only a matter of time.

Haven't seen any in the wild, but i built a few poc's just to prove to myself that I wasn't being overly paranoid.

If you're distributing something that uses this package, it's not just your dev computer at risk, it's all the users.

I'm aware thanks, but if your company is doing the standard practice of using 10k dependencies for some JS webslop you don't really have any other options but to protect yourself.

Some companies mandate that npm packages have to be x months old. Which gives time for this stuff to be discovered.

Reply on news.ycombinator.com