软件是所有现代企业的核心，在运营的各个方面都至关重要。 几乎每个企业都会有意或无意地使用开源软件，因为即使是专有软件也依赖于开源库。 OpenUK的 2022 年“开放状态”报告发现，89% 的企业都依赖开源软件，但并非所有人都清楚他们所依赖的软件的细节。
企业越来越需要有关其操作关键型软件的更多信息。 负责任的企业对他们的软件供应链非常感兴趣，并为每个应用程序创建软件材料清单 (SBOM)。 这一级别的信息至关重要，因此当在他们的软件中发现安全漏洞时，他们可以立即确定哪些软件和版本正在使用，以及哪些系统受到影响。 在这些情况下，知识就是力量！
对志愿者的依赖
2021 年末，一个名为 Log4Shell 在广泛使用的 Java 日志框架 Log4j 中被识别。 由于这是一个广泛使用的开源库，因此该漏洞得到了广泛宣传，并有望得到修复。 但是，那 该项目的维护者是志愿者. 他们有日常工作，即使有大量系统受到影响，也不会随时待命进行紧急安全修复。 据估计，仅此漏洞就影响了 93% 的企业云环境。
当时，有一些关于开源的负面新闻，但事实是，如果这是一个闭源组件，那么该漏洞可能永远不会被公开，从而使组织容易受到攻击。 该库的开源性质意味着可以对其进行检查、发现问题以及其他人提供的建议。 所以，是的，维护人员在他们的志愿者项目中没有因安全问题而随叫随到。 那么，最大的问题是：我们是如何陷入这样一种情况，即大公司依赖软件，而这些软件是由做其他事情的人负责支付账单的？
无论软件的许可证是什么，忽视软件依赖性都是一项冒险的事情，但是当它是开源的并且被广泛使用时，它就变得特别危险。 坚持一个漏洞的故事； 这个问题在代码库中已经存在多年，但没有被发现。 事实上，被如此广泛使用的工具并没有得到如此广泛的支持——而且 接下来发生的就是历史.
这个故事一遍又一遍地重复，在许多具有关键依赖关系但不采取行动支持维护者或项目本身的企业中。 拥有企业使用的软件的 SBOM 意味着他们手头有信息。 对于向他人提供软件的组织来说，在提供代码的同时提供 SBOM 的期望越来越成为常态。
了解依赖关系以评估风险
了解依赖关系可以更容易地评估与每个依赖关系相关的风险。 这些开源项目是最容易评估的：问题是否得到响应，最近是否有任何发布？ 能够查看每个项目的维护者和项目活动可以很好地了解项目的健康状况。
企业可以通过支持他们所依赖的项目来发挥自己的作用，以降低风险。 一些项目直接通过 GitHub Sponsors 计划接受赞助，其他项目可能会更喜欢提供托管或安全审计。 每个开源项目都感谢贡献。 如果您的企业自己创建了这个库，那么公司内部的工程师将不得不自己修复每个错误。
开源更像是一种共享所有权方案。 我们不必都重复构建相同的东西，而是可以做出贡献，这样既省力又能带来更好的质量。 企业可以做的最有影响力的事情之一就是利用他们的一点工程资源和 为项目的错误修复或功能做出贡献 这是业务的核心。
让您自己的工程师参与项目 有很多好处。 他们了解它并可以关注新功能或新版本何时可用。 至关重要的是，业务对依赖项目的健康和状态有深入的了解，并且是保持项目健康的一部分，从而降低了业务因依赖问题而面临的风险。 包括 Aiven 在内的许多组织都有一个 OSPO（开源项目办公室），其员工致力于为组织使用的项目做出贡献，甚至维护这些项目。 这些部门通常有助于公司在开源生态系统中的普遍存在，并使其他员工能够参与开源。
另一种方法是支持现有的支持开源的组织。 这 OpenSSF（开源安全基金会） 致力于提高开源项目的安全性，并由依赖这些项目的组织资助。 它还发布了优秀的学习资源，以便企业可以了解他们使用的软件的风险。 另一个类似的组织是 Tidelift，与维护者合作以确保满足某些基本要求，再次由组织资助。 Tidelift 还提供工具和教育，以帮助企业管理其软件供应链并采用该领域的最佳实践。
确保更安全的软件未来
企业依赖于软件，这包括开源软件，它被广泛使用并且通常比专有替代品更安全。
这是一个聪明的举动，但更聪明的举动是清楚地了解软件供应链及其依赖关系。 当确实出现问题时，取决于健康的项目并提供可用的软件详细信息可以帮助每个组织。 如果每个组织都这样做，那么发生诸如 Log4Shell 漏洞之类的事件的风险就会降低。
