In the 1990’s we saw viruses and worms proliferate across the Windows platform until the problem became so bad that Bill Gates had to stop shipping and fundamentally change the way Microsoft built software.
Dan Geer first wrote about this in CyberInsecurity: The Cost of Monopoly. How the Dominance of Microsoft’s Products Poses a Risk to Security and followed up years later with Heartbleed as a Metaphor after a bug in the open-source library Open-SSL caused havoc.
In the last few weeks, we have again been reminded by CloudBleed and the Amazon AWS S3 outage that despite sage advice for many years, we are still building on monocultures and burying our heads in the sand. I get it. It’s herd behavior but when you watch a school of sardines get rounded up by dolphins you can’t help but ask yourself why humans aren’t smarter than sardines.
I argue that CloudBleed probably went undetected for some time in part because the vulnerable component was built with a language that is not popular called Ragel.
Open-source is amazing. We love it. It rules our world, fuels our fire, powers our product and floats our boat but no one should ever forget that reusable code can also mean reusable vulnerablities and potentially reusable backdoors and reusable malware. This fact is not lost on the bad guys who are always looking for the biggest attack surface that will have the biggest impact.
The conditions are all true for significant and sustained data breaches to be common-place as a result of hackers exploiting open-source upstream (not yet happened to my knowledge) or downstream where that open-source is consumed and deployed.
Keep using open-source. It’s brilliant and it’s changing the world but use it with an appropriate dose of caution. Trust but verify. By making open-source security an integral part of your continuous security process you can protect yourself, your users and the users of your open-source code.
And yes this post is totally self-serving but I have conviction and signals that stormy times are ahead.