281–290 of 1001 posts
Earlier quoted context omitted.
NPM is owned by github/microsoft. I'm sure they could afford to buy one of these products or just build their own, but clearly security is not a thing they care about.
Somehow I didn't realize GitHub purchased npm in 2020. GitHub is the second word on npmjs.org. How did I not notice?
A lot of fingers in a lot pies
Earlier quoted context omitted.
> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…
Which mitigations specifically are in npm but not in crates.io? As far as I know crates.io has everything that npm has, plus - strictly immutable versions[1] - fully automated and no human in the loop perpetual yanking - no deletions ever - a public and append only index Go modules go even further and add automatic checksum verification per default and a cryptographic transparency log. Contrast this with docker hub f…
I'm not referring to mitigations in public repositories (which you're right, are varied, but that's a separate topic). I'm purely referring to internal mitigations in companies leveraging open-source dependencies in their software products.
These come in many forms, everything from developer education initiatives to hiring commercial SCA vendors, & many other things in between like custom CI automations. Ultimately, while many of these measures are done broadly for all ecosystems when targeting general dependency vulnerabilities (CVEs from accidental bugs), all of the supply-chain-attack motivated initiatives I've seen companies engage in are single-ecosystem. Which seems wasteful.
Earlier quoted context omitted.
> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…
> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.
Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.
Earlier quoted context omitted.
> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…
> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.
I wonder who actually discovered this attack? Can we credit them? The phrasing in these posts is interesting, with some taking direct credit and others just acknowledging the incident. Aikido says: > We were alerted to a large-scale attack against npm... Socket says: > Socket.dev found compromised various CrowdStrike npm packages... Ox says: > Attackers slipped malicious code into new releases... Safety says: > The S…
Earlier quoted context omitted.
> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…
I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.
NPM is special in the same way as Windows is special when it comes to malware: it's a more lucrative target.
However, the issue here is that - unlike Windows - targetting NPM alone does not incur significantly less overhead than targetting software registries more broadly. The trade-off between focusing purely on NPM & covering a lot of popular languages isn't high, & imo isn't a worthwhile trade-off.
Related (7 days ago): NPM debug and chalk packages compromised (1366 points, 754 comments): https://news.ycombinator.com/item?id=45169657
No direct relation to the specific attack on debug/chalk/error-ex/etc that happened 7 days ago.
The article states that this is the same attackers that got control of the "nx" packages on August 27th, which didn't really get a lot of traction on HN when it happened: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
Earlier quoted context omitted.
I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.
Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.
Earlier quoted context omitted.
> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.
> usually an NPM package which pulls its dependencies automatically Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.
I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…
Javascript is badly over-used and over-depended on. So many websites just display text and images, but have extremely heavy javascript libraries because that's what people know and that is part of the default, and because it enables all the tracking that powers the modern web. There's no benefit to the user, and we'd be better off without these sites existing if there were really no other choice but to use javascript…
Eh... This over-generalises a bit. That can be said of anything really, including native desktop applications.