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 .containers.cna.datePublic #378

Open
zmanion opened this issue Dec 30, 2024 · 5 comments
Open

require .containers.cna.datePublic #378

zmanion opened this issue Dec 30, 2024 · 5 comments

Comments

@zmanion
Copy link
Contributor

zmanion commented Dec 30, 2024

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

@ccoffin
Copy link
Collaborator

ccoffin commented Dec 31, 2024

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.

@jayjacobs
Copy link
Collaborator

I think you might be referencing the "datePublished" field within the cveMetadata section.

  • containers.cna.datePublic is defined as "If known, the date/time the vulnerability was disclosed publicly."
  • cveMetadata.datePublished is defined as "The date/time the CVE Record was first published in the CVE List."

@jayjacobs
Copy link
Collaborator

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.

@zmanion
Copy link
Contributor Author

zmanion commented Jan 3, 2025

I assert that the "if known" part of containers.cna.datePublic is always known and the CNA should(?) be responsible for discovering it. And yes, it is at least cveMetadata.datePublished, but I'm not sure we want to automatically set this? A consumer could apply logic that datePublic must be at least datePublished. For some vulnerabilities, sorting out datePublic might require additional work for CNAs, so we should discuss, but my opinion is that this is an important quality data point.

@zmanion
Copy link
Contributor Author

zmanion commented Jan 3, 2025

Rough count of datePublic use:

Year datePublicCount totalCount
==== =============== ==========
1999             721       1579
2000            1221       1242
2001            1481       1556
2002            1900       2392
2003            1341       1553
2004            2550       2707
2005            4074       4767
2006            6768       7142
2007            6328       6580
2008            6735       7176
2009            4129       5040
2010            3840       5217
2011            3451       4861
2012            4175       5893
2013            4584       6780
2014            7849       8982
2015            7426       8748
2016            8763      10555
2017           12989      17010
2018           12979      17457
2019            3943      17018
2020            3649      20575
2021            4785      22983
2022            4245      25287
2023            5194      29080
2024            4694      32905

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