feat(vulnfeeds): handle rejected CVEs and propagate withdrawn status - #5761
feat(vulnfeeds): handle rejected CVEs and propagate withdrawn status#5761jess-lowe wants to merge 12 commits into
Conversation
another-rex
left a comment
There was a problem hiding this comment.
If a rejected CVE is brand new to us, we ignore it.
Should we also just be publishing withdrawn entires for them rather than ignoring it?
At least, should we be doing this in the cve and nvd versions, and then in combine-to-osv decide whether to publish it. (To avoid cases where it's withdrawn in nvd, but there in cve, and we're just publishing it as if cve is the only source and not correctly marking it as withdrawn.)
another-rex
left a comment
There was a problem hiding this comment.
Some questions, but otherwise everything else LGTM.
|
|
||
| var withdrawnTime *timestamppb.Timestamp | ||
| if cve.Metadata.State == "REJECTED" { | ||
| withdrawnTime = timestamppb.New(modified) |
There was a problem hiding this comment.
It looks like there's also "dateRejected", which might fit better here?
There was a problem hiding this comment.
There was a problem hiding this comment.
good point - updated for cve5. nvd doesn't seem to have an equivalent so I'll keep it as modified date
| v.DatabaseSpecific = databaseSpecific | ||
| } | ||
|
|
||
| return v, metrics, models.Rejected |
There was a problem hiding this comment.
Hmm this returns early while the CVE one doesn't. Is this because NVD removes most of the details once it rejects a record?
There was a problem hiding this comment.
I've made them both return early now - information outside the basic stuff isn't really relevant after rejection
If a CVE is marked as Rejected upstream (in NVD or CVEList), OSV will now handle it properly instead of ignoring the change or keeping stale data.
How it works
(Tested and verified with local scripts and unit tests).
Closes #4610