告诉HN：放慢脚步
供应链攻击的数量及其造成的影响范围正在不断增加。主要的罪魁祸首是那些不仅仅是编程语言的生态系统，这些生态系统中本应“自带电池”的内容，最终却堆积成一大堆没人愿意审查的库和模块。
这种情况无法扩展。让所有潜在用户审查这些代码无疑是在自找麻烦，绝大多数人最初就没有资源来编写这些模块/库，因此他们很可能也没有资源去审查他们所使用的所有内容。
我试着想象一下，如果Linux不只有一个发行版，而是有几千个，每一个都有可能在瞬间变得恶意，这在长远来看是行不通的。所有这些系统只能在没有恶意行为者、并且你可以隐含信任源头的世界中运作。
请改善内容的策划。下一个供应链漏洞很可能会是“重大漏洞”，而我相当确定，随着概念验证的增多，各国政府正在努力实现这种能力。我们需要更少的分发点，提供更好的策划，并在纳入之前进行更严格的审查，类似于Linux内核的做法。
我们不需要这种疯狂的高发布速度，整堆代码每天都在更新。你应该放慢速度，做好质量保证。
可靠性来自于投入时间进行审查和增加理解的能力，而不是来自于以惊人的速度发布的能力。不要把下游当作质量保证的工具，等到出错后再去修复。如果今天编写的代码，世界明天甚至后天都不需要。开发环境到发布的“快速通道”也有可能将任何环境的妥协导出到你的发布版本中，尤其是当你接受外部对代码的贡献时。
查看原文
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.<p>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.<p>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.<p>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.<p>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.<p>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.