Create a best practices of the CVE JSON usage #241
Comments
|
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. |
|
Thanks @sei-vsarvepalli! My team has tracked down a bunch of these and worked with NVD over the last two years to change One CVE that still has |
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 |
|
More questions from CERT/CC team members
|
|
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 |
|
At this time, CVE Records for CSV has The Count is the number of affected[]/versions[]/status/ with 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 |
|
Please include the concern in #181 in the doc. |
|
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. |
|
Also consider these two issues to be addressed. |
|
I am in the process of making the best practices in a forked document. I would like to get some community input on some of these questions
Please reply to this thread so we can have open discussion and ideas from you. |
|
/cc @oliverchang as he may have thoughts to add here as well.
In my opinion (comparing with the OSV Schema), yes. The
This sounds analogous to the OSV Schema's
I have no opinion here.#220 |
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. |
|
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. |
This is important to decide (or maybe review) and document. I don't think CVE makes any assumptions (and we should state this somewhere). There is a defaultStatus field which defaults to "unknown." Yesterday I was looking at https://www.cve.org/CVERecord?id=CVE-2022-27518, looking only at that record I can't tell if anything has been fixed. Looking at the reference, Citrix has indeed provided fixes. The CVE record of course allows a CNA to convey when fixes exist, what is missing might be a process requirement or recommendation for CNAs to update records to specifically include fix information. |
|
On Thu, 24 Aug 2023 at 02:51, Art Manion ***@***.***> wrote:
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
This is important to decide (or maybe review) and document. I don't think
CVE makes any assumptions (and we should state this somewhere). There is a
defaultStatus field which defaults to "unknown."
This is getting towards the root of the discussion I have been wanting to
have. I'm not convinced this is the right place for it, but given we're
talking about the topic, I'll start here, and we can reconvene it elsewhere
as appropriate...
What is the intention of a CVE record?
What is the utility of a CVE record that conveys a defaultStatus of
"unknown"?
Who is a CVE record for?
Basically, I'm asking about how fitness for purpose is determined.
More broadly, what is the purpose of the CVE Program (given it's ultimately
a collection of CVE records)
Who are its customers?
What are their needs?
How is the CVE Program's success at meeting their needs being evaluated?
I can refer myself to the CVE Program's mission statement: "Identify,
define, and catalog publicly disclosed cybersecurity vulnerabilities."
This statement doesn't seem to be touching on the "for who?" or "and then
what?" or really, the "why?"
If the vulnerabilities are being identified, defined and cataloged to a
minimum standard of "defaultStatus: unknown", and that's deemed to be
acceptable, then I'm questioning if that's actually providing any benefit
to anyone.
Yesterday I was looking at https://www.cve.org/CVERecord?id=CVE-2022-27518,
looking only at that record I can't tell if anything has been fixed.
Looking at the reference, Citrix has indeed provided fixes. The CVE record
of course allows a CNA to convey when fixes exist, what is missing might be
a process requirement or recommendation for CNAs to update records to
specifically include fix information.
I've been running records like this through an internal filter of:
Is this record conveying actionable information to a consumer of it?
To Vijay's point that started this conversation (and thank you Vijay for
doing it), if a record cannot convey to its consumers, the answer to the
question "Is this software I have installed vulnerable to this
vulnerability, do I need to take any action?" then I do not feel like it is
achieving its intended purpose, even though that intended purpose isn't
currently explicitly spelled out (I'm happy to be corrected on this).
With the best of intentions,
Andrew
… —
Reply to this email directly, view it on GitHub
<#241 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUWBPVJUD2RUNCOVJESYA3XWYYJVANCNFSM6AAAAAA2R73ZGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Andrew Pollock
Software Engineer, Google Open Source Security Team | ***@***.***
Google LLC
This email is confidential. If you are not the right addressee, please
inform the sender and please erase this email including any attachments.
|
|
Thorough as always, I think this question is for the SPWG I am not in the SPWG. It looks like the GH page is not active, however I went ahead and created an issue there as well so we can track this and hopefully capture some responses that may either be already in the works or can be provided. Vijay |
|
I'm going to respond in two comments. For background, I've beein closely involved in CVE for a long time. So I have opinions and bias and have probably internalized things that may not be written down, clearly, or at all. Also I'm not claiming to fully represent the CVE Board or all of the CVE Program here. Also happy to take this elsewhere but I'm not sure where. A specific opinion of mine that may not be the majority: CVE is identification. More is needed to perform various vulnerability management activities. Identification is necessary but not sufficient. Identification gets a little tricky as we are defining the abstract (and subjective) concept of "a vulnerability" (or two, or five). From @andrewpollock:
To identify a publicly disclosed vulnerability.
To identify a publicly disclosed vulnerability. "Unknown" should often be a transient status, and could indicate that an investigation is ongoing. Or "unknown" could indicate that the issuing CNA does not intend to investigate EoL products. If at least one "product" in a CVE Record is not "affected" (perhaps after investigation) then philosophically one could argue that there is no vulnerability.
Any and everyone. A little more precisely, those engaged in (broadly defined) vulnerability management.
To (sufficiently) identify (and deduplicate) publicly disclosed vulnerabilities.
The public, but more specificaly vulnerability managers. Much of the U.S. government. Possibly the EU. Current funding is U.S. government, DHS CISA. Vulnerability identification as a public service.
To identify publicly disclosed vulnerabilities (as a necessary but insufficient part of a variety of vulnerability management activities).
A couple metrics I can quickly think of:
I'm not aware of any official quality metrics, I'm generally aware that others have tried to assess CVE quality. Some quality enforcement can be automated, some requires manual effort.
I don't disagree, and won't argue much about which things go in mission, vision, goals, etc. But there is a modular idea here that the follow on activities are perhaps not something CVE specifies or concerns itself with. Of course CVE is very aware of "who" and "what next" and at least some of "why" -- much of the CVE Program membership are vulnerability managers of various types.
I'd consider this sort of record to be of poor quatliy and something CVE can address at a system level (e.g., rules that disallow a long-lasting "unknown" status). However this record is still a benefit, now we can go argue about the value and quality of CVE-2022-27518 (and I can at least follow a reference to the vendor's more up-to-date information) instead of talking about "the Citrix ADC SAML vulnerability, no the other one, from December 2022." Identification alone is valuable, important, and necessary, even when record quality varies. |
|
From @andrewpollock:
I guess I probably don't need this second comment and will be repeating myself, but anyway: I agree that CVE-2022-27518 does not meet the use case of "Am I affected and what should I do?" The current CVE preference would be for the CNA (Citrix) to update the CVE Record. This record does meet the (very basic but critical) use case of "What are we even talking about." CVE wants to do more than identification, and even minimal identification requires information about what is affected, what is fixed, some detail about the vulnerability. But even an out-of-date or low-quality record likely still fulfills the need for identification. |
|
Thanks for your input @zmanion @sei-vsarvepalli had cross-posted my questions that you've responded to at CVEProject/strategic-planning-working-group#2 which may be a more appropriate place to have this conversation? |
Yep that would probably be a better place to discuss, although the SPWG doesn't use that repo regularly. FWIW I'll make the CVE Board and SPWG aware of this discussion, others may have input. |
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.mdto 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 versionsbeing misunderstoodunaffectedand the affected/0/versions/0/status is alsounaffected- this suggest no product isaffectedin the CVE record.v2.87 or laterwhich 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.
The text was updated successfully, but these errors were encountered: