Apple and security: 5 deadly development sins

If Apple carries on with its many programming misdeeds, it will soon see a breakdown in its shiny, new security

Recently, Apple decided to replace open source OpenSSL with its own libsecurity_ssl. In doing so, Apple went from a large community to a small community with poor development practices.

Reportedly, the company made the move due to OpenSSL not having a "stable API," meaning that when Apple distributed security patches to OpenSSL, applications dependent on it would break. It had other options, such as creating a wrapper and asking people to use that instead; backporting fixes to old versions (à la Red Hat); or working with the community to stabilize the API. In my past dealings with Apple, however, I've noticed it doesn't play so nice with others unless it makes all the rules and serves as decider. I have a feeling other options were moot before it made their own security library.

[ See InfoWorld's "iOS 7 for developers" special report for the scoop on the bells and whistles in Apple's mobile OS -- and how you can harness them. | Keep up with key Apple technologies with the Technology: Apple newsletter. | Discover what's new in business applications with InfoWorld's Technology: Applications newsletter. ]

Which brings us to Apple's first deadly sin: arrogance. Arrogance is a common bug in software developer personalities. It's fine if it makes you no fun at parties or wins you an InfoWorld column, but it isn't fine if it leaks into your code. Humble developers assume code can be broken and can live with attempts to prove that even if they wrote it. The code is proven bad -- not your fragile ego. The first thing I teach green developers is to assume their favorite theory is wrong and to seek to disprove it rather than prove it. People who try to prove themselves right are prone to confirmation bias and looping.

This brings us to Apple's second deadly sin: I can't find the automated tests for libsecurity_ssl. According to a poster on Hacker News, there are a couple dozen tests (a bit light for this sort of thing), but I couldn't find them.

On the other hand, I found a comprehensive suite of tests for OpenSSL. In fact, maybe Apple should have run a version of this on its code since a casual glance would have caught it -- which means Apple doesn't actually run automated tests on check-ins.

We're not talking a full agile process; we're talking basic principles. I often get comments from people who dispute the nature of a "unit" or what an integration test should be, but surely we can all agree that you should have an automated test before release as to whether your SSL library validates SSL certs?

Possibly related to the first deadly sin is Apple's general lack of collaboration. We know best, fork first, rewrite first -- then maybe we let the cool kids join us if they are worthy. Sometimes this has turned out well and we get KHTML turning into WebKit (which Google has in turn forked -- but that's for another post). This time, it cost Apple customers and users. For security, having the larger community is critical; collaborating rather than keeping your failures secret until you fix them is key. This culture of secrecy and arrogance has been written about before and will bite Apple again.

The next deadly sin is Apple's mind-set. Security requires you to think backward. The worst systems are designed by people who try to keep other people out and think accordingly. The best systems are designed by people who are empathetic. Sure, there is science and research, but fundamentally, how can I defeat it? Think like the black hat. I prescribe that Apple watch a lot of bad serial killer movies.

Finally, learn from your mistakes. Each iteration (if it has iterations) needs a retrospective. What went wrong? What went right? If you find one goto fail bug, maybe you should look for other goto fail bugs? If that happens a few times, maybe you should consider goto harmful for your organization (even if you think it has its place elsewhere)? Maybe big blocks of repetitive if statements are bad, too? Who's reviewing this code at Apple?

I know I'll never have the answer. As long as the faithful line up to worship at the Apple Store and keep swiping their cards for the bling, nothing will change. Who said trustworthy computing was profitable?

This article, "Apple and security: 5 deadly development sins," was originally published at Keep up on the latest news in application development and read more of Andrew Oliver's Strategic Developer blog at For the latest business technology news, follow on Twitter.