jacquesm

The number of supply chain attacks and the blast radius as a result of these is ever increasing. The big culprits are languages that are not just languages but whole eco-systems, where stuff that should be 'batteries included' ends up in a massive stack of libraries and modules that nobody can be bothered to review.

This doesn't scale. Reviewing all of this code by all of the potential users is just asking for it, the bulk of them did not have the resource to write the module/library in the first place so they most likely will not have the resources to review everything they ingest.

I'm trying to imagine Linux with not one distribution but several thousand each of which could become malicious at the drop of a hat. In the longer term this will not work. All of these systems can only work in a world where there are no bad actors and where you implicitly trust the source.

Please improve curation. The next supply chain bug may well be 'the big one' and I'm pretty sure that various nation states are aiming to achieve that kind of capability now that there are ample proofs of concept out there. We need fewer points of distribution with better curation and far stricter review before inclusion, something along the lines of the Linux Kernel.

We do not need these crazy high release speeds with daily updates all over the stack, then you should just slow down and do better QA.

Reliability comes from the ability to invest the time review and increase understanding, not from the ability to release at breakneck speed, use your downstream as QA and then to fix things when you get them wrong. If it was coded today the world does not need it until tomorrow or even the day after tomorrow. Having a 'hot path' from your development environment to release that is fast also has the potential to export any compromise of your environment to your releases. More so if you accept external contributions to your code.