Hacker News Reader

Comment by porsager | Hacker News Reader

This won't prevent packages you're already giving capabilities to - to later do something evil in a small patch update.

So it's not enough - you should also not rely on "automatic security updates" through some sort of semver trust. Lock your dependencies up completely, choose packages with a small dependency tree or zero dependencies, and at the same time use the newly launched https://socket.dev to know what packages do. Also reading through the source of your dependencies should be on the list.

View on HN

> This won't prevent packages you're already giving capabilities to - to later do something evil in a small patch update.

True - its not perfect! But the principle of least privilege should help limit the blast radius. How many packages in npm dependency tree need access to the filesystem? Or to the network? I bet its a vanishingly small percentage of the packages in the average nodejs project. Being vulnerable to malicious code in 3 hand selected packages is much, much better than being vulnerable to malicious code in any of the packages in your dependency tree.

And even then, we can be very specific about what those packages have direct access to. Right now the situation is "every package can read and write to any file on my computer". The fine grained permissions I'm proposing in this post would let us say "only package X can access the filesystem at all, and when it does it only has access to this subdirectory".

Much better!

Thanks for sharing Socket.dev! Totally agree that a key part of any supply chain security strategy must be understanding what packages actually do when they run.

For example, see the package `angular-calendar` which is a calendar/date picker web component. When you look it up on Socket.dev [1], you'll see that it actually uses:

- Install scripts

- Telemetry to track you

- Network access

- Shell access

- Environment variable access

- File system access

Which is waaay more capabilities than you'd expect. All of these capabilities turn out to be caused by a single dependency which implements telemetry to track the package usage a la Google Analytics.

[1]: https://socket.dev/npm/package/angular-calendar/issues/0.29....

Wow.. Yeah that's a great example of exposing what's actually going on!

Btw, is there a specific reason you're not listing the "yellow issues" from a packages dependencies on its front page? For instance https://socket.dev/npm/package/mongoose doesn't really show anything on the front page, but if you go to "dependency issues" you get "uses network, eval etc.". I think it'd be necessary to treat "dependency issues" the same as the packages own issues.

We're not happy with the noisiness of filesystem and network issues, so we mark them as a bit lower priority for the moment. The specific issue is that we currently only detect when 'fs', 'net', etc. are required and not whether they're actually used and which specific functions are used.

We're working on improving our analysis and are close to shipping a big update at which point we'll increase the severity of these issues.

Reply on news.ycombinator.com