I was going to say the following:

    Except that being responsible for your dependencies (and the dependencies of your dependencies...) is impossibly hard. You would need to build everything yourself after auditing the code.

But then I thought about it some more and its likely that you don’t need to audit the code, since the malware probably isn’t in the public git repo. Yes, its still a risk, but the probability of malware is much lower (and at least you CAN audit the code if you wanted to).

You still need to get the source for all your dependencies and all of their dependencies and so on and build it yourself, but you should probably do that anyway and host the artifacts in your own private repo. That’s good practice and avoids issues like the left-pad thing.

It's only impossibly hard to audit this kind of thing if you have an insanely large and deep tree of transitive dependencies in the first place. This seems to be a particularly bad problem in the JS world, for this and many other reasons, but most programming languages and their communities don't work that way. Auditing a small number of larger dependencies, when most of them are probably widely used and from reasonably trustworthy sources, is much more achievable.

Ha, what an excellent timing with another related story on top of the HN: https://news.ycombinator.com/item?id=16087024

I also think that with tree shaking and last-mile minification being more common these days, auditing might not be as daunting as it seems.

The other languages have the same problem. It's only spread over different places.

For example, JS doesn't have a standard library. Many languages do. So when JS downloads loads of transitive dependencies, many are there because there's no stdlib.

Have you audited your C++, or Java, or Ruby, or... stdlib lately? Especially those that come preinstalled with your OS of choice?

Same goes for anything that you download via Maven, or gems, or easy_install, or include as direct GitHub references in your Go code.

Those standard libraries are typically widely used. In many cases, the source can be examined. In most cases, there's a large professional team at a reasonably reputable organisation responsible for maintaining them. In almost all cases, there are no transitive dependencies not managed by the same people. Once installed on your system, they generally don't change unless you actively change them. While there is some risk in any dependency (cf. Reflections on Trusting Trust) the level of risk is on an entirely different scale in this sort of situation compared to what much of the JS world does every day.

> In many cases, the source can be examined.

Have you examined them, though? ;) And yes, I was thinking about Reflections on Trusting Trust as well :)

> In almost all cases, there are no transitive dependencies not managed by the same people.

That's why I said the risk is spread very differently compared to JS :)

And anyway, what dependencies does a webpage for processing credit cards need?

Very little or none. But it’s easy to get carried away in the client with things like card number validation, detecting the card type based on number, date drop down picker for the expiry date, animation library for showing when it’s processing, etc. Let alone leaving in the standard includes like Google Analytics, tracking URLs, A/B testing tools, etc.