行业新闻与博客

根据 Synopsys 2020年开源安全和风险分析报告，过时或废弃的开源组件几乎在所有商业软件中都存在，从而使企业和消费者应用程序面临安全问题，许可证合规性违规和操作威胁的 风险。

Synopsys 研究人员分析了 1,250 多个商业代码库。Synopsys 网络安全研究中心（CyRC）检查了黑鸭审计服务团队执行的代码库审计。

该报告重点介绍了商业应用程序中开源使用的趋势和模式。它提供了见解和建议，以帮助组织更好地管理其软件风险。

2020 OSSRA 报告重申了开源在当今软件生态系统中的关键作用。

Synopsys 发现，在过去的一年中，经过有效审核的代码库中有 99％至少包含一个开源组件。开源占整体代码的 70％。

该报告强调了陈旧或废弃的开源组件的继续广泛使用，这些组件已经过时四年以上，或者在过去两年中没有开发活动。

Synopsys 首席安全策略师 Tim Mackey 表示：“很难消除开源软件在现代软件开发和部署中的重要作用，但很容易从安全和许可证合规性的角度忽略开源软件如何影响您的应用程序风险态势。”网络安全研究中心。

他告诉 LinuxInsider，《 2020 OSSRA 报告》强调了组织如何努力有效地跟踪和管理其开源风险。这场斗争涉及维护准确的第三方软件组件清单和开源依赖项。

他说：“保持最新状态是从多个层面解决应用程序风险的关键起点。”

主要发现

据 Synopsys 称，今年分析中最令人担忧的趋势是不受管理的开源所带来的日益严重的安全风险。代码审计显示，百分之七十五的代码库包含具有已知安全漏洞的开源组件。

这个数字高于去年报告中的 60％。同样，49％的代码库包含高风险漏洞，而 40％的代码库包含高风险漏洞。

开放源代码采用率的不断提高，使人们对商业软件中不受管理的开放源代码的警觉性增加。

根据今年的 Syopsys 报告，百分之九十九的代码库至少包含一些开源代码，每个代码库平均有 445 个开源组件。这与 2018年发现的 298 个开源组件相比有了显着增加。经过审核的代码中有 70％被确定为开源，这个数字从 2018年的 60％增长到 2015年的 36％几乎翻了一番。

轮班时间

Mackey 认为，与去年的分析相比，今年的报告揭示了一些出乎意料的发展，表明了好坏。

他说：“我们看到了整体安全趋势的变化，同时，有证据表明治理流程无法跟上使用率的增长。”

好消息是，这是审计工作第一年没有在基础数据中看到 HeartBleed 漏洞。这表明，尽管仍然存在着长长的尾巴，但无论是重构工作还是仅仅是对高影响力漏洞的更深入了解都正在硕果累累。

在坏消息方面，随着开放源代码使用量的增加，未修补的漏洞的增加说明了对手动流程的依赖。Mackey 解释说，这是在漏洞披露由于其他报告权限而增加的时间点。

最终结果是，没有自动化解决方案以过滤出不适用于他们的 CVE 的企业被迫测试由于应用程序或系统组成而可能无法利用的披露。

风险趋势

通过代码审核发现的最值得关注的开源风险趋势的摘要发现以下内容：

百分之九十一的代码库包含的组件或者已经过期超过四年，或者在过去两年中没有开发活动。

除了存在安全漏洞的可能性增加之外，使用过时的开源组件的风险还在于更新它们也会带来不必要的功能或兼容性问题。

易受攻击的开源组件的使用再次呈上升趋势。在 2017年至 2018年期间，包含易受攻击的开源组件的代码库所占比例从 78％下降至 60％之后，在 2019年上升至 75％。

同样，包含高风险漏洞的代码库百分比从 2018年的 40％跃升至 2019年的 49％。

臭名昭著的 Heartbleed 错误或 2017年困扰 Equifax 的 Apache Struts 漏洞没有对 2019年审核的代码库产生影响。

威胁知识产权，许可

报告称，大量持续使用不受管理的开源组件也使知识产权面临风险。尽管开源软件享有免费的声誉，但与商业代码一样，开源软件仍受许可证的约束。

研究人员发现 68％的代码库包含某种形式的开源许可证冲突。33％包含没有可识别许可证的开源组件。

报告总结说，安全漏洞是一个主要问题。将近一半的代码库包含高风险漏洞。

