在 Black Duck 二進位分析（又稱 Protecode）工具中，有多種漏洞分類選項
來自幫助：
分診範圍
您可以將範圍套用至第三方元件中的分類漏洞。在對已知漏洞進行分類時，您可以從以下選項中進行選擇：
帳戶：適用於公司帳戶內該元件的所有使用
團體：適用於組內組件的所有使用
應用：僅適用於在同一應用程式中使用該元件
應用程式名稱：適用於在具有相同應用程式名稱的掃描應用程式中使用該元件
檔案哈希值：適用於在具有相同檔案雜湊的掃描應用程式中使用該元件
我想要的是在我的庫中對 CVE 進行分類，以便將分類結果延續到下一次掃描。我期望“文件雜湊”選項應該做到這一點，但是，當我下次上傳我的存檔時，我仍然看到與未分類相同的 CVE。怎麼了？
答案1
TL;DR - 使用「群組」範圍。
細節
API文件使其更加清晰
PUT /api/triage/vulnerability/
component - Component name
version - Component version
vulns - List of vulnerability ids
scope - Scope in which the triage affects. Possible values:
- CA - Account wide
- FN - Filename
- FH - File hash
- R - Result
- G - Group
product_id - In FN, FH and R scopes the related product
group_id - In G scope the related group
所以實際上在工具中進行了分類不反對文件， 但針對庫版本（上下文中的庫 === 元件）。理論上甚至不存在對文件進行分類的可能性，因為您對版本進行分類。考慮到這一點，其餘的想法就很簡單了。
那麼「文件哈希」是什麼？
清楚地寫著，如果您使用“FH”，則需要product_id，並且product是與二進位檔案一起上傳的存檔的同義詞（在當前上下文中）。因此，每個產品都有一個且唯一的「檔案雜湊」——上傳已存檔的雜湊。這使得這個選項完全沒有用，因為，我假設，一個人不是單獨上傳100個文件，而是與軟體一起上傳archive\zip\tar.gz，其中包含多個二進位。顯然，即使自述文件發生了變化，存檔的雜湊值也會隨著每次重新打包而改變。
我想要的是在我的庫中對 CVE 進行分類，以便將分類結果延續到下一次掃描。
由於“文件哈希”不適合此目的，讓我們通過其他可用的範圍選項來看看我們可以在這裡做什麼：
結果
最簡單的預設選項。同時，最無用。直接對應到Application幫助中提到的範圍：Applies to uses of the component within the same application only。簡而言之 - 沒有任何結轉。
檔案名稱
我個人認為“文件名”比Application name幫助中的相應行更清晰。無論如何，這也很清楚 - 僅當存檔名稱相同時才會進行分類。當它以某種方式解決問題時，它引入了新問題——區分不同構建的問題。通常我們這樣命名我們的 zip，MyCoolBuild_942_ab4e3f這樣很容易找到並檢查過去建置的結果。如果您不在乎，那麼如果您將 zip 命名為MyCoolBuild.zip.
團體
人們可以猜到，這只是整個集團範圍內的分類。如果您的團隊有自己的組，那麼您完全可以節省使用它的費用。
就我而言，我們讓整個公司將文件上傳到一組，所以我們可能然而，有一些衝突，該工具的手冊說，如果您要對此庫進行自訂建置（例如，為了自己修復一些 CVE），則應該使用版本後綴。如果每個人都遵循這個規則，從不命名自訂函式庫，1.0.2那麼1.0.2_company_build不同團隊的分類之間就不會有衝突。
帳戶
我不知道，因為我的 BDBA 實例中沒有這個選項 -_-
測試上述假設的正確性
透過進行幾次測試上傳可以輕鬆確認上面的所有內容。
檔案哈希值- 以不同名稱上傳同一檔案兩次，並對具有「FH」範圍的 CVE 進行分類 - 然後分類將被結轉。
檔案名稱- 上傳一次存檔，然後稍微修改存檔（在裡面新增空白文字檔案）並再次上傳。分類將被結轉。
團體- 上傳一個自動偵測版本的庫，然後修改二進位檔案並以不同的名稱上傳 - 分類將被繼承。
作為一項附加測試，您還可以上傳包含兩個庫的存檔並覆蓋其中一個庫的版本 - 它將在 UI 中將它們分開並啟用單獨的分類。