Oh sorry... looks like you sort of did based on Method 3, which has the "least accuracy".
If you notice a specific descrepency let us know - because the "Patch Exists" field should be accurate. We will only flag it if the vendor has specifically released a *patch* for the Vulnerability not if they recommend upgrading to another version etc.
First of all, John, thanks for your OP, which gave me some ideas as to how to address these items for which no action is possible.
I'm trying to build out an Excel workbook which will use a combination of advanced criteria, VBA,Vlookups and other formulae to filter the results and produce "actionable" items.
I'm trying to make it as "One-Stop" as possible, because although I know how to work with SQL and other such tools, I ultimately need to parcel out this work to people with more basic tools and knowlege.
Was your latest comment, i.e. that only Vulns with NO solution (patch or upgrade) be flagged? (or, potentially, to offer a choice, either just "no patch", or "upgrade required", or both...)
P.S.: I'm using MVM version 7.
I split out two categories..those fixable by a patch and those not fixable by a patch.
You can further break this down into categories like:
High rated vulns-patchable vs not patchable
System compromise vulns-patchable vs non patchable
The vulns with no patch available and specifically those not related to config changes tell a story about the state of security. Vulns that NEED a patch, but haven't been fixed yet are accumulating all over the securitys-sphere. Stop gaps are much needed..especially because those behind APTs have the same knowledge we do... But most security departments don't have the resources to manage all of the mitigating technologies to help reduce risk for all of the vuln types across a diverse software scape. Thus, security is becoming an art more than a science.