Repository navigation
Define if and how CNAs assign CVE IDs to bundled third-party products. #30
Description
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.
Activity
EvansJonathan commentedon Jul 26, 2017
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 commentedon Aug 22, 2017
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 commentedon Aug 29, 2017
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 commentedon Aug 30, 2017
The current rules that relate to this issues are 2.1.2 and INC1. 2.1.2 says:
and INC1 says:
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.
dadinolfi commentedon Sep 29, 2017
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 commentedon Sep 29, 2017
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 commentedon Sep 29, 2017
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 commentedon Nov 4, 2024
Hello from 2024 in which software identity and relationships have not yet been solved, but cross-referencing this issue CVEProject/quality-workgroup#11 and noting that using ADP containers (a downstream CNA providing an ADP container on an upstream record) is under active discussion.