Molet

为什么代码安全扫描还不足够

Molet 安全防护 2023-01-02 409浏览 0

为什么代码安全扫描还不足够

2017年3月, Equifax公司服务器存储的1.4亿人的敏感信息被盗。这是怎么发生的?

Equifax公司使用Apache Struts框架来运行其网站。2017年3月初,Apache公司在Apache Struts中发现了一个安全漏洞(CVE-2017-5638),并于3月7日发布了一个安全补丁来修复上述漏洞。

3月9日,Equifax公司管理员收到通知为受到影响的软件打好补丁,但他们没有这样做。3月12日,网络攻击者获得了对Equifax公司内部服务器的访问权限,从而发生了历史上规模最大的一次数据泄露事件。

本文将探讨如何通过一些步骤控制代码质量,并在文中简要描述安全扫描过程。然而,这次探讨的不只是如何对代码进行安全扫描,而是对依赖项的扫描。

第三方依赖项有什么问题

人们需要了解软件行业中第三方组件的使用情况。以下是开源技术提供商Black Duck公司对1000多个商业代码库进行审计的主要发现:

  • 96%的扫描应用程序包含开源组件。
  • 在2017年,开源代码的使用率从36%增加到57%。
  • 每个应用程序的开源组件平均数量为257个。

此外,根据Veracode公司的调查:

  • 应用程序由多达90%的开源代码组成。
  • 开发人员在2017年下载了520多亿个Java组件(以及120亿个Docker Hub组件)。
  • 开源软件的使用量在过去5年中增加了5倍。

很明显,如今的软件主要是由开源依赖项构建的,而第三方依赖项的数量在未来将会增长。

(1)应用程序安全风险

不幸的是,随着第三方依赖项越来越多,在软件中引入安全漏洞的风险也在增加。

开源的全球性安全组织OWASP在2013年就意识到了这个问题,并将“使用具有已知漏洞的组件”项目添加到OWASP的10大应用程序安全风险的列表中。

组件(例如库、框架和其他软件模块)以与应用程序相同的权限运行。如果利用易受攻击的组件,可能会导致严重的数据丢失或服务器接管。使用具有已知漏洞的组件的应用程序和API可能会破坏应用程序的安全防御,并遭遇各种网络攻击和不良影响。

这并不意味着开源软件比专有组件风险更高,不必避免使用它。那么,这种风险有多大?根据Veracode公司发布的软件安全状况报告,其风险相当高:近88%的Java应用程序在组件中至少存在一个漏洞。

在讨论解决这个问题之前,先检查一下运行一个简单的Spring Boot应用程序需要多少依赖项。

(2)Spring Boot应用程序依赖项示例

使用Spring初始化程序生成了一个Spring Boot项目示例,其中包含一些流行的依赖项,如下图所示:

为什么代码安全扫描还不足够

Spring Boot初始化示例项目设置:

为什么代码安全扫描还不足够

因此,对于Spring Boot应用程序示例,需要额外的55个JAR(37MB)才能使应用程序成功启动和运行。此外,JAR的数量取决于想要使用的附加功能/工具,它可能会变得更大。

例如,在目前正在处理的一个项目中,有262个依赖项。然而,大量的第三方依赖使得整个安全检查过程非常困难。为什么?先了解一下如何检测人工检依赖项没有已知的安全漏洞。

(3)第三方依赖扫描过程

以下人工依赖项检查过程的步骤:

首先,收集给定的依赖识别信息(例如供应商、产品和版本)以构建通用平台枚举(CPE)。例如,org.springframework:spring-core:5.2.0.RELEASE的CPE将是cpe:/a:pivotal_software:spring_framework:5.2.0

其次,使用上一步中的标识符搜索NVD等常见漏洞和暴露(CVE)数据库,并检查给定依赖项是否存在任何漏洞。

然后,重复前两个步骤55次(在这个示例中)

所以,看起来没那么糟糕。在此忽略以上述方式进行依赖项扫描需要一些时间并且需要人工进行的事实。真正的问题是新的漏洞可能随时出现在CVE数据库中。

用户不能仅仅因为过去检查过它们,就假设其依赖项将永远安全。这意味着必须在开发/测试阶段以及软件在生产中运行时检查其依赖项。

自动依赖项扫描

依赖项检查是客户必须定期做的事情。此外,需要检查已经发布的软件的依赖性,以便可以在客户发现软件中的安全漏洞之前准备一个补丁版本。

这并不是什么不寻常的事情。世界各地的公司越来越关注软件安全。

以下了解是否有任何工具可以帮助保持依赖项免受漏洞影响。

以下是Java世界中两个最流行的工具,它们使用户能够快速轻松地检查漏洞数据库的依赖关系:

  • WASP Dependency-Check——这是一种简单的工具,用于扫描Java和.Net应用程序以识别已知易受攻击的依赖项的使用情况。可以将OWASPDC用作独立的命令行工具。此外,可以将其与最喜欢的构建工具(Maven/Gradle)集成或将其用作持续集成(CI)/持续交付(CD)管道中的一个步骤(例如Jenkins)。
  • Snyk Open Source ——该工具比OWASPDC先进得多(但是它每月只对数量有限的扫描免费)。它不仅扫描应用程序依赖项并显示潜在问题。该工具可以优先考虑最值得修复的问题并建议自动更新,因此检查应用程序代码是否可以访问易受攻击的功能,并检查是否在运行时调用了漏洞。

简而言之,这些工具可以帮助列出应用程序中的第三方依赖项,并指出存在已知漏洞的依赖项。此外,它们还提供了有关其发现严重性的信息。

但是,并非每个安全漏洞都会对应用程序造成风险。例如,可能根本没有在代码中使用受影响的功能。这当然需要更深入的分析,而不仅仅是简单的依赖漏洞扫描。

结语

总而言之,第三方依赖项扫描是左移安全方法的支柱之一。换句话说,这意味着应该在开发生命周期的早期集成安全扫描。

为此需要:

  • 工具——可以使用它来扫描应用程序的依赖项,例如OWASPDC。
  • 自动扫描(定期和频繁)——可以通过将扫描工具与持续集成(CI)服务器(例如Jenkins OWASP DC插件)或构建工具(例如GradleO WASP DC插件)集成来实现这一点。
  • 漏洞审查和修复过程——一旦发现了漏洞,应该仔细查看,并决定是忽略它还是将依赖项升级到最接近的安全版本。

以上提到的最后一点可能是最有问题的一点。

首先,应该让信息安全团队参与审查依赖扫描工具的发现。根据严重性和对应用程序的实际影响,可能不需要对它做任何事情而只需忽略它。但需要记住的是,这必须是一个慎重的决定。

其次,一旦决定需要修补漏洞,就应该准备好快速交付应用程序的修补版本。特别是当该版本已经投入生产时。

继续浏览有关 安全 的文章
发表评论