🥇DevSecOps：工作原理及SCA的比較。第一部分

隨著 Synopsys、Sonatype、Snyk、White Source 發布有關開源程式庫漏洞的年度報告，第三方軟體元件分析（軟體組成分析 - SCA）在開發過程中的重要性日益增加。據報道 2020 年開源安全漏洞狀況 2019年開源專案中發現的漏洞數量比前一年增加了近1.5倍，而60%至80%的專案使用了開源元件。從獨立角度來看，SCA流程是OWASP SAMM和BSIMM作為成熟度指標的單獨實踐，並且在2020年上半年，OWASP發布了新的標準OWASP軟體組件驗證標準（SCVS），為軟體供應鏈中第三方組件的驗證提供了最佳實踐。

最具說明性的案例之一發生了 2017 年 143 月，該公司與 Equifax 達成了合作。未知攻擊者獲取了 209 億美國人的個人信息，包括全名、地址、社會安全號碼和駕照號碼。在000起案件中，文件還包含受害者銀行卡的資訊。此次洩漏是由於 Apache Struts 2 (CVE-2017-5638) 中的一個嚴重漏洞被利用而導致的，而該漏洞已於 2017 年 XNUMX 月發布修復程序。該公司有兩個月的時間安裝更新，但沒有人願意這麼做。

本文將從分析結果品質的角度來討論選擇進行SCA的工具的問題。也將提供這些工具的功能比較。我們將嵌入 CI/CD 和整合功能的過程留到後續發布。 OWASP 提供了多種工具在您的網站上，但在目前審查框架內，我們將僅涉及最受歡迎的開源工具 Dependency Check、稍微不太知名的開源平台 Dependency Track 和企業解決方案 Sonatype Nexus IQ。我們還將研究這些解決方案的工作原理，並比較所獲得的誤報結果。

的操作原理

依賴性檢查 — 是一個實用程式（CLI、maven、jenkins 模組、ant），用於分析專案檔案、收集有關依賴項的資訊片段（套件名稱、groupid、規格標題、版本…）、建立 CPE 字串 —（通用平台枚舉）、套件 URL（PURL）並從資料庫（NVD、Sonatype OSS Index、NPMMLMA…XNPMML

我們來看看 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 Index 等）中發現的 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 不僅可用作依賴關係追蹤的輸入，還可用於庫存供應鏈中的軟體元件，例如將軟體交付給客戶。 2014 年，美國甚至提出了一項法律供審議《2014年網路供應鏈管理與透明度法案》，其中規定，在購買軟體時，任何狀態。該機構必須申請 BOM 以防止使用易受攻擊的組件，但該法案尚未生效。

回到 SCA，Dependency Track 已經與 Slack 等通知平台、Kenna Security 等漏洞管理系統進行了現成的整合。另外值得一提的是，Dependency Track 還可以識別軟體包的過時版本並提供有關許可證的資訊（由於支援 SPDX）。

如果我們具體談論SCA的質量，那麼存在著根本的差異。

依賴軌道不接受設計作為輸入，而是接受 BOM。這意味著如果我們要測試項目，我們首先需要產生 bom.xml，例如使用 CycloneDX。因此，Dependency Track 直接依賴 CycloneDX。同時，它允許定制。 OZON 團隊寫道 CycloneDX 模組為 Golang 專案建立 BOM 文件，以便透過 Dependency Track 進行進一步掃描。

Nexus IQ — Sonatype 的商業 SCA 解決方案，它是 Sonatype 生態系統的一部分，其中還包括 Nexus Repository Manager。如果您的組織尚未成功從 CycloneDX 切換到新解決方案，Nexus IQ 可以透過 Web 介面或 API 接受 war 檔案（用於 Java 專案）和 BOM 作為輸入。與開源解決方案不同的是，IQ 不僅參考資料庫中已識別元件的 CP/PURL 和對應的漏洞，還考慮到自身的研究，例如易受攻擊的函數或類別的名稱。稍後分析結果時我們將討論智商的機制。

