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

Add publication date as a required field #45

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

Add publication date as a required field #45

EvansJonathan opened this issue Jul 27, 2017 · 6 comments

Comments

@EvansJonathan
Copy link
Contributor

GOAL: Add new required fields.
CHANGE: Should we make the publication date a required field?
OUTCOME: Enrich the metadata included in CVE entries.

@EvansJonathan
Copy link
Contributor Author

[Manion 2017-07-11]
yes (publication of the populated CVE ID, not the public disclosure date of the vulnerability?)

@kurtseifried
Copy link

Question, how do we define "public" specifically? e.g. I did a huge pile of CVE's last week, "published" them in a google sheet on Friday, but haven't gotten around to putting them into the DWF database, or the MITRE database yet. If I had put them in the public good sheet and not tweeted it, it would technically be public, but impossible to find.... I would suggest we consider in descending order:

  1. publication in MITRE DB (obvious yes)
  2. publication in sub-CNA DB/website at known location (e.g. DWF git) (strong yes)
  3. publication in some other well known location. e.g. oss-security list (pretty strong yes)
  4. publication, and announcement in other (sort of maybe yes?)

@david-waltermire
Copy link

Why not include information about all workflow publication events? E.g. pub by the CNA, pub by the root, etc.

@chandanbn
Copy link

chandanbn commented Sep 8, 2017

I would suggest a timeline or events section in the JSON to optionally record different types of events that occur in the course of vulnerability lifecycle (not just different publication dates) such as vulnerability-introduced-date, discovery-date, vendor-notification-date. These should be optional, but if the information is available and the CNA or the researcher wants to provide them, it would be useful from a curation point of view.

@dadinolfi
Copy link
Contributor

dadinolfi commented Sep 12, 2017

For a vulnerability to be considered "public", per 2.1.1:

Note: for a vulnerability to be considered "public", the following conditions must be met:
• There must be a URL including information about the vulnerability accessible from the internet.
• The Terms of Use of the website must allow the CVE List to link to the URL.
• The document linked by the URL must contain the minimum required information for a CVE Entry (see Appendix B).
Registration and login requirements are acceptable, but there cannot be other restrictions for accessing that content. Also, advisories that require payment for access are not considered public. That said, if you have a public advisory with the minimum required details with additional details available through paid access, the vulnerability is still considered public.

Therefore, the "publication date" should be the date that the conditions above are met.

@dadinolfi
Copy link
Contributor

Note, this is related to #12, as they go hand-in-hand. If we are tracking when things happen, we can also track who makes it happen.

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

5 participants