我在供应商 A 的库中发现了一个漏洞，我报告了它，他们修复了它，我收到了 CVE。
我们注意到一些应用程序（我们称之为供应商 B），包含供应商 A 的库，我们报告了它，他使用固定库更新了应用程序并发布了新版本。
供应商 B 是否也应为其应用程序分配 CVE？
他告诉我，他将在修复的更改日志中写下，它解决了供应商 A 的 CVE。
这两个应用程序都是开源的。
这种事情的过程通常是什么？
我认为任何存在漏洞的程序，即使它们包含易受攻击的库，也应该在修复和发布其应用程序的新版本时分配 CVE。在这种情况下，如果易受攻击的库影响了 1000 个应用程序，那么这 1000 个应用程序是否都应该报告 CVE？我想不会，但我不知道。
2.1.2
2.1.2 如果一个 CVE ID 被分配给一个漏洞，CNA 必须做出合理的努力来通知维护者该漏洞所在的代码。
例如，如果操作系统供应商在上游供应商的库中发现漏洞，除了将 CVE ID 分配给漏洞外，操作系统供应商还应尝试联系上游供应商。这将有助于避免重复的 CVE ID 分配，并确保受此漏洞影响的其他人会知道它。
7.3
CNA 仅限于将 CVE ID 分配给其范围内的漏洞。有时，一个 CNA 的范围与另一个 CNA 的范围重叠。示例包括同时发现相同漏洞的研究人员 CNA 和产品依赖于同一易受攻击库的维护人员 CNA。在这种情况下，CNA 应该在它们之间进行协商，以确定谁应该分配 CVE ID。如果无法达成协议，则应将问题上报给相应的 Root CNA。
因此供应商 B 不得为其应用程序分配 CVE。
Benoit Esnard 的回答是正确的，假设供应商 B 没有对相关库代码进行任何修改，或者上述修改已应用于上游。
如果不是这种情况，您需要确定易受攻击的代码是否在库的上游版本中，或者是供应商 B 所做修改的一部分。如果是前者，则 CVE 仅适用于上游。如果是后者，CVE 应归属于供应商 B 的产品，而不是上游项目。
鉴于您所说，似乎没有进行修改，因此分配给供应商A的项目