Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

241–250 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#241
post #240
post #5

Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?

Vulnerability scanners and security researchers would be looking those first 3 days

Re: Malicious npm packages detected across Red Hat Cloud Services

#242
post #201

Earlier quoted context omitted.

Thank you for the thorough response. I got the following from yours and other responses: * The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread. * This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user cana…

> Maybe NPM should run scanners before distributing malware? I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited. So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM fo…

Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.

Re: Malicious npm packages detected across Red Hat Cloud Services

#246
post #206

Earlier quoted context omitted.

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing sma…

> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client. Which is another part of this entire insanity: Browsers are already >. They're also built by > companies companies that collect > of analytics. You'd t…

The web api is actually extensive. I can understand complaints about it being not exactly approachable, and some wanting a cleaner abstraction, but there’s no way that it is small. Most issues is about people wanting to download a small library than just vendoring the small snippet of code.

The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.

Re: Malicious npm packages detected across Red Hat Cloud Services

#247

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

Shouldn't you also restrict version number for a package not just the latest?

Re: Malicious npm packages detected across Red Hat Cloud Services

#248

Earlier quoted context omitted.

The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.

Sure but like.. come on. Is that really a defense? Most packages are run on devs machines. And it's not like "Oh it's just running on my production server, what could go wrong there" is any better.

We should not dismiss that it is slightly better. Production servers vary rarely have creds to the source repository nor to other production servers running possibly more sensitive code where investing in a smaller supply chain was justified.

Re: Malicious npm packages detected across Red Hat Cloud Services

#249
post #232
post #212

Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes? All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with. In fact, the entire situation has been exacerbated by coding agents because now practically every…

Days since last malicious packages in NPM: 0 (evergreen) Days since last malicious packages in PyPI: 30 Days since last malicious packages in Maven: 120 I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.

Except that the JavaScript / NPM ecosystem is 6-7 times larger than Python and Java / Maven.

https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0...

Check the linked resource which has the actual data.

Post reply on HN