再保险:CNA规则公告

> > 2.2.9。发布需要CVE信息以标准格式> >表示,决定和管理由CVE项目(区域> >板?)>这是为什么“TBD”?不是CVRF符合要求?>如果不满足CVE项目的要求,是时候考虑这些而修改>创建另一个CVRF CVRF代替。(HB)我认为你指的是提交CVRF成绿洲,和即将到来的修订。CVRF修订进入绿洲是专门关注创建一个咨询格式而不是脆弱的格式。就我个人而言,我希望它是否则,但那是发达的共识在TC的发展建议。仍然是需要有漏洞的某种特定格式交换漏洞信息,希望可以使用相同的词汇,它是有用的。> > [CVEID]: > >[产品]:> >(版本):> > [PROBLEMTYPE]: > >[引用]:> >[描述]:>似乎这是重塑CVRF的一个简化版本。>为什么不使用相同的词汇用于CVRF(见1),避免>不得不解决相同的模棱两可CVRF已经解决了吗? >'VERSION' alone is ambiguous. It is ambiguous in the example given. >Suggestion: Use any of: Fixed-Version, Known-Affected-Version, >Last-Affected-Version, First-Fixed-Version, see [1] for more. >Instead of 'REFERENCES' use 'Reference' and allow repeats. >Note that CVRF uses 'Title' or 'Note' instead of 'DESCRIPTION'. [HB] Yes, CVRF uses 'Note' but they have an extra attribute called 'type' with a value of the same name and semantic meaning. Since they were creating an advisory format and not a vulnerability format they used 'Description' for a different purpose at the document level instead of the vulnerability level. There are several examples of names that would have naturally been used at the vulnerability level but instead were included at the document level throughout the CVRF dictionary and alternate names/methods were employed to arrive at the same semantics. >In addition to these, it may be useful to include the following >optional fields (or any other field from the CVRF dictionary) to make >the format future proof. If CVRF is lacking a particular field, that >should be brought up >during its revision. [HB] I have concerns as to whether CVRF is the correct venue for a vulnerability format given the goals the OASIS TC has set for itself. >InitialReleaseDate >CurrentReleaseDate >CVSSScore >Acknowledgement >Publisher >CWE >CPE >While the given example works for a single vendor single product, >without unambiguous guidance on how to encode multiple products, >vendors or versions, it can become complicated (i.e we will be >reinventing the CVRF wheel) [HB] I would agree that some sort of unambiguous structure/language is needed but I would argue that, although better than just VERSION, what is provided by CVRF is not expressive enough either. [HB] Additionally, I would note that the NVD has implemented the ability to parse and ingest CVRF documents from the 4 vendors we have found that implement it (if Juniper does as well let me know), no two of the vendors have implemented it the same (especially around the product area) and we have written vendor/feed specific rules to assist in processing the files. If CVE were to use CVRF then it would be necessary to develop a CVE specific profile that everyone would need to adopt. Also, given the change in tastes and current practice, JSON is or has become the preferred data exchange syntax for many (NVD receives requests for us to implement JSON fairly often) and I think that is something that may need consideration as well, but I would agree that using a common dictionary/taxonomy/ontology to bind multiple formats is a must.