讓我們總結一些功能特性，並考慮支援的語言進行分析：

語
Nexus IQ
依賴性檢查
依賴關係跟踪

Java的
+
+
+

C / C ++
+
+
-

C#
+
+
-

淨
+
+
+

Erlang
-
-
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

蟒蛇
+
+
+

紅寶石
+
+
+

Perl的
-
-
-

斯卡拉
+
+
+

目標C
+
+
-

迅速
+
+
-

R
+
-
-

Go
+
+
+

功能

功能
Nexus IQ
依賴性檢查
依賴關係跟踪

能夠確保檢查原始程式碼中使用的元件的許可純度
+
-
+

能夠掃描和分析 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 IQ
依賴性檢查
依賴關係跟踪

LDAP/Active Directory 集成
+
-
+

與持續整合系統 Bamboo 集成
+
-
-

與持續整合系統 TeamCity 集成
+
-
-

與持續整合系統 GitLab 集成
+
+-（作為 GitLab 插件）
+

與持續集成系統 Jenkins 集成
+
+
+

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

支援透過工具的 Web 服務（API）進行客製化集成
+
-
+

依賴性檢查

第一次開始

讓我們對故意存在漏洞的應用程式運行依賴性檢查德維嘉.

為此我們將使用依賴檢查 Maven 插件:

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

結果，dependency-check-report.html 將會出現在目標目錄中。

讓我們打開該文件。在漏洞總數的摘要資訊之後，我們可以看到嚴重程度和置信度較高的漏洞訊息，其中指明了軟體包、CPE 和 CVE 的數量。

接下來是更詳細的訊息，特別是做出決定的依據（證據），即某個 BOM。

接下來是 CPE、PURL 和 CVE 描述。順便說一句，由於 NVD 資料庫中沒有糾正建議，因此未將其納入。

為了有系統地查看掃描結果，您可以使用最少的設定來配置 Nginx，或將產生的缺陷傳送到支援依賴關係檢查連接器的缺陷管理系統。例如，Defect Dojo。

依賴關係跟踪

安裝

反過來，Dependency Track 是一個帶有顯示圖表的網路平台，因此在這裡不會出現將缺陷儲存在第三方解決方案中的緊迫問題。
支援以下場景安裝：Docker、WAR、可執行WAR。

第一次開始

我們轉到正在運行的服務的 URL。透過 admin/admin 登錄，變更您的登入名稱和密碼，然後進入儀表板。接下來我們要做的是用 Java 建立一個測試應用程式項目 主頁/項目 → 建立項目 。我們以 DVJA 為例。

由於 Dependency Track 只能接受 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 報告。 Dependency Check 整合的最新支援版本是 1.0.0 - 4.0.2，而我測試的是 5.3.2。

這裡視頻（и 這裡)，當時還有可能。

Nexus IQ

第一次開始

Nexus IQ 安裝已從檔案中完成文件，但為了這些目的我們編譯了一個 Docker 映像。

登入控制台後，需要建立一個組織（Organization）和一個應用程式（Application）。

如您所見，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 網路介面中的 URL 找到產生的報告：

在這裡您可以看到所有具有不同重要性等級（從資訊到安全關鍵）的政策違規行為。元件旁的字母 D 表示該元件是直接依賴 (Direct Dependency)，元件旁的字母 T 表示元件是傳遞依賴 (Transitive Dependency)，也就是具有傳遞性。

順便說一下，報告 2020 年開源安全狀況報告 Snyk 報告稱，Node.js、Java 和 Ruby 中發現的 70% 以上的開源漏洞都存在於傳遞依賴關係中。

如果我們打開其中一個 Nexus IQ 政策違規行為，我們可以看到該元件的描述以及版本圖，它顯示了當前版本在時間圖上的位置，以及漏洞在何時不再存在漏洞。圖表上蠟燭的高度顯示了使用該組件的受歡迎程度。

如果您前往漏洞部分並展開 CVE，您可以閱讀此漏洞的描述、消除建議，以及此元件被破壞的原因，即該類別的存在 DiskFileitem.class.

