Show HN: Hagana – Runtime protection for Node.js to block supply chain attacks
11 points| jackbeck | 3 years ago |github.com
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.
gkapur|3 years ago
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!
jackbeck|3 years ago
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.
ovao|3 years ago
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?
jackbeck|3 years ago
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.