Hacker News Reader

Comment by dodgerdan | Hacker News Reader

Will this be met with a shrug from the JS community? Or is this the come to Jesus moment for the JS supply chain?

What do you expect the community to do?

Stop using thousands of packages? Start vetting packages, as if security was important?

There are already dozens of us saying it is possible to not have too many dependencies, and vet packages before installing. But every time we open our mouths we are treated as if we just escaped some sort of insane asylum.

At a place I worked in the past we used to have a 40-line microservice using plain-node without any dependencies. That was by design. One junior dev took it upon himself, in their spare time, to convert the whole thing to use some js MVC framework, complete with a full-blown build process, transpilers, and all the nine yards. There was a big discussion in the PR and a lot of juniors complained that we should migrate because they "didn't learn plain node.js in college".

We can't have nice things anymore.

It surprises me that colleges teach web frameworks.

Me too. But what really suprises me is that today that's virtually the only thing some of them are teaching.

It's Java or Python for programming basics (arithmetics, ifs, print), then straight into frameworks.

That's really unfortunate. I think education is the best place to teach these things bottom up. Especially considering that you understand a framework way better after creating one yourself. There are not that many essential parts in a web framework anyways, it's the plumbing, the tooling and the polish around them that makes them productive.

Exactly. IMO you're a 100x better developer when you at least tried to create something you use from scratch.

I find however this will become harder and harder with newbies being constantly bombarded online with messages stating that creating anything from scratch is a futile exercise, together with companies influencing college curriculums.

I suppose it's job security for a lot of us that colleges are producing developers who don't know what a string is.

It's unrealistic to vet the entire chain of dependencies especially considering how they can become vulnerable at any time. Developers can't be expected to be responsible for that.

What we need is a set of policies around dependencies that we agree on as an industry and tools to help make securing our systems easier.

We're working on it: https://slsa.dev/spec/v0.1/requirements

Nope. It is completely realistic as long as you keep the chain of dependencies manageable.

To vet dependencies properly you have to stop using thousands of them willy-nilly.

To stop using thousands of them you mostly have to change only your development dependencies. Runtimes dependencies, even in large Javascript projects, are often well behaved and are rarely a big issue. Except maybe for a few large backend frameworks.

No, that won't destroy your company.

Anything that helps vetting will be more than welcome, though.

> What do you expect the community to do?

Ensuring that the core infrastructure of their software systems doesn’t have the same security standards as teenagers wordpress site would be an awesome start.

Depending on what you're calling core infrastructure, it might not be something under control of "the community".

For once, I don't think this highlights an issue exclusively specific to JS.. this could've happened to any package system that Github owned when the attacker was able to pivot after accessing the private repos.

  > Will this be met with a shrug from the JS community?

Go read the comment that begins "Top 10 maintainer here". Not even a shrug.

Was this incident facilitated by something inherent in the JS ecosystem? I have the impression it wasn't.

The JS ecosystem sucks, but anyway, not particularly their fault in this case.

I’m of a bit of an opposite mind on the many, and usually very public, NPM security issues. Because from my experience the JS ecosystem, and it’s woes, teach a lot of people to never trust the part of their operation that is coming from someone else. I mean not everyone, obviously, but in my anecdotal experience it’s far more common to see good package control and review processes for JS than any other language, well except for maybe Python when the Python is done by software engineers and not “data-scientists”.

Supply chain security is immensely important, and I encourage you not to learn about it the hard way like I did. Which somewhat ironically happened in the .Net ecosystem when one of our trusted Nuget packages got hacked many years ago. Now, I could be mistaken and I hope I am, but I suspect that if you ask a Java, a JS and a C# developer if they trust their ecosystem, then only one of them is likely to say yes.

So no, there won’t be some great revelation in the JS community. The best you can hope for with stories like these is that fewer developers feel like imposters when they realise that GitHub stores plaintext security assets in their logs.

As a member of the JS community: shrug. I revoked my OAuth apps on Github, changed my passwords. The tarballs are unaffected. Not worried.

I hope this is self-deprecating humor, but for anyone that takes it at face value:

The implication of a successful attack on NPM, with huge unvetted dependency graphs currently in fashion, would be that any of the thousands dependencies of a modern small JavaScript app could suddenly include malicious code that runs your dev machine or your production systems.

(That's why the key part of the announcement is "GitHub is currently confident that the actor did not modify any published packages in the registry or publish any new versions to existing packages".)

What would you expect the JS community do after this? What would you do?

Yes, because this fundamentally wasn't an attack against NPM or any specific package manager. This stemmed from a breach at Heroku.

Reply on news.ycombinator.com