ProHoster > 博客 > 管理 > DevSecOps：SCA 的操作原理和比较。 第一部分

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

随着 Synopsys、Sonatype、Snyk 和 White Source 等公司发布的开源库漏洞年度报告的发布，开发过程中第三方软件组件分析（软件成分分析 - SCA）的重要性与日俱增。 。 据报道 2020 年开源安全漏洞状况 2019年已发现的开源漏洞数量比上一年增加了近1.5倍，而60%至80%的项目使用了开源组件。 独立的基础上，SCA流程是OWASP SAMM和BSIMM的单独实践，作为成熟度指标，并且在2020年上半年，OWASP发布了新的OWASP软件组件验证标准（SCVS），为验证第三方提供了最佳实践。供应链中的各方组成部分 BY。

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

最能说明问题的案例之一 发生 2017 年 143 月与 Equifax 合作。 身份不明的攻击者获取了 209 亿美国人的信息，包括全名、地址、社会安全号码和驾照。 在 000 起案件中，文件还包含受害者银行卡的信息。 此次泄漏是由于利用 Apache Struts 2 中的一个关键漏洞 (CVE-2017-5638) 造成的，而修复程序早在 2017 年 XNUMX 月就已发布。 该公司有两个月的时间来安装更新，但没有人理会它。

本文将从分析结果质量的角度讨论进行SCA的工具选择问题。 还将提供这些工具的功能比较。 集成到CI/CD的过程以及集成能力将留待后续发布。 OWASP 提供了广泛的工具 在您的网站上，但在本次评测中我们只会触及最流行的开源工具 Dependency Check、知名度稍低的开源平台 Dependency Track 和企业解决方案 Sonatype Nexus IQ。 我们还将了解这些解决方案的工作原理并比较所获得的误报结果。

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

的操作原理

依赖性检查 是一个实用程序（CLI、maven、jenkins 模块、ant），用于分析项目文件、收集有关依赖项的信息（包名称、groupid、规范标题、版本...）、构建 CPE（通用平台枚举）行、包 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_framework 版本 3.0.0。 如果我们打开一个漏洞 CVE-2014-0225 在NVD中，我们可以看到对这个CPE的提及。 您应该立即注意的第一个问题是，根据 CPE 的说法，NVD 中的 CVE 报告框架中的问题，而不是特定组件中的问题。 也就是说，如果开发人员与框架紧密相关，并且已识别的漏洞不会影响开发人员使用的模块，则安全专家将不得不以某种方式拆解此 CVE 并考虑更新。

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

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

  • 方案： 总会有“pkg”表明这是一个包 URL（必需）
  • 类型： 包的“类型”或者包的“协议”，例如maven、npm、nuget、gem、pypi等。 （必填项目）
  • 空间： 一些名称前缀，例如 Maven 组 ID、Docker 映像所有者、GitHub 用户或组织。 可选，取决于类型。
  • 名称： 包名（必填）
  • 版本： 套餐版本
  • 预选赛： 软件包的附加资格数据，例如操作系统、体系结构、发行版等。可选且特定于类型。
  • 子路径： 包中相对于包根的附加路径

例如：

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

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

XML 格式的 BOM 示例如下：

<?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 不仅可以用作 Dependency Track 的输入参数，还可以用于盘点供应链中的软件组件，例如，用于向客户提供软件。 2014年，美国甚至提出了一项法律 《2014年网络供应链管理和透明度法案》，其中指出购买软件时，任何状态。 该机构必须申请 BOM 以防止使用易受攻击的组件，但该法案尚未生效。

回到 SCA，Dependency Track 已与 Slack 等通知平台、Kenna Security 等漏洞管理系统集成。 还值得一提的是，Dependency Track 还可以识别过时的软件包版本并提供有关许可证的信息（由于 SPDX 支持）。

如果我们具体谈论SCA的质量，那么就有根本性的区别。

Dependency Track 不接受项目作为输入，而是接受 BOM。 这意味着如果我们想测试项目，我们首先需要生成bom.xml，例如使用CycloneDX。 因此，Dependency Track 直接依赖于 CycloneDX。 同时，它允许定制。 这是 OZON 团队写的 CycloneDX模块 用于为 Golang 项目组装 BOM 文件，以便通过 Dependency Track 进一步扫描。

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

