Earlier quoted context omitted.
Almost all of them.
I haven’t seen this in Go or Java?
Ok, so you are right, Go and Java (Maven, at least) doesn't have this issue.
Malicious npm packages detected across Red Hat Cloud Services
481–490 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#482Earlier quoted context omitted.
There's literally no excuse - I'm still baffled.
You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not. And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward…
I think the post you're replying to was commenting on "web dev is a culture shock in so many ways", not the concept of cooldowns overall.
Re: Malicious npm packages detected across Red Hat Cloud Services
#483Earlier quoted context omitted.
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit o…
> they very frequently get malicious npm packages taken down within a day of publishing If I'm reading the secondarily-linked blog post correctly, this was live for 12 days before discovery.
No, the reference to May 19 in the article is about a previous supply chain attack against AntV (https://www.stepsecurity.io/blog/shai-hulud-here-we-go-again...). I think there may be some copy-paste mistakes where they reused part of that previous article and didn't contextualize it correctly.
The npm package `@redhat-cloud-services/chrome` version 2.3.1, which was part of this current supply chain attack, was published on June 1. The malicious package version is no longer listed on npmjs.com's web UI since it was taken down, but the publish date of 2.3.1 can still be seen in https://registry.npmjs.org/@redhat-cloud-services/chrome by searching for the version number there, and the publish date was 2026-06-01T10:54:42.121Z.
I find the article extremely annoying for not having a clear timeline of when these malicious package versions were available.
Re: Malicious npm packages detected across Red Hat Cloud Services
#484Earlier quoted context omitted.
I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
Caching proxies are a decent middle ground like Artifactory. AWS might support that (maybe only on certain repo types?) Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local…
or you can throw all of this into the trash and just use Nix.
Re: Malicious npm packages detected across Red Hat Cloud Services
#485Earlier quoted context omitted.
what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly e…
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check i…
You might have been "pwned" in the meantime waiting for 7 days!
If I'm checking, I have to check everything no? That's just updating every dependency!
Am I taking crazy pills? Obviously cooldowns don't work.
Re: Malicious npm packages detected across Red Hat Cloud Services
#486[flagged]
Re: Malicious npm packages detected across Red Hat Cloud Services
#487Earlier quoted context omitted.
not if you have internal repos?
I think you can set it on internal repos, but then you need to allow-list internal code. People act like this is simple + solved, but it's not. It turns into 100K-1M's of LLM tokens on a semi-regular basis, or "just hire a build infra team for your side project" pretty quickly.
did you write this with an LLM? also, no, there are no docs for allow listing internal libraries or namespaces in NPM that I can find
Re: Malicious npm packages detected across Red Hat Cloud Services
#488Earlier quoted context omitted.
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check i…
You might have been "pwned" in the meantime waiting for 7 days! If I'm checking, I have to check everything no? That's just updating every dependency! Am I taking crazy pills? Obviously cooldowns don't work.
If you install a package that has been part of a supply chain attack, you definitely have a problem. If you have a dependency with a vulnerability, you might have a problem, and any really bad one you are likely to find out about anyway. You can also subscribe to notifications for CVEs as well. Obviously, you would ideally be reviewing every update to every dependency manually, and reviewing them for security problems as well, but in the absence of the resources to do that, the risk balance for cooldowns makes a decent amount of sense (especially since the number of high-profile everyone-patch-now vulnerabilities in the npm ecosystem is now a fair bit smaller than the number of supply chain attacks).
Re: Malicious npm packages detected across Red Hat Cloud Services
#489Earlier quoted context omitted.
The biggest problem is not software but culture, not at npm, but in the js ecosystem. The js ecosystem is simply a juicy targets, the attack surface is enormous. The attacker can make their attack more sophisticated, there will always be a maintainer that can seed the worm spread. Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.
I'd go further and say that how JS and the web itself has been run over the years has predisposed it to this sort of thing. JS didn't have a passable stdlib until ES6. It had bugs built into it because Eich was given a stupidly short time window to deliver the first version. Everyone (particularly MS) had (and still sort of do) their own way of interpreting the language. In spite of all of this it became the primary…
Yes this is kinda my point.
Instead of having a few projects/org, it's a constellation of packages too small, it's impossible to know who you depend on when adding a dependency.
Re: Malicious npm packages detected across Red Hat Cloud Services
#490Earlier quoted context omitted.
The kind of 'urgent CVE' situation they're describing generally involves you learning about it out-of-band and then rushing to deploy an update. If you learn about a supply chain attack, oops, you might already have been pwned in the meantime, depending on when your builds ran. If you learn about an important CVE, you're not going to count on what's deployed already being patched, you're going to at a minimum check i…
You might have been "pwned" in the meantime waiting for 7 days! If I'm checking, I have to check everything no? That's just updating every dependency! Am I taking crazy pills? Obviously cooldowns don't work.
Do you update your dependencies and push to production every single day? Saturdays and sundays too?
What are the chances that your code is using a vulnerable dependency AND doing so in an exploitable manner AND the vulnerability being serious enough to warrant immediate attention? The likelihood of that is extremely low unless you're high-profile enough to have a team dedicated to this.
99.9% of vulnerabilities in your dependencies aren't actually exploitable in your project. Most exploitable vulnerabilities probably aren't that serious. And even if it's serious, it's unlikely that you would be targeted immediately.
On the other hand you have a constant stream of unreviewed dependency updates, each one having a small chance of containing malicious code.
The most pragmatic approach, IMO, is to set up alerts for high severity CVEs, cooldown of at least 24h, and only execute code in per-project sandboxes (VMs or containers).
1 day is short enough that it would practically never be a problem, regardless of severity. It's historically been long enough to discover the vast majority of these supply chain attacks, and alerting for high severity CVEs is something you should be doing anyway if you're worried about security.