隨著Synopsys、Sonatype、Snyk、White Source等公司發布的開源庫漏洞年度報告的發布，第三方軟件組件分析（英文Software Composition Analysis - SCA）在開發過程中的重要性與日俱增。 據報導 2019年已發現的開源漏洞數量比上一年增加了近1.5倍，而60%至80%的項目使用了開源組件。 獨立意見認為，SCA 流程是獨立於 OWASP SAMM 和 BSIMM 作為成熟度指標的實踐，並且在 2020 年上半年，OWASP 發布了新的 OWASP 軟件組件驗證標準（SCVS），提供了驗證第三方的最佳實踐供應鏈中的組件BY.
最能說明問題的案例之一 2017 年 143 月與 Equifax 合作。 身份不明的攻擊者獲取了 209 億美國人的信息，包括全名、地址、社會安全號碼和駕駛執照。 在000起案件中，文件還包括受害者銀行卡的信息。 此次洩漏是由於利用 Apache Struts 2 中的一個關鍵漏洞 (CVE-2017-5638) 造成的，而修復程序早在 2017 年 XNUMX 月就已發布。 該公司有兩個月的時間來安裝更新，但沒有人關心它。
本文將從分析結果的質量角度討論選擇進行SCA的工具的問題。 還將給出儀器的功能比較。 我們將嵌入CI/CD的過程和集成機會留給後續出版物。 OWASP 引入了多種工具 ，但作為當前審查的一部分，我們將僅涉及最流行的開源依賴項檢查工具、不太知名的開源依賴項跟踪平台和 Sonatype Nexus IQ Enterprise 解決方案。 我們還將了解這些解決方案的工作原理並比較所獲得的誤報結果。
的操作原理
是一個實用程序（CLI、maven、jenkins 模塊、ant），用於分析項目文件、收集有關依賴項的信息片段（包名稱、groupid、規範標題、版本...）、構建CPE 字符串- （通用平台枚舉）、包 URL (PURL) 並從數據庫（NVD、Sonatype OSS Index、NPM Audit 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。 如果我們打開一個漏洞 在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/[email protected]
pkg:pypi/[email protected]— 接受生成的現成物料清單 (BOM) 的本地 Web 平台 и ，即關於可用依賴項的現成規範。 這是一個 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/[email protected]</purl>
</component>
<!-- More components here -->
</components>
</bom>BOM 不僅可以用作 Dependency Track 的輸入參數，還可以用於盤點供應鏈中的軟件組件，例如，用於向客戶提供軟件。 2014年，美國甚至提出一項法律供考慮 ，這表示購買軟件時，任何狀態。 機構必須申請 BOM 以防止使用易受攻擊的組件，但該法案尚未生效。
回到 SCA，Dependency Track 與 Slack 等通知平台、Kenna Security 等漏洞管理系統進行開箱即用的集成。 還值得一提的是，Dependency Track 還可以檢測軟件包的過時版本並提供有關許可證的信息（由於 SPDX 支持）。
如果我們具體談論SCA的質量，那麼就有根本性的區別。
Dependency Track 不接受項目作為輸入，而是接受 BOM。 這意味著如果我們想測試項目，我們首先需要生成bom.xml，例如使用CycloneDX。 因此，Dependency Track 直接依賴於 CycloneDX。 同時，它允許定制。 所以 OZON 團隊寫道 為 Golang 項目構建 BOM 文件，以便通過 Dependency Track 進一步掃描。
是 Sonatype 的商業 SCA 解決方案，它是 Sonatype 生態系統的一部分，其中還包括 Nexus Repository Manager。 如果您的組織沒有時間從 CycloneDX 切換到新的解決方案，Nexus IQ 可以通過 Web 界面或 API 接受戰爭檔案（對於 Java 項目）和 BOM 作為輸入。 與開源解決方案不同，IQ不僅參考了所識別組件的CP/PURL以及數據庫中相應的漏洞，而且還考慮到了自己的研究，例如存在漏洞的函數或類的名稱。 IQ 的機制將在稍後的結果分析中討論。
我們總結一下一些功能特性，同時也考慮支持的語言進行分析：
語
Nexus 智商
依賴性檢查
依賴軌道
Java的
+
+
+
C / C ++
+
+
-
C#
+
+
-
淨
+
+
+
Erlang
-
-
+
JavaScript（NodeJS）
+
+
+
PHP
+
+
+
蟒蛇
+
+
+
紅寶石
+
+
+
Perl的
-
-
-
斯卡拉
+
+
+
目標C
+
+
-
迅速
+
+
-
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/Active Directory 集成
+
-
+
竹持續集成集成
+
-
-
與持續集成系統集成（持續集成）TeamCity
+
-
-
與持續集成系統集成（持續集成） GitLab
+
+- （作為 GitLab 的插件）
+
與持續集成系統集成（持續集成）Jenkins
+
+
+
IDE 插件的可用性
+ IntelliJ、Eclipse、Visual Studio
-
-
支持通過該工具的 Web 服務 (API) 進行自定義集成
+
-
+
依賴性檢查
第一次開始
對故意存在漏洞的應用程序運行依賴項檢查 .
為此我們使用 :
mvn org.owasp:dependency-check-maven:check結果，dependency-check-report.html 將出現在目標目錄中。
讓我們打開文件。 匯總完漏洞總數後，我們可以看到嚴重度和置信度較高的漏洞信息，包括包數、CPE、CVE數量。
接下來是更詳細的信息，特別是做出決定的基礎（證據），即某個 BOM。
接下來是 CPE、PURL 和 CVE 的描述。 順便說一句，由於 NVD 數據庫中不存在修復建議，因此未附上修復建議。
要係統地查看掃描結果，您可以使用最少的設置配置 Nginx，或將收到的缺陷發送到支持依賴性檢查連接器的缺陷管理系統。 例如，缺陷道場。
依賴軌道
安裝
反過來，Dependency Track 是一個基於 Web 的平台，具有顯示圖形，因此不存在在第三方解決方案中存儲缺陷的嚴重問題。
支持以下安裝場景：Docker、WAR、可執行 WAR。
第一次開始
轉到正在運行的服務的 URL。 我們通過admin/admin進入，更改登錄名和密碼，之後我們就進入了Dashboard。 接下來我們要做的是為 Java 測試應用程序創建一個項目 主頁/項目 → 創建項目 。 我們以 DVJA 為例。
由於 Dependency Track 只能將 BOM 作為輸入，因此必須檢索此 BOM。 讓我們使用 :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom我們獲取 bom.xml 並將該文件加載到創建的項目中 DVJA → 依賴項 → 上傳 BOM.
讓我們轉到管理 → 分析器。 我們知道我們只啟用了內部分析器，其中包括 NVD。 我們還連接 Sonatype OSS Index。
因此，我們得到了我們項目的下圖：
另外，在列表中您還可以找到一個適用於 Sonatype OSS 的漏洞：
主要令人失望的是 Dependency Track 不再接受 Dependency Check xml 報告。 依賴項檢查集成的最新受支持版本是 1.0.0 - 4.0.2，而我測試的是 5.3.2。
這裡 （и ）當它還有可能的時候。
Nexus 智商
第一次開始
Nexus IQ 安裝來自軟件檔案 ，但我們為此目的編譯了一個 Docker 鏡像。
登錄控制台後，您需要創建組織和應用程序。
正如您所看到的，IQ 情況下的配置有些複雜，因為我們還需要創建適用於不同“階段”（開發、構建、階段、發布）的策略。 當易受攻擊的組件靠近生產管道時，這對於阻止它們是必要的，或者當開發人員下載它們進入 Nexus Repo 時立即阻止它們。
為了感受開源和企業之間的區別，讓我們通過 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 表示該組件是 Direct Dependency，組件旁邊的字母 T 表示該組件是 Transitive Dependency，即具有傳遞性。
順便說一句，報告 來自 Snyk 的報告稱，在 Node.js、Java 和 Ruby 中發現的開源漏洞中，超過 70% 都存在傳遞依賴關係。
如果我們打開其中一個 Nexus IQ 策略違規，我們可以看到該組件的描述，以及版本圖，它顯示了當前版本在時間圖上的位置，以及漏洞在什麼時候停止變得脆弱。 圖表上蠟燭的高度顯示了使用該組件的受歡迎程度。
如果你進入漏洞部分並打開CVE，你可以閱讀這個漏洞的描述、修復建議，以及這個組件被違反的原因，即該類的存在 DiskFileitem.class.
我們去掉js組件，只總結一下第三方Java組件。 在括號中，我們指出了在 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
讓我們構建可視化圖表來估計誤報和誤報與漏洞總數的比率。 組件是水平標記的，其中識別的漏洞是垂直標記的。
相比之下，Sonatype 團隊進行了一項類似的研究，使用 OWASP 依賴性檢查測試了包含 1531 個組件的項目。 正如我們所看到的，噪聲與正確響應的比率與我們的結果一致。
來源：
讓我們看一下掃描結果中的一些 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
描述 來自 NVD：
描述 來自 NVD：
CVE-2011-2894 本身就很出名。 報告中 此 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.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 和組件之間只有框架是通用的，這就是依賴項檢查認為這是一個漏洞的原因。
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 數據庫中的漏洞也對結果產生了重要影響。 據報導 45% 的已發現開源漏洞沒有報告給 NVD。 根據 WhiteSource 數據庫的數據，在 NVD 之外提交的所有開源漏洞中，只有 29% 最終會在那裡發布，這就是為什麼在其他地方尋找漏洞也如此重要。
因此，依賴性檢查會產生大量噪音，遺漏一些易受攻擊的組件。 Dependency Track 產生的噪音較少，並檢測大量組件，在 Web 界面中不會在視覺上傷害眼睛。
然而，實踐表明，開源應該成為邁向成熟 DevSecOps 的第一步。 將 SCA 嵌入到開發中首先要考慮的是流程，即與管理層和相關部門一起思考組織中理想的流程應該是什麼樣子。 事實證明，對於您的組織來說，首先，依賴項檢查或依賴項跟踪將涵蓋所有業務需求，並且由於正在開發的應用程序的複雜性不斷增加，企業解決方案將成為邏輯上的延續。
附錄 A. 成分結果
符號：
- High - 組件中的高級別和嚴重級別漏洞
- 中 - 組件中的中等嚴重性漏洞
- 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
Medium
-
-
TRUE
mysql-連接器-java:5.1.42
高
高
高
TRUE
彈簧表達式：3.0.5
高
未找到組件
TRUE
彈簧網：3.0.5
高
未找到組件
高
TRUE
彈簧上下文：3.0.5
Medium
未找到組件
-
TRUE
彈簧芯：3.0.5
Medium
高
高
TRUE
struts2-config-browser-plugin：2.3.30
Medium
-
-
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. 漏洞結果
符號：
- High - 組件中的高級別和嚴重級別漏洞
- 中 - 組件中的中等嚴重性漏洞
- 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
高
假
重複 RCE(OSSINDEX)
-
CVE-2017，15708
CVE-2017，15708
高
假
重複 RCE(OSSINDEX)
SONATYPE-2015-0002
遠程代碼執行（OSSINDEX）
遠程代碼執行(OSSINDEX)
高
TRUE
公共文件上傳：1.3.2
CVE-2016，1000031
CVE-2016，1000031
CVE-2016，1000031
高
TRUE
SONATYPE-2014-0173
-
-
Medium
TRUE
公共 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
-
-
Medium
TRUE
mysql-連接器-java:5.1.42
CVE-2018，3258
CVE-2018，3258
CVE-2018，3258
高
TRUE
CVE-2019，2692
CVE-2019，2692
-
Medium
TRUE
-
CVE-2020，2875
-
Medium
假
與 CVE-2019-2692 相同的漏洞，但增加了“攻擊可能會嚴重影響其他產品”
-
CVE-2017，15945
-
高
假
不適用於 mysql-connector-java
-
CVE-2020，2933
-
低
假
複製到 CVE-2020-2934
CVE-2020，2934
CVE-2020，2934
-
Medium
TRUE
彈簧表達式：3.0.5
CVE-2018，1270
未找到組件
-
高
TRUE
CVE-2018，1257
-
-
Medium
TRUE
彈簧網：3.0.5
CVE-2016，1000027
未找到組件
-
高
TRUE
CVE-2014，0225
-
CVE-2014，0225
高
TRUE
CVE-2011，2730
-
-
高
TRUE
-
-
CVE-2013，4152
Medium
TRUE
CVE-2018，1272
-
-
高
TRUE
CVE-2020，5398
-
-
高
TRUE
支持 IQ 的例子：“Sonatype 安全研究團隊發現該漏洞是在 3.0.2.RELEASE 版本中引入的，而不是公告中所述的 5.0.x 版本中引入的。”
CVE-2013，6429
-
-
Medium
TRUE
CVE-2014，0054
-
CVE-2014，0054
Medium
TRUE
CVE-2013，6430
-
-
Medium
TRUE
彈簧上下文：3.0.5
CVE-2011，2894
未找到組件
-
Medium
TRUE
彈簧芯：3.0.5
-
CVE-2011，2730
CVE-2011，2730
高
TRUE
CVE-2011，2894
CVE-2011，2894
CVE-2011，2894
Medium
TRUE
-
-
CVE-2013，4152
Medium
假
spring-web 中相同漏洞的重複
-
CVE-2013，4152
-
Medium
假
該漏洞與 spring-web 組件有關
-
CVE-2013，6429
CVE-2013，6429
Medium
假
該漏洞與 spring-web 組件有關
-
CVE-2013，6430
-
Medium
假
該漏洞與 spring-web 組件有關
-
CVE-2013，7315
CVE-2013，7315
Medium
假
從 CVE-2013-4152 中拆分。 + 該漏洞與 spring-web 組件相關
-
CVE-2014，0054
CVE-2014，0054
Medium
假
該漏洞與 spring-web 組件有關
-
CVE-2014，0225
-
高
假
該漏洞與 spring-web 組件有關
-
-
CVE-2014，0225
高
假
spring-web 中相同漏洞的重複
-
CVE-2014，1904
CVE-2014，1904
Medium
假
該漏洞與 spring-web-mvc 組件有關
-
CVE-2014，3625
CVE-2014，3625
Medium
假
該漏洞與 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
Medium
假
該漏洞與 spring-web-mvc 組件有關
-
CVE-2018，1272
CVE-2018，1272
高
TRUE
CVE-2014，3578
CVE-2014-3578（OSSINDEX）
CVE-2014，3578
Medium
TRUE
SONATYPE-2015-0327
-
-
低
TRUE
struts2-config-browser-plugin：2.3.30
SONATYPE-2016-0104
-
-
Medium
TRUE
彈簧TX：3.0.5
-
CVE-2011，2730
-
高
假
該漏洞不適用於 spring-tx
-
CVE-2011，2894
-
高
假
該漏洞不適用於 spring-tx
-
CVE-2013，4152
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2013，6429
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2013，6430
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2013，7315
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2014，0054
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2014，0225
-
高
假
該漏洞不適用於 spring-tx
-
CVE-2014，1904
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2014，3625
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2016，9878
-
高
假
該漏洞不適用於 spring-tx
-
CVE-2018，1270
-
高
假
該漏洞不適用於 spring-tx
-
CVE-2018，1271
-
Medium
假
該漏洞不適用於 spring-tx
-
CVE-2018，1272
-
Medium
假
該漏洞不適用於 spring-tx
struts-核心：1.3.8
-
CVE-2011-5057（OSSINDEX）
Medium
法斯萊
Struts 2 的漏洞
-
CVE-2012-0391（OSSINDEX）
CVE-2012，0391
高
假
Struts 2 的漏洞
-
CVE-2014-0094（OSSINDEX）
CVE-2014，0094
Medium
假
Struts 2 的漏洞
-
CVE-2014-0113（OSSINDEX）
CVE-2014，0113
高
假
Struts 2 的漏洞
CVE-2016，1182
3VE-2016-1182
-
高
TRUE
-
-
CVE-2011，5057
Medium
假
Struts 2 的漏洞
-
CVE-2012-0392（OSSINDEX）
CVE-2012，0392
高
假
Struts 2 的漏洞
-
CVE-2012-0393（OSSINDEX）
CVE-2012，0393
Medium
假
Struts 2 的漏洞
CVE-2015，0899
CVE-2015，0899
-
高
TRUE
-
CVE-2012，0394
CVE-2012，0394
Medium
假
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
Medium
假
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
-
-
Medium
假
適用於 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
-
Medium
假
對於struts2核心
-
CVE-2013，2115
-
高
假
對於struts2核心
-
CVE-2014，0114
-
高
假
對於commons-beanutils
-
CVE-2015，0899
-
高
假
與標籤庫無關
-
CVE-2015，2992
-
Medium
假
與 struts2-core 相關
-
CVE-2016，1181
-
高
假
與標籤庫無關
-
CVE-2016，1182
-
高
假
與標籤庫無關
struts-tiles-1.3.8
-
CVE-2012，0394
-
Medium
假
對於struts2核心
-
CVE-2013，2115
-
高
假
對於struts2核心
-
CVE-2014，0114
-
高
假
在 commons-beanutils 下
-
CVE-2015，0899
-
高
假
不適用於瓷磚
-
CVE-2015，2992
-
Medium
假
對於struts2核心
-
CVE-2016，1181
-
高
假
與標籤庫無關
-
CVE-2016，1182
-
高
假
與標籤庫無關
來源： www.habr.com