TrailOfBits Weighs In On Mac OS X Vulnerability Stats
Dave G. | May 30th, 2008 | Filed Under: Industry Punditry
Before I comment. Yes, that’s right. Dino Dai Zovi is now a blogger. What’s next… twitter? I thought he only runs web browsers to find quicktime vulnerabilities?
Ok, enough tomfoolery. Dino writes about Mac OS X vulnerability statistics. Based on the information provided by Apple Security Updates, he shows:
Internal: 44
External: 53
Upstream: 84
Then gives a rule of thumb vis-a-vis internal vulnerability finding:
[vendors] should be finding and fixing at least as many vulnerabilities in shipping products as external researchers are.
I’d actually argue differently. Most vendors should have been finding these bugs before shipping. If you are continuing to find bugs in your product after you shipped it, you probably didn’t invest enough in security prior to release.
These statistics are also really hard for external folks to really know because, organizations patch things silently more often than you’d think. Sometimes it’s intentional, sometimes it gets fixed as a reliability bug or someone just changes the code. And that’s not all:
- Just because an external party didn’t receive credit, doesn’t mean it was found internally.
- Just because an external party did receive credit, doesn’t mean it wasn’t found internally.
Here is what I think it really fascinating about these stats:
Almost half of the individual flaws Apple has had to fix were due to code that Apple doesn’t actually own. I do not envy any vendor that has to manage that. It’s a nightmare for everyone.
This also extends past Apple. Everyday, enterprises purchase applications (think enterprise oriented web apps) that ship with third-party code (e.g. OpenSSL, mysql, apache, Oracle). How many of those do you think get updated regularly?


Patrick Bogen
June 2nd, 2008 9:59 amAt my organization (a large university), we have a lot of independent system administrators that come to us to request openings through our external firewall to their servers whenever they wish to deploy a new service. As part of this, we perform a security audit (usually through Nessus, although we’re evaluating some more thorough web app scanning solutions). Nessus often reports out-of-date versions of software, and all too often, the reply /is/ “this is an appliance, I can’t update it.” Sometimes the eventual reply is “the vendor says they’ve patched this old version,” but it makes you wonder if the vendor actually has done that, or if they’re just saying so.
Leave a reply