Re: Comparing like with like ?
@alain williams - "It is very hard to see what they are comparing with what."
It's easy, he's comparing apples to oranges. For example, I just went to the NIST database and did a few queries of my own. Red Hat Enterprise had a total of 37 vulnerabilities, and that included things like vulnerabilities in Java (which might be better classified as third party).
So why does all of RHEL have fewer vulnerabilities than the Linux kernel supposedly does on its own? The reason is simple, I took a quick scan over the Linux kernel vulnerability list, and it was dominated by new "releases" such as 3.17 or 3.18. I'm running a fairly new user kernel, and it's only 3.13.
A "release" by Kernel.org doesn't automatically go into production on RHEL, Suse, or Ubuntu. Kernel development is time based, and each "release" is simply whatever they happened to have when the release date (every few weeks) rolls around. You don't install kernels from Kernel.org unless you are either a kernel developer, or else you are really, really adventurous. Instead, you wait for your distro to test and package one up, and they won't do that until it has been tested. That's not even taking into account the difference between development releases and long term support releases (which I won't go into).
That doesn't even take into account the fact that the kernel that Red Hat (for example) releases is not the same thing that the central kernel developers released. Red Hat, Suse, etc. add their own fixes and patches, and send the results upstream (with a CVE) as well as to their customers. That's what distros get paid to do.
To get the equivalent to this for Windows, you would need access to Microsoft's internal bug tracker and then report "oh noes! Windows 12 development version has bugs in it!". Well no guff, non-released development software does indeed have some serious bugs. The question that matters is how many of those bugs make it out into an actual public release that people are expected to use for serious work. Because Linux development takes place out in the open instead of behind closed doors, you get to see all the internal screw-ups before they get fixed that you don't get to hear about when they happen in the development of proprietary code. What matters to you and I though is what gets shipped as a final product.
So why did GFI spaff out some rather obvious guff? Well:
a) They really have no idea what they're doing, or
b) They're trolling for business from panicked users by positioning pumped up numbers in the press.
I would take a guess that the answer is "a", someone knows how to click on a NIST web form, but has no idea what the numbers really mean. If that's the sort of company you want to pay to handle your security for you, then good luck.