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.19k stars 455 forks source link

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

Open tzirn opened 1 week ago

tzirn commented 1 week 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 1 week 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 1 week ago

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

terriko commented 1 week 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 1 week 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..... ; )