search

intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.25k stars 466 forks source link

cve-bin-tool v3.4 "published" and "updated" values #4468

Open tzirn opened 2 months ago

tzirn commented 2 months ago

Description

v3.4 of the tool and have parameters to tell it to make a new json/vex file. The published and updated values it puts in for each CVE found is just the date this report was run. Shouldnt it be the published and updated values from the CVE itself?

To reproduce

Steps to reproduce the behavior:

  1. run v3.4 with this command: cve-bin-tool -i test_SBOM.csv --vex-file test_cve-bin-tool_triageFile-2.json -f csv,html --vex-output triage0923b.json
  2. look at the new output file "triage0923b.json" and in each CVE listing the published and updated fields are just the time the tool was run. Even when we put in the correct values in the input vex/json file, the output vex/json file overwrites them with the current date/time.
  3. v3.3 used to just put in the values "NOT_KNOWN" which wasnt good either.

Expected behavior: add the published and updated dates from the CVE itself - each CVE has this data Actual behavior: adds just the current date/time the tool was run to these fields for every CVE

Version/platform info

Version of CVE-bin-tool: v3.4 Installed from pypi or github? pypi Operating system: Windows

Anything else?

Feel free to add any other context here.

output triage file that I just ran attached along with a short screenshot if the diffs between 3.3 (which just put in NOT_FOUND) and 3.4.

triage0923b.json

image

tzirn commented 2 months ago

Here is an example of the data in a CVE on the cvedetails.com website and the same one from the NVD website for the same CVE: image image

tzirn commented 2 months ago

@terriko I thought you'd want to know about my further testing of v3.4

terriko commented 2 months ago

Hm, I think this may be a bit of a pain to solve completely because I'm not sure we're storing those values in our cache, but I'm not sure why we're over-writing them. Thanks for pointing it out!

mastersans commented 2 months ago

@terriko @tzirn This mainly originate from lib4vex, so at the time of implementing new triage functionality as far as i remember we don't have way to define different update stamps in lib4vex for a vulnerability, i might have to double check in lib4vex this, regardless the bug should be easy to fix i guess so..... ; )

tzirn commented 1 month ago

hi, just checking in to see if anything has come around for this. I can help test if there is. Thanks

terriko commented 1 month ago

Pinging @anthonyharrison -- I think he was still traveling when this bug was filed so he may have missed it. If it's in lib4vex then it's probably him that'll fix it.

anthonyharrison commented 1 month ago

Sorry for the delay. @tzirn the published and modified date in the VEX document refer to the date which the vulnerability was first added to the VEX document and the date when it was last updated. The fields must be independent of the dates within the CVE database.

Consider the following scenario.

Suppose a vulnerability is declared for a component at time A. This is the published time in the CVE database. If the product P does not use the component until a later time B, the product is not vulnerable until time B. It would therefore be incorrect to report in the VEX document that the product had been vulnerable since time A. The modified time in the VEX document refers to the time that the VEX document is updated. Each time the VEX document is updated, every vulnerability should be reviewed to see if there has been an update in its status. In most cases there will be no change, but the modified state indicates that it has been 'reviewed'.

cve-bin-tool implements the above VEX lifecycle; of course the VEX document can always be manually updated to reflect a different lifecycle if required.

tzirn commented 1 month ago

@anthonyharrison each time I run it they both just update to the date of when I ran it - even though they have all been in my VEX input file for months. Notice how in my example above the published and updated both have the same date and time.

anthonyharrison commented 1 month ago

@terriko @tzirn There is an error is the VEXGenerate code which is setting the "updated" field of a vulnerability to the time that the cve was last updated. This is not necessary, removing this line should hopefully correct the issue.

tzirn commented 1 month ago

@anthonyharrison I dont see it being updated to the time that the CVE was last updated. I see it setting it to the date and time the cve-bin-tool was run. It would be more correct to have the "updated" field be set to the time that the CVE was last updated. Please see my example above when I first opened this - those date and times are the run time of the cve-bin-tool (9-23-2024) not the CVE published date (7-4-24) or the CVE updated date (7-8-24)