我们总结一下一些功能特性，同时也考虑支持的语言进行分析：

选择语言
Nexus 智商
依赖性检查
依赖轨道

爪哇岛
+
+
+

C / C ++
+
+
-

C#
+
+
-

。净
+
+
+

Erlang
-
-
+

JavaScript（NodeJS）
+
+
+

PHP
+
+
+

Python
+
+
+

红宝石
+
+
+

Perl的
-
-
-

斯卡拉
+
+
+

目标C
+
+
-

Swift
+
+
-

R
+
-
-

Go
+
+
+

功能

功能
Nexus 智商
依赖性检查
依赖轨道

能够确保源代码中使用的组件经过许可纯度检查
+
-
+

能够扫描和分析 Docker 镜像的漏洞和许可证清洁度
+ 与 Clair 集成
-
-

能够配置安全策略以使用开源库
+
-
-

能够扫描开源存储库以查找易受攻击的组件
+ RubyGems、Maven、NPM、Nuget、Pypi、Conan、Bower、Conda、Go、p2、R、Yum、Helm、Docker、CocoaPods、Git LFS
-
+ Hex、RubyGems、Maven、NPM、Nuget、Pypi

专业研究小组的可用性
+
-
-

闭环运行
+
+
+

使用第三方数据库
+ 封闭的 Sonatype 数据库
+ Sonatype OSS、NPM 公共顾问
+ Sonatype OSS、NPM Public Advisors、RetireJS、VulnDB，支持自己的漏洞数据库

在尝试根据配置的策略加载到开发循环中时能够过滤开源组件
+
-
-

修复漏洞的建议、修复链接的可用性
+
+-（取决于公共数据库中的描述）
+-（取决于公共数据库中的描述）

按严重程度对检测到的漏洞进行排名
+
+
+

基于角色的访问模型
+
-
+

CLI 支持
+
+
+-（仅适用于 CycloneDX）

根据定义的标准对漏洞进行采样/排序
+
-
+

按应用程序状态显示的仪表板
+
-
+

生成 PDF 格式的报告
+
-
-

生成 JSONCSV 格式的报告
+
+
-

俄语支持
-
-
-

整合能力

积分
Nexus 智商
依赖性检查
依赖轨道

LDAP/活动目录集成
+
-
+

与持续集成系统 Bamboo 集成
+
-
-

与持续集成系统 TeamCity 集成
+
-
-

与持续集成系统GitLab集成
+
+- （作为 GitLab 的插件）
+

与持续集成系统 Jenkins 集成
+
+
+

IDE 插件的可用性
+ IntelliJ、Eclipse、Visual Studio
-
-

支持通过该工具的 Web 服务 (API) 进行自定义集成
+
-
+

依赖性检查

首先开始

让我们对故意存在漏洞的应用程序运行依赖项检查 DVJA.

为此，我们将使用 依赖检查 Maven 插件:

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

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

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

让我们打开文件。 汇总完漏洞总数信息后，我们可以看到严重度和置信度较高的漏洞信息，包括包数、CPE、CVE数量。

接下来是更详细的信息，特别是做出决策的依据（证据），即某个 BOM。

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

接下来是 CPE、PURL 和 CVE 描述。 顺便说一句，由于 NVD 数据库中不存在纠正建议，因此未包含这些建议。

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

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

依赖轨道

安装

反过来，Dependency Track 是一个带有显示图表的基于 Web 的平台，因此这里不会出现在第三方解决方案中存储缺陷的紧迫问题。
支持的安装脚本有：Docker、WAR、可执行 WAR。

首先开始

我们转到正在运行的服务的 URL。 我们通过admin/admin登录，更改登录名和密码，然后进入仪表板。 接下来我们要做的就是为 Java 中的测试应用程序创建一个项目 主页/项目 → 创建项目 。 我们以 DVJA 为例。

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

由于 Dependency Track 只能接受 BOM 作为输入，因此必须检索此 BOM。 让我们充分利用 CycloneDX Maven 插件:

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

我们获取 bom.xml 并将该文件加载到创建的项目中 DVJA → 依赖项 → 上传 BOM.

