UI - Modified Date in Vulnerability-Based and Library-Based Alerting Mode
This article aims to clarify what the ‘Modified Date’ column in each organization type reflects and which actions trigger the date change. It also suggests a way of identifying the last NVD update for CVEs.
What is the Modified date for:
The Modified date’s role is to display information about the time when an alert has been last changed.
Section I: The role of “Modified Date” inside multiple reports
The vulnerability report contains the column “Modified” or “Modified Date” (depending on the organizational model). Below are the events that determine the change of the data in this column:
For Library-based alerts model (old model): In the “Vulnerabilities“ report the “Modified” column displays the date of the latest NVD change (as in the old organizational model actions like ‘ignore’ and ‘restore’ can not be performed at the vulnerability level, only at the library level).
Vulnerability-based alerts model: In the “Alerts- View by Vulnerability” report, the “Modified Date” column displays the last NVD update or the last change made on the vulnerability inside the app (in this case, vulnerabilities can be set individually to ‘ignore’ or ‘active’).
When is the Modified date expected to change?
A “Modified Date” column is also present at the library level inside the Alerts report (Library-based model) or inside “Alerts- View by Library” (Vulnerability-based model). It is often expected that this value will represent the date of the last plugin update. However, the modified date will update as a result of any of the following events:
One of the associated vulnerabilities is updated by the NVD
The status of the library alert is changed inside the app (ignore/restore -activate)
The status of one of the vulnerability alerts associated with the library is changed inside the app (only for the new model)
It is important to note that in views where the alert has multiple occurrences (each having its own modified date), the modified date that gets displayed is the one from the latest occurrence of the alert.
Examples
In the example below, we can see how in the new organization model, a status change performed on an individual vulnerability alert will affect the Modified Date of the containing library alert as well.
In the below example, we will choose to ignore one of the vulnerabilities associated with spring-core-2.5.jar. We can see that the initial Modified Date is Sep 24th, 2020.
We notice that this library has 3 vulnerabilities associated.
We will proceed with changing the status of CVE-2018-1199 from ‘active’ to ‘ignored’.
We then navigate back to the library level alerts and notice that the Modified Date of the library has been updated as well:
Section II: Finding the date of the last NVD update for a vulnerability
In order to see the exact date when a certain CVE was last updated in NVD we will access the page of the security vulnerability itself. Here, under “General Details” the specific date will be mentioned under the ‘Modified’ tag as presented below: