Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns. https://www.redhat.com/en/lightwell
That was a few days ago: https://news.ycombinator.com/item?id=48313577
Malicious npm packages detected across Red Hat Cloud Services
401–410 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#402Earlier quoted context omitted.
Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
It’s kind of insane this doesn’t happen in the publish pipeline by default.
[deleted]
Re: Malicious npm packages detected across Red Hat Cloud Services
#403Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…
[dead]
Re: Malicious npm packages detected across Red Hat Cloud Services
#404In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…
Why doesn't Java seem to have anything close to this issue? Isn't it a solved problem?
No deep dependency graph, so easy to audit and inspect. Stable development process, so easier to manage the flow of updates. And I believe a more cautious ecosystem. Not everyone is rushing to create or adopt new libraries, especially for what could have been a single file. So most libraries are about solving a domain, not just one single algorithm.
Same thing with C, Perl, PHP,…
Re: Malicious npm packages detected across Red Hat Cloud Services
#405Earlier quoted context omitted.
Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.
I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
Re: Malicious npm packages detected across Red Hat Cloud Services
#406Has anyone thought of having an agent review all dependency upgrades before upgrading? I feel like that would at least catch some of these
Yes, I do this. It absolutely would catch some of these.
Re: Malicious npm packages detected across Red Hat Cloud Services
#407Earlier quoted context omitted.
Ok so no external dependencies, or pull versions from 2021 and apply security patches?
- Best practice for both reliability and security is to not immediately upgrade to latest versions. Only immediately upgrade to security-patched versions. If your software doesn't need a new version, you can remain on the old version. - When a feature you're developing, or a transitive dependency, requires an upgraded version, you can upgrade to the latest stable version that satisfies the dependency. But as each of…
it would be way easier if dependencies were a flat list and not a graph, aka peer in npm parlance. I believe that’s what go does. A library only need to say that it depends 1.x.x or 1.2.x and it’s up to the application to provide it. Conflict is handled manually.
The onus is on libraries developers to cleanup their act. Start vendoring code instead of depending on hundreds tiny libraries.
Re: Malicious npm packages detected across Red Hat Cloud Services
#408Earlier quoted context omitted.
Some packages need to build native dependencies. sharp for example needs to build libvips on the system [0] to work 0: https://github.com/lovell/sharp/blob/main/install/build.js
Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.
but how can you verify that the prebuilt binaries aren’t compromised?
Re: Malicious npm packages detected across Red Hat Cloud Services
#409It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.
Re: Malicious npm packages detected across Red Hat Cloud Services
#410Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…
> anything where code executes ALL the agentic orchestrators like codex, claude-code, etc. seem to do this by default.
Exactly, popular AI coding harness (OpenCode/KiloCode) downloads random npm packages in the background without you knowing. What's worse is the devs don't care.