Add a "first_not_affected" field or similar to properly describe all possible ranges for affected packages

[pereyra-m]

Description

Hi!

I was trying to express some NVD vulnerabilities with OSV.
They use these keywords for the ranges

• versionStartIncluding
• versionStartExcluding
• versionEndIncluding
• versionEndExcluding

So we can have these type of intervals

• [X,..., Y] : from X to Y, both ends included
• [X,..., Y) : from X to Y, X included, Y excluded
• (X,..., Y] : from X to Y, X excluded, Y included
• (X,..., Y) : from X to Y, both ends excluded

But here in OSV, we have:

• introduced: this is equivalent to versionStartIncluding
• fixed: this is equivalent to versionEndExcluding
• last_affected: this is equivalent to versionEndIncluding
• limit: in this context, it is similar to fixed

It isn't posible to express (X,..., Y] / (X,..., Y) ranges, we are missing an equivalen to versionStartExcluding.

Example

The https://nvd.nist.gov/vuln/detail/CVE-2022-34465 vulnerability has this type of ranges

[chrisbloom7]

For context, this seems to be a duplicate of #31 and #35 (comment), with versionStartExcluding being synonymous with the lower bound exclusive operator >.

[pereyra-m]

Thank you very much for indicating these related issues, I didn't know this had been discussed in the past.

We need to express the NVD vulnerabilities database in OSV format, and after that all the manual verification and curation process will begin.
I've read in the related discussions you show that adding > is not ideal, because almost always it's possible to find the first version affected of the range.

But this is the way the NVD is expressing some vulnerabilities.

Let me add more examples:

https://nvd.nist.gov/vuln/detail/CVE-2022-22566

https://nvd.nist.gov/vuln/detail/CVE-2022-24724

https://nvd.nist.gov/vuln/detail/CVE-2022-24831

https://nvd.nist.gov/vuln/detail/CVE-2022-29243

[oliverchang]

Hi @pereyra-m, thanks for filing this issue.

FWIW, this was discussed as part of the CVE 5.0 schema as well (CVEProject/cve-schema#87 (comment)), where it was decided that a '>' operator was uncommon enough that it didn't warrant encoding in the new schema.

I do recognize that these come from NVD's CPE ranges instead of from the CVE itself -- do you have any numbers on how often these are used in the context of open source packages? A lot of the CPEs you pointed out seem to point to vendor specific products that can't be encoded in OSV anyway.

[pereyra-m]

Hi @oliverchang !
Thank you very much for your quick answer!

I can see that in CVE 5.0 this isn't supported and you are trying to be fully compatible. And I can also understand that in some situations the '>' operator could introduce some difficulties in the evaluation or even false positives.

But the examples I have shown are from the NVD where CVE 4.0 is used currently, and I'm trying to translate this database to OSV. If the NVD allows this, then those who fill the information can use it.
Do you suggest that for this particular cases I use the affected[].ranges[].database_specific field?

Also, this means that CVE 5.0 has a breaking change and it won't be backward compatible with the expressions in CVE 4.0?

A lot of the CPEs you pointed out seem to point to vendor specific products that can't be encoded in OSV anyway.

Our teams needs to be able to detect vulnerabilities in both open/closed source software.
Here I have some examples of open source vulnerabilities too.
Some of them are in state UNDERGOING REANALYSIS, that's why the information isn't accurate or complete yet. But we can't skip them until the analysis is finished

source: https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2021.json.gz

https://nvd.nist.gov/vuln/detail/CVE-2021-20194

https://nvd.nist.gov/vuln/detail/CVE-2021-22187

https://nvd.nist.gov/vuln/detail/CVE-2021-22917

https://nvd.nist.gov/vuln/detail/CVE-2021-33037

https://nvd.nist.gov/vuln/detail/CVE-2021-3743

I couldn't tell you of often this is right now.
Regards.