DevSecOps：SCA的原理和比较。第一部分

随着Synopsys，Sonatype，Snyk，White Source发布的有关开源库漏洞的年度报告的发布，在开发过程中对第三方软件组件进行分析（软件组成分析-SCA）的重要性日益提高。根据2020年开源安全漏洞状况与上一年相比，2019年发现的开源漏洞数量增加了近1.5倍，而使用开源组件的项目占60％至80％。如果您寻求独立意见，SCA流程是OWASP SAMM和BSIMM的单独实践，它是成熟度的指标，并且OWASP在2020年上半年发布了新的OWASP软件组件验证标准（SCVS），该标准提供了验证供应链中第三方组件的最佳实践。通过。







2017年5月，Equifax发生 了最显着的案例之一。未知的攻击者查获了1.43亿美国人的信息，包括全名，地址，社会保险号和驾驶执照。在209,000个案件中，文件还包括受害者银行卡上的信息。该漏洞是由于利用了Apache Struts 2（CVE-2017-5638）中的一个关键漏洞而导致的，该修复程序于2017年3月发布。该公司有两个月的时间来安装更新，但没人对此感到困扰。



本文将根据分析结果的质量讨论选择进行SCA的工具的问题。还将对这些工具进行功能比较。嵌入CI / CD的过程以及集成的可能性将留待将来的出版物使用。OWASP在其网站上展示了各种各样的工具，但是作为当前审阅的一部分，我们将仅涉及最受欢迎的开源工具Dependency Check，不太知名的开源平台Dependency Track和Sonatype Nexus IQ Enterprise解决方案。我们还将弄清楚这些解决方案的工作原理，并比较误报得到的结果。

工作原理

Dependency Check是一个实用程序（CLI，maven，jenkins模块，ant），可分析项目文件，收集多条依赖信息（包名称，groupid，规范标题，版本...），构建CPE行-（Common Platform Enumeration），Package URL（PURL）并从数据库（NVD，Sonatype OSS索引，NPM审核API ...）中检测CPE / PURL的漏洞，然后以HTML，JSON，XML格式生成一次性报告...



让我们看看CPE的样子：

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

• 部件：表明该组件属于应用程序（a），操作系统（o），硬件（h）（必填项）
• 供应商：产品制造商的名称（必填）
• 产品：产品名称（必填项）
• 版本：组件版本（作废的项目）
• 更新：更新程序包
• 版本：旧版（不推荐使用）
• 语言： RFC-5646中定义的语言
• 软件版：软件版本
• 目标软件：产品运行所在的软件环境
• 目标硬件：产品运行所在的硬件环境
• 其他：供应商或产品信息

CPE示例如下所示：

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

该行表示CPE 2.3版描述了制造商pivotal_software 提供的应用程序组件，名称为spring_framework3.0.0版。如果我们在NVD中打开CVE-2014-0225漏洞，我们会看到对此CPE的提及。应该立即注意到的第一个问题是，根据CPE，NVD中的CVE报告说框架中存在问题，而不是特定组件中存在问题。也就是说，如果开发人员与框架紧密联系，并且所确定的漏洞不适用于开发人员使用的那些模块，则安全专家将不得不以某种方式拆卸此CVE并考虑进行更新。



SCA工具也使用该URL。程序包的URL格式如下：

scheme:type/namespace/name@version?qualifiers#subpath

• 提示：始终会有“ pkg”表示这是软件包的网址（必填）
• 类型：包装的“类型”或包装的“协议”，例如maven，npm，nuget，gem，pypi等。（强制性条款）
• 命名空间：一些名称前缀，例如Maven组ID，Docker映像所有者，GitHub用户或组织。可选，取决于类型。
• 名称：软件包名称（必填）
• 版本：软件包版本
• 限定词：软件包的其他限定词，例如OS，体系结构，发行版等。可选和特定于类型的项目。
• 子路径：包中相对于包根的附加路径

例如：

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Track是一个本地Web平台，它接受CycloneDX和SPDX生成的现成材料清单（BOM），即有关现有依赖关系的现成规范。这是一个描述依赖关系的XML文件-名称，哈希，程序包url，发布者，许可证。接下来，Dependency Track解析BOM，查看可用于从漏洞数据库（NVD，Sonatype OSS索引...）中识别出的依赖项的CVE，然后构建图形，计算指标并定期更新组件漏洞状态数据。



BOM可能是XML格式的示例：

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
  <components>
    <component type="library">
      <publisher>Apache</publisher>
      <group>org.apache.tomcat</group>
      <name>tomcat-catalina</name>
      <version>9.0.14</version>
      <hashes>
        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
      </hashes>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

BOM不仅可以用作依赖关系跟踪的输入参数，而且还可以用于清单供应链中的软件组件，例如用于向客户提供软件。 2014年，美国甚至提出了2014年《网络供应链管理和透明度法案》以供考虑，该法案规定在购买软件时，任何州都可以。该机构必须请求BOM来防止利用易受攻击的组件，但是该法案从未生效。



回到SCA，Dependency Track具有与Slack等通知平台和Kenna Security等漏洞管理系统的现成集成。还应该说，Dependency Track可以检测软件包的过时版本，并提供有关许可证的信息（由于支持SPDX）。



如果我们专门谈论SCA的质量，则存在根本差异。



依赖关系跟踪不接受项目作为输入，但接受BOM。这意味着，如果我们要检查项目，则首先需要例如使用CycloneDX生成bom.xml。因此，Dependency Track直接依赖于CycloneDX。同时，它允许自定义。因此，OZON团队编写了CycloneDX模块来为Golang项目构建BOM文件，以便通过依赖关系跟踪进行进一步扫描。



连结智商是Sonatype的商业SCA解决方案，它是Sonatype生态系统的一部分，还包括Nexus Repository Manager。如果您的组织尚未设法从CycloneDX重建到新的解决方案，则Nexus IQ可以通过Web界面或API将战争档案（用于Java项目）和BOM作为输入数据。与开放源代码解决方案不同，IQ不仅指已识别组件的CPE / PURL和数据库中的相应漏洞，而且还考虑了其​​自身的研究，例如易受攻击的函数或类的名称。智商机制将在以后的结果分析中讨论。



让我们总结一些功能特性，并考虑支持的语言进行分析：





功能性





整合机会

依赖检查

第一次开始

让我们 在故意易受攻击的DVJA应用程序上运行Dependency Check 。



为此，我们将使用Dependency Check Maven插件：

mvn org.owasp:dependency-check-maven:check

结果，dependency-check-report.html将出现在目标目录中。







让我们打开文件。在获得有关漏洞总数的摘要信息之后，我们可以看到有关具有高度严重性和可信度的漏洞的信息，其中指出了程序包，CPE，CVE编号。



这之后是更详细的信息，尤其是证据所基于的信息，即某个BOM。







接下来是CPE，PURL和CVE描述。顺便说一下，由于在NVD数据库中不存在针对修复的建议，因此未附加这些建议。







要系统地查看扫描结果，您可以使用最少的设置配置Nginx，或将产生的缺陷发送到支持Dependency Check连接器的缺陷管理系统。例如，缺陷道场。

依赖追踪

安装

反过来，Dependency Track是一个带有显示图表的Web平台，因此，在第三方解决方案中存储缺陷没有严重的问题。

有以下受支持的安装脚本：Docker，WAR，可执行WAR。

第一次开始

转到正在运行的服务的URL。我们通过admin / admin输入，更改用户名和密码，然后进入仪表板。接下来，我们将在Home / Projects→Create Project中为Java测试应用程序创建一个项目。让我们以DVJA为例。







由于“依赖关系跟踪”只能接受BOM表作为输入，因此必须检索此BOM表。让我们使用CycloneDX Maven插件：

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

获取bom.xml并在创建的DVJA项目中上载文件→依赖关系→上载BOM。



让我们转到管理→分析器。我们了解我们仅启用了内部分析器，包括NVD。我们还将连接Sonatype OSS索引。







因此，我们为项目获得了以下图片：







同样在列表中，您可以找到一个适用于Sonatype OSS的漏洞：







主要令人失望的是Dependency Track不再接受Dependency Check xml报告。我测试了5.3.2时，最近一次支持的Dependency Check集成版本是1.0.0-4.0.2。



这是仍可行的视频（现在是）。

连结智商

第一次开始

Nexus IQ是从文档档案中安装的，但是我们为此编译了一个Docker映像。



登录控制台后，您需要创建一个组织和一个应用程序。















如您所见，在IQ情况下的设置要稍微复杂一点，因为我们还需要创建适用于不同“阶段”（开发，构建，阶段，发布）的策略。当有漏洞的组件沿着管道靠近产品移动时，这是必须的，或者当开发人员下载它们进入Nexus Repo时，立即阻止它们。



为了感受开源与企业之间的差异，让我们通过Maven插件以相同的方式对Nexus IQ进行相同的扫描，之前已在NexusIQ界面中创建了一个测试应用程序dvja-test-and-compare：

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>

转到IQ Web界面中生成的报告的URL：







在这里，您可以看到具有不同重要性级别的所有策略违例（从“信息”到“安全关键”）。组件旁边的字母D表示该组件是直接依赖关系，而组件旁边的字母T表示该组件是传递依赖关系，即它是可传递的。



顺便说一句，Snyk的《 2020年开源安全状况报告》报告说，在Node.js，Java和Ruby中发现的开源漏洞中有70％以上属于传递依赖项。



如果我们打开一种违反Nexus IQ策略的行为，则可以看到该组件的描述以及版本图，该图在时间轴上显示当前版本的位置，以及该漏洞在何时不再脆弱。图表上烛台的高度显示了此组件的受欢迎程度。







如果转到漏洞部分并披露CVE，则可以阅读此漏洞的说明，消除建议以及违反此组件的原因，即存在类DiskFileitem.class。











让我们仅概述第三方Java组件，删除js组件。在括号中，我们指出了在NVD之外发现的那些漏洞的数量。



Nexus IQ总数：

• 扫描的依存关系：62
• 脆弱依赖性：16
• 发现的漏洞：42（8个声纳类型数据库）

全面依赖检查：

• 扫描的依存关系：47
• 脆弱依赖性：13
• 找到的漏洞：91（14个sonatype oss）

完全依赖跟踪：

• 扫描的依存关系：59
• 脆弱依赖性：10
• 发现的漏洞：51（1个sonatype oss）

下一步是分析结果，找出其中哪些漏洞是真正的缺陷，哪些是假阳性。

免责声明

这篇评论不是不可否认的真理。作者的目标不是将其他工具与其他背景区分开。审查的重点是展示SCA工具如何工作以及如何检查其结果。

结果比较

条件：第三方组件漏洞的



误报是：

• 识别出的组件的CVE不匹配
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• 例如，在spring-web组件中发现了CVE，此后SCA指向了Spring Framework其他组件中的同一CVE，而CVE与其他组件无关。在这种情况下，它将为假阳性。

研究的对象是开源项目DVJA。该研究仅涉及Java组件（无js）。

摘要结果

让我们直接看一下对已发现漏洞的手动检查的结果。每个CVE的完整报告可在附录中找到。



所有漏洞的摘要结果：



按组件汇总的结果：



让我们构建可视化图表来评估误报和误报占漏洞总数的比率。组件是水平标记的，组件中标识的漏洞是垂直标记的。















相比之下，Sonatype团队进行了类似的研究，以使用OWASP Dependency Check来测试1,531个组件项目。如我们所见，噪声与正确触发的比率与我们的结果相当。





来源：www.sonatype.com/why-precision-matters-ebook



让我们看一下扫描结果中的一些CVE，以了解产生这些结果的原因。

更多细节

＃1

首先让我们看一下Sonatype Nexus IQ的一些有趣之处。



Nexus IQ指出了反序列化问题，该问题可以在Spring Framework中多次执行RCE。spring-web中的CVE-2016-1000027：3.0.5第一次，spring-context中的CVE-2011-2894：3.0.5和spring-core：3.0.5。最初，似乎跨多个CVE存在一个重复的漏洞。因为如果您查看NVD数据库中的CVE-2016-1000027和CVE-2011-2894，那么一切似乎都是显而易见的





说明CVE-2011至2894年从NVD：





说明CVE-2016-1000027的NVD：





CVE-2011至2894年本身是相当有名。 《 2011年白色资源报告》将该CVE列为最常遇到的事件之一。原则上，NVD中对CVE-2016-100027的描述很少，并且似乎仅适用于Spring Framework 4.1.4。看一下参考，这里或多或少变得清晰。我们从Tenable的文章中了解到，除了RemoteInvocationSerializingExporterCVE-2011-2894中的漏洞之外，该漏洞还可以在中看到HttpInvokerServiceExporter。 Nexus IQ告诉我们的是：







然而，NVD中没有这样的东西，这就是为什么Dependency Check和Dependency Track接收到假否定的原因。



另外，从CVE-2011-2894的描述中，您可以了解到该漏洞确实存在于spring-context：3.0.5和spring-core：3.0.5中。可以从发现此漏洞的人的文章中找到对此的确认。

＃2

如果研究CVE-2016-4003漏洞，我们将了解该漏洞已在2.3.28版中修复，但是Nexus IQ仍会通知我们。在该漏洞的描述中有一条注释：







