Neil MacDonald

A member of the Gartner Blog Network

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Coverage Areas:

Even Cool Products Need to be Written Securely

by Neil MacDonald  |  March 20, 2009  |  3 Comments

Here’s another interesting data table out of the latest IBM ISS X-Force security report:


This table shows the Operating Systems with the most security vulnerabilities in 2008. Compared to any single version of any other OS, Apple OS X takes the top spot.

I am bound to get some comments saying that I am claiming that Windows is more secure than OS X. I am not. Microsoft has its issues – but Mac OS X clearly has its own issues. Any OS will have vulnerabilities, but fewer is always better – it reduces risk and, more importantly, reduces our cost of supporting and maintaining the system. The question is not does Apple produce more or less secure OS code than Microsoft or Sun or IBM. Look at the data and ask yourself “Is Apple doing enough to produce secure code for me?”.

Microsoft learned the hard way. In the 2001-2002 timeframe, you were really feeling the pain of using Microsoft’s vulnerable software (Sasser, Blaster, Code Red, Nimda and so on). You voted with your wallet and started switching to alternative OSs like Linux. Bill Gates woke up one night in a cold sweat. The infamous “Trustworthy Computing Memo” was written. Millions were spent on changing Microsoft’s development process and culture (including the use of testing tools) to produce more secure code.

It was painful for Microsoft. It was painful for us. But it needed to happen.

If we are going to use Apple products in the enterprise, then we should hold them to the same standards we hold any of our IT suppliers to, including specific requirements for security testing and threat modeling throughout the software development process.

Even cool products need to be written securely.


Category: Application Security     Tags:

3 responses so far ↓

  • 1 Kyle Johnson   March 20, 2009 at 8:56 am

    The IBM report notes these as “disclosed vulnerabilities” and doesn’t indicate whether these are all reported or those that remain unfixed. I think a more interesting metric would be the number (and percentage) of *unfixed* vulnerabilities and the mean time from report to fix. I would also be nice to have some kind of weighting based on the level of the threat. As you said, every operating system has vulnerabilities, it’s how long it takes to fix them, how critical they are, and how many are left open that is important.

  • 2 Neil MacDonald   March 20, 2009 at 10:34 am

    Kyle, good points. All vulnerabilities are not created equal. Here’s what I’ve seen on the average time to fix. Check out Figure 5 in this document:

    At least for the time period covered in this report, Apple was slower in patch development time for their OS as compared to Microsoft but faster than Sun and HP. I can’t seem to locate a newer version but if anyone has a newer version or a similar report from another security lab please post it here. Note that as it pertains to Safari specifically, Apple does well in Figures 7 and 8.

    Any of these numbers can be misleading. For example, if Microsoft fixes a vulnerability that was never publicly disclosed, how is this counted?

    Rather than worry about whether or not one vendor is better than another, let’s focus our efforts on requiring *all* of our vendors to produce more secure code, including Apple (and SAP, Microsoft, Novell, Oracle, Sun, HP, IBM and so on…)

    And, as you point out, what’s their track record for delivering timely patches.

  • 3 Yes, Macs are Vulnerable Too.   September 25, 2009 at 10:27 am

    […] To me, the data shows Apple needs to put more focus on security in its development (and response) process. […]