GVM VT updates delay in applying


We are running GVM 21.4.0 on Kali Linux. We are seeing an issue in updates not being picked up / synced immediately; it appears to be several days for this to happen. Our update process has been to run gvm-feed-update, which updates NVT, GVMD, Scap and Cert data; e.g. this was run on 9th and 10/07/2021 and we see corresponding update entries in the gvmd.log. However, it has not been until 13/07/2021 that we see the following in gvmd.log:

md manage:   INFO:2021-07-13 11h18.48 utc:174233: OSP service has different VT status (version 202107091126) from database (version 202106301035, 74525 VTs). Starting update ...
md manage:   INFO:2021-07-13 11h19.28 utc:174233: Updating VTs in database ... 276 new VTs, 1702 changed VTs
md manage:WARNING:2021-07-13 11h19.30 utc:174233: update_nvts_from_vts: SHA-256 hash of the VTs in the database (...) does not match the one from the scanner (...).
md manage:   INFO:2021-07-13 11h24.09 utc:174233: Updating VTs in database ... 74873 new VTs, 0 changed VTs
md manage:   INFO:2021-07-13 11h24.11 utc:174233: Updating VTs in database ... done (74873 VTs).

Indeed in our scans before and after this update, we see some different scan results (e.g. vulnerability score) in the web interface, whereas we would have expected them to be the same if the scans both happened after the gvm-feed-update on 09/07/2021. Can someone explain why there is a delay between the feed update and this VTs update in the database? Is there anything we’re missing in terms of how we should do the feed updates? (an additional command after gvm-feed-update?)

The actual loading of the vt data from the feed is done by ospd-openvas. gvmd asks ospd-openvas in a regular interval (should be some minutes) for updates of the vt data via the <get_vts/> request. So you need to look at the ospd-openvas.log file first.

There’s been a more recent gvm-feed-update on 20/07/2021, but again the ‘Updating VTs’ doesn’t appear in gvmd.log until a bit of a delay (19 hrs) on 21/07/2021:

md manage:   INFO:2021-07-21 13h42.43 utc:2396184: OSP service has different VT status (version 202107201028) from database (version 202107161017, 74985 VTs). Starting update ...

This one is within 24 hrs though, so OK, just surprised not happening immediately after the feed update.

ospd-openvas.log doesn’t appear to have anything relevant; it’s latest log entries are from 2021-07-14 and contains scan start/finish entries. (There have been scans since then so perhaps surprising there’s nothing more recent? Does the process need to flush its logs to the file?)