我們只總結一下與第三方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 影響的 Cisco 產品的相同元件的 CVE。在這種情況下，這將是一個假陽性。
例如，在 spring-web 元件中發現了一個 CVE，隨後 SCA 又指出 Spring Framework 的其他元件中也存在相同的 CVE，但該 CVE 與其他元件並無關係。在這種情況下，這將是一個假陽性。

選擇開源專案DVJA作為研究對象。研究只涉及java元件（沒有js）。

概要結果

讓我們直接看看已發現漏洞的手動審查結果。每個 CVE 的完整報告可在附錄中找到。

所有漏洞的總結結果：

參數
Nexus IQ
依賴性檢查
依賴關係跟踪

已識別漏洞總數
42
91
51

錯誤偵測的漏洞（誤報）
2（4.76％）
62（68,13％）
29（56.86％）

未發現相關漏洞（假陰性）
10
20
27

按組件匯總結果：

參數
Nexus IQ
依賴性檢查
依賴關係跟踪

已識別組件總數
62
47
59

易受攻擊組件總數
16
13
10

錯誤識別易受攻擊的組件（誤報）
1
5
0

錯誤識別易受攻擊的組件（誤報）
0
6
6

讓我們建立視覺化圖表來評估假陽性和假陰性與漏洞總數的比例。組件以水平方式標記，其中識別出的漏洞以垂直方式標記。

為了進行比較，Sonatype 團隊進行了類似的研究，使用 OWASP 依賴性檢查測試了一個包含 1531 個組件的項目。我們可以看到，噪音與正確命中率與我們的結果一致。

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

讓我們看看掃描結果中的一些 CVE，以了解這些結果背後的原因。

更

№1

讓我們先來看看 Sonatype Nexus IQ 的一些有趣的點。

Nexus IQ 指出了 Spring Framework 中存在著能夠多次執行 RCE 的反序列化問題。 CVE-2016-1000027 首次出現在 spring-web:3.0.5 中，CVE-2011-2894 出現在 spring-context:3.0.5 和 spring-core: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 來自NVD：

描述 CVE-2016，1000027 來自NVD：

CVE-2011-2894 本身相當有名。在報告中 2011 年白色來源該 CVE 被認為是最常見的 CVE 之一。 NVD中對CVE-2016-100027的描述很少，而且似乎只適用於Spring Framework 4.1.4。讓我們來看看參考到這裡，一切已經或多或少變得清晰起來。從可成立的文章我們理解，除了脆弱性之外 RemoteInvocationSerializingExporter 在 CVE-2011-2894 中，該漏洞出現在 HttpInvokerServiceExporter。 Nexus IQ 告訴我們的是：

然而，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
假

如果我們研究漏洞 CVE-2016-4003，我們就會明白它在 2.3.28 版本中已被修復，然而 Nexus IQ 卻向我們告知了這一點。漏洞描述中包含一條註記：

也就是說，漏洞僅與舊版的 JRE 結合存在，這就是他們決定警告我們的原因。然而，我們認為這是一個誤報，儘管不是最糟糕的。

№3

部件
脆弱性
導致

xwork-核心:2.3.30
CVE-2017，9804
TRUE

xwork-核心:2.3.30
CVE-2017，7672
假

如果我們看一下 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，CVE-1.3.8-1.3.8，CVE-XNUMX-XNUMX，依賴性檢查將其附加到 XNUMX-struts. XNUMX。這些元件與 CVE 中所述的內容（請求處理、頁面驗證等）無關。這是因為這些 CVE 和元件唯一的共同點就是框架，這也是 Dependency Check 將其視為漏洞的原因。

與spring-tx:3.0.5的情況相同，與struts-core:1.3.8的情況類似。對於 struts-core，Dependency Check 和 Dependency Track 發現了許多漏洞，這些漏洞實際上適用於 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，CVE-3.0.5-3.0.5，CVE-XNUMX-XNUMX，CVE-XNUMX-XNUMX，CVE-XNUMX-XNUMX，CVE-XNUMX-XNUMX，CVE-XNUMX-XNUMX，XNUMX-XNUMX-XNUMX，CVE-XNUMX-XNUMX，這些依賴於. .XNUMX。同時，其中一些 CVE 是由 Nexus IQ 發現的，然而 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 IQ
依賴性檢查
依賴關係跟踪
導致