让我们转到管理 → 分析器。 我们知道我们只启用了内部分析器，其中包括 NVD。 我们还连接 Sonatype OSS Index。

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

因此，我们得到了我们项目的下图：

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

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

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

主要令人失望的是 Dependency Track 不再接受 Dependency Check xml 报告。 依赖项检查集成的最新受支持版本是 1.0.0 - 4.0.2，而我测试的是 5.3.2。

这里 视频 （和 这里）当它还有可能的时候。

Nexus 智商

首先开始

Nexus IQ 的安装来自以下档案 文件资料，但我们出于这些目的构建了一个 Docker 镜像。

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

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

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

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

正如您所看到的，IQ 情况下的设置有些复杂，因为我们还需要创建适用于不同“阶段”（开发、构建、阶段、发布）的策略。 当易受攻击的组件通过管道接近生产时，必须阻止它们，或者当开发人员下载它们进入 Nexus Repo 时立即阻止它们。

为了感受开源和企业之间的区别，让我们通过 Nexus IQ 以相同的方式执行相同的扫描 Maven插件，之前已在 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：

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

在这里，您可以看到所有策略违规，指示不同的重要性级别（从“信息”到“安全严重”）。 组件旁边的字母 D 表示该组件是 Direct Dependency，组件旁边的字母 T 表示该组件是 Transitive Dependency，即具有传递性。

顺便说一句，报告 2020 年开源安全状况报告 来自 Snyk 的报告称，在 Node.js、Java 和 Ruby 中发现的开源漏洞中，70% 以上都存在传递依赖关系。

如果我们打开其中一个 Nexus IQ 策略违规，我们可以看到该组件的描述，以及版本图，其​​中显示了当前版本在时间图中的位置，以及漏洞在什么时候停止变得脆弱。 图表上蜡烛的高度显示了使用该组件的受欢迎程度。

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

如果您转到漏洞部分并展开 CVE，您可以阅读该漏洞的描述、消除建议以及该组件被违反的原因，即该类的存在 DiskFileitem.class.

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

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

我们只总结一下与第三方Java组件相关的，去掉js组件。 在括号中，我们指出了在 NVD 之外发现的漏洞数量。

总 Nexus IQ：

  • 扫描的依赖项：62
  • 脆弱的依赖项：16
  • 发现漏洞：42（8 sonatype db）

总依赖性检查：

  • 扫描的依赖项：47
  • 脆弱的依赖项：13
  • 发现漏洞：91（14 sonatype oss）

总依赖跟踪：

  • 扫描的依赖项：59
  • 脆弱的依赖项：10
  • 发现漏洞：51（1 sonatype oss）

在接下来的步骤中，我们将分析获得的结果，并找出这些漏洞中哪些是真正的缺陷，哪些是误报。

免责声明

这个评论并不是不争的事实。 作者的目的并不是要在其他乐器的背景下突出显示一种单独的乐器。 审查的目的是展示 SCA 工具的运行机制以及检查其结果的方法。

结果比较

条款和条件：

第三方组件漏洞的误报是：

  • CVE 与已识别组件不匹配
  • 例如，如果在 struts2 框架中识别出一个漏洞，并且该工具指向该漏洞不适用的 struts-tiles 框架的某个组件，那么这是误报
  • CVE 与已识别的组件版本不匹配
  • 例如，该漏洞与 python 版本 > 3.5 相关，并且该工具将版本 2.7 标记为易受攻击 - 这是误报，因为实际上该漏洞仅适用于 3.x 产品分支
  • 重复的 CVE
  • 例如，如果 SCA 指定启用 RCE 的 CVE，则 SCA 会为适用于受该 RCE 影响的思科产品的同一组件指定 CVE。 在这种情况下，将会出现误报。
  • 例如，在 spring-web 组件中发现了 CVE，之后 SCA 指向 Spring Framework 的其他组件中的相同 CVE，而该 CVE 与其他组件无关。 在这种情况下，将会出现误报。

研究对象是开源项目 DVJA。 研究只涉及java组件（不含js）。

结果总结

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

所有漏洞的汇总结果：

参数
Nexus 智商
依赖性检查
依赖轨道

已发现的漏洞总数
42
91
51

错误识别的漏洞（误报）
2（4.76％）
62（68,13％）
29（56.86％）

