Live data from Hacker News

Pnpm has a new setting to stave off supply chain attacks

pnpm.io

21–30 of 152 posts

Re: Pnpm has a new setting to stave off supply chain attacks

#22

If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.

Not really, app sec companies scan npm constantly for updated packages to check for malware. Many attacks get caught that way. e.g. the debug + chalk supply chain attack was caught like this: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...

Re: Pnpm has a new setting to stave off supply chain attacks

#23
post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

> Does the JS ecosystem really move so fast that you can’t wait a month or two before updating your packages?

In 2 months, a typical js framework goes through the full Gartner Hype Cycle and moves to being unmaintained with an archived git repo and dozens of virus infected forks with similar names.

Re: Pnpm has a new setting to stave off supply chain attacks

#24
post #9

That solve not really the problem. A better (not perfect) solution: Every package should by AI analysed on an update before it is public available, to detect dangerous code and set a rating. In package.json should be a rating defined, when remote package is below that value it could be updated, if it is higher a warning should appear. But this will cost, but i hope, that companies like github, etc. will allow package…

Ah, yes! The universal and uncheatable LLM! Surely nothing can go wrong.

Perfect is the enemy of good. Current LLM systems + "traditional tools" for scanning can get you pretty far into detecting the low hanging fruit. Hell, I bet even a semantic search with small embedding models could give you a good insight into "what's in the release notes matches what's in the code". Simply flag it for being delayed a few hours, till a human can view it. Or run additional checks.

Re: Pnpm has a new setting to stave off supply chain attacks

#26
post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

> Does the JS ecosystem really move so fast that you can’t wait a month or two before updating your packages?

Really depends on the context and where the code is being used. As others have pointed out most js packages will use semantic versioning. For the patch releases (the last of the three numbers), for code that is exposed to the outside world you generally want to apply those rather quickly. As those will contain hotfixes including those fixing CVEs.

For the major and minor releases it really depends on what sort of dependencies you are using and how stable they are.

The issue isn't really unique to the JavaScript eco system either. A bigger java project (certainly with a lot of spring related dependencies) will also see a lot of movement.

That isn't to say that some tropes about the JavaScript ecosystem being extremely volatile aren't entirely true. But in this case I do think the context is the bigger difference.

> then again, we make client side applications with essentially no networking, so security isn’t as critical for us, stability is much more important)

By its nature, most JavaScript will be network connected in some fashion in environments with plenty of bad actors.

Re: Pnpm has a new setting to stave off supply chain attacks

#27

Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.

The new setting is consistent with the old ones, which is more important IMHO:

https://pnpm.io/settings#modulescachemaxage

Re: Pnpm has a new setting to stave off supply chain attacks

#29

If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.

A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.

In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code...

> It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed

> This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3, which got published just a few minutes earlier.

Post reply on HN