We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specific development for making things dramatically worse, it's cryptocurrencies, not AI. They've turned the cottage industry of malicious hacking into a multi-billion-dollar enterprise that's attractive even to rogue nations such as North Korea. And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
We know how to write software with very few bugs (although we often choose not to). We have no good plan for keeping big enterprises secure in this reality. Autonomous LLM agents will be used by ransomware gangs and similar operations, but they don't need FreeBSD exploit-writing capabilities for that.
The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.
FAIR has a very interesting architecture, inspired by atproto, that I think has the potential to mitigate some of the supply-chain attacks we've seen recently.
In FAIR, there's no central package repository. Anyone can run one, like an atproto PDS. Packages have DIDs, routable across all repositories. There are aggregators that provide search, front-ends, etc. And like Bluesky, there are "labelers", separate from repositories and front-ends. So organizations like Socket, etc can label packages with their analysis in a first class way, visible to the whole ecosystem.
So you could set up your installer to ban packages flagged by Socket, or ones that recently published by a new DID, etc. You could run your own labeler with AI security analysis on the packages you care about. A specific community could build their own lint rules and label based on that (like e18e in the npm ecosystem.
Not perfect, but far better than centralized package managers that only get the features their owner decides to pay for.
The deeper structural issue is that plugin update notifications function as an implicit trust signal. Users see "update available" and click without questioning whether the author is still the same person. A package signing and transfer transparency system similar to what npm has been working toward would help here, but the WordPress ecosystem has historically moved slowly on security infrastructure.
edit: The idea is the $1 goes towards the tokens required to scan the source code by an LLM, not simply cost a dollar for no other reason that raising the bar.
First submission is full code scan, incremental releases the scanner focuses on the diffs.
But I have encountered a lot of groupthink, brigading downvotes etc. So I stopped having high expectations over the years.
In the case of Wordpress plugins, it’s bloody obvious that loading arbitrary PHP code in your site is insecure. And with npm plugins, same thing.
Over the years, I tried to suggest basic things… pin versions; require M of N signatures by auditors on any new versions. Those are table stakes.
How about moving to decentralized networks, removing SSH entirely, having a cryptocurrency that allows paying for resources? Making the substrate completely autonomous and secure by default? All downvoted. Just the words “decentralized” and “token” already make many people do TLDR and downvote. They hate tokens that much, regardless of their necessity to decentralized systems.
So I kind of gave up trying to win any approval, I just build quietly and release things. They have to solve all these problems. These problems are extremely solvable. And if we don’t solve them as an industry, there’s going to be chaos and it’s going to be very bad.