You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should QWG try to estimate which types of non-CNA community members are most affected by the rollout of JSON 5, and what communication they require to continue doing their work?
For example, AWG is holding a workshop for the CNA audience on September 23, covering JSON 5 and CVE Services 2.0. No part of the CVE Program has announced anything analogous for a non-CNA audience.
There is, of course, a very wide variety of non-CNA organizations who may ultimately be affected by JSON 5 in vastly different ways. Here is one example that might represent a simple case of a JSON 5 dependency for a non-CNA organization.
The U.S. government publishes a weekly CISA Vulnerability Bulletin - for example, the https://us-cert.cisa.gov/ncas/bulletins/sb21-186 document. (Although part of CISA has a CNA, the bulletin isn't a product of that CNA.) A bulletin can contain a CVE description of the form:
CVE-2021-35958
** DISPUTED ** TensorFlow through 2.5.0 allows attackers to overwrite arbitrary files via a crafted archive when tf.keras.utils.get_file is used with extract=True. NOTE: the vendor's position is that tf.keras.utils.get_file is not intended for untrusted archives.
Some CISA Vulnerability Bulletin reader organizations (inside and outside the government) use TensorFlow, and are required to make a decision about whether they need to take action to mitigate CVE-2021-35958. It's plausible that an organization has an operational policy in which the decision process (and the time scale for making the decision) depends on whether the exact term "** DISPUTED **" is present.
If CVE-2021-35958 had originally been published in JSON 5, then "** DISPUTED **" would (or should) not be present in the Prose Description. Instead, there would be a "disputed" tag in the CNA container. If CISA does nothing after the JSON 5 transition, then "disputed" information might, in effect, disappear. Even if CISA does not rely on JSON 4 records today to produce a Vulnerability Bulletin, they might start to rely on JSON 5 records if that were important to the quality of their bulletin. Also, other organizations may rely on JSON 5 records to prepare similar vulnerability-information resources for their own constituents (in which the resource shows the Prose Description but not the full CVE Record).
Some of the outcomes available to QWG are:
Produce documentation about the meaning of the "disputed" tag in the CNA container, noting that this is a data element that has moved during the JSON 4 to 5 transition (not a brand new element), with examples of how this data element could be used during production of a vulnerability-information resource. One example is that the CISA could choose to rely directly on JSON 5 records, but prepend the "** DISPUTED **" text to a Prose Description in their bulletin for backwards compatibility. Another example is that CISA could choose to rely directly on JSON 5 records, and add a "Disputed" column in their bulletin.
Produce documentation highlighting data elements that have moved, and also highlighting some of the data elements that are newly standardized (if they are expected to have widespread interest to CVE consumers). For example, after seeing this documentation, CISA might choose to revise its Vulnerability Bulletin production so that it parses JSON 5 records to capture both "disputed" information and also capture any CVSS scores that were calculated by CNAs.
Produce documentation suggesting that, in many cases, third parties should not directly rely on JSON 5 records when producing a vulnerability-information resource, but should instead rely on NVD. For example, when CVE Services receives a JSON 5 record directly from a CNA (with that disputed tag), and NVD consumes that JSON 5 record for an https://nvd.nist.gov/vuln/detail/CVE-2021-xxxxx page, it is possible that NVD will prepend "** DISPUTED **" to the NVD Current Description field. It is neither required nor forbidden for NVD to do this. However, if NVD does do this, then the CISA Vulnerability Bulletin (which is a derivative work of NVD) might be able to continue to produce its Description column in exactly the same way as before.
Decide that QWG has no recommendation on how a vulnerability-information resource could convey the "disputed" tag, and do not produce any examples. In other words, QWG is only responsible for documenting the meaning of all JSON 5 data elements, not for anticipating which data elements may most affect downstream consumers. Similarly, the CVE Website team is eventually responsible for displaying the "disputed" tag on cve.org, but is not responsible for suggesting what any third party (e.g., CISA) might do with the "disputed" tag within their own third-party product. In particular, QWG is not responsible for alerting anyone about a potential surprise that the "disputed" information has now moved outside of the Prose Description field. In the above example, future CISA Vulnerability Bulletins would likely begin to omit "disputed" information, unless someone at CISA proactively read the full JSON 5 documentation, and reached their own conclusion that they needed a new strategy to convey "disputed" information to bulletin readers.
Should QWG try to estimate which types of non-CNA community members are most affected by the rollout of JSON 5, and what communication they require to continue doing their work?
For example, AWG is holding a workshop for the CNA audience on September 23, covering JSON 5 and CVE Services 2.0. No part of the CVE Program has announced anything analogous for a non-CNA audience.
There is, of course, a very wide variety of non-CNA organizations who may ultimately be affected by JSON 5 in vastly different ways. Here is one example that might represent a simple case of a JSON 5 dependency for a non-CNA organization.
The U.S. government publishes a weekly CISA Vulnerability Bulletin - for example, the https://us-cert.cisa.gov/ncas/bulletins/sb21-186 document. (Although part of CISA has a CNA, the bulletin isn't a product of that CNA.) A bulletin can contain a CVE description of the form:
Some CISA Vulnerability Bulletin reader organizations (inside and outside the government) use TensorFlow, and are required to make a decision about whether they need to take action to mitigate CVE-2021-35958. It's plausible that an organization has an operational policy in which the decision process (and the time scale for making the decision) depends on whether the exact term "** DISPUTED **" is present.
If CVE-2021-35958 had originally been published in JSON 5, then "** DISPUTED **" would (or should) not be present in the Prose Description. Instead, there would be a "disputed" tag in the CNA container. If CISA does nothing after the JSON 5 transition, then "disputed" information might, in effect, disappear. Even if CISA does not rely on JSON 4 records today to produce a Vulnerability Bulletin, they might start to rely on JSON 5 records if that were important to the quality of their bulletin. Also, other organizations may rely on JSON 5 records to prepare similar vulnerability-information resources for their own constituents (in which the resource shows the Prose Description but not the full CVE Record).
Some of the outcomes available to QWG are:
Produce documentation about the meaning of the "disputed" tag in the CNA container, noting that this is a data element that has moved during the JSON 4 to 5 transition (not a brand new element), with examples of how this data element could be used during production of a vulnerability-information resource. One example is that the CISA could choose to rely directly on JSON 5 records, but prepend the "** DISPUTED **" text to a Prose Description in their bulletin for backwards compatibility. Another example is that CISA could choose to rely directly on JSON 5 records, and add a "Disputed" column in their bulletin.
Produce documentation highlighting data elements that have moved, and also highlighting some of the data elements that are newly standardized (if they are expected to have widespread interest to CVE consumers). For example, after seeing this documentation, CISA might choose to revise its Vulnerability Bulletin production so that it parses JSON 5 records to capture both "disputed" information and also capture any CVSS scores that were calculated by CNAs.
Produce documentation suggesting that, in many cases, third parties should not directly rely on JSON 5 records when producing a vulnerability-information resource, but should instead rely on NVD. For example, when CVE Services receives a JSON 5 record directly from a CNA (with that disputed tag), and NVD consumes that JSON 5 record for an https://nvd.nist.gov/vuln/detail/CVE-2021-xxxxx page, it is possible that NVD will prepend "** DISPUTED **" to the NVD Current Description field. It is neither required nor forbidden for NVD to do this. However, if NVD does do this, then the CISA Vulnerability Bulletin (which is a derivative work of NVD) might be able to continue to produce its Description column in exactly the same way as before.
Decide that QWG has no recommendation on how a vulnerability-information resource could convey the "disputed" tag, and do not produce any examples. In other words, QWG is only responsible for documenting the meaning of all JSON 5 data elements, not for anticipating which data elements may most affect downstream consumers. Similarly, the CVE Website team is eventually responsible for displaying the "disputed" tag on cve.org, but is not responsible for suggesting what any third party (e.g., CISA) might do with the "disputed" tag within their own third-party product. In particular, QWG is not responsible for alerting anyone about a potential surprise that the "disputed" information has now moved outside of the Prose Description field. In the above example, future CISA Vulnerability Bulletins would likely begin to omit "disputed" information, unless someone at CISA proactively read the full JSON 5 documentation, and reached their own conclusion that they needed a new strategy to convey "disputed" information to bulletin readers.
Offer a recommendation that all CVE derivative works shall provide information about the full CVE Record. For example, a CISA Vulnerability Bulletin should contain an annotated link or footnote stating "The Description column is not the full CVE Record. To obtain the full CVE Record, go to https://github.com/CVEProject/cvelist5/blob/master/2022/0xxx/CVE-2022-0001.json and refer to documentation available on the https://cve.org/ProgramOrganization/WorkingGroups#QualityWorkingGroupQWG and https://github.com/CVEProject/cve-schema/blob/master/schema/v5.0/CVE_JSON_5.0.schema websites." In other words, the CVE Program specifically does not want any third party to display or announce new CVE Records with only a subset of the record content, unless the third-party resource offers its own navigation to the full record content, or informs the reader about where the full record content can be found.
The text was updated successfully, but these errors were encountered: