Bug 13001

Summary:	Need to consider how to handle triage for reserved CVEs
Product:	[Yocto Project Subprojects] Security Response Tool	Reporter:	Ross Burton <ross.burton>
Component:	General	Assignee:	David Reyna <david.reyna>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Medium
Version:	unspecified
Target Milestone:	2.7
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Ross Burton 2018-11-09 12:59:09 UTC

CVE-2018-10195 is 'reserved' at MITRE:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10195

However Red Has has lots of details:

https://access.redhat.com/security/cve/cve-2018-10195

This means that the CVE doesn't appear in triage, and can't be searched.  It's like a ghost CVE that you'll never know about.

Could srtool know that CVEs are incrementing and if there are any gaps in the data then put them in triage so the user can see if its still reserved (and leave it pending), or discover that e.g. Red Hat has more data and triage appropriately.

Comment 1 David Reyna 2018-12-18 05:32:33 UTC

In the latest update:

1. After the NIST CVEs are scanned, the MITRE database is scanned for any CVEs that have not been created from the NIST data.

This data is the missing "reserved" CVEs.

2. When the "New" CVEs are scanned and scored, the CVE data from the alternate CVE sources are automatically registered (except for sources that are without bulk downloads and are REST accessed only).

This provides the comparison CVE sources automatically for the triage process.

Comment 2 David Reyna 2019-01-12 18:30:33 UTC

Implemented