OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [csaf] Switching to use the first.org JSON schemas for CVSS scoring - issue #3


Hi Omar and others,

Those of you with real CVRF data - do we have cases where we have CVSS scores, but no vector?

Eric.

On Mon, Nov 18, 2019 at 2:38 PM Luke Tamagna-Darr <ltamagnadarr@tenable.com> wrote:
I don't have any additional options to offer. I don't like option 2. Even if we can narrow down to a set of CVSS vectors - a single score can easily be associated with multiple vectors - at best we can just guess which of those vectors is the correct one and the reality is that the vector is the important component for anyone that wants to understand the vulnerability beyondÂa simple score.

I lean towards option 3, refuse to convert such documents, and issue a warning that a cvss vector is not available.ÂÂ

Lucas Tamagna-DarrÂ| Director of Engineering - Detection Automation
Tenable Network Security

ltamagnadarr@tenable.com




On Thu, Nov 14, 2019 at 11:48 PM Eric Johnson <eric@tibco.com> wrote:
See previous emails for issues #1, #2 related to using JSON schema from first.org. This email raises a 3rd issue.

The existing CVRF specification allows CVSS scores to be provided, without requiring that a CVSS vector also be provided. The CVSS schemas from first.org require the presence of the CVSS vector.

Question:
  • How do we address the compatibility question that raises. How can existing CVRF documents migrate to CSAF, if vectors may not be present in the original CVRF?
Up until this point, the CSAF document format has been compatible with the existing CVRF format. However, with the switch to using JSON schemas from first.org, if a CVRF instance does not contain a CVSS vector, then it cannot be converted to the CSAF JSON form without being out of compliance.

Options that I've thought of:
  • Define a "placeholder" vector that satisfies the RE, but is obviously a bogus vector, and use that.
  • Build an exhaustive table of every possible score, and the vectors that produce it. When producing a JSON document, provide a vector from that table.
  • Refuse to convert such documents.
Thoughts?

Eric.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]