| ▲ | cddotdotslash 4 days ago |
| NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point. |
|
| ▲ | PokestarFan 4 days ago | parent | next [-] |
| NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them |
| |
| ▲ | Cthulhu_ 4 days ago | parent | next [-] | | But Github does loads of things with security, including reporting compromised NPM packages. I didn't know NPM is owned by Microsoft these days though, now that I think about it, Microsoft of all parties should be right on top of this supply chain attack vector - they've been burned hard by security issues for decades, especially in the mid to late 90's, early 2000s as hundreds of millions of devices were connected to the internet, but their OS wasn't ready for it yet. | |
| ▲ | wutbrodo 4 days ago | parent | prev | next [-] | | It's not like NPM pre-Microsoft was a paragon of professional management or engineering... | | | |
| ▲ | bnchrch 4 days ago | parent | prev | next [-] | | Good god. Not everything has to be about your opinion on AI. | | |
| ▲ | PokestarFan 4 days ago | parent | next [-] | | GitHub was folded into Microsoft's "CoreAI" team. Not very confidence-inspiring. | |
| ▲ | jay_kyburz 4 days ago | parent | prev [-] | | Actually, they could probably use AI to see if each update to a package looks malicious or obfuscated. |
| |
| ▲ | txdv 3 days ago | parent | prev | next [-] | | Just write a check.md instruction for copilot to check it for malicious acticity, problem solved | |
| ▲ | andix 4 days ago | parent | prev [-] | | Is it really owned and run by Microsoft? I thought they only provide infrastructure, servers and funding. |
|
|
| ▲ | buzuli 4 days ago | parent | prev | next [-] |
| For packages which have multiple maintainers, they should at least offer the option to require another maintainer to approve each publish. |
|
| ▲ | mrguyorama 4 days ago | parent | prev | next [-] |
| Why would NPM do anything about it? NPM has been a great source of distributing malware for like a decade now, and none of you have stopped using it. Why in the world would they NEED to stop? It apparently doesn't harm their "business" |
| |
| ▲ | pants2 4 days ago | parent [-] | | Dozens of businesses have been built to try fixing the npm security problem. There's clearly money in it, even if MS were to charge an access fee for security features. |
|
|
| ▲ | twistedpair 4 days ago | parent | prev | next [-] |
| Identical, highly obfuscated (and thus suspicious looking) payload was inserted into 22+ packages from the same author (many dormant for a while) simultaneously and published. What kind of crazy AI could possible have noticed that on the NPM side? This is frustrating as someone that has built/published apps and extensions to other software providers for years and must wait days or weeks for a release to be approved while it's scanned and analyzed. For all the security wares that MS and GitHub sell, NPM has seen practically no investment over the years (e.g. just go review the NPM security page... oh, wait, where?). |
|
| ▲ | legohead 4 days ago | parent | prev [-] |
| I blame the prevalence of package mangers in the first place. Never liked em, just for this reason. Things were fine before they became mainstream. Another annoying reason is package files that are set to grab the latest version, randomly breaking your environment. This isn't just npm of course, I hate them all equally. |
| |
| ▲ | stevenpetryk 4 days ago | parent [-] | | I'm a little confused, is this rage bait or what? > Things were fine before they became mainstream As in, things were fine before we had commonplace tooling to fetch third party software? > package files that are set to grab the latest version The three primary Node.js package managers all create a lockfile by default. | | |
| ▲ | int_19h 3 days ago | parent | next [-] | | > As in, things were fine before we had commonplace tooling to fetch third party software? In some ways they were. I remember how much friction it was to take a dependency in your typical desktop C++ or Delphi app in late 90s - early 00s. And because of that, developers would generally be hesitant to add a new dependency without a strong justification, especially so any kind of dependency that comes with its own large dependency tree. Which, in turn, creates incentives for library authors to create fairly large, framework-style libraries. So you end up with an ecosystem where dependencies are much more coarse and there are fewer of them, so dependency graphs are shallow. Whether this is an advantage or a disadvantage in its own right can be debated, but it's definitely less susceptible to this kind of attack because updating dependencies in such a system is also much more involved; it's not something that you do with a single `npm install`. | |
| ▲ | nananana9 3 days ago | parent | prev [-] | | I mostly share GP's sentiment, although they didn't argue their point very well. > As in, things were fine before we had commonplace tooling to fetch third party software? Yes. The languages without a dominant package manager (basically C and C++) are the only ones that have self-contained libraries, that you can just drag into your source tree. This is how you write good libraries - as can be seen by the fact that for many problems, there's a powerful C (or C++, but usually C) library with minimal (and usually optional) dependencies, that is the de-facto standard, and has bindings for most other languages. Think SDL, ffmpeg, libcurl, zlib, libpng/jpeg, FreeType, OpenSSL, etc, etc. That's not the case for libraries written in JS, Python, or even other compiled languages like Go and Rust - libraries written in those languages come with a dependency tree, and are never ported to other languages. |
|
|
