开源代码带来的10大安全和运营风险

Endor Labs 引入了OWASP风格的清单，列出了使用开源软件 (OSS) 中固有的最重要或影响最大的风险。

OSS 的使用实际上是免费的，而且随时可用——它满足了软件开发中对速度和低成本的商业需求。超过 80% 的现代应用程序代码来自 OSS 的情况并不少见，因此它会一直存在（至少在某些新技术可以提供更快但仍然便宜的软件开发之前）。

这里的问题是我们对我们使用的开源的来源知之甚少。它没有保证或 SLA；我们通常不知道这个开发工具的开发者；它可以在我们不知情的情况下引入重大安全风险（想想Log4J）。

Endor Labs 是一家总部位于加利福尼亚州帕洛阿尔托的初创公司，由 Dimitri Stiliadis（首席技术官）和 Varun Badhwar（首席执行官）于 2021 年创立，是一家专注于在商业应用程序开发中越来越多地使用 OSS 所包含的复杂性和威胁的公司。

其 Station 9 研究团队现已开发并发布了一份关于十大开源软件风险的报告。希望是为 OSS 效仿OWASP Top Ten 为 Web 应用程序安全提供的内容。它按严重程度列出了十个最重要的风险（安全和/或操作），提供了描述、示例、补救措施和进一步的参考来源。与 OWASP 列表一样，它将随着个别风险的变化或严重程度被新风险取代而得到维护。

不出所料，当前排名第一的风险是“已知漏洞”。Endor 描述指出，“组件版本可能包含易受攻击的代码，由其开发人员意外引入。漏洞详细信息已公开，例如通过 CVE。漏洞利用和补丁可能可用也可能不可用。” 这里值得注意的是 Rapid7 的研究指出，56% 的 CVE 漏洞在公开披露后的 7 天内被利用。

其余九种风险是：

• 合法包的妥协，例如，攻击者可能会注入恶意代码以利用供应链攻击该代码的用户
• 名称混淆攻击，类似于基于 Web 的攻击中的拼写错误抢注
• 未维护的软件，其中的组件可能在不知不觉中不再得到维护或支持
• 过时的软件，即使可能有更新的版本，但仍在使用旧版本，
• 未跟踪的依赖项，可能是因为它不是上游 SBOM 的一部分
• 许可证和监管风险，例如，许可证可能与下游消费者的预期用途不相容
• 不成熟的软件，OSS项目开发可能不符合开发最佳实践
• 未经批准的更改，组件可能在开发人员不知情的情况下更改
• 依赖性过小或过大，在后一种情况下，组件可能会提供很多功能，但只能使用其中的一小部分

当然，OSS 风险远不止十种。“如果情况发生变化，我们可能至少每年都会更新这份名单。几年，什么都不会改变；几年之后，”Badhwar 告诉SecurityWeek。

您可能认为引入 SBOM 是为了为应用程序开发人员解决这些问题，但 SBOM 几乎是独一无二的，它是一项领先于行业实践而不是落后于行业实践的法规。“业界还没有为 SBOM 做好准备，”Badwahr 说。自动生成通常不准确且不完整。“如果我们要转向使用 SBOM 作为我们风险分析的无可争议的事实来源，我们需要解决这些问题。今天情况并非如此。”

尽管 OSS 生态圈对许多正在使用的商业应用程序很重要，但它的脆弱性也值得考虑。Badwahr 指向 Core-JS。“Core-JS 是互联网的基石。选择任何互联网应用程序，你都可以确定它使用了 Core-JS。”

但是 Core-JS 由俄罗斯的 Denis Pushkarev 维护。他靠它过着相对微薄的生活——直到现在。西方对俄罗斯的财政捐助受到了西方货币制裁的打击。根据 The Stack 的一份报告，他被迫考虑替代方案，包括将其封闭源代码和商业化。 

事实上，OSS 生态圈的可持续性取决于其贡献者的可持续性，而这与地缘政治的未来一样难以预测。Endor 希望对主要 OSS 风险的列举能够帮助应用程序开发人员将注意力集中在使用开源软件所涉及的风险上——包括突然无人维护的软件（风险 #4）。