Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require all approved submission formats can capture the same information #42

Open
EvansJonathan opened this issue Jul 27, 2017 · 8 comments

Comments

@EvansJonathan
Copy link
Contributor

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

@EvansJonathan
Copy link
Contributor Author

[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).

@kurtseifried
Copy link

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.

@dadinolfi
Copy link
Contributor

Note: Issue #39 makes JSON the preferred format. Any other formats should be derivative of it moving forward.

@dadinolfi
Copy link
Contributor

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.

@EvansJonathan
Copy link
Contributor Author

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 😃.

@ghost
Copy link

ghost commented Sep 15, 2017

@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.

@EvansJonathan
Copy link
Contributor Author

@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.

@dadinolfi
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants