As you said Stephen, from a bizops standpoint, RAS tends to be the focus because management doesn't really want to get into the nitty-gritty, as long as the business is "operating smoothly", meaning the non-IT functions can "produce the goods" and the revenue keeps growing the back account balance at the rate that is expected. In that context, the "nitty-gritty" is for the most part ignored as "background noise". 
Given that Garrett is a student, his"time investment" and "creation investment", as harvested, congealed, and captured as text/graphics in "transient RAM", are critical one-time, never-to-be-fully-duplicated investments whose loss can be ill afforded by encountering a bug preventing it from being saved properly, or a crash preventing it from being saved at all!
For that reason, I completely applaud Garrett's disciplined approach in trying to "get to the bottom of things" by trying to get his hands on the actual stats for a fact-based decision regarding
- crash events, frequency and trends
- bug events, frequency and trends
but I would throw my own spin on things by suggesting that bug events need to be broken into sub-groupings as follows:
- OS-core software
- OS-support software
- non-OS non-GUI software
- non-OS GUI-based software
and this last grouping broken down even further into
- business productivity supply-chain
- business productivity financial
- business productivity engineering
- business productivity creative
- business productivity communications (email, multimedia groupware, multimedia presentation, instant messaging, social media, etc.)
- other business productivity non-financial
Keeping in mind, personal/home productivity is no different than business productivity, just at a different scale, using scale-appropriate tools. 
Given that, I too "rummaged" to see what I could find, and came up dry for what I think Garrett was really looking for.
I fear the only approach available is to visit the "issue management facility" (bug enhancement tracker) for each of the main distros, and somehow distill what is presented into a sensible form. The only alternative to that is for each Distro's problem tracking "Manager" to have compiled the desired type of stats of their own volition, recognizing that such would be most attractive to anyone trying to make that decision to commit to their distro based on "demonstrated stability".
As an aside global total "change count" is a false statistical reference because different Distros have different approaches regarding the scope specification for a code-related issue; what might constitute only 1 issue for resolution might constitute 3 separate issues (more finely divided) for another system.
A further aside, this document is great to "clear one's head" about what to look for in "reported" statistics!
Regarding security-related issues, you have the following resources "Master Index":
For documented Ubuntu-specific instances, those are summarized here:
As an overview on the Common Vulnerabilities and Exposures (CVE) Program, this presentation offers a good backgrounder: