Hacker News Reader

Comment by mohsen1 | Hacker News Reader

npm should take responsibility and up their game here. It’s possible to analyze the code and mark it as suspicious and delay the publish for stuff like this. It should prevent publishing code like this even if I have a gun to my head

View on HN

Why would npm care? They're basically a monopoly in the JS world and under the stewardship of a company that doesn't even care when its host nation gets hacked when using their software due to their ineptitude.

I think malware check should be opt-in for package authors, but provide some kind of 'verified' badge to the package.

Edit: typo

npm is on life support by msft. But there's socket.dev that can tell you if a package is malicious within hours of it being published.

“within hours” is at least one hour too late, and most likely multiple hours.

Absolutely not. you get npm packages by pulling not them pushing them to you as soon as a new version exist. The likelyhood of you updating instantly is close to zero and if not, you should set your stuff up so that it is. Many ways to do that. Even better if compared to a month or two - which is how long it often takes for a researcher to find a carefully planted malware.

Anyway, the case where reactive tools (detections, warnings) don't catch it is why LavaMoat exists. It prevents whole classes of malware from working at runtime. The article (and repo) demonstrates that.

Sure, it should never happen in CI environment. But I bet that every second, someone in the world is running "npm install" to bring in a new dependency to a new/existing project, and the impact of a malicious release can be broad very quickly. Vibe coding is not going to slow this down.

Vibe coding brings up the need for even more granular isolation. I'm on it ;)

LavaMoat Webpack Plugin will soom have the ability to treat parts of your app same as it currently treats packages - with isolation and policy limiting what they can do.

I've worked in software supply chain security for two years now and this is an extremely optimistic take. Nearly all organizations are not even remotely close to this level of responsiveness.

Again, that's why LavaMoat exists. Set it up once and it will block many classes of attacks regardless of where they come from.

Depends on whether they hold publishing to the main audience until said scan has finished.

I always thought this would be the ideal monetization path for NPM; enterprises pay them, NPM only supplies verified package releases, ideally delayed by hours/days after release so that anything that slips through the cracks has a chance to get caught.

Enterprises today typically use a custom registry, which can include any desired amount of scans and rigorous controls.

That would put them into liability or be a quite worthless agreement taking no responsibility.

> but provide some kind of 'verified' badge to the package

I would worry that that results in a false sense of security. Even if the actual badge says "passes some heuristics that catch only the most obvious malicious code", many people will read "totally 100% safe, please use with reckless abandon".

They already have this

https://docs.npmjs.com/trusted-publishers

https://docs.npmjs.com/generating-provenance-statements

i can guarantee you npm will externalize the cost of false-positive malware scans to package authors.

Or at a minimum support yubikey for 2fa.

Original author could be evil. 2fa does nothing.

If my grandma had wheels she'd be a bike. You don't need to attack the problem from only one angle.

Your grandma is a bike then. The 2fa is going to solve nothing and any attacker worth their salt knows it.

unphishable 2fa would have prevented this specific case tho... what are you talking about?

They do, I use a yubikey and it requires me to authenticate with it whenever I publish. They do support weaker 2fa methods as well, but you can choose.

Reply on news.ycombinator.com