Open EvansJonathan opened 7 years ago
[Manion 2017-07-11] All allowed formats should be consistent, moving towards JSON MVP (and optional elements) as the standard. Focus on MVP. Note multiple "vulnerability data format" efforts: CVE, CVE+DWF, CVRF/SCAF, NIST NVD, NIST vulntology. CVE format should focus on CVE mission of vulnerability identification. Connect/integrate with other formats (severity, product list, type of vulnerability) but do not build the into CVE MVP (just need the hooks/containers).
This is why I built the DWF (and adopted by CVE somewhat) format to be "containerized" and include "official" and unofficial elements, so we can dump this all in, ideally in a documnted format that can be easily parsed. E.g. if someone starts jamming in CVSSv3 JSON into an element called CVSSV3 that should be pretty self explanatory.
Note: Issue #39 makes JSON the preferred format. Any other formats should be derivative of it moving forward.
Since JSON is the preferred format, instead of maintaining separate formats, should the CSV format and the flat file format both be deprecated?
We would accept CSV and flat file using the existing formats until a specific date (I propose April 1, 2018, to give existing CNAs two quarters to update their processes), and then the Primary CNA would no longer accept submissions in anything other than the JSON format or via the CVE Request form.
My worry with ending support for the other formats is that JSON is harder to implement. I can have someone handcraft a flat file submission properly, but I would expect errors if I had them do the same in JSON. This would make it harder to bring on new CNAs.
Also, I suggest not scheduling anything on April 1st 😃.
@EvansJonathan longer term it's on my todo list to have some basic tooling to help create JSON files for CVEs that will be open sourced.
@kseifriedredhat that is great. I would like those tools created and shown to be easy for CNAs to use before we consider dropping support for the easier format.
During the 9/20 Board meeting, the Board came to a consensus that all formats should be able to capture the same specific information. Appendix B will be updated to reflect this, indicating what fields are required and which are optional.
GOAL: Include optional fields in CVE entry CSV and flat file submission standard. CHANGE: Include [INITIALRELEASEDATE], [CURRENTRELEASEDATE], [CVSSSCORE], [ACKNOWLEDGEMENT], [PUBLISHER], [CWE], [CPE]. Should we rely on the JSON format to supply this instead? OUTCOME: More metadata can be submitted in regularized formats. NOTES: Consider more scalable