当涉及漏洞分类时,放弃CVSS并优先考虑可利用性

在软件安全方面,当今开发人员面临的最大挑战之一是信息过载。在一定程度上要归功于开源代码的广泛传播和使用( 学习 Red Hat的研究表明,在接受调查的组织中使用的软件中有36%是开放源代码的),以及普通应用程序日益复杂的情况,现在可以预期一个给定项目具有大量依赖项。反过来,这些依赖关系中的每一个都代表了潜在的机会,如果没有适当地保护,就可能出现漏洞。

漏洞分类

由于这种情况,开发人员面临着新的挑战。扫描工具生成的自动漏洞报告将返回数百个(甚至不是数千个)漏洞,并且许多组织都报告缺乏熟练的网络安全专业人员,因此团队的工作人员已经太少而无法修复。快速修复扫描发现的每个漏洞的可能性是不可行的。

为了解决这个问题,开发人员和安全专业人员传统上依靠漏洞评分系统来帮助他们确定最关键的漏洞的优先级, 简化补救工作。尽管这是一种以更少的漏洞更快地发布软件的好方法,但是这种方法过于简单。在进行分类工作时,可利用性是一个更为重要的基准。

为什么传统计分系统不再足够

自动扫描返回的大量漏洞并不是一个新问题。实际上,开发人员通常将其视为安全性的障碍。为了尝试过滤这些大数据集,开发人员进行了漏洞分类,在此漏洞中,他们按照对应用程序安全性或功能性构成的风险来对已检测到的缺陷进行分类。然后,开发人员可以修复似乎最迫切的漏洞,以便更快地发布软件。

目前,许多开发人员都依赖通用漏洞评分系统(CVSS)。该系统代表了评估漏洞严重性的基本标准。分数范围从0到10,其中10是最高分(表明严重程度最高)。开发人员通常会将CVSS分数分配给他们检测到的漏洞,并按从高到低的顺序排序,将精力集中在得分最高的漏洞上。

不幸的是,这种方法不是最理想的,最终导致疏忽和“安全”代码较少。

涉及漏洞修复时,请勿成为foo()

充分利用安全扫描工具的大部分归功于开发人员对扫描检测到的漏洞进行分类的方法。开发人员不应关注CVSS评分所确定的严重性,而应通过关注其为可利用性提供的潜在途径来优先考虑漏洞。

那么,对漏洞的利用到底意味着什么?有两个核心因素:

  • 必须从用户代码中直接或间接调用库中易受攻击的方法
  • 攻击者需要精心设计的输入才能找到触发漏洞的方法

作为说明这一点的示例,请设想一个场景,该漏洞是由正在使用的库中的foo()方法触发的,但是在检查时确定该代码本身实际上根本没有调用foo()。这是一个表面上似乎很严重的漏洞的示例,但是从上下文的角度考虑,它并没有提供利用漏洞的真实途径。有了这些知识,开发人员就可以继续为其他实际可利用的漏洞修复此漏洞。

采取整体方法评估剥削可能性

现代开发人员配备了完整的代码库,可用于数十种单一API方法。此外,他们使用的库还有其他第三方库本身,它们仅部分使用可用的API。这意味着,如果在应用程序的依赖项中检测到漏洞,则实际被利用的可能性可能低于5%。对于试图保护软件并保持效率的开发人员来说,这具有许多重要的意义:

  • 当前的优先级排序方法集中在错误的区域,并且花费了宝贵的时间来修复可能甚至无法利用的漏洞
  • 本质上,无法利用的漏洞是误报。如果攻击者无法达到给定的代码流,则可以安全地忽略其他更紧迫的问题
  • 尽管扫描返回了软件中似乎无法克服的漏洞列表,但扫描后需要修复的真实漏洞数量明显低于当今通常理解的数量。

通过利用可以分析项目源代码以及所有使用过的软件包的源代码的自动扫描工具,在检查调用图形和数据流时,可以真正评估可利用性和风险。

漏洞分类:通过可利用的路径快速提供安全性

开发人员面临着许多挑战,既需要更快的软件交付速度,又要在完成的代码中提供更好的安全性。结果,我们看到了开源代码和自动漏洞扫描技术的增长和采用。但是,尽管这些工具具有重要的用途,但漏洞分类在软件开发中同样至关重要,在该软件开发中,可能会丢失或获得敏捷性。

迄今为止,更常见的分类策略是利用CVSS评分,但是可利用的路径哲学提供了可以帮助实现更高效率的不同选择。

通过将精力集中在那些对软件安全性构成真正威胁的漏洞上,开发人员可以大大减少需要解决的错误的数量。这种方法不仅可以加快交付速度,而且还可以使开发人员更加放心,他们可以确定那些具有实际开发途径的漏洞已得到修复。

分享这个