Show HN: Hagana – Runtime protection for Node.js to block supply chain attacks | Hacker News Reader

Show HN: Hagana – Runtime protection for Node.js to block supply chain attacks

github.com

11 pointsjackbeck4 comments

I recently came across an amazing post that really emphasizes the dangers associated with installing npm packages. It seems that every week a new supply chain attack occurs.

In my opinion, the existing solutions for this don't quite cut it so I decided to create a library which provides runtime protection for Node. It currently protects against:

- Unauthorized file system access

- Unauthorized network access

- Unauthorized command execution - (by way of exec/spawn)

I just released the first beta version of the library and I'd love to hear what you guys think.

Note: Protection is still missing for post/pre install scripts, but that's up next.

Open articleView on HN

Cool idea -- in some ways this "deno"-fies node, which I think is a sensible approach.

So far, Hagana only blocks outbound traffic from packages that are using the http or https modules. Support for other modules (e.g. net, dgram, dns) is coming soon.

This could be a problematic approach, though. If you are going OSS and do want to become ubiquitous, you will likely need much stronger protections. Obfuscation is not a path to security but blocking only some very basic vectors and then being explicit about it will have attackers adopt other similar vectors.

All in all, a cool first attempt at building with some work to do!

Thanks! This sort of "deno"-fies Node, but in my opinion it's a bit smarter. With Deno, it's an all or nothing approach where 3rd party libraries still have the same access as the main application.

Hagana is still not at the stage where it's fully ready to block all attacks, there's still work to be done, but I do want to be transparent about the approach taken so that the open source community can create issues that show sandbox breakouts (as someone already has).

Eventually it'll get to the point where the security will be tight enough that having it open source won't make a difference.

Additionally, even having this rudimentary protection is still more effective at blocking generic supply chain attacks than not having any protection at all.

Firstly, congrats on the release! With recent events, something like this seems like it could be valuable.

I will kind of jump in to the obvious thing first here though: the offer is tooling around dependency security in the npm ecosystem with a package users will install from npm.

Granted, vetting one package that works to vet others helps reduce the surface area to something manageable, and that’s a good thing, but I’m curious about how you’re thinking about the chicken-egg scenario that this introduces. What assures users that malicious code doesn’t seep its way into this package as it’s seeped into others?

Thank you!

I've given this exact question some thought. I think that the only real way to make sure this doesn't happen is by not allowing any 3rd party packages into the codebase. That means any package I want to install will have to be manually copied over. Granted, that this isn't the state now in the repo since I wanted to get to a POC phase as quickly as possible, but it's something I'm going to do.

Reply on news.ycombinator.com