Bug: cve-bin-tool doesn't find the same CVEs between 3.2 and 3.3

[Virthuss]

Description

Hi everyone.

I'm facing a weird behavior after migrating to cve-bin-tool 3.3.

I use to generate a SBOM file which was read by cve-bin-tool this way:

    {
      "components":
      [ ... ]
    }

Following a migration to 3.3, this format didn't work anymore and I'm now using:

    {
      "bomFormat": "CycloneDX",
      "specVersion": "1.4",
      "version": 1,
      "components":
      [ ... ]
    }

And I'm now having weird results. Many CVEs are properly reported but some appear to be missing. An example:

In the components before I had the following:

        {
          "type": "standalone tool",
          "name": "lens",
          "version": "5.2.5"
        },

This was successfully returning a CVE ( https://nvd.nist.gov/vuln/detail/CVE-2021-23154 ).

However this same CVE is now NOT reported by cve-bin-tool.

Is there any reason to explain this ? Is this my configuration, my sbom file format ? Has there been any update that could explain this behavior ?

Instructions

See description above.

This is the command I'm running, if needed:

`  cve-bin-tool \
    --nvd json \
    --sbom cyclonedx \
    --sbom-file ${nameFile} \
    --affected-versions \
    --format json \
    -o cve_scan_content.json \
    --nvd-api-key ${vars.NVD_API_KEY} \
    ${refreshCVEs ? ' -u now ' : '--offline'} `

Thanks in advance !

[terriko]

Hm. Definitely sounds like a bug but I'm not sure where. There were some big changes in the NVD data and how we parse versions between 3.2 and 3.3, but a quick lazy check shows that for the particular CVE you listed, it is correctly listed in my local database and our newer version compare function does indeed show that 5.2.5 < 5.3.3 as expected, so my best guess is that it could be related to the sbom parsing itself, or that it could be an issue that we've already fixed in main. There's some big changes in sbom parsing in the upcoming release because of the changes for VEX triage.

Could you take a sec and see if you get the same results with our 3.4 pre-release on pypi? https://pypi.org/project/cve-bin-tool/3.4rc0/ I'm hopeful that the changes will mean it's already fixed, but if not at least seeing what's still wrong now would be very helpful.

I know the sbom parsing library we use has also been upgraded, so you might want to try doing `pip install -U lib4sbom" as well if you're not running it all in a fresh venv or similar.

[Virthuss]

I tried with the version 3.4rc0 but without success. I'm still able to get some CVEs but the lens one doesn't show up. Edit: just to be as accurate as possible, I also tried with and without pip install -U lib4sbom

[anthonyharrison]

@Virthuss Can you post the SBOM file you are using and I will have a look at it?

It is possible that the validation improvements of the SBOM parser has resulted in previous erroneous entries no longer been accepted. For example, "type": "standalone tool", is not valid CycloneDX.

[Virthuss]

@anthonyharrison good point, I'm using a parser I used to generate CycloneDX files and it now seems to work better.

However I'm now facing a different issue. Some CVEs versions are getting much harder to parse.

Some examples: CVE-2019-13209 max version: 2.2.5-rc6.0.20190621200032-0ddffe484adc+incompatible CVE-2022-41325 max version: 3.0.17.4-0+deb10u2 USN-4376-1 max version: ubuntu13 - 1.1.1-1ubuntu2.1~18.04.5 CVE-2023-34111 max version: 2023-05-22

Before we usually had easier and more readable format for versions ( like 9.1.4 ). Have anyone else reported issues with the version values reported by cve-bin-tool for the latest versions ?

[terriko]

That probably is a side effect of the new version compare function. The old one only understood versions in very limited formats (basically X.Y.Z plus a few pre/post release options as defined by PEP440 -- this was fine for python but didn't work for more general version compare on products).

So what you're getiting now is likely a lot more accurate to what's in the vuln database, but it wouldn't be hard to print versions truncated to X.Y.Z if that's a feature people want to make it easier to read. I lean towards wanting the more precise data but especially with those distro-specific versions, I can see how it might not be useful to everyone.

[Virthuss]

That probably is a side effect of the new version compare function. The old one only understood versions in very limited formats (basically X.Y.Z plus a few pre/post release options as defined by PEP440 -- this was fine for python but didn't work for more general version compare on products).

So what you're getiting now is likely a lot more accurate to what's in the vuln database, but it wouldn't be hard to print versions truncated to X.Y.Z if that's a feature people want to make it easier to read. I lean towards wanting the more precise data but especially with those distro-specific versions, I can see how it might not be useful to everyone.

Is there any library or tool you would recommend ( for Node.JS or for PostgreSQL ) to manage version comparison with the new syntax ? I'm trying to use SQL queries to check if any of my tool with a specific version might be included within the CVE version's range, but my old algorithm using regex is now outdated. Or is there any API I could use to achieve the same result ?

[terriko]

Hah, if I could recommend a library that actually worked for generic version compare, I wouldn't have written one myself. (And oh, that would have made my life so much easier.)

So, uh, yeah, the library we use is in cve-bin-tool. You can import it using from cve_bin_tool.version_compare import Version" and then if you stick the versions you want to compare into Version it'll use regular operators. e.g. Version(2.5) < Version(3.0.17.4-0+deb10u2) == True` . We went through several months of rewrites and feedback a year ago and haven't found a bug in a while so it'll probably just work for most cases, though I feel like there's still a small chance of weirdness if you tried to compare, say, hashes instead of versions. If you do hit anything problematic, let us know and we'll keep tuning things!

[Virthuss]

Hah, if I could recommend a library that actually worked for generic version compare, I wouldn't have written one myself. (And oh, that would have made my life so much easier.)

So, uh, yeah, the library we use is in cve-bin-tool. You can import it using from cve_bin_tool.version_compare import Version" and then if you stick the versions you want to compare into Version it'll use regular operators. e.g. Version(2.5) < Version(3.0.17.4-0+deb10u2) == True` . We went through several months of rewrites and feedback a year ago and haven't found a bug in a while so it'll probably just work for most cases, though I feel like there's still a small chance of weirdness if you tried to compare, say, hashes instead of versions. If you do hit anything problematic, let us know and we'll keep tuning things!

Got it, I will try to use it when I have time. If I have an issue about this I'll create a different ticket as this is a different scope.

Thanks a lot for your responses and your help !