v3.4 excludes micro-ecc when version is "1" instead of "1.0" which worked in 3.3

[tzirn]

Description

@terriko requested I open a new bug report:

in v3.4 of this tool when the micro-ecc version is set at 1 in the SBOM CSV file (because Excel keeps changing 1.0 to 1 before the CSV is saved) the tool doesnt find the micro-ecc vulnerability at all even though it's in our triage input file.
This was found to be due to the fact that it was not 1.0 However, as I said this worked in v3.3 so users didnt have to fight with excel to constantly re-force it to 1.0.
This was found when testing v4.4 in this bug report: micrium uC/Lib vulnerability causes cve-bin-tool to delete triage response data from triage input file

To reproduce

Steps to reproduce the behavior:

1. have a CSV SBOM with a product that has a known issue in a main version (like 1.0, 2.0, etc)
2. in this SBOM store the version as an integer without decimal places, so 1, or 2, etc
3. run the cve-bin-tool and see the output report doesnt contain the known issue

Expected behavior: to list the known issue as the tool did in v3.3
Actual behavior: the output report doesnt contain the known issue

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version): 3.4
Installed from pypi or github?
Operating system: Linux/Windows: Windows 10

• On Windows you can run systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
  OS Name: Microsoft Windows 10 Pro
  OS Version: 10.0.19042 N/A Build 19042
  Python version (e.g. python3 --version): v3.12.0
  Running in any particular CI environment we should know about? N/A

Anything else?

Feel free to add any other context here.
You can get the files I used from the bug report linked at the beginning here

[terriko]

So, my guess is what happened here is that it's a side effect of having to move away from the old version compare library. The old library had moved to more PEP440 compliance and was rejecting anything that didn't comply with that format (which is a HUGE number of versions in the overall database). So there's no chance of going back; it would break a lot of things.

At a guess, the problem is either that we're doing a string compare so "1" != "1.0" for the basic equals case or that the comparison code is saying that the two items have different length of arguments so therefore they can't be the same. Given that this came up due to excel's over-zealous number handling, my guess is that it's only going to happen with versions that are XXX.0 so that may be easy to add in as a special case.

The question is whether anyone actually does mean XXX.0 to not be the same as XXX, but I don't think I've seen that in the data yet. My instinct is that we should fix this and then be prepared to re-work only if it turns out to be a problem.