Define if and how CNAs assign CVE IDs to bundled third-party products.

[EvansJonathan]

GOAL: Make the CNA processes more standardized and repeatable. CHANGE: Define if and how CNAs assign CVE IDs to bundled third-party products. OUTCOME: Reduce duplicate, increased transparency in processes, and better quality entries.

[EvansJonathan]

Possible wording: A product vendor may assign a CVE ID to a bundled product, if: the producer of the bundled product is not a CNA they coordinate with the producer of the bundled product or (if contact with the producer fails) the Root CNA for the product.

[kurtseifried]

so I would say this is covered, if the third party product is covered by a CNA (e.g. Apache), then they have to go to them, if not covered then they go to the over arching one (e.g. OpenSource == DWF), or ultimately MITRE, if someone embeds it, chances are others do.

[david-waltermire]

I believe this is covered as well based on Kurt's reasoning, but this represents a mindset to focus on the third-party, not the bundle for CVE assignment, which is useful to clarify in the CNA rules.

[EvansJonathan]

The current rules that relate to this issues are 2.1.2 and INC1. 2.1.2 says:

Only assign CVE IDs to security vulnerabilities when no lower level CNA exists which already covers a more constrained scope .

and INC1 says:

In Scope of Authority: Does the vulnerability report fall into the scope of authority for the CNA. CNAs can only assign CVE IDs to vulnerabilities that are within their scope of authority as defined by their root CNA.

• Yes: Continue to INC2.
• No: DEFER to appropriate CNA or Root CNA
• Not sure: CONSULT Root CNA

Kurt's position is one possible interpretation of these rules. Another is that the CNA of the downstream product has a product that is affected, and therefore it is in that CNA's scope. I don't think any of the CNAs are using this interpretation, but it is possible.

Another interpretation is that while vulnerability is not in the CNA's direct scope, the CNA is the "appropriate CNA" because its scope is more constrained than any of the Root CNAs's. This is the interpretation I believe this proposal is trying to solve since it is not just a a legitimate interpretation, but somewhat within the spirit of the rules. This obviously increases the likelihood of duplicates, but I don't think it is any greater of a risk than having the non-vendor CNAs.

[ghost]

So one note: intersection vulnerabilities between 2 (or more) components with 1 (or more) CNAs involved. I assume simply suggesting that people try to cooperate will be enough (most everyone wants to do the right thing).

[ghost]

Also this is why I wanted the affected section in JSON for nested/embedded/etc stuff (e.g. a vendor using library Foo in Product Blah can simply list their Affects:Vendor:Product:Version as affected and voila). We don't need more CVEs to fix this, we just need better CVE data.

[dadinolfi]

Suggestion: add to Section 2.1.2:

---

Note: when assigning a CVE ID to a vulnerability in a bundled product, a downstream vendor/developer may assign a CVE ID for the bundled product if: • The producer of the bundled product is not a CNA, or • The assigner coordinates with the producer of the bundled product or (if contact with the producer fails) the Root CNA for that bundled product.

---

This language encourages coordination when the source of the vulnerability lies in code obtained from outside the CNA's own code.

[EvansJonathan]

I would suggest that both conditions have to be true, not just one. Also, I would change "a downstream vendor/developer" to something like "the CNA for a downstream product." We should make it clear that only CNAs can assign CVE IDs.

Also, if they aren't already there, we should add "bundled product," "upstream," and "downstream" to the list of defined terms.

[dadinolfi]

For Appendix A:

A bundled product is a product distributed with another product. In CVE terms, the developer of a bundled product included in another vendor’s product is considered an upstream developer compared to the vendor distributing the bundled product, who is considered to be a downstream developer. For example, if Apple includes the apache server in Mac OS X, the apache server is considered a bundled product, and Apple is considered a downstream developer for the apache server, whereas Apache is considered the upstream developer for the apache server.

[zmanion]

Hello from 2024 in which software identity and relationships have not yet been solved, but cross-referencing this issue https://github.com/CVEProject/quality-workgroup/issues/11 and noting that using ADP containers (a downstream CNA providing an ADP container on an upstream record) is under active discussion.