3 ms·

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 no

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 https://socket.dev to know what packages do. Also reading through the source of your dependencies should be on the list.

josephg 5y ago
> 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!
feross 5y ago
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.0?tab=dependencies https://socket.dev/npm/package/angular-calendar/issues/0.29....
- porsager 5y ago
  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 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.
  - feross 5y ago
    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.

josephg 5y ago

> 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!

feross 5y ago

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.0?tab=dependencies https://socket.dev/npm/package/angular-calendar/issues/0.29....

porsager 5y ago
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 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.
- feross 5y ago
  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.