dom4j： 1.6.1
高
高
高
TRUE

log4j-核心：2.3
高
高
高
TRUE

log4j： 1.2.14
高
高
-
TRUE

公共收藏：3.1
高
高
高
TRUE

公用文件上傳：1.3.2
高
高
高
TRUE

commons-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-配置-瀏覽器插件:2.3.30
媒材
-
-
TRUE

彈簧-TX：3.0.5
-
高
-
假

struts-核心:1.3.8
高
高
高
TRUE

xwork-核心: 2.3.30
高
-
-
TRUE

struts2-核心：2.3.30
高
高
高
TRUE

struts-taglib：1.3.8
-
高
-
假

struts-tiles-1.3.8
-
高
-
假

附錄 B. 漏洞結果
符號：

高 — 元件中存在高等級和嚴重等級的漏洞
中 — 組件中存在中等嚴重程度的漏洞
TRUE — 真正陽性問題
FALSE－誤報問題

部件
Nexus IQ
依賴性檢查
依賴關係跟踪
嚴重性
導致
評論

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
高
假
重複 RCE（OSSINDEX）

-
CVE-2017，15708
CVE-2017，15708
高
假
重複 RCE（OSSINDEX）

SONATYPE-2015-0002
RCE（OSSINDEX）
RCE（OSSINDEX）
高
TRUE

公用文件上傳：1.3.2
CVE-2016，1000031
CVE-2016，1000031
CVE-2016，1000031
高
TRUE

SONATYPE-2014-0173
-
-
媒材
TRUE

commons-beanutils：1.7.0
CVE-2014，0114
CVE-2014，0114
CVE-2014，0114
高
TRUE

-
CVE-2019，10086
CVE-2019，10086
高
假
此漏洞僅適用於 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
-
媒材
假
與 CVE-2019-2692 相同的漏洞，但帶有註釋“攻擊可能會嚴重影響其他產品”

-
CVE-2017，15945
-
高
假
不適用於 mysql-connector-java

-
CVE-2020，2933
-
低
假
與 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
媒材
假
spring-web 中相同漏洞的重複

-
CVE-2013，4152
-
媒材
假
該漏洞與 spring-web 組件有關。

-
CVE-2013，6429
CVE-2013，6429
媒材
假
該漏洞與 spring-web 組件有關。

-
CVE-2013，6430
-
媒材
假
該漏洞與 spring-web 組件有關。

-
CVE-2013，7315
CVE-2013，7315
媒材
假
與 CVE-2013-4152 分離。 + 該漏洞與 spring-web 組件有關

-
CVE-2014，0054
CVE-2014，0054
媒材
假
該漏洞與 spring-web 組件有關。

-
CVE-2014，0225
-
高
假
該漏洞與 spring-web 組件有關。

-
-
CVE-2014，0225
高
假
spring-web 中相同漏洞的重複

-
CVE-2014，1904
CVE-2014，1904
媒材
假
該漏洞與 spring-web-mvc 組件有關

-
CVE-2014，3625
CVE-2014，3625
媒材
假
該漏洞與 spring-web-mvc 組件有關

-
CVE-2016，9878
CVE-2016，9878
高
假
該漏洞與 spring-web-mvc 組件有關

-
CVE-2018，1270
CVE-2018，1270
高
假
對於 spring-expression/spring-messages

-
CVE-2018，1271
CVE-2018，1271
媒材
假
該漏洞與 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-配置-瀏覽器插件:2.3.30
SONATYPE-2016-0104
-
-
媒材
TRUE

彈簧-TX：3.0.5
-
CVE-2011，2730
-
高
假
該漏洞與 spring-tx 無關

-
CVE-2011，2894
-
高
假
該漏洞與 spring-tx 無關

