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 date of publishing in vulnerability detail view #1355

Open
TG1999 opened this issue Dec 4, 2023 · 3 comments
Open

Add date of publishing in vulnerability detail view #1355

TG1999 opened this issue Dec 4, 2023 · 3 comments
Assignees

Comments

@TG1999
Copy link
Contributor

TG1999 commented Dec 4, 2023

ATM in VCIO a vulnerability is an object created by the culmination of multiple advisories. We will use the NVD importer publish date as default for each vulnerability, in case an advisory from the NVD is not being used in that vulnerability we will use the most oldest publishing date from other importers' advisory.

Ways to achieve this:

  • 1.) Store two DateTime fields in the vulnerability model, nvd_published_date and latest_published_date. We will populate nvd_published_date with the date/time of the NVD advisory publishing date and and latest_published_date will be keep changing as new advisories add any data in the Vulnerability, if we have nvd_published_date for a vulnerability we will always use it as a default date.

  • 2.) For every vulnerability, get a list of advisories that have the aliases of that vulnerability. If any advisory from that list is from the NVD use that date otherwise use the oldest date of publish among those advisories

  • 3.) Store a list of advisories that are used in the creation of that vulnerability in the Vulnerability model and compute the date of publish from that list of advisories. If any advisory from that list is from the NVD use that otherwise use the oldest date of publish among those advisories

@TG1999
Copy link
Contributor Author

TG1999 commented Dec 4, 2023

@pombredanne do let me know which way makes best sense, or if you have any other way in mind, let me know

@pombredanne
Copy link
Member

I would go with 3. which is where we want to go eventually for #1316
You likely also want to do 2. also to migrate the data... though I would rather avoid big database-wide data migrations for this case and instead use an improver as this is not critical data to correct before we can start VCIO. If this were a real data migration if could run for hours and the system will be unavailable for the whole time. This is a one-off improver and it is not harmful if it runs multiple times, because it would be idem-potent IMHO.

@TG1999
Copy link
Contributor Author

TG1999 commented Dec 20, 2023

blocked on merging of #1310

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

2 participants