未发现相关漏洞（漏报）
10
20
27

按成分汇总结果：

参数
Nexus 智商
依赖性检查
依赖轨道

已确定的总成分
62
47
59

易受攻击的组件总数
16
13
10

错误识别易受攻击的组件（误报）
1
5
0

错误识别易受攻击的组件（误报）
0
6
6

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

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

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

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

为了进行比较，Sonatype 团队进行了一项类似的研究，使用 OWASP 依赖项检查测试了包含 1531 个组件的项目。 正如我们所看到的，噪声与正确响应的比率与我们的结果相当。

DevSecOps：SCA 的操作原理和比较。 第一部分
来源： www.sonatype.com/why- precision-matters-ebook

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

详情

№1

我们首先来看看有关 Sonatype Nexus IQ 的一些有趣的点。

Nexus IQ 指出了反序列化的一个问题，能够在 Spring 框架中多次执行 RCE。 spring-web:2016 首次出现 CVE-1000027-3.0.5，spring-context:2011 和 spring-core:2894 出现 CVE-3.0.5-3.0.5。 乍一看，多个 CVE 之间似乎存在重复的漏洞。 因为，如果你查看 NVD 数据库中的 CVE-2016-1000027 和 CVE-2011-2894，似乎一切都很明显

部件
漏洞

弹簧网：3.0.5
CVE-2016-1000027

弹簧上下文：3.0.5
CVE-2011-2894

弹簧芯：3.0.5
CVE-2011-2894

使用说明 CVE-2011-2894 来自内华达州：
DevSecOps：SCA 的操作原理和比较。 第一部分

使用说明 CVE-2016-1000027 来自内华达州：
DevSecOps：SCA 的操作原理和比较。 第一部分

CVE-2011-2894本身就相当有名。 报告中 白源 2011 此 CVE 被认为是最常见的 CVE 之一。 原则上，NVD 中对 CVE-2016-100027 的描述很少，并且似乎仅适用于 Spring Framework 4.1.4。 我们来看看 参考 在这里，一切都或多或少变得清晰起来。 从 站得住脚的文章 我们了解，除了以下漏洞之外 RemoteInvocationSerializingExporter 在 CVE-2011-2894 中，该漏洞出现在 HttpInvokerServiceExporter。 这就是 Nexus IQ 告诉我们的：

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

然而，NVD 中没有这样的内容，这就是为什么 Dependency Check 和 Dependency Track 都会收到漏报的原因。

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

№2

部件
漏洞
导致

struts2-核心：2.3.30
CVE-2016-4003
FALSE

如果我们研究漏洞 CVE-2016-4003，我们就会知道它已在版本 2.3.28 中修复，但是 Nexus IQ 向我们报告了该漏洞。 漏洞描述中有一段注释：

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

也就是说，该漏洞仅与过时的 JRE 版本一起存在，他们决定向我们发出警告。 尽管如此，我们认为这是误报，尽管不是最糟糕的。

№3，

部件
漏洞
导致

xwork-核心：2.3.30
CVE-2017-9804
TRUE

xwork-核心：2.3.30
CVE-2017-7672
FALSE

如果我们看一下CVE-2017-9804和CVE-2017-7672的描述，我们就会明白问题是 URLValidator class，其中 CVE-2017-9804 源于 CVE-2017-7672。 第二个漏洞的存在除了其严重性已增加到“高”之外没有任何有用的负载，因此我们可以认为它是不必要的噪音。

总体而言，Nexus IQ 没有发现其他误报。

№4

有几个因素使 IQ 从其他解决方案中脱颖而出。

部件
漏洞
导致

弹簧网：3.0.5
CVE-2020-5398
TRUE

NVD 中的 CVE 声明它仅适用于 5.2 之前的版本 5.2.3.x、5.1 之前的 5.1.13.x 以及 5.0 之前的版本 5.0.16.x，但是，如果我们查看 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，Dependency Check和Dependency Track已经发现了很多实际适用于struts2-core的漏洞，struts2-core本质上是一个单独的框架。 在这种情况下，Nexus IQ 正确理解了情况，并在其发布的 CVE 中表明 struts-core 已达到生命周期，有必要迁移到 strutsXNUMX-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。 同时，Nexus IQ 也发现了其中一些 CVE，但是 IQ 正确地将它们识别为另一个组件。 因为这些漏洞在 spring-core 中没有被发现，所以不能说它们原则上不在框架中，并且开源工具正确地指出了这些漏洞（他们只是错过了一点）。

