随着开发团队竞相跟上软件生产的竞争步伐，开源组件已成为每个开发人员工具箱中不可或缺的一部分，帮助他们以 DevOps 的速度创建和交付创新产品。
开源使用率的持续上升，以及像 Equifax 漏洞利用开源组件中的漏洞这样引人注目的数据泄露事件，可能最终让组织准备好管理开源安全并解决开源漏洞的狂野西部。 但问题是，他们是否知道从哪里开始。 （要了解更多信息，请参阅定性与定量：是时候改变我们评估第三方漏洞严重性的方式了吗？）
无处不在的开源
WhiteSource 最近发布了开源漏洞管理状态报告，以提供见解，帮助组织更好地了解如何处理开源安全问题。 根据该报告，其中包括对来自美国和西欧的 650 名开发人员进行的开源使用情况调查的结果，高达 87.4% 的开发人员“经常”或“一直”依赖开源组件。 ” 另有 9.4% 的人回答说他们“有时”使用开源组件。 值得注意的是，只有 3.2% 的参与者回答说他们从不使用开源，这很可能是公司政策的结果。
这些数字毫无疑问地清楚地证明，从事软件项目的开发人员最有可能利用开源组件。
开源漏洞：结果出来了
该报告还深入挖掘了 WhiteSource 开源数据库，该数据库汇集了国家漏洞数据库 (NVD)、安全公告、同行评审漏洞数据库和流行的开源问题跟踪器，以了解开发团队需要的开源漏洞 去处理。
结果显示，已知的开源漏洞数量在 2017 年创下历史新高，接近 3,500 个漏洞。 与 2016 年相比，披露的开源漏洞数量增加了 60% 以上，而且这一趋势在 2018 年没有放缓的迹象。
他们中最脆弱的是什么？
该研究还深入研究了数据库，以寻找最易受攻击的开源项目，并得出了令人惊讶的结果。 虽然 7.5% 的开源项目存在漏洞，但在前 100 个最受欢迎的开源项目中，有 32% 的项目至少存在一个漏洞。
虽然一个漏洞足以让多个库面临风险，但一个易受攻击的开源项目平均包含八个漏洞。 这意味着最受欢迎的开源项目通常也是漏洞高发的项目。
当我们查看开源漏洞数量最多的前 10 个开源项目列表时，这种洞察力会变得更加清晰。 前 10 名列表包括我们许多人都在使用的非常流行的开源项目。
这些项目有不止一个共同点：它们中的大多数都是面向互联网的前端组件，具有广泛的攻击面，非常容易暴露，这使得它们相对容易被利用。 这就是为什么它们吸引了很多开源安全研究社区的关注。
许多这些项目的另一个共同点是大多数都得到了商业公司的支持。 考虑到它们背后的利害关系和资源，有人可能会问：由如此大的参与者支持的项目怎么会如此脆弱？
开源漏洞的狂野西部
过去，开源漏洞的发现会引发一场关于开源组件是否维护得足够好以供安全使用的激烈辩论。 令人高兴的是，那些日子已经过去了，今天我们知道，报告的开源漏洞的增加表明开源社区和安全社区正在迅速响应以跟上威胁形势。
开源社区的指数级增长，以及后来在广受欢迎的组件中发现臭名昭著的开源漏洞（例如那些让 Heartbleed 蓬勃发展的组件），已经提高了人们对开源安全性的认识，并且一大批研究人员分析了开源 漏洞的项目，以及修复的快速周转。
事实上，WhiteSource 报告发现，在所有报告的漏洞中，有 97% 在开源社区中至少有一个修复建议，安全更新通常在漏洞发布后的几天内发布。 （有关开源的更多信息，请查看开源：好得令人难以置信？）
开源社区处于安全之上——现在用户需要跟上
虽然开源社区在提高开源安全性方面的协作和努力在漏洞发现、披露和快速修复方面肯定会显示出成果，但由于开源社区的去中心化性质，用户很难跟上。
当开发人员使用商业软件组件时，版本更新是他们付费服务的一部分，供应商可能会非常努力地确保您看到它。
这不是开源的工作方式。 WhiteSource 数据显示，只有 86% 的已报告开源漏洞出现在 CVE 数据库中。 这是因为开源社区的协作和分散性质意味着有关开源漏洞的信息和更新会在数百个资源中发布。 此类信息无法手动跟踪，尤其是当我们考虑开源使用量时。
如何在开源安全方面取得领先
考虑到开源使用的普遍程度，开源漏洞的持续增加是组织必须正面应对的挑战。 虽然大量的开源漏洞（包括最流行的项目）可能看起来势不可挡，但学习社区管理开源安全的方式是朝着正确方向迈出的一步。
下一步是接受开源安全管理附带一套不同于保护商业或专有组件的规则、工具和实践。 坚持使用相同的漏洞管理程序和工具无助于开源安全管理。
采用解决这些差异的开源安全策略并结合正确的技术来自动化他们的管理将帮助安全和开发团队直面开源漏洞的独特挑战，使他们能够重新开始构建优秀软件的业务。
