To add to this, SU3 was recently applied.
That'll get a bit difficult to check (given that the time period is a month+) but here's a few possibile candidates in a stream of thought listing:
- Someone decided to move all the spyware stuff into "do not scan" (which shouldn't make any current results go "poof" - but bear with me, it's part of the picture).
- Someone THEN decided to clear the Core-side vulnerability results and re-ran the vulnerability scanner. This would be one way to get to the the combination of "don't scan for spyware ++ 0 data on the Core == I know of no spyware on this device".
- Trawling through your vulnerability agent scanning settings may help paint a better picture (the above scenario of "Clear Core-side results + rescan" also works if someone disabled the "Scan for spyware" category).
- The "Clear Core-side information" can be run either on the client ("vulscan /clear") or on the Core (there's a button) ... so maybe as part of a support call, the vulnerability data got cleared out? (It's a common troubleshooting step when vulscan data seems to get out of synch -- you wipe out both the Core & Client side caches/data & re-scan from zilch in essence. It's the equivalent of forcing a re-sync between them).
... there's really quite a few legitimate and/or "whoops - unintentional" ways that this may have happened (not to mention less than unintentional but I'd be surprised if some malicious actor would care about falsifying spyware numbers). Checking through config can help quite a bit here -- but all I can do is give you example breadcrumbs to look for.
Unless you've got auditing enabled, this will be a case of "checking logs" -- and since many places do a daily vulscan, and our default number of backup logs is 3 on the client ... that's not sounding like it'll give you a lot.
Hope that this helps you guys a bit?
... as an aside -- you've found 173 devices infected with "high priority" spyware/malware items & this didn't cause concern / actions ...?