minvws
fix first and last seen in (findings)reports by basing them off the OOI, not the finding.
see https://github.com/minvws/nl-kat-coordination/pull/2154#discussion_r1430533352 Describe the bug Our first and last seen timestamps are not collected on the OOI (or source) but from the finding. As findings are usually created by Bits, they
According to @dekkers in https://github.com/minvws/nl-kat-coordination/pull/2308, we should leave it as is, then we should either add a first seen of ooi and or remove the last seen. What does everyone think?
So, findings are created in one of two ways: Either directly by a boefje/normalizer combi. which means we have a meaningfull first date for the finding, and we could also collect the last run that still showed this finding to be present. Or, they are created from a BIT, which takes a set of OOI's as its input. These all eventually have a first-seen and a last-seen date, but more importantly, the BIT itself has created the finding on a given date (because at that point the combination of inputs led to the BIT creating the FindingOOI. A last-date would then be the last validation time for the sum of all input OOI's for that BIT (which might be a bit complex and recursive if bits have been acting on other bit-created OOI's).
So the first one is correct for all findings created by the Shodan boefje/normalizer. I agree that there we can simply do first seen -> first time shodan returned finding and last seem -> last time shodan returned finding.
For the BITs:
First seen can be: First time input OOI is created First time finding is created
The last seen would make sense in case its the OOI, but in case of the finding, it doesnt, since BITs that create findings usually only run once -> when the SoftwareInstance is created (or when it changes clearence level). In that case, first and last seen will almost always be equal.
We will add four different ways cves are "proven" in KAT and discuss solutions afterward.