开源改变了软件世界，通过实现跨产品和行业的广泛重用，极大地降低了引入新技术的成本。但是，从开源中提取代码就会发现，它们来源非常分散。

当组织没有考虑对其所依赖的开源库的长期支持问题时，最坏的情况下很可能影响其软件的安全问题。2021年底一系列log4j漏洞就是一个很好的例子。组织应该在利用开源便捷的同时，花时间仔细考虑他们的供应链安全问题，为未来潜在的安全事件做好准备。

开源并非完全免费

来自多个来源的代码带来了安全挑战，组织并不总是能够处理甚至意识到这些挑战。供应链可能非常复杂，由一个巨大的开源依赖树组成，所有依赖都定期更新。当上游开源软件更新或更改时，IT 团队通常不会审核系统中的每一行代码。由于依赖关系网络、不断变化以及 IT 团队缺乏深入评估，外部安全威胁应该是一个非常值得关注的问题。

不管最初谁应该为这些漏洞负责，企业在发布包含漏洞开源代码的软件时都面临着责任。如果没有适当的流程来审查开源组件的包含和更新，组织将继续陷入使用开源组件的陷阱，而不了解他们所承担的风险。此外，随着软件世界的不断发展，容器化等新技术将使安全态势更加遥不可及。

一旦公开开源项目中的漏洞，组织可能需要在紧迫的时间里审计相关软件的安全性。这很可能拉低开发效率，因为要么审核成千上万行代码，要么进行最新版本升级。

保持开源安全

建议IT领导在项目开始之前建立安全措施，重点关注威胁及风险的缓解。确保对新的开源依赖项进行安全审查，如使用SCA工具等在开发期间即可进行，并定期更新这些依赖项以降低未来发生安全风险的几率。及时检测及定期维护非常重要，因为你无法修复不知道的漏洞和问题，并且尽快修复比查找历史缺陷更容易。

DevSecOps 发挥作用的地方正是在这里，在软件开发期间解决安全问题，不但可以降低成本，而且有助于打破部门之间的障碍。

首先，团队需要理解在他们的环境中部署了什么软件，假设他们从一开始就没有为材料清单编制文档。这可能很困难，因为现代软件堆栈中有许多依赖层。例如，大多数容器漏洞扫描器都仅限于通过操作系统包管理器安装的包(例如apt或yum)。在设计上，这遗漏了许多依赖项，比如静态链接的二进制文件、手动安装的包、编程语言依赖项等等。

其次，团队需要使依赖项保持最新。虽然这可能会对开发人员的时间和资源造成压力，但这种持续关注安全事项的成本肯定比团队在意外破坏时所需的成本要低得多。部分企业当前已经在使用静态应用安全测试工具SAST或开源组件成分分析等协助发现安全问题。

当团队采取适当的措施来评估和指导开源依赖性的安全问题时，可以显著降低软件供应链风险，对安全隐患的关注和审查可以提前避免风险，同时提高开发人员安全意识。

文章来源：

https://www.helpnetsecurity.com/2022/01/26/code-open-source/

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)