-
Notifications
You must be signed in to change notification settings - Fork 157
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 .containers.cna.datePublic #378
Comments
Don't disagree that this should be included in the CVE Record in every case. However, maybe we could just have CVE Services add it when it isn't provided. If datePublic is not provided by the CNA, maybe just have CVE Services define it using the same date/time as datePublished. This assumes that the vulnerability was first public the day it was published in the CVE list, but i think that's the best assumption if we don't get the datePublic. If we require datePublic, i guess it's possible that we might get a more accurate date in some cases, but is it worth it to require the field? I'd be curious what the percentage is of new CVE Records with and without this data. If most CNAs include it already, then maybe it would make sense to require it. |
I think you might be referencing the "datePublished" field within the cveMetadata section.
|
I do think that this is related to #291, and should be treated the same. I assume cve-services would handle both since the JSON schema must define both the date the CVE was published and updated. Neither should be required since they are probably overwritten, but both need to be defined in the schema for the consumers. |
I assert that the "if known" part of |
Rough count of
|
Require .containers.cna.datePublic. By defintion, a CVE ID can only exist if the vulnerability is public (ignoring the temporary period between RESERVED and PUBLISHED).
The text was updated successfully, but these errors were encountered: