So number of security flaws doesn't matter, because the more bugs you have, the better it is.
edit: I'm going to re-write this bit:
The problems with counting flaws are myriad. As there is no mention as to *what* you're counting. A DoS vulnerability may not be worth patching for a machine in your MZ running a service that's only used for a few hours every day. Especially if it means dispatching a tech to a CO in Nowhereville USA. This is part of your security profiling procedure where the company decides what are the things it's trying to protect. Is it uptime? Is it data integrity? Is it different for different servers? On top of that "counting" is lame because it assumes that every flaw is of equal weight. However in the *real* security world we don't think that way. The term-du-jour is "modeling" but all this is is taking a page out of risk management's book. Here we use MS's model DREAD - http://msdn.microsoft.com/en-us/library/ff648644.aspx . Essentially we assign every flaw a bunch of criteria like how frequently this could be taken advantage of or the skillset required to pull it off. On top of that there is always remediation. That is, is there a workaround or fix? Can we use a firewall or our BGP equipment to mitigate the risk?
...and that's just for the group of outstanding flaws. IIRC the little mouse was actually referring to bugs that either were closed or being addressed. That metric is probably pretty close to useless. It's almost an example of the gamblers fallacy.
Uptime doesn't matter, because you dont need to reboot after a privilege escalation.
Depends on where in the stack the escalation takes place and again if there are ways to mitigate it. Uptime is a statistic that might tell you something about security but it can just as easily tell you something about funding, business goals, overall admin philosophy. So it's not likely to be a very *good* indicator of security.
Design choices doesn't matter, because .... (insert stupid reason here)
Again it depends, for example a microkernel architecture could be considered a security design choice but the BSD's manage fine without it.
Security is not a concept.
Actually that statement didn't say it was. All that sentence said is that security *contains* concepts.
It's a question of counting flaws and measuring uptime.
Like for example the idea that some mice might have that "security" is based purely on two metrics - is a concept.
Do you really need me to explain how those two metrics: Number of flaws and Uptime don't necessarily tell you anything about security?
Not to mention some of the postings you've made of these kinds of metrics makes me think you've never taken a statistics class.