发现

正如我们所看到的，通过人工审查确定已识别漏洞的可靠性并不能给出明确的结果，这就是出现争议问题的原因。 结果表明，Nexus IQ 解决方案的误报率最低，准确率最高。

首先，这是因为Sonatype团队在其数据库中扩展了NVD中每个CVE漏洞的描述，将特定版本组件的漏洞指示到类或功能，并进行了额外的研究（例如，检查旧软件版本上的漏洞）。

那些未包含在 NVD 中但仍然存在于带有 SONATYPE 标记的 Sonatype 数据库中的漏洞也对结果产生了重要影响。 据报道 2020 年开源安全漏洞状况 45% 的已发现开源漏洞没有报告给 NVD。 根据 WhiteSource 数据库的数据，在 NVD 之外报告的所有开源漏洞中，只有 29% 最终在该漏洞中发布，这就是为什么在其他来源中查找漏洞也很重要。

因此，依赖性检查会产生大量噪音，遗漏一些易受攻击的组件。 Dependency Track 产生的噪音较少，并检测大量组件，在 Web 界面中不会在视觉上伤害眼睛。

然而实践表明，开源应该成为迈向成熟 DevSecOps 的第一步。 将 SCA 集成到开发中时首先要考虑的是流程，即与管理层和相关部门一起思考组织中理想的流程应该是什么样子。 事实证明，对于您的组织来说，首先，依赖项检查或依赖项跟踪将涵盖所有业务需求，并且由于正在开发的应用程序的复杂性不断增加，企业解决方案将成为逻辑上的延续。

附录 A：成分结果
符号：

  • 高——组件中的高级别和严重级别漏洞
  • 中 - 组件中中等严重级别的漏洞
  • TRUE — 真正的积极问题
  • FALSE — 误报问题

部件
Nexus 智商
依赖性检查
依赖轨道
导致

dom4j：1.6.1
高
高
高
TRUE

log4j-核心：2.3
高
高
高
TRUE

log4j：1.2.14
高
高
-
TRUE

公共收藏：3.1
高
高
高
TRUE

公共文件上传：1.3.2
高
高
高
TRUE

公共 beanutils:1.7.0
高
高
高
TRUE

公共编解码器：1:10
中
-
-
TRUE

mysql-连接器-java:5.1.42
高
高
高
TRUE

弹簧表达式：3.0.5
高
未找到组件

TRUE

弹簧网：3.0.5
高
未找到组件
高
TRUE

弹簧上下文：3.0.5
中
未找到组件
-
TRUE

弹簧芯：3.0.5
中
高
高
TRUE

struts2-config-browser-plugin：2.3.30
中
-
-
TRUE

弹簧TX：3.0.5
-
高
-
FALSE

struts-核心：1.3.8
高
高
高
TRUE

xwork 核心：2.3.30
高
-
-
TRUE

struts2 核心：2.3.30
高
高
高
TRUE

struts-taglib:1.3.8
-
高
-
FALSE

struts-tiles-1.3.8
-
高
-
FALSE

附录 B：漏洞结果
符号：

  • 高——组件中的高级别和严重级别漏洞
  • 中 - 组件中中等严重级别的漏洞
  • TRUE — 真正的积极问题
  • FALSE — 误报问题

部件
Nexus 智商
依赖性检查
依赖轨道
严谨求真
导致
备注

dom4j：1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
高
TRUE

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
高
TRUE

log4j-核心：2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
高
TRUE

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
低
TRUE

log4j：1.2.14
CVE-2019-17571
CVE-2019-17571
-
高
TRUE

-
CVE-2020-9488
-
低
TRUE

SONATYPE-2010-0053
-
-
高
TRUE

公共收藏：3.1
-
CVE-2015-6420
CVE-2015-6420
高
FALSE
重复 RCE(OSSINDEX)

-
CVE-2017-15708
CVE-2017-15708
高
FALSE
重复 RCE(OSSINDEX)

