2019年超过55％的开源漏洞被评为高或严重，但不要被这个数字吓到，要真正了解漏洞及其对企业或产品的威胁等级，我们需要信息的绝不只是一个冷冰冰的CVSS评分。

根据WhiteSource的《开源安全漏洞现状报告》，软件开发行业对开源组件越来越依赖,对开放源代码安全漏洞的关注度也不断提升，导致发现的开放源代码漏洞数量也逐年增加，2019年开源软件漏洞的数量呈现爆发式增长（下图）。

面对代码库中不断增多的开源漏洞，软件开发企业如何才能跟上长长的安全警报清单，确保他们能够优先修复最紧急的问题？

安全警报的优先级已成为漏洞管理的重要组成部分，许多企业都将CVSS（通用漏洞评分系统）评分作为确定其开源安全漏洞优先级的客观标准。但是，WhiteSource研究报告中的数据表明，仅依靠CVSS等级进行优先级排序对企业帮助不大。

自2005年以来，FIRST（事件响应和安全团队论坛）创建的CVSS已成为评估漏洞严重性的事实标准。在CVSS中，研究人员检查漏洞的属性、时间、影响和环境指标，以了解漏洞利用的难度以及漏洞被攻击者成功利用后可能造成的破坏程度。

多年来，随着安全社区致力于改进评分系统，CVSS不断发展和更新版本，添加了新参数，例如于2015年发布的CVSS v3增加了“范围和用户交互”指标，这些信息比CVSS v2中提供的信息更详细。在CVSS v2中，漏洞评分是基于该漏洞对主平台的总体影响，而在CVSS v3中，漏洞评分是基于对特定组件的影响。而最新发布的CVSS v3.1则旨在“明晰和改进现有标准”。

但是，虽然v3为帮助企业更好地判定漏洞的严重性提供了更细粒度的信息，但企业也应该意识到，迁移到V3.1新标准会对评分产生重大变化。

WhiteSource的研究报告分析了2016年至2019年间报告的10000多个开源漏洞的CVSS评分，以比较由CVSS v2，v3.0和v3.1三个版本的漏洞严重程度评分的变化（下图）。

资料来源：WhiteSource

数据显示，v3.0和v3.1分数明显高于v2分数。例如，在v2下一个CVSS评分7.6的漏洞在v3.x标准下的评分可高达9.8分。

将v2.0评级标准与v3.0评级标准进行比较，可以部分解释这一巨大变化：

资料来源：WhiteSource

从以上对比可以看出， CVSS v3.x的漏洞分数普遍较高于之前的版本，通过比较CVSS v3漏洞的严重性评分的分布，我们可以更好地了解威胁性较高（High）和严重（Critical）的开源漏洞分布。

资料来源：WhiteSource

2019年的数字表明，2019年开放源代码漏洞增加了50％，超过55％的CVE被评为高或严重。这意味着不仅更多的CVE被归类为高危和严重漏洞，此类漏洞的总量也在增加。

CVSS v3.1版本首次强调其评分衡量的是漏洞的严重性而不是风险。而CVSS的最新定位是：为用户提供更全面、更精确的上下文，以及对漏洞严重性评分的共享理解，允许更多用户利用该信息。但是数据显示，虽然计分方法的不断发展，但是开发人员和安全团队依然使用有限的优先级工具来处理大量高严重性漏洞。

漏洞严重性评分分布不平衡（高危漏洞占比高）的原因有很多。例如安全社区对高危问题更加关注，以及CVE创建过程较为困难和耗时，导致威胁性较低的漏洞被排除在CVE之外。那么问题来了，开发和安全团队如何解决这种不平衡？

随着安全形势的不断发展，我们知道，要真正理解漏洞及其对企业或产品的影响，一个评分数字是远远不够的。例如，一个评分很低的胰岛素泵漏洞，却有可能危及生命。同时，一个漏洞的严重程度和优先级还与漏洞暴露时间、武器化进度和利用难度等诸多因素相关。

V3.1基于这样的理解，即不应将CVSS分数视为唯一参数。在评估我们资产中的安全漏洞风险时，需要考虑诸如脆弱性的依赖关系或网络架构和配置等因素。

DevSecOps团队需要在漏洞评估中将企业的软件清单、云环境和网络结构都考虑在内，基于风险和威胁实施高效漏洞管理，不要过于依赖 CVSS 来决定漏洞修复的优先级。CVSS是风险评估的一个重要变量，但并不能代表风险本身。

安全牛《2020高效漏洞管理指南》现已开始接受预订，预订邮箱：[email protected]，邮件主题关键词：高效漏洞管理。

参考资料

WhiteSource开源漏洞现状报告：

https://resources.whitesourcesoftware.com/research-reports/the-state-of-open-source-vulnerabilties-2020

相关阅读

不要继续将 CVSS 得分当做风险评分

给漏洞打分 介绍一下CVSS与Tripwire的差异