-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify the nested CNA structure #49
Comments
Current text of section 1.2: |
To add under the diagram: |
Update to first paragraph: |
The Board's Strategic Planning Working Group is still considering this suggestion and where other language can be improved. Leaving this issue open until they have had time to review it. |
one note: the DWF CNA entries now include who the parent is, who the primar and secondary CVE Mentors are, e.g.: so people are welcome to parse this data and make a graph if they want. |
To be clear: we should require CNA's to publish their sub-CNA data publicly, for a ton of reasons, not just to make graphs, but also to allow people to find them, report problems to the parent, etc. |
With regards to "The Primary CNA operates the CVE Program, manages Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs" in your original text, the intent of the federated model is for delegation of management of Sub-CNAs to the Root CNAs. The primary will manage the roots, the roots will manage the subs. The text needs to be revised to reflect this. |
Similar to my previous comment, the expectation under a federated model is that root CNAs are responsible for recruitment of sub-CNAs in their scope. The text in the summary "The Primary CNA operates the CVE Program, [...], trains and admits new Root CNAs and Sub-CNAs" should be revised to reflect this. One way of handling this is for the Primary to forward to the appropriate root any party interested in joining a scope covered by that root. |
Are we disallowing further federation under a Sub-CNA? Should this be allowed? Should roots have the ability to organize in a way that makes sense for their scope? |
@david-waltermire-nist so we already have people/orgs that exist in multiple hierarchies (e.g. Josh Bressers in DWF and for Elastic), I'm wondering what other styles of organization are needed (hierarchy with membership in multiple hierarchies/levels seems to address most things no?). |
We are not allowing further federation under a Sub-CNA. We have an example of a nested Root in the third column of the graphic. The goal of having Root organize by scope is correct, in my opinion. But for edge cases, not every Sub-CNA will be a perfect fit. As long as we have things well documented and can direct requests to the right place, escalate problems appropriately, and disseminate CVE ID blocks efficiently, I'm not sure it will have a huge impact. |
Some minor rewording for the first paragraph of 1.2: In a federated CNA structure, CNAs are categorized as Primary, Root, and Sub-CNAs (or just "CNAs", generically). Multiple Sub-CNAs may operate under the oversight of a Root CNA, while the Root CNAs operate under the oversight of a single, Primary CNA or another Root CNA. Sub-CNAs only assign CVEs for vulnerabilities in their own products or their domain of responsibility, hereinafter referred to as scope. Root CNAs manage a group of Sub-CNAs within a given domain or community, train and admit new Sub-CNAs, and are the assigners of last resort (i.e., no Sub-CNA exists for the scope) within that domain or community. The Primary CNA oversees the CVE Program, coordinates Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs, enables Root CNAs to administer their CVE scope, and is the assigner of last resort for requesters that are unable to have CVEs assigned at the Sub- or Root CNA levels. |
GOAL: Better describe the nested Root CNA structure (with a new diagram?).
CHANGE: Describe the nested Root CNA structure. Provide diagrams to give a visual representation of the structure for further clarity.
OUTCOME: Reduce confusion when speaking about the Root CNA structure and operation.
The text was updated successfully, but these errors were encountered: