I want to start off by saying that I know R7 is working on improvements to the vulnerability First Found date within IVM/Nexpose. Ultimately this will be concluded in August. Before then they have made a few adjustments to the First Found date by “displaying the true First Found date for the vulnerability on the asset”. This is the date, not the number of days, that the vuln was identified on the asset. There is also the First Found (number of days ago) number which may or may not mean the same thing as the First Found date - to make it easier for us to know the exact number of days without doing the math ourselves perhaps.
So, here is an example; Nexpose identified Log4j on a number of assets about 30 days ago. The only modification to the vuln was the CVSS score, that’s it. However, according to First Found date and days ago, they are over 2 years old. Are they truly that old (been on the asset that long) or is that just the date it was first “seen” on the asset and now we have a reoccurrence? They can’t be that old because we remediated everything in our environment back in 2021/22.
This brings me to the vulnerable since date that we can use when running reports (not SQL, just basic stuff). Vulnerable since is what it sounds like; the asset has been vulnerable to X vulnerability since X date and is still vulnerable. In my example above, that date corresponds with the ~30 days, same as when they showed up on the console.
However, I’ve been told that the vulnerable since date is faulty and I also believe to be true, but not for everything and not all the time. I see vulnerabilities “moving”; meaning I know that the TLS/SSL we have on systems are years old, yet the vulnerable since date will move to the right. After investigating this and other vulnerabilities, I see there are changes in the proof from scan to scan and this corresponds to the vulnerable since date changing.
Now, it is possible that the First Found date/days is accurate but isn’t representative of how long the vuln has actually been on the asset - that makes sense per the first paragraph. If this is the case, and First Found date is accurate and only represents what they are saying it does and that vulnerable since is faulty, then compliance becomes an issue.
How do I truly know how long a vulnerability has been on an asset? What date do I trust? We’ve been using vuln since date for compliance purposes. Can’t use the publish date nor the first found date/days as there could be reoccurrence (vuln coming back like the log4j above). Reoccurrence is part of the update in August, so excited about that.
Yes, I have a ticket in. It is possible I am doing something wrong and/or just missing the mark here.
Has anyone else experienced the above? Have you found a good workaround? or is there a better solution?
Thank you!