SONATYPE-2015-0002
远程代码执行（OSSINDEX）
远程代码执行(OSSINDEX)
高
TRUE

公共文件上传：1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
高
TRUE

SONATYPE-2014-0173
-
-
中
TRUE

公共 beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
高
TRUE

-
CVE-2019-10086
CVE-2019-10086
高
FALSE
该漏洞仅适用于1.9.2+版本

公共编解码器：1:10
SONATYPE-2012-0050
-
-
中
TRUE

mysql-连接器-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
高
TRUE

CVE-2019-2692
CVE-2019-2692
-
中
TRUE

-
CVE-2020-2875
-
中
FALSE
与 CVE-2019-2692 相同的漏洞，但带有注释“攻击可能会严重影响其他产品”

-
CVE-2017-15945
-
高
FALSE
与 mysql-connector-java 不相关

-
CVE-2020-2933
-
低
FALSE
CVE-2020-2934 的副本

CVE-2020-2934
CVE-2020-2934
-
中
TRUE

弹簧表达式：3.0.5
CVE-2018-1270
未找到组件
-
高
TRUE

CVE-2018-1257
-
-
中
TRUE

弹簧网：3.0.5
CVE-2016-1000027
未找到组件
-
高
TRUE

CVE-2014-0225
-
CVE-2014-0225
高
TRUE

CVE-2011-2730
-
-
高
TRUE

-
-
CVE-2013-4152
中
TRUE

CVE-2018-1272
-
-
高
TRUE

CVE-2020-5398
-
-
高
TRUE
支持 IQ 的说明性示例：“Sonatype 安全研究团队发现该漏洞是在 3.0.2.RELEASE 版本中引入的，而不是公告中所述的 5.0.x 版本。”

CVE-2013-6429
-
-
中
TRUE

CVE-2014-0054
-
CVE-2014-0054
中
TRUE

CVE-2013-6430
-
-
中
TRUE

弹簧上下文：3.0.5
CVE-2011-2894
未找到组件
-
中
TRUE

弹簧芯：3.0.5
-
CVE-2011-2730
CVE-2011-2730
高
TRUE

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
中
TRUE

-
-
CVE-2013-4152
中
FALSE
spring-web 中相同漏洞的重复

-
CVE-2013-4152
-
中
FALSE
该漏洞与 spring-web 组件有关

-
CVE-2013-6429
CVE-2013-6429
中
FALSE
该漏洞与 spring-web 组件有关

-
CVE-2013-6430
-
中
FALSE
该漏洞与 spring-web 组件有关

-
CVE-2013-7315
CVE-2013-7315
中
FALSE
从 CVE-2013-4152 中拆分。 + 该漏洞与 spring-web 组件相关

-
CVE-2014-0054
CVE-2014-0054
中
FALSE
该漏洞与 spring-web 组件有关

-
CVE-2014-0225
-
高
FALSE
该漏洞与 spring-web 组件有关

-
-
CVE-2014-0225
高
FALSE
spring-web 中相同漏洞的重复

-
CVE-2014-1904
CVE-2014-1904
中
FALSE
该漏洞与 spring-web-mvc 组件有关

-
CVE-2014-3625
CVE-2014-3625
中
FALSE
该漏洞与 spring-web-mvc 组件有关

-
CVE-2016-9878
CVE-2016-9878
高
FALSE
该漏洞与 spring-web-mvc 组件有关

-
CVE-2018-1270
CVE-2018-1270
高
FALSE
对于 spring 表达式/spring 消息

-
CVE-2018-1271
CVE-2018-1271
中
FALSE
该漏洞与 spring-web-mvc 组件有关

-
CVE-2018-1272
CVE-2018-1272
高
TRUE

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
中
TRUE

SONATYPE-2015-0327
-
-
低
TRUE

struts2-config-browser-plugin：2.3.30
SONATYPE-2016-0104
-
-
中
TRUE

弹簧TX：3.0.5
-
CVE-2011-2730
-
高
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2011-2894
-
高
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2013-4152
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2013-6429
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2013-6430
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2013-7315
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2014-0054
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2014-0225
-
高
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2014-1904
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2014-3625
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2016-9878
-
高
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2018-1270
-
高
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2018-1271
-
中
FALSE
该漏洞并非 spring-tx 特有

