There's an oft-repeated homily that goes something like this: "The only reason Linux hasn't become a malware target is because it's not that popular." I'm learning there's more truth to that than we realize. Especially if open source developers in general use "open source" in the abstract as a security measure ... and it's not.

Consider the newly-emergent psyb0t botnet, which infests Linux-based cablemodem devices. It doesn't seem to have made much inroads in the U.S., since the variety of device being attacked is more prevalent in Europe and Asia than it is here. Also, and I must be fair about this, the reason the botnet gets a toehold is because early iterations of the router shipped with remote-admin enabled by default with no username or password required.

That said, it's a short step from that to a botnet that exploits security flaws in OSS components, things entirely apart from the default configuration in the system. It's also rather troubling that there apparently was no oversight to insure that something like this didn't happen -- something that too many open source projects do not have in place as a standard operating procedure.

The article above puts it in the bluntest possible terms:

... these devices [are] a mass community of targets for attacks on default configuration errors. And it all just goes to prove there's nothing inherent in Linux that makes it more secure. It's all about how you configure an operating system to function, out of the box and with user intervention. The main thing keeping Linux on the desktop out of botnets is the sophistication of its users. Without that, embedded Linux devices are only as secure as the vendors want to make them. Given that vendors will usually make the security ease of use trade-off in favor of ease, I think psyb0t may just be the tip of the iceberg.

This is why I feel that any open source project of any significant size -- anything that stands a chance of being widely adopted in consumer-oriented or Internet-facing scenarios -- needs at least one experienced full-time security auditor. Not just contributions from the community, but one or more guys on the inside aggressively going through everything line-by-line, scenario-by-scenario, looking for things as simple as this and as subtle as Ye Olde Buffere Overflowe. (Can you imagine something like this being manifested against, say, devices with open firmware?)

Understand something -- I'm not making a bonehead argument like "Linux / open source solutions aren't mature enough to be used in production scenarios" or "Open source means the bad guys can see your weaknesses" or anything that glib and simpleminded. I'm insisting that the best practices need to start now, before things like this hit the masses and not after. As if the Windows security fiascoes weren't proof enough of that.

InformationWeek is conducting a survey on data loss prevention. Find out more here, and take part through March 25.

Follow me and the rest of InformationWeek on Twitter.