你不应该更新你的依赖项

更简单的时代……系统管理员的罕见历史照片，这是一个古老的物种，后来演变成现代的 DevOps，大约在 1999 年 1 月。这张照片几乎没有包含他对 Linux 2.2 的发布和即将到来的 LinuxWorld Expo 的前景的兴奋，正在与他的义务互利主义者（俗称“软件供应商销售哥们”）在生产中执行两年一次的软件补丁程序。上世纪 90 年代末，我从大学退学后开始从事科技行业。我的第一台金属服务器在两周内遭到入侵。 （是的，phpMyAdmin。是的，未打补丁。是的，仍然感到羞耻。）从字面上看，我们在那个时代深刻内化的第一件事就是“非常仔细地审查你所依赖的东西，阅读所有变更日志和补丁，及时应用，始终保持最新”。可以肯定，对于大多数喜欢 npm-dependabot-trigger 的人来说，这听起来很奇怪，甚至很陌生……如今，面对毁灭性供应链事件的全面、看似无法克服的猛攻，一些包管理器开始建议在一定天数之前不要更新依赖项（只是为了确保，你知道，走在你前面的白痴付出代价并首先发现问题……）。长期以来一直是基本软件安全卫生和白话智慧的主要内容现在被认为是有害的：不要更新得太快，否则会让自己面临持续的供应链攻击。当然，不升级确实会让您面临针对（技术修补的）上游 CVE 的积极活动。如果你这样做的话就该死。如果你不这样做就该死。旧的运营模式确实在一个更小、更简单的技术世界中，在一个更受控制和孤立的环境中，你将依赖于少数可以手动审查的正式定义的供应商，并且复杂的供应链问题和具有传奇色彩的依赖关系列表......甚至不是一个科幻概念。在过去的两到三十年中，向开源的大规模转变（部分是由更好的安全故事支撑的：“与闭源供应商相比，您可以从更好的社区驱动的审查中受益！”……哦，可爱的夏天孩子……），随着生态系统规模的指数级增长，带来了大量新问题，通过一系列可怕的“核心依赖”漏洞（还记得 bind 、 openssl ，还是 log4j ？）痛苦地揭示出来，这些漏洞基本上破坏了整个系统互联网，反复。第一次“认识”可能是在 2010 年代中期：开源维护人员不仅仅是免费劳动力，他们也工作过度、装备不足、人手严重不足，并且与其他人一样有能力或无能力。然而他们的工作支撑着大多数软件（现在仍然如此）。再加上无可救药的天真包管理器和软件分发作为一个类别的深刻缺陷和不足，一些新的（非常）流行的堆栈的无能，以及在企业行业中竞争竞争对手的压力越来越大，共同孕育了一种只保留前一个外观（“总是完全修补”部分）的文化，现在缺乏实质内容，本质上变成“只是更新所有内容，无论它是什么，甚至都不看”。 “供应链脆弱性”的概念成为主流。更广泛的行业反应大多是举手投足：“我们使用的是最新版本。上游将修补。您还想从我们这里得到什么？”先锋派还会与精心包装的官僚机构打交道，这些官僚机构无助于解决实际问题的根本原因，但却让我们都感觉更好，通过创造额外的工作（当然是为了一大笔钱）来灌输一种令人欣慰的幻觉，即我们处于控制之中：负责任的披露计划和盛大的安全政策、禁运、CVE 和神圣的 CVSS（超级有用，对吗？对吧？）、合规流程、认证……或者在一个更丰富多彩的语言：“也许 openSSL 会有更多问题，但我们不知道如何修复它，更不用说重写它，我们不知道我们到底在其中使用了什么，即使我们愿意，我们也没有时间这样做，而且这比处理偶尔的全球影响要花费更多的钱，所以，让我们继续盲目地过滤他们发布的任何内容，无论如何，我们将像世界其他地方一样安全。哦，嘿，我们是 ISO已认证。”某种形式的“数量安全（只要我不必做任何事情）”，作为互惠互利社区的原始开源理想主义承诺的扭曲版本。在你声称你从来不是我们中的一员之前：看着我的眼睛并发誓你向你的 OSS 上游捐款，并且你从来没有在不阅读差异的情况下合并轰炸 Dependabot PR。不，你不知道。是的，你做到了。从供应链脆弱性到供应链妥协：信任的终结 对于这一点上的读者或任何经历过过去十年的人（或任何自……检查笔记……1984 年以来一直关注的人）来说，这个行业应该是显而易见的