google
NVD description version extraction needs improvement
** Vulnerabilities** OSV CVE-2022-33967 -- NVD CVE-2022-33967
OSV CVE-CVE-2022-30552 -- NVD CVE-2022-CVE-2022-30552
OSV CVE-2022-30790 -- CVE-2022-30790
OSV CVE-2022-30790 -- NVD CVE-2022-30790
Describe the data quality issue observed I have seen consistent issues with the conversion of CVEs to OSV in the GIT ecosystem, In the examples I have given we see from NVD a clear definition of "from version X until version Y are affected by this vulnerability" but in OSV, the range start with "commit 0" meaning all version before, leading to a false positive identification.
And in some cases, there is no range given at all in NVD, but the OSV entry still uses "introduced 0" in the ranges.
Suggested changes to record The "introduced" commit needs to correlate to the version in the range given by NVD, assuming we are using NVD as our source, and if we are not, then state from where this assumption comes from.
Additional context i think it might be a bug in the conversion of version tocommits so i will open a bug as well and link it into this issue, just to make sure.
:sparkles: Thank you for your interest in OSV.dev's data quality! :sparkles:
Please review our FAQ entry on how to most efficiently have this addressed.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
this is the bug issue i opened in case this is on intended and is a bug https://github.com/google/osv.dev/issues/3522
This issue has not had any activity for 60 days and will be automatically closed in two weeks
See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.
Hey @sha-cy, sorry for the late response. I believe what is happening here is that we have an assumption in place that if there is only 1 version given, it is the last affected version, and everything before that is affected, which in these cases is wrong.
The NVD conversion code needs a bit of a rework, which I am aiming to do once the CVEList conversion project is completed.
In the first case you've provided, it is clearly enumerated, so we'll look into whether it makes better sense to just place these versions directly into the osvschema versions field rather than extracting a range.
Hey Jess, thanks for the response. Can you share what the "CVEList conversion project" is? From the quick search i did couldn't find anything
Hey Jess, thanks for the response. Can you share what the "CVEList conversion project" is? From the quick search i did couldn't find anything
https://github.com/orgs/google/projects/151/views/1 here you go!