Define how to handle third-party updates to a CNA's entry.

[EvansJonathan]

GOAL: Make the CNA processes more standardized and repeatable.
CHANGE Define how to handle third-party updates to a CNA's entry. References? Description changes?
OUTCOME: Set expectations, consistent results, and transparent processes.

[kurtseifried]

this is actually quite complicated but we defined MITRE as "the source of truth" (e.g. DWF assigns CVE, submits to MITRE, 3rd party then updates it via MITRE, DWF is now out of synch, that's the DWF's problem now). I suggest we simply use that (yes this creates a race condition, but hopefully it is minimized).

[EvansJonathan]

I don't think we want MITRE to the single point of failure here. If the assigning CNA can handle it, then they should. Also, one of the incentives for a company to become a CNA is so that it has a say in the process for the CVEs about its products. Not all CNAs will care, but for this is an important issue.

[david-waltermire]

This is something we need to work out as part of the Git pilot. NVD is working towards being able to publish information back. We may be a good test case/driver for this.

[dadinolfi]

Let's answer some root questions first, and please comment on the responses or if you think any other questions need answering before we talk about specific process.

Why might a CVE entry be updated?

• add/update reference
• update description
• resolve the existence of a duplicate entry
• reject entry

Regardless of process, who would update a CVE entry after it has been populated? Who are the distinct parties that would be requesting an update?

• CNA that assigned the CVE ID
• third-party with information not currently included in the CVE entry
• Root or Primary CNA resolving an issue with the CVE entry

If a CVE entry was created by a CNA (not the Primary), can they choose to vet any updates before they are made? If so, can other CNAs choose to just allow any update to the entries they created? In other words, should we be assuming that not all CNAs will need to be in the critical path of a CVE entry update?

• As with many of the CNA rules, the philosophy we have driven toward is the rules should not force a CNA to follow business practices that don't serve an important purpose for the CVE program. Ignoring the technical process, if we allow CNAs to choose if they want to vet changes or not, we enable them more freedom in building their vulnerability management programs. If we lock it to must/cannot vet, we limit their options and potentially create more work or reduce their control in ways that don't match their business. This hybrid models satisfies the needs of the largest number of stakeholders.

[ghost]

Ok so the DWF process for this is simple (not implemented yet, but soon), basically:

1. CVE request comes in, lives in spreadsheet for public, email for private
2. CVE is assigned
3. once CVE is public JSON is created and committed to DWF repo, then also to cvelist MITRE repo
4. once MITRE accepts the entry in cvelist repo DWF deletes it from our end

If DWF needs to update a CVE we pull it from cvelist, update it, and commit it back.

Essentially MITRE's cvelist repo becomes our source of truth. We don't have to keep things in synch, etc. unless we're actually in the process of modifying them. This will work even better longer term if MITRE moves the cvelist to a public repo and so on.

[dadinolfi]

Suggestion:

Change title of Appendix E from "Process to Correct Counting Issues" to "Process to Correct Counting Issues or Update CVE Entries"

Add the following to Appendix E:

---

In general, a CVE entry may be updated in order to:
• Add or update a reference;
• Update a description;
• Resolve the existence of a duplicate entry; or
• Reject an entry.
These updates may be initiated by:
• The CNA that assigned the CVE ID;
• A third-party with information not currently included in the CVE entry; or
• A Root or the Primary CNA resolving an issue with the CVE entry.
As part of a CNA’s vulnerability management process, a CNA can choose whether they wish to vet any updates to CVE IDs that they assigned. The process for communicating those changes between CNAs and requesters will vary depending on the CNA. It is not a requirement that CNAs must vet changes to their CNA entries.

---

[EvansJonathan]

If a CNA chooses to vet the updates, do they get the final say? I think there is somewhere else in the rules that says the Primary CNA has final say over all content decisions.

Can a CNA choose to vet some changes but not others? For example, a CNA may not care about adding references, but would care about the description being changed.

How would someone know whether CNA decided to vet updates? Is that information going to be added to the CNA directory?

[ghost]

So for updates it's easy with git, someone submits a change request and then the CNA commits it, or not, if they do commit it they can add a commit message like "REF update, auto accepted" or "change of description, signed off by Bob Smith".

[dadinolfi]

@EvansJonathan All your questions are good ones, but they are questions we cannot answer right now since we do not have enough experience with this. For now, we do not have unified processes for this vetting. As mentioned, each CNA probably has different needs.

I'm proposing we leave the specific process outside of the Rules. When we have more infrastructure available, we could create a portal or something similar that would allow CNAs to set their preferences and display them in our directory or some such. For now, we can see how much of an operational issue this will be, learn from it, and adapt more quickly with process than we can update the Rules document.

As @kseifriedredhat shows, some of these issues can be resolved by the CNAs themselves. Let's find out the implications of such a change.

[ghost]

I think also if everyone treats MITRE as the source of truth this problem will largely be a non issue, and regardless of what we do, if multiple parties want to modify the global description at the same time for example, we'd have some sort of merge situation, which git gets us in spades.