Summary

Software Vulnerability Manager can connect to the SQL database of an active production SCCM server and fetch the program data collected through Software Inventory scans done by deployed CCM Clients.

This article explains where at the System Center Administration Console you can find the same data SVM collects and displays in the form of a Completed Scan. 

Question

SVM users scanning their hosts via the System Center Import Feature in SVM know in theory that received scan data is being fetched by SVM from the SQL database. The information ends up in the SQL database initially after being gathered through a 'Software Inventory Cycle' by the Configuration Manager Agent (or Client) that resides on systems.



You may want to compare the collected data by CCM Client on different hosts with the data reported by the Software Vulnerability Manager solution for accuracy and reporting purposes. 

Software Inventory Data 

The short answer is that you can find the data imported through the Software Inventory cycle when you right-click on the host you are interested in, then go to 'Start' > 'Resource Explorer' and you review the "Software" menu that comes next in the next window.  



Users might get confused after opening the Resource Explorer as it contains several menus for both Hardware and Software, and program data is being displayed under both of those.

Under 'Hardware' three-view (left-top side) you'll likely notice a long list of sub-entries and among them, you'll find 'Installed Applications' and 'Installed Applications (64)'

Under 'Software' three-view (left-top side) you'll notice 4 sub-categories: "Collected Files", "File Details", "Last Software Scan" and "Product Details"?

Which of those menus under matches 1-to-1 what SVM sees and collects when scanning SCCM?

Under 'Software' > 'Product Details' you can identify the particular executable files and their name and version metadata, as it has been identified and collected by the Configuration Manager Agent.

SVM uses this same metadata to correlate its Vulnerability Intelligence and match the security state of your application. This is the most accurate menu to be looking at when you need to compare scan data in SVM with collected data in SCCM for discrepancies.

This data matches the metadata information that is used by SVM to evaluate the program state, and it also matches the evaluation method preferred by SVM by looking at executable files data.

NOTE: Keep in mind that Inventory Scanning is the second perfect choice for 100% data collection as it yields some inconsistencies that produce misses. Flexera recommends the use of Agents for scanning for 100% accuracy. 

Hardware Data Incompleteness

Installed Applications' and 'Installed Applications (64)'  under"Hardware"  ' show similar matching information about names and versions of your programs. In most circumstances, this information should be identical or at least perfectly close to the information displayed under 'Software'.

As seen under 'Administration/Client Settings/Default Client Settings/Hardware Inventory/Set Classes' , SCCM indicates that this information is collected from the Registry, however. You could imagine that these lists (under 'Hardware') are the same as you would be watching 'Add and Remove Programs' on the actual client. This could be useful in many troubleshooting scenarios, but don't overtrust it. 

You can use this menu to see the data generally placed across the system, but remember that SVM evaluates vulnerabilities on a file-by-file basis. A system may have one registry entry, but five or six files laying around on the drives in users folders that are all vulnerable, risky, and will get missed out for your complete disadvantage and that poses even bigger risks of failing to recognize where an attack happens.

One flaw of looking for program installation (and existence) in the registry on a given host is that the registry displays only 'full installations' of software on the machine. Here are some of the 'misses' this scan can produce when it comes to the accuracy of scanning:

• The registry may not necessarily write information about files that failed to get cleaned up.
• Such files should be identified and patched if possible.
  • If not, such files should be regularly cleaned or a decision to permanently removed.