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

[tzirn]

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

• 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: v3.12.0
  Running in any particular CI environment we should know about? No

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

[tzirn]

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:

[tzirn]

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

[terriko]

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]

@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]

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

[terriko]

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]

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]

@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]

@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]

@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)

[JigyasuRajput]

Hey!
I'm working on it, reproduced it locally.

[JigyasuRajput]

so in the debugging logs I noticed that the last modified field does exists but it's empty -> last_modified=''

 DEBUG cve_bin_tool.OutputEngine - CVE object: CVE(cve_number='CVE-2023-37369', generate.py:209 severity='HIGH', remarks=<Remarks.NotAffected: 6>, description='In Qt before 5.15.15, 6.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.2, there can be an application crash in QXmlStreamReader via a crafted XML string that triggers a situation in which a prefix is greater than a length.', comments='code_not_reachable: NotAffected: QXmlStreamReader NOT USED BY PI or SWI', score=7.5, cvss_version=3, cvss_vector='CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H', data_source='NVD', last_modified='', metric={}, justification='code_not_reachable', response=[]) 

also noticed that published date doesn't exists at all in the data structure

this is because the cve database is not populating the publication and last modified dates from NVD and lib4vex defaults to using the current timestamps.

-> so completely removing these fields is the right solution?
would love to hear thoughts about this