I feel that Jia Tan would also have inspired other, perhaps less well-funded, bad actors to try similar things.

Often you'll see one attack succeed or semi-succeed, but the actual plan was a good one, and it gets copied by less sophisticated attackers that can't come up with their own plans but copy other attacks that have had some success.

While technical knowledge is required to execute this, the social engineering aspect is more accessible. Backdoors aren't too hard to find and add even if you're not super technical. This means that the volume of such attacks is likely to increase and also be harder to defend against.

I'm really hoping that the XZ attack makes folks more wary though given enough time, the feeling of urgency will pass and folks may become more lax again.

Major vendors like GitHub can have a good impact here in adding detection and tools to enable detection and prevention of bad actors in this manner, though a lot of OS doesn't work around centralised tools like this and requires people to keep being vigilant.

I kinda feel that it's inevitable for such an attack to take place in the future and have similarly devastating consequences. Things are just too decentralised and independent (which is a good thing) to cover all bases effectively.

We can hope that maintainers of very commonly-used packages/tools are vigilant but people are people.

> It’s not surprising that the OpenJS foundation and the JavaScript ecosystem, which is used by over 95% of all websites, would be the next target of threat actors

I'm certainly glad that the Executive Directors of the "OpenJS Foundation" and "Open Source Security Foundation" feel so important, but something tells me that this is a bit of... an exaggeration... Maybe they should join their efforts with "Open Website Foundation" and "Open Hardware Foundation" to cover 100% of bullshit bingo misleading naming of corporations whose necessity is unnecessary in the first place.

A vulnerability like this one sells for $1 mil.

At this point is cheaper to hire 5 full time programmers for a year to just introduce a vulnerability in an open-source project. Do it the old Google way - you work 80% of time on legit features and bug fixes to get credibility and in 20% of time you work on the backdoor.

The report, which is phrased as a press release, buries the lede. Some good quotes:

> I'm wondering if perhaps the Linux ecosystem is actually a bunch of aging infrastructure. If so, that fact might be obscured by seemingly healthy contributions to the Linux kernel. There's a ton of other "basic infrastructure" that gets shipped alongside the kernel, though: coreutils, binutils, gcc, make, autotools, cmake, zlib, xz, etc etc etc. -- Camdon Cady

> Our team at Socket catches 100+ software supply chain attacks in npm, PyPI, and Go every week.

> Software engineer Andrew Nesbitt has been playing around with the concept of a "blast radius" for open source security advisories on He uses the CVSS score of a security advisory multiplied by the number of repositories that depend upon that package to determine the “blast radius.”

Shouldn’t performance testing be a part of any standard change process for a distribution? You can hide in the code, but you can’t hide from the laws of physics.