"CVE counting" is not necessarily a good proxy for "security". The practice of drawing conclusions from various CVE statistics has been variously debunked over the years. I strongly recommend reading this 6-year old(!) resource from @lcamtuf:<p><a href="https://lcamtuf.blogspot.com/2010/05/vulnerability-databases-and-pie-charts.html" rel="nofollow">https://lcamtuf.blogspot.com/2010/05/vulnerability-databases...</a><p>My own personal favorite anecdotes of why CVE counting is fail:<p>1) Adobe used to tour around presenting a chart of how their CVEs were decreasing over time. But then @taviso did a bit of simple fuzzing and found almost 100 issues. So it turns out the Adobe CVE count was low simply because no-one was looking hard. In fact, Adobe assigned a single CVE to all the issues, in this waffling blog post:
<a href="http://blogs.adobe.com/security/2011/08/how-did-you-get-to-that-number.html" rel="nofollow">http://blogs.adobe.com/security/2011/08/how-did-you-get-to-t...</a><p>2) Google Chrome has lots of CVEs because of the monetary incentives to go and find and report them. A quick comparison of CVEs for Chrome vs. some browser without a decent rewards program might lead you to incorrect conclusions.<p>3) Historically, Microsoft did not publicly disclosure or assign CVEs for issues found internally by employees. This contrasts with Chrome and Firefox, which have a greater culture of openness, where internal security discoveries are documented publicly. Quasi-arbitrary decisions like this bend the numbers all over the place, from vendor to vendor and product to product.
So, I was curious what the Google vulnerabilities are, and it looks like quite a few of them at notes as "On Samsung S3 through S5 devices..." which seems to indicate it's not an Android problem, but a Samsung extensions to Android problem.<p>It's interesting, because depending on why you're looking, you might want those combined and you might want those separated. If you are interested in an Android phone, you are interested in the vulnerabilities from Google's software that apply, as well as the vulnerabilities of the phone provider if them are extending Android. If you are buying a Nexus or Pixel device, you don't care about Samsung or HTC vulnerabilities. If you just want to know about problems in Google's suite of web applications, you don't necessarily care about Android at all.<p>Similarly, for Apple you might want to know the track record of their phones, or you might want to know about their OS's. For windows, you might want to know about base OS vulnerabilities, or phone vulnerabilities, or Office and other application vulnerabilities.<p>For large companies, attributing all vulnerabilities to the company may not be the most useful way to do this. Also, if you want to know how responsible a company is, it might be more useful to provide a vulnerabilities to employed software engineers per company ratio. If company X has 10 vulnerabilities and 10 programmers, and company Y has 100 vulnerabilities but 10,000 programmers, company Y may look worse on a pure vulnerability level, but conceivably they could be doing a really good job at writing secure software, but they are just putting out a lot more software.
This is an interesting list, but I wonder about the definition of "vendor". Seeing the distribution makers in the list, I had a look at Debian's CVEs, and I saw that the counts included CVEs for software being packaged/distributed by Debian. Then you have the entities that I feel perfectly fit the "Vendor" descriptor: Adobe, Microsoft, etc..<p>Then you have Oracle at the top, but I expect that number is a combination of vulnerabilities in products produced by Oracle (like Java), and vulnerabilities reported in Oracle Linux.<p>I wish there was a better distinction between "distributor" (or "software packager") vs. "software creator".
All time is an interesting look. At 11 vulnerabilities per product, Microsoft is much much better than Apple or Google. I have to revise some unfair and unwarranted opinions.
I wonder if this list is a true indicator of code quality, it would be interesting to also know the amount of code. For instance, one vulnerability/100 lines of code or something like that.