Top 50 Vendors by Total Number of Distinct Vulnerabilities in 2016
cvedetails.com
cvedetails.com
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.
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.
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.
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.
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".