[marcus_holmes]

No. we've been shouting warnings for years. There have been dozens, if not hundreds of threads on HN alone warning of supply-chain security threats.

At this point if you're not actively auditing your dependencies, and reducing all of them where you can, then you're on the wrong side of history and going down with the Titanic.

The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod. The fact that "everyone else did it" doesn't make it less stupid.

[erulabs]

> The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod

I mean, no. This is hyperbole at best and just wrong at median. A system of relative trust has worked very well for a very long time - Linus doesn’t have root access to all our systems, even if we don’t have to read every line of code.

[chha]

Linus doesn't have root access to our systems for several reasons. One of them is the fact that we get the actual source code, and not just a compiled blob doing "something". Another is the fact that they have at least some level of reviews wrt who can commit code, although this isn't perfect as the case with the University of Minnesota proved.

Npm on the other hand is much, much worse. Anyone can publish anything they want, and they can point to any random source code repository claiming that this is the source. If we look at how often vulnerable packages are discovered in eg. npm, I'd argue that the current level of trust and quality aren't sustainable, partly due to the potentially huge number of direct and transitive dependencies a project may have.

Unless you start to review the actual component you have no way to verify this, and unlike the Linux kernel there is no promise that anyone has ever reviewed the package you download. You can of course add free tools such as the OWASP Dependency Check, but these will typically lag a bit behind as they rely on published vulnerabilities. Other tools such as the Sonatype Nexus platform is more proactive, but can be expensive.

[elevader]

Maybe this is arguing semantics but unless you run something like Gentoo you will most likely get the linux kernel as a binary blob contained in a package your distribution provides. There isn't really any guarantee that this will actually contain untampered linux kernel sources (and in case of something like RHEL it most likely doesn't because of backports) unless you audit it, which most people won't do (and maybe can't do). So, in princpile at least, this isn't really that much better than the node_modules situation. Security and trust are hard issues and piling on 100s of random js dependencies sure doesn't help but you either build everything yourself or you need to trust somebody at some point.

[chha]

It depends on how you look at it. If I'm running Debian, I have decided to trust their sources and their process, regardless of how their software is being delivered. That process and the implementation of it is the basis for my trust. If I'm really paranoid, I can even attempt to reproduce the builds to verify that nothing has changed between the source and the binary blob.[1]

For npm, trust isn't really a concept. The repository is just a channel used to publish packages, they don't accept any responsibility for anything published, which is fair considering they allow anyone to publish for free. There are no mechanisms in npm that can help you verify the origin of a package and point to a publicly available source code repository or that ensures that the account owner was actually the person who published the package.

Security and trust is very hard, but my point here is that npm does nothing to facilitate either, making it very difficult for the average developer to be aware of any issues. The one tool you get with npm is...not really working the way it was supposed to.[2]

1 - https://reproducible-builds.org/ 2 - https://news.ycombinator.com/item?id=27761334

[elevader]

I 100% agree and I kind of wonder why this doesn't seem to be a problem with similar repositories like maven. That doesn't seem to hit HN every 1-2 weeks with a new security flaw/compromised package so they seem to be doing something right, whatever that may be.

[chha]

It's likely to be a combination of several things. Npm is trendy and has a low threshold for getting started, plus the fact that adding eg. bitcoin miners to a website is a nice way to decentralize and ramp up mining capacity.

Maven on the other hand define several requirements, such as all files in a package being signed, more metadata and they also provide free tools the developers can use to improve the quality of a package.

[ptx]

You do need to trust somebody (such as your Linux distribution of choice) but with NPM you're trusting thousands of somebodies and your system's security depends directly on all of them being secure and trustworthy.

[elevader]

Yeah, that is true. And npm as a whole doesn't really have a good track record in being worthy of a lot of trust.

[marcus_holmes]

Linux has all sorts of controls and review policies that NPM doesn't have. It's a false equivalence to say "we trust Linux, so therefore trusting NPM is OK".

If <random maintainer> commits code to their repo, pushes it to npm, and you pull that in to your project (possibly as an indirect dependency), what controls are in place to ensure that that code is not malicious? As far as I can tell, there are none. So how is this not trusting that <random maintainer> with commit-to-prod privileges?

[IggleSniggle]

Yeah, this is what I meant, except it goes in all directions. It’s not stating a “false equivalence” because pointing out that you can draw a line between 0 and 100 isn’t stating an equivalence.

Different risk profiles exist. There’s a difference between installing whatever from wherever, installing a relatively well known project but with only one or two Actually Trusted maintainers, and installing a high profile well maintained project with corporate backing.

This is true in Linux land, and it’s true in npm land. You can’t just add whatever repo and apt get to your hearts content. Or, you know, you also can, depending on your tolerance for risk.

[marcus_holmes]

I agree with what you're saying, but I don't see any discussion of risk in any conversation about JS programming (and I'm only picking on JS because of the OP - Ruby and Python aren't any better, and even Rust is heading the same way).

For example (taking one of the top results for "javascript dependency management" at random): https://webdesign.tutsplus.com/tutorials/a-guide-to-dependen... talks about all the dependency management methods available. The word "risk" is not in that article. There is no paragraph saying "be aware that none of these package managers audit any of the packages they serve, and you are at risk of supply-chain attack if you import a dependency using any of them".

This doesn't get any better as you get more expert. I've had conversations with JS devs who've been professionally coding for years, and none of them are aware of it (or if they are, treat it as a serious threat). You can see the same in the comments here.

If there's not even any discussion of risk, and no efforts to manage it, then it's not really a relevant factor. No-one is considering the risk of importing dependencies, so the 0-100 scale is permanently stuck on 100.

[waingake]

And should we all start rolling our own crypto now to avoid dependencies? In most cases a stable library is going to be much more secure than a custom implementation of `x`. Everything has trade-offs. What's stupid is dogma.

[djbusby]

I know you're being hyperbolic and I also want to add that for crypto you should just use libsodium. The algos and the code are very good. And lots of very smart folk have given it a lot of review. And its API is very nice.

[IggleSniggle]

When you say this, do you mean actual C libsodium? Because surely you don’t mean that I, a js developer, should need to figure out how to wrap this .h file thingy to get it to work in js when there’s SIX third-party libsodium implementations/wrappers/projects sitting right there listed on the libsodium website? /s

[jimmont]

This. And npm isn't the only instance. (Appreciate the voice in the wilderness Marcus.)

[FranksTV]

Or perhaps, the sky is not falling.