"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:
My own personal favorite anecdotes of why CVE counting is fail:
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:
http://blogs.adobe.com/security/2011/08/how-did-you-get-to-t...
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.
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.
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.
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.
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.
I don't think that's quite right or at least incomplete. I think that when developing software that runs on many, many platforms different platforms will have different interactions with the software which can sometimes result in bugs.
Sometimes the fault will be with the platforms, e.g. when the bug results from POSIX noncompliance, and sometimes the platform will interact with the program in a valid but unusual way, that isn't covered by the program and thus results in a bug.
I agree with this, but this isn't what I was referring to. I was referring to things like CVE-2016-7989 which says:
On Samsung Galaxy S4 through S7 devices, a malformed OTA WAP PUSH SMS containing an OMACP message sent remotely triggers an unhandled ArrayIndexOutOfBoundsException in Samsung's implementation of the WifiServiceImpl class within wifi-service.jar. This causes the Android runtime to continually crash, rendering the device unusable until a factory reset is performed, a subset of SVE-2016-6542.
Note where is says "Samsung's implementation", and specifically mentions that it affects Samsung devices. That's not an android interaction with the hardware platform, that's a completely different company altering the software to market a customized device, and those alterations included vulnerabilities. It's almost like Adobe's vulnerabilities in Acrobat reader being attributed to Microsoft because it runs on Windows.
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..
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.
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.
Well not really, the data is meaningless anyway because there is not a "severity scale", or "weight", and not even a "probability" sometimes you find a CVE that needs (just invented) the concurrency of a command being issued ona wednesday night between 01:00 AM and 1:07 AM, with full moon, a local access, opening a specially crafted file with an obscure program noone uses ...
That would count as a "vulnerability" just like a serious issue that affects all instances of - say - Chrome or Word 2013 installed.
As well, what are the effects of the vulnerability (IF exploited)?
I mean, one thing is something that - still say - offsets the GPS position of a photo by 2.25 m Eastward and another thing is one that brings on its knees - say - Cloudflare.
https://lcamtuf.blogspot.com/2010/05/vulnerability-databases...
My own personal favorite anecdotes of why CVE counting is fail:
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: http://blogs.adobe.com/security/2011/08/how-did-you-get-to-t...
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.
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.