BDBA（黑鸭二进制分析）分类范围误导

Question

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

因此，工具中的分类实际上已经完成不反对文件，但针对库版本（上下文中的 library === component）。理论上甚至不可能对文件进行分类，因为您要对版本进行分类。考虑到这一点，其余的想法就很简单了。

那么“文件哈希”是什么？

上面明确写到，如果您使用“FH”，则需要使用 product_id，并且 product 是上传的存档和二进制文件的同义词（在当前上下文中）。因此，每个产品都只有一个“文件哈希” - 上传存档的哈希。这使得此选项完全无用，因为我认为，人们不会单独上传 100 个文件，而是使用包含多个二进制文件的软件上传 archive\zip\tar.gz。显然，存档的哈希会随着每次重新打包而改变，即使 readme 文件有所更改。

我想要的是在我的库中对 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 实例中没有这个选项 -_-

测试上述假设的正确性

通过进行几次测试上传，可以轻松确认上述所有内容。

文件哈希- 以不同的名称上传两次相同的文件，并将 CVE 分类为“FH”范围 - 然后分类将会继续进行。

文件名- 上传一次档案，然后稍微修改档案（在其中添加空文本文件）并再次上传。分类将继续进行。

团体- 上传一个带有自动检测版本的库，然后修改二进制文件并以不同的名称上传 - 分类将被延续。

作为附加测试，您还可以上传包含两个库的档案并覆盖其中一个库的版本 - 它会在 UI 中将它们分开并启用分离分类。

Answer 1