-
CVE-2013，4152
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2013，6429
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2013，6430
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2013，7315
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2014，0054
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2014，0225
-
高
假
該漏洞與 spring-tx 無關

-
CVE-2014，1904
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2014，3625
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2016，9878
-
高
假
該漏洞與 spring-tx 無關

-
CVE-2018，1270
-
高
假
該漏洞與 spring-tx 無關

-
CVE-2018，1271
-
媒材
假
該漏洞與 spring-tx 無關

-
CVE-2018，1272
-
媒材
假
該漏洞與 spring-tx 無關

struts-核心:1.3.8
-
CVE-2011-5057（OSSINDEX）

媒材
假
Struts 2 漏洞

-
CVE-2012-0391（OSSINDEX）
CVE-2012，0391
高
假
Struts 2 漏洞

-
CVE-2014-0094（OSSINDEX）
CVE-2014，0094
媒材
假
Struts 2 漏洞

-
CVE-2014-0113（OSSINDEX）
CVE-2014，0113
高
假
Struts 2 漏洞

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

-
-
CVE-2011，5057
媒材
假
Struts 2 漏洞

-
CVE-2012-0392（OSSINDEX）
CVE-2012，0392
高
假
Struts 2 漏洞

-
CVE-2012-0393（OSSINDEX）
CVE-2012，0393
媒材
假
Struts 2 漏洞

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

-
CVE-2012，0394
CVE-2012，0394
媒材
假
Struts 2 漏洞

-
CVE-2012-0838（OSSINDEX）
CVE-2012，0838
高
假
Struts 2 漏洞

-
CVE-2013-1965（OSSINDEX）
CVE-2013，1965
高
假
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
媒材
假
Struts 2 漏洞

-
CVE-2016-0785（OSSINDEX）
CVE-2016，0785
高
假
Struts 2 漏洞

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

-
CVE-2016-4003（OSSINDEX）
CVE-2016，4003
高
假
Struts 2 漏洞

xwork-核心:2.3.30
CVE-2017，9804
-
-
高
TRUE

SONATYPE-2017-0173
-
-
高
TRUE

CVE-2017，7672
-
-
高
假
與 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
-
高
假
與 CVE-2018-1327 重複

-
CVE-2017，9804
-
高
TRUE

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

CVE-2016，4003
-
-
媒材
假
適用於 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
2017 年 Equifax 駭客利用的漏洞也屬於同一漏洞

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
-
媒材
假
對於 struts2-core

-
CVE-2013，2115
-
高
假
對於 struts2-core

-
CVE-2014，0114
-
高
假
對於 commons-beanutils

-
CVE-2015，0899
-
高
假
不適用於 taglib

-
CVE-2015，2992
-
媒材
假
與 struts2-core 相關

-
CVE-2016，1181
-
高
假
不適用於 taglib

-
CVE-2016，1182
-
高
假
不適用於 taglib

struts-tiles-1.3.8
-
CVE-2012，0394
-
媒材
假
對於 struts2-core

-
CVE-2013，2115
-
高
假
對於 struts2-core

-
CVE-2014，0114
-
高
假
在 commons-beanutils 下

-
CVE-2015，0899
-
高
假
不適用於磁磚

-
CVE-2015，2992
-
媒材
假
對於 struts2-core

-
CVE-2016，1181
-
高
假
不適用於 taglib

-
CVE-2016，1182
-
高
假
不適用於 taglib

來源： www.habr.com

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

的操作原理

依賴性檢查

第一次開始

依賴關係跟踪

安裝

第一次開始

Nexus IQ

第一次開始

免責聲明

結果比較

概要結果

更

№1

№2

№3

№4

№5

№6

發現

添加評論取消回复

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

的操作原理

依賴性檢查

第一次開始

依賴關係跟踪

安裝

第一次開始

Nexus IQ

第一次開始

免責聲明

結果比較

概要結果

更

№1

№2

№3

№4

№5

№6

發現

添加評論 取消回复

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

添加評論取消回复