Track date timestamps in vulnerability data

[wagoodman]

What would you like to be added:
Where possible, track the following timestamps for each provider:

• published date
• modified date
• withdrawn date
• fix date (if there is a fix)

Why is this needed:
This is very helpful in terms of understanding what data has changed in the grype DB, especially when grype DB v6 schema lands.

Additional context:

Here's what I see today in terms of providers need work (github and nvd are not listed since they already capture this information and output it as results):

Provider	Published	Modified	Fixed	Withdrawn	Comments
alpine	⚠️	⚠️	❌	✅	Use NVD date info (publish + modified + withdrawn) + aports git timestamps (publish + modified). Fixed dates not available in current sources
wolfi	✅	✅	⚠️	✅	Port to using advisories over secdb (however, this might not be stable). Fixed dates available in advisory data
chainguard	✅	✅	⚠️	✅	Port to using advisories over secdb (however, this might not be stable). Fixed dates available in advisory data
amazon	✅	✅	❌	❌	Use XML pubdate + HTML span info. Fixed dates not available in current data sources
debian	✅	❌	❌	❌	Dates listed for each DSA. Important: Legacy distros not covered. Fixed dates not clear from current DSA format
mariner	✅	❌	❌	❌	Use advisory_date field in OVAL XML. Fixed dates not available in OVAL format
oracle	✅	❌	❌	❌	Use issued field in elsa-all XML. Fixed dates not available in current XML structure
rhel	✅	✅	⚠️	❌	Use issued and updated in OVAL XML. RHSA has tracking.initial_release_date but ideally would use binary package timestamps from Rocky Linux source
sles	✅	✅	❌	❌	Use issued and updated in OVAL XML. Fixed dates not available in current OVAL format
ubuntu	⚠️	⚠️	⚠️	❌	Use git timestamp for each commit when processing (modified). Published requires more effort. Fixed dates require fetching normalized CVE data from USN records

Legend Explanation

• ✅ - Data is trivially accessible from existing input data already being downloaded.
• ⚠️ - Possible to associate the data but will require more work (or downloading more data sources).
• ❌ - Not clear where to get this information from.

This work depends on adding date information to be added to the OS workspace schema #266

Current development status

Provider	Published	Modified	Fixed	Withdrawn	PR
oracle	✅	-	-	-	exists already

[zhill]

I think there is a good use-case for specifically tracking when fix information is added to a record outside of just the broader "Modified" category if that information available.

[wagoodman]

Good call -- the v6 schema has a spot for this but it is not really leveraged yet, I'll update this table...