知名开源作者呼吁对软件供应链进行验证，而非盲目信任

在 2026年3月发布的一篇博文 "中，curl创建者兼首席开发人员Daniel Stenberg指出，软件行业默认信任知名组件的做法已经不再适用。Stenberg认为，用户和组织应主动验证所使用的软件，并以curl自身的实践为例，具体说明了如何做到这一点。 据估计，curl运行在数百亿台设备上，是现存部署最广泛的软件组件之一。Stenberg列举了多种可能导致这样一个大项目遭到破坏的场景，包括恶意贡献者合并受污染的代码、遭入侵的提交者无意中分发了经过篡改的版本、受勒索的团队成员进行超出预期的修改，或是被黑客入侵的分发服务器提供经过篡改的tar包。他指出，这些场景可能独立发生，也可能在短时间内接连发生，而对于curl这样覆盖面特别广的项目，一旦攻击得手，后果将十分严重。 软件和数字安全应当基于验证，而非信任。我强烈建议更多的软件用户和消费者对curl进行验证。理想情况下，还应要求大家对依赖链中的其他软件组件至少进行同等程度的验证。—— Daniel Stenberg Curl项目已经实施了一套全面的管控措施，旨在使Git存储库成为权威且可审计的事实来源。这些措施包括：强制使用统一的代码风格、禁止使用某些被认为难以安全使用的C函数、设定函数复杂度上限、要求对所有拉取请求进行人工和自动审查，以及禁止二进制Blob和绝大多数base64编码内容的使用——这两者都可能被用于隐藏恶意有效载荷。Stenberg还描述了在每次提交时运行的200多个持续集成任务，它们采用将警告视为错误的严格编译器设置进行构建；通过谷歌的OSS-Fuzz项目持续进行模糊测试；对所有提交者强制实行双因素认证。每项措施都旨在让关注该项目的人一眼就可以看出任何偏离预期的行为。 除了这些内部控制措施外，Stenberg还主张建立一个更广泛的验证生态系统。他解释说，该项目在curl网站上提供了经过签名的发布工件以及一个专门的 验证页面 "，以便独立用户能够核查发布版本是否仅包含git存储库中的内容，以及是否由发布经理签名。他承认，自己无法得知这些用户的身份，也无法确定他们是否确实存在，但他认为，即使只有少数的独立验证者，也足以提供有意义的核查：一旦发现任何异常，其中任何一位都能发出警报。 如果哪怕只有少数用户能证实他们收到了由curl发布管理员签名的curl发布包，并且确认该发布包的内容未被篡改，并且仅包含源自git存储库的代码，那就相当不错了。—— Daniel Stenberg 在文章末尾，Stenberg直接建议对所有依赖项都进行此类验证，并指出“软件和数字安全应基于验证，而非信任”。2025年4月之前的社区讨论从多方面呼应了这一立场。在LinkedIn上，安全和平台工程领域的从业者指出，2024年发现的XZ Utils后门事件——长期通过可信贡献者植入恶意代码——揭示了基于声誉的信任所存在的局限性。要了解更多信息，可以查阅 Cameron Stihel的这篇博文 "和 Ryan Johnston的这篇博文 "。该攻击通过长期贡献赢得维护者的信任，随后在liblzma组件中植入代码变更。这正是Stenberg在其威胁载体清单中描述的典型场景。 目前，用于精确描述软件构成的结构化工具之一是软件物料清单（SBOM）。在 InfoQ关于2026年伦敦QCon大会演讲的报道 "中，sbomify创始人Viktor Petersson指出，团队采用SBOM的时间已经所剩无几。他提到了《欧盟网络弹性法案》（CRA）。该法案将于2026年9月开启首个执法窗口，并要求在2027年12月前全面符合SBOM标准，同时警告说后果远不止罚款：“CRA的重点不在于罚款。实际上，它可能导致销售受阻。你的产品可能会被禁止进入欧洲市场。”自2021年起生效的美国第14028号行政令，将SBOM作为向联邦政府销售软件的采购条件，而美国食品药品监督管理局（FDA）也要求医疗设备必须提供SBOM。 Petersson的演讲涵盖了SBOM生成的全生命周期，包括大多数团队都会跳过的步骤：签名。他直言不讳地指出，这是个错误，并且强调，具体使用的工具甚至不如签名这一行为本身重要，因为签名能提供可验证的溯源链。Petersson直言道：“任何签名都比不签名好。请务必在你的构建管道中对SBOM进行签名，而不是在某人的机器上。”这与Stenberg的论点直接相关：curl 已经提供了经过签名的发布工件，并清晰而详细地说明了验证步骤，从而为使用者提供了Petersson称之为目标的溯源链。 CI/CD管道也是一个潜在的薄弱环节。 InfoQ曾报道过 "，2025年4月，一个广受欢迎的GitHub Action遭到入侵。从这个事件可以清晰地看到，单个恶意操作或遭到入侵的操作如何同时泄露多个项目的机密信息和构建产物。该事件进一步强化了以下呼吁：加强对第三方操作的管控，将依赖项固定到特定的提交哈希值，并监控CI工具中的意外变更。Stenberg的方法直接解决了这一问题：curl CI任务被配置为仅以只读方式访问源代码存储库，并使用zizmor工具进行检查，降低了不安全任务配置的风险。 Petersson还提到了生命周期方面的挑战。他指出，一款实际的产品通常包含数十份SBOM，它们在每次运行持续集成（CI）时都会发生变化，而监管机构可能会要求提供特定历史版本的SBOM。他将当前的做法比作版本控制出现之前的软件开发：“如今处理SBOM的感觉，就像90年代通过电子邮件发送补丁来管理源代码一样。”这一治理问题印证了Stenberg提出的更广泛的观点。生成、签名和验证软件工件的工具已经有了，而使用这些工具的监管压力正在加大，因此，组织应通过验证其所使用的软件来实现闭环管理。 原文链接： https://www.infoq.com/news/2026/05/stenberg-curl-verification-trust/ "