在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 提出的更广泛的观点。生成、签名和验证软件工件的工具已经有了，而使用这些工具的监管压力正在加大，因此，组织应通过验证其所使用的软件来实现闭环管理。