On the first of the month — also the first of the year — Dana Blankenhorn published the sensationally titled The biggest threat to open source in 2009. His thesis is simple: that, because open source software usually lacks any mechanisms for easily updating to the latest security patched version, the growing popularity of open source software will render it more vulnerable to problems than its closed source counterparts.

As a lead-in to his main point, he said:

There is no longer any doubt that hackers and malware writers are going after open source projects as they once went after Windows. Vulnerabilities are being found, discovered, created, exchanged.

There seems to be a common malady amongst opinionated tech writers — that of never quite getting it when it comes to the fundamental principles of security. A particular favorite for being ignored is that of security through obscurity. Many many moons ago, I wrote what I think is a decent treatment of the subject as it applies to open source software, Security through visibility. While it makes a pretty strong case for ignoring the bleatings of “popularity is insecurity” doomsayers, it’s really only the first step toward full understanding of all the problems with the assumption that the only thing “secure” about open source software is obscurity.

Obviously, based on his start to the article, I was already expecting very little in the way of useful information. His next statement left me even more mystified at what appeared to be a towering edifice of ignorance, however. Specifically, he said:

The best protection against vulnerabilities is to keep software updated, but most open source lacks update services. That’s one part of the Windows license that is worth paying for, and there does not seem to be an open source equivalent.

As a long-time user of open source operating systems, previously favoring Debian GNU/Linux, and subsequently moving on to FreeBSD, I was stunned to see this in writing, published for all the world to see. Was he serious? Could he really believe that?

One of the most visible wins for open source Unix-like OSes, once one has learned a fair bit about them, is the casual availability of superior software management systems. I’ve written a brief primer for effective use of APT for TechRepublic, Efficient software management with the Advanced Package Tool in Debian. I’ve also addressed the excellence of a security tool integrated with FreeBSD’s ports system, How FreeBSD makes vulnerability auditing easy: portaudit. Both of these articles illustrate some of the significant benefits of better software management systems than offered by MS Windows.

Perhaps even more relevant to Dana’s point is the fact that, on open source Unix-like OSes (but not on MS Windows), the software management system typically manages security updates for far more than just the core OS and a couple of applications created by the same vendor. Such Unix-like OSes’ software management systems tend to provide security update management for literally thousands of software packages originating outside the core OS project itself — in some cases, tens of thousands.

Then, his next statement clarified his meaning:

An exception is Firefox . . . But how many take advantage of this? And how tied is Firefox to updating for security purposes? Remember we’re talking about pushing updates, not asking users to pull them.

Suddenly, it all became clear. In Dana Blankenhorn’s mind, “open source software” refers only to the handful of popular open source applications that are regularly used on MS Windows systems. I find it interesting that the only example of an open source application he offers is an exception to his rule, however.

Where are all the legions of open source applications that don’t provide easy software updates? Whose fault is it that MS Windows doesn’t have a software management system that can help ease the process of applying security patches for these applications the way open source OSes do? Where are the examples of closed source applications that provide such update management as he describes, where the MS Windows compatible open source alternative does not — thus justifying his singling out of open source software as somehow more notably vulnerable?

Perhaps the worst part of the inaccuracies of the article is the fact that its clear assumptions (that all software worth discussing is MS Windows centric, for instance) for those of us who know better are opaque to those who do not. A manager with little or no experience of OSes outside of MS Windows may read this article and come away with the assumption that open source OSes completely lack software management systems. As a result, he or she may scupper any potential plans to deploy open source Unix-like systems in the network. So much for “the best tool for the job”; such decisions are often difficult to make well even when you aren’t hampered by wrong-headed ideas like those Dana’s article might inspire.

He does make a good point about corporate culture, though:

But until this ramps up (hopefully in a competitive market), enterprise managers have an easy way to say “no” to open source.

Regardless of how dangerous this is, the fact that managers feel it’s dangerous makes it so.

Too bad some of those managers might “feel” it’s dangerous specifically because of his own article.

I’d clarify that to say that managers feeling it’s dangerous doesn’t actually make it so — but it does make it so for all intents and purposes in the corporate environment, when it comes to technology implementation decisions. When the higher-up says “I think the closed source software offering is better, because I have these concerns about the open source software alternative,” his or her subordinate (and perhaps more technically inclined) IT worker will eventually reach a point where he or she must either make decisions limited by the manager’s fears or polish his resume. Take it from someone who knows from personal experience.

On one hand, I’m inclined to be dismayed by this common bureaucratic failure of corporate culture, and feel the urge to rail against it. After all, security is everybody’s problem; it’s not just a problem for “that guy over there”. Your problem, to a significant extent, becomes my problem when you connect to the Internet.

On the other hand, knowing something about security that others don’t provides something of a competitive advantage. Where competitors may stumble and fall, the organization with a knowledgeable IT department will remain stable and secure, and prosper where others have failed.

I guess there’s a silver lining to every cloud of disinformation.