即，该漏洞仅与过时的JRE版本一起存在，他们决定警告我们。尽管如此，我们认为这是假阳性，尽管不是最坏的一种。

3号

如果我们查看CVE-2017-9804和CVE-2017-7672的描述，我们将理解问题是URLValidator class，并且CVE-2017-9804跟在CVE-2017-7672之后。第二个漏洞的存在不携带任何有效负载，除非其严重性已提高到“高”，因此可以将其视为不必要的噪音。



总体而言，未发现Nexus IQ的其他误报。

＃4

有几件事将智商与其他决策区分开。





NVD中的CVE表示，它仅适用于5.2.x至5.2.3版本，5.1.x至5.1.13版本以及5.0.x至5.0.16版本，但是，如果我们在Nexus IQ中查看CVE描述，我们将看到以下内容：

咨询偏离通知：Sonatype安全研究团队发现此漏洞是在版本3.0.2.RELEASE中引入的，而不是在通报中所述的5.0.x。



随后是此漏洞的PoC，报告该漏洞存在于3.0.5版本中。



否定假被发送到依赖检查和依赖跟踪。

＃5

让我们看一下“依赖性检查”和“依赖性跟踪”的误报。



依赖性检查的突出之处在于，它将适用于NVD中整个框架的CVE反映为那些CVE不适用的组件。这适用于CVE-2012-0394，CVE-2013-2115，CVE-2014-0114，CVE-2015-0899，CVE-2015-2992，CVE-2016-1181，CVE-2016-1182，它们依赖于“依赖项”到struts-taglib：1.3.8和struts-tiles-1.3.8。这些组件与CVE中描述的内容无关-请求处理，页面验证等。这是由于以下事实：这些CVE与组件之间的共通之处仅在于框架，这就是Dependency Check将其视为漏洞的原因。



spring-tx的情况相同：3.0.5，struts-core的情况相同：1.3.8。对于struts-core，“依赖关系检查”和“依赖关系跟踪”发现了许多实际上适用于struts2-core的漏洞，该漏洞本质上是一个单独的框架。在这种情况下，Nexus IQ会正确理解图片，并在发布的CVE中表明struts-core寿命已尽，因此有必要使用struts2-core。

＃6

在某些情况下，解释显式的“依赖关系检查”和“依赖关系跟踪”错误是不公平的。特别是CVE-2013-4152，CVE-2013-6429，CVE-2013-6430，CVE-2013-7315，CVE-2014-0054，CVE-2014-0225，CVE-2014-0225，它们是依赖性检查和依赖性跟踪指的是spring-core：3.0.5实际上指的是spring-web：3.0.5。同时，找到了其中的一些CVE，尽管如此，Nexus IQ仍可以正确地将它们识别为另一个组件。由于这些漏洞没有在spring-core中发现，因此原则上不能说它们不在框架中，并且开源工具正确地指出了这些漏洞（它们只是漏掉了一点）。

结论

如我们所见，通过手动检查来确定所识别漏洞的可靠性并不会产生明确的结果，而这会引发争议性的问题。结果是Nexus IQ解决方案具有最低的误报率和最高的准确性。



首先，这是由于Sonatype团队已从其数据库中的NVD扩展了对每个CVE漏洞的描述，准确指定了特定版本组件的漏洞的类别或功能，进行了进一步的研究（例如，检查较旧版本的漏洞）软件版本）。



NVD中未包含但仍带有SONATYPE标记的Sonatype数据库中存在的那些漏洞对结果产生了重要影响。根据2020年开源安全漏洞状况发现的开源漏洞中有45％不会报告给NVD。根据WhiteSource数据库，在NVD以外报告的所有开放源漏洞中，只有29％最终在此处发布，这就是为什么在其他位置寻找漏洞也很重要的原因。



结果，“依赖项检查”会产生大量噪音，并缺少一些易受攻击的组件。 Dependency Track产生的噪音较小，并显示大量组件，这些组件在视觉上不会伤害Web界面中的眼睛。



尽管如此，实践表明，开源是应该成为成熟的DevSecOps的第一步。为了将SCA嵌入到开发中，首先要考虑的是流程，即与管理层和相关部门一起考虑理想流程在组织中应该是什么样的。事实证明，对于您的组织而言，“依赖关系检查”或“依赖关系跟踪”将首先满足所有业务需求，并且由于已开发应用程序的复杂性不断提高，企业解决方案将成为逻辑上的延续。