All right - try this out.
1 - query the VULNERABILITY table for a vulnerability you care about. So let's say "MS14-007" ... your SQL (assuming you're on SQL server) will look like so:
""
select * from Vulnerability where Vul_ID like '%MS14-007%'
""
Note that I'm using "LIKE" because you can get situations where you have a _MSU and/or _ENU / _FRA and so on variants that may or may not affect your results.
==> The thing you care about here is the VULNERABILITY_IDN (this will vary on a "per database"-basis.
Step 2 - Run "GATHER HISTORICAL" ... you'll see why in a minute
Step 3 - Armed with your VULNERABILITY_IDN, query the PATCHTREND table. So let's assume your IDN is "32801", you get something like this
""
select top 10 * from PatchTrend where Vulnerability_Idn=32801
""
Now - chances are that you'll get several results back on this. If you're paying attention to the LOGDATE column, you'll see that essentially you've got one line of data for each time you've run "Gather Historical":
- Detected
- Scanned
- NotScannedCount
- Repaired
- RepairFailures
That's probably the easiest way to get to the data in one, nice place.
Now - IMPORTANT thing here is that not *ALL* of the data you might be looking for is necessarily available in a human-readable format in the database. For storage-space reasons, a lot of the data is actually in BLOB format, so we're calculating these results & so on based on programming code & not just SQL alone, and then spit the results back into a dedicated table (the PATCHTREND... stuff). This isn't to discourage - I'm just pointing out that not necessarily everything you're looking for we "do by SQL" ... some of the stuff has to be done code & SQL.
Hope this helps.
- Paul Hoffmann