I think it might be good to change the way the ElasticSearch hook deals with timestamps in this PR.
Otherwise the elasticsearch finding will have a timestamp and a @timestamp field.
With the @timestamp being a couple of seconds later as it is filled by the hook.

Also while were at it, is timestamp the best name for it?
I'd suggest to call it parsedAt and add another (nullable) field called identifiedAt to the finding data type which can be filled by the parser if the scanners result file can pin point to a more exact time of identification.

@J12934 so do you think we just drop the "@timestamp" field in elasticsearch then and include the "parsedAt" and "identifiedAt" fields? Or do we keep it for compatibility?

@JohannesZahn

• Let's keep elasticsearch as is (with @timestamp) because it's a common pattern to use within elasticsearch data.
• Add implment parsedAt as new general findings data
• Document identifiedAt in the findings spec but leave the implementation open for the feature

@rseedorff @J12934 the parser now uses "parsed_at" instead of "timestamp" in scb findings conform snake case. Here an example and the complete findings.json attached.

{
    "name": "Retrieved access-control-allow-origin header: *",
    "description": null,
    "category": "Nikto Finding",
    "location": "http://juice-shop/",
    "osi_layer": "NETWORK",
    "severity": "INFORMATIONAL",
    "attributes": {
        "ip_address": "10.96.193.17",
        "hostname": "juice-shop",
        "banner": "",
        "method": "GET",
        "port": 3000,
        "niktoId": 999986
    },
    "id": "370bebe5-54df-471b-a26c-a574cd465dd0",
    "parsed_at": "2021-06-22T12:27:28.153Z"
}

findings.zip