这些漏洞中约有 73％使代码库所有者面临可能的法律问题。开源组件的许可证似乎与代码库的整体许可证冲突，或者根本没有许可证。

报告称，许可证冲突的发生率因行业而异。

这些冲突的范围从互联网和移动应用程序的最高 93％到虚拟现实，游戏，娱乐和媒体应用程序的最低 59％。

关于报告

这是 Synopsys 的《开源安全和风险分析报告》的第五版。它提供了商业软件中开源安全性，合规性和代码质量风险的当前状态的深入快照。

其结果基于 Synopsys 的开源审核服务团队在 2019年审查的匿名数据。出于此代码审核的目的，Synopsys 定义了代码库作为应用程序，服务或库的源代码和库。

研究人员将托管软件定义为已识别和跟踪的软件组件的来源，年龄，许可和版本信息。研究人员还研究了已应用或缺少的更新以及安全补丁。

报告要点

2020 OSSRA 报告总结说，组织需要更好地维护开源组件。该代码是他们构建或使用的软件的关键部分。

Mackey 说：“我们继续建议企业在自动化方面进行投资以创建准确的库存，但真实情况是其中之一。” “开发，企业 IT 和企业法律团队需要定义一个开源使用流程。”

不再建议下载开源组件，程序包或解决方案并简单地使用它。他补充说，如果对该下载进行了不正确的管理，那么它将使企业面临与任何商业软件一样的治理挑战。

关键区别在于律师没有商业实体可以依靠来解决。该修补程序将需要来自支持该组件的开源社区，或者来自本地开发团队，后者最好将其修复程序提交给社区。

Mackey 说：“无论哪种方式，如果社区参与不是流程的一部分，那么要保持补丁兼容状态就变得更加困难。”

更差或更安全？

Mackey 表示，OSSRA 报告并未考虑开源软件的整体安全性。相反，它着眼于在商业环境中使用时的管理程度。

他说：“话虽如此，我们确实对数据集中发现的一些突出漏洞进行了更深入的分析，以更好地了解核心风险是什么。”

开源软件安全性提出了新的挑战。SaltStack 的首席技术官 Thomas Hatch 表示，专有软件通常包括开源软件，这是非常普遍的，几乎是通用的 。

他告诉 LinuxInsider：“还必须记住，专有软件随附的开源软件的版本可能无法可靠地公开或完全不公开。要追踪它几乎变得不可能。”

开源软件更安全的最初观点是，许多人可以带来更多的修复程序。但是，哈奇指出，这种主张似乎并不能说明小型开源项目在现代的泛滥。

他说：“今天开放源代码太多，审核变得越来越困难。我要说的是，今年开放源软件的安全状态比去年更糟。”

在重大项目不断完善的同时，整体格局的增长远远超过了跟踪功能。Hatch 说，该报告非常有用，但作为正在进行的发现项目，它的功能甚至会更强大。

有用不徒劳

Mackey 保证，年复一年发布此类报告具有真正的纠正目的。

他解释说，当公司在五年前发布 OSSRA 报告时，企业领导者们确实缺乏对开源活动对其整体运营的影响的意识。

那是许多高调利用开源漏洞的背景。五年后，法规要求的复杂性随着开源的增长而增加。

OSSRA 报告基于通过并购获得的商业应用程序。Mackey 说，基础数据为开源提供了一个视角，而对开发团队的简单调查或其他轻量级数据收集无法获得这种视角。

DevOps 安全需求

Synopsys 的 2020 OSSRA 报告提供的高级别趋势的良好指标，根据阿里 Golshan，首席技术官 StackRox。但是，公司在决策过程中应该考虑的因素更多，尤其是与开源安全性有关的决策。

他对 LinuxInsider 表示：“随着 DevOps 实践与开源解决方案的结合使用，导致与云相关的技术的部署变得更加广泛，与开源相关的风险问题变得越来越动态。”

Golshan 指出，整个攻击面正在云原生空间中发生重大变化-从传统的攻击和运行时攻击，转向专注于整个构建过程中暴露的更大的攻击面。

他警告说，从操作角度来看，将云原生技术与开源组件结合使用可能会带来优势，而从安全角度来看却具有挑战性。“应该将类似 Synopsys 的报告视为一个很好的提醒，以便更仔细地研究如何保护构建过程。”

本文由机器译制