-
CVE-2018-1272
-
中
FALSE
该漏洞并非 spring-tx 特有

struts-核心：1.3.8
-
CVE-2011-5057 (OSSINDEX)

中
法斯莱
Struts 2 的漏洞

-
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
高
FALSE
Struts 2 的漏洞

-
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
中
FALSE
Struts 2 的漏洞

-
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
高
FALSE
Struts 2 的漏洞

CVE-2016-1182
3VE-2016-1182
-
高
TRUE

-
-
CVE-2011-5057
中
FALSE
Struts 2 的漏洞

-
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
高
FALSE
Struts 2 的漏洞

-
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
中
FALSE
Struts 2 的漏洞

CVE-2015-0899
CVE-2015-0899
-
高
TRUE

-
CVE-2012-0394
CVE-2012-0394
中
FALSE
Struts 2 的漏洞

-
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
高
FALSE
Struts 2 的漏洞

-
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
高
FALSE
Struts 2 的漏洞

-
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
高
法斯莱
Struts 2 的漏洞

-
CVE-2013-2115
CVE-2013-2115
高
法斯莱
Struts 2 的漏洞

-
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
高
法斯莱
Struts 2 的漏洞

-
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
高
法斯莱
Struts 2 的漏洞

CVE-2014-0114
CVE-2014-0114
-
高
TRUE

-
CVE-2015-2992
CVE-2015-2992
中
FALSE
Struts 2 的漏洞

-
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
高
FALSE
Struts 2 的漏洞

CVE-2016-1181
CVE-2016-1181
-
高
TRUE

-
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
高
FALSE
Struts 2 的漏洞

xwork-核心：2.3.30
CVE-2017-9804
-
-
高
TRUE

SONATYPE-2017-0173
-
-
高
TRUE

CVE-2017-7672
-
-
高
FALSE
CVE-2017-9804 的副本

SONATYPE-2016-0127
-
-
高
TRUE

struts2-核心：2.3.30
-
CVE-2016-6795
CVE-2016-6795
高
TRUE

-
CVE-2017-9787
CVE-2017-9787
高
TRUE

-
CVE-2017-9791
CVE-2017-9791
高
TRUE

-
CVE-2017-9793
-
高
FALSE
CVE-2018-1327 的副本

-
CVE-2017-9804
-
高
TRUE

-
CVE-2017-9805
CVE-2017-9805
高
TRUE

CVE-2016-4003
-
-
中
FALSE
适用于 Apache Struts 2.x 至 2.3.28，即版本 2.3.30。 但是，根据描述，如果使用 JRE 2 或更低版本，则 CVE 对于任何版本的 Struts 1.7 都有效。 显然他们决定在这里为我们再保险，但看起来更像是假的

-
CVE-2018-1327
CVE-2018-1327
高
TRUE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
高
TRUE
Equifax 黑客在 2017 年利用的同一漏洞

CVE-2017-12611
CVE-2017-12611
-
高
TRUE

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
高
TRUE

struts-taglib:1.3.8
-
CVE-2012-0394
-
中
FALSE
对于struts2核心

-
CVE-2013-2115
-
高
FALSE
对于struts2核心

-
CVE-2014-0114
-
高
FALSE
对于commons-beanutils

-
CVE-2015-0899
-
高
FALSE
不适用于 taglib

-
CVE-2015-2992
-
中
FALSE
参考struts2-core

-
CVE-2016-1181
-
高
FALSE
不适用于 taglib

-
CVE-2016-1182
-
高
FALSE
不适用于 taglib

struts-tiles-1.3.8
-
CVE-2012-0394
-
中
FALSE
对于struts2核心

-
CVE-2013-2115
-
高
FALSE
对于struts2核心

-
CVE-2014-0114
-
高
FALSE
在 commons-beanutils 下

-
CVE-2015-0899
-
高
FALSE
不适用于瓷砖

-
CVE-2015-2992
-
中
FALSE
对于struts2核心

-
CVE-2016-1181
-
高
FALSE
不适用于 taglib

-
CVE-2016-1182
-
高
FALSE
不适用于 taglib

来源： habr.com

添加评论