Create a best practices of the CVE JSON usage

[sei-vsarvepalli]

There are potential valid CVE JSON record are valid as far as CVE5JSON schema goes, but have information that is not very meaningful. This may be due to the lack of examples in this repository or due to lack of additional guidance. The proposal is to update the version.md file and add a new best-practices.md to capture some guidelines to help CNA's have sufficient guidance to provide quality data for the CVE Program.

Two examples from the CVE-2023-30906 that illustrate the affected versions being misunderstood

1. CVE-2023-30906 has affected/0/defaultStatus as unaffected and the affected/0/versions/0/status is also unaffected - this suggest no product is affected in the CVE record.
2. CVE-2023-30906 has affected/0/versions/0/version shows v2.87 or later which likely actually means versions below 2.87 are affected should be in JSON like
   "versions": [{ "status": "affected", "version": "0", "lessThan": "2.87" }

Related issue from #215 - versions affected.

[sei-vsarvepalli]

Discussion in AWG July 25, 2023 - participants added a scenario where every version mentioned in the CVE records is affected and there is no patched version, at least according the information provided in CVE. This can be correct only if the CVE record is also marked as "End of Life"

An example was shared https://cveawg.mitre.org/api/cve/CVE-2021-26411 according to initial record all the versions of Edge is "affected" leaving none of the versions can be identified as patched or fixed.

@jgamblin shared a script used from NVD data that can help identify potential nonsensical values seen in the "affected" field https://gist.github.com/jgamblin/356dbf593192587aa21679841f37b932 - this can be helpful in narrowing down guidance with examples.

There may also be NVD data that identifies CPE that did not come from the vendor or from the CNA, which is nonsensical or impossible to parse and identify affected and patched products.

[jgamblin]

Thanks @sei-vsarvepalli!

My team has tracked down a bunch of these and worked with NVD over the last two years to change cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* to cpe:2.3:a:google:chrome:-:*:*:*:*:*:*:* which doesn't allow us to identify the version that is actually vulnerable but does stop it from flagging on every version.

One CVE that still has cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* and cpe:2.3:a:mozilla:firefox:*:*:*:*:*:*:*:* is:
https://nvd.nist.gov/vuln/detail/CVE-2012-4930

[sei-vsarvepalli]

Thanks @sei-vsarvepalli!

My team has tracked down a bunch of these and worked with NVD over the last two years to change cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* to cpe:2.3:a:google:chrome:-:*:*:*:*:*:*:* which doesn't allow us to identify the version that is actually vulnerable but does stop it from flagging on every version.

One CVE that still has cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* and cpe:2.3:a:mozilla:firefox:*:*:*:*:*:*:*:* is: https://nvd.nist.gov/vuln/detail/CVE-2012-4930

Very helpful. I think our best practices document will helpfully target new submissions with CVE JSON5.x schema documents submitted via CVE Services 2.x. I think legacy data before that has so many issues with the affected field that was upconverted programmatically from an earlier schema. However this data is very useful in seeing patterns of poor behavior.

[sei-vsarvepalli]

More questions from CERT/CC team members

1. Zero-Day CVE's - is it assumed that a zero-day CVE is NOT in Published state?
2. What if a mitigation or workaround is available but no fixed versions are available, can this be in Published state with no affected version ?
3. We should also consider CVE EoL for e.g., - here https://cveawg.mitre.org/api/cve/CVE-2023-3091

[andrewpollock]

I think it's important to state assumptions. We had a related discussion recently regarding OSV records and biasing for false negatives over false positives.

OSV makes no assumptions about the "fixedness" of a vulnerability at the time a record is published. It does assume that if a last_affected version or commit is specified that the next available version will fix the vulnerability.

https://ossf.github.io/osv-schema/#affected-fields

[sei-vsarvepalli]

At this time, CVE Records for unaffected as the status shows only 25 entries in CVE Records. I have enclosed the analysis done by my colleague here.
unaffected-2023080301.csv

CSV has
CVE#|STATE|CNA|defaultStatus|status*|Count

The Count is the number of affected[]/versions[]/status/ with unaffected status.

It looks like most entries are some specific CNA's who may be can be reached and educated. Enforcing in CVE publishing clients will also help before this gets to be too big to resolve.

18 hpe
2 canonical
1 vmware
1 redhat
1 forcepoint
1 dell
1 apache

[chandanbn]

Please include the concern in #181 in the doc.

[sei-vsarvepalli]

Also reference : https://www.cve.org/ResourcesSupport/AllResources/CNARules "MUST contain the affected or fixed version(s)." In terms of this proposal, a CNA could state that there is one fixed version, and that defaultStatus is (by default) unknown.

[sei-vsarvepalli]

Also consider these two issues to be addressed.

CVEProject/cvelistV5#6

CVEProject/cvelistV5#21

[sei-vsarvepalli]

I am in the process of making the best practices in a forked document.
https://github.com/sei-vsarvepalli/cve-schema/blob/sei-vsarvepalli-best-practices/schema/v5.0/docs/best_practices.md

I would like to get some community input on some of these questions

1. The title vs description fields - do we expect more information in the description field than title?
2. Currently our versionType is a free form text with only examples - any reason we should not restrict this to an enum - allowing custom to be used as a catchall? We could also specific semver-1.0 vs semver-2.0 as distinct and add caller to it as well.
3. Should the section Interacting with the API also be part of this Best Practices.

Please reply to this thread so we can have open discussion and ideas from you.

[andrewpollock]

/cc @oliverchang as he may have thoughts to add here as well.

• The title vs description fields - do we expect more information in the description field than title?

In my opinion (comparing with the OSV Schema), yes. The title should be a short one-line summary, and the description can be as long-form as it needs to be. Both should be for human consumption, and it should be considered a bug if the description contains more actionable version information than the affected field. e.g. https://github.com/CVEProject/cvelistV5/blob/ac4381d93bd70d5c72f446c0e632a011c4e6a6fe/cves/2023/36xxx/CVE-2023-36054.json makes me sad.

• Currently our versionType is a free form text with only examples - any reason we should not restrict this to an enum - allowing custom to be used as a catchall? We could also specific semver-1.0 vs semver-2.0 as distinct and add caller to it as well.

This sounds analogous to the OSV Schema's affected[].ranges[].type field.

• Should the section Interacting with the API also be part of this Best Practices.

I have no opinion here.#220

[zmanion]

Discussion in AWG July 25, 2023 - participants added a scenario where every version mentioned in the CVE records is affected and there is no patched version, at least according the information provided in CVE. This can be correct only if the CVE record is also marked as "End of Life"

I'd argue that it is valid for a CVE record to only list affected products and not have any fixes and not be marked unsupported-when-assigned. CVE identifies vulnerabilities, regeardless of fixes.

[zmanion]

Note that the CVE Numbering Authority (CNA) Rules are under significant revision, with a draft available to CNAs and other stakeholders hopefully by the end of September. If the timing works out, it would be better for the best practices doc and the new rules revision to be in sync.