In Eric S. Raymond's seminal essay on open source, The Cathedral and the Bazaar, he defines Linus's Law, which states that "given enough eyeballs, all bugs are shallow." In other words, if enough people are looking at a certain code, security and quality issues will be discovered.
So how can we explain the Heartbleed bug going undetected for a good two years with such massive adoption rate? Or any other security vulnerabilities discovered since? Does it refute the Linus law?
Linus’s Law Didn’t Fail
The answer lies in the way open source projects are maintained. Jim Zemlin, executive director of the Linux Foundation, shared an interesting fact during the recent Cyber Security Europe. He said that in the pre-Heartbleed days, OpenSSL was maintained by only two guys named Steve.
Let that sink in for a minute – 66% of all websites at that time were powered by technology built around OpenSSL and that doesn't include email services, chat services, and a wide variety of apps available on every platform, but only 2 guys maintained it.
According to Linus’s law, Heartbleed should have been discovered long before it actually did, right? No!
All these companies were using OpenSSL, but only a small fraction was actually contributing to the project. You may have tens of thousands of developers using your project, but that doesn’t necessarily mean you have tens of thousands of eyeballs reviewing it and contributing to it. This is why it is so important that we, as a community, will contribute to open source projects.
Open source is not immune to security threats
Companies of all sizes are opening up to open source and using it on huge scales. According to Forrester’s developer survey, 80% of developers are using open source components in commercial software products.Software companies are making the transition from viewing open source as an alternative to writing their own code or using third party libraries to making open source their first choice.
However, there is a huge disproportion between open source projects massive usage and the resources maintaining and contributing to these projects. This disproportion can explain why popular open source projects still have issues.
Heartbleed Crisis Led to More Funding
In the wake of the Heartbleed OpenSSL security disaster, many industry giants realized that they need to pay more attention to open source and assume responsibility for improving the security and quality of popular open source projects.
The Linux Foundation, a nonprofit organization dedicated to accelerating the growth of Linux and collaborative development, announced the creation of the Core Infrastructure Initiative (CII) in 2014. The CII takes a collaborative, pre-emptive approach for strengthening cyber security with industry giants like Google, Cisco, Microsoft, Facebook, Amazon, IBM, Intel, Samsung, Fujitsu and VMWare backing it up financially.
“We want to find the projects on the Internet that are broken and fix them. We have raised a multi-million fund to provide grants to projects to help them out. Examples include fellowships for the OpenSSL community to help them work full time” Says Zemlin.
Other initiatives include education programs, hackathons, scholarships and access to research and whitepapers. Shared tools for testing and auditing will also be made available and the CII is even paying testers to look at projects for vulnerabilities– including OpenSSL’s 500,000 lines of code. Just recently Mozilla declared it is offering $1M to support open source projects.
Who’s Responsible for the Open Source in Your Product?
If it’s not clear already … it’s YOU.
The open source community and the industry as a whole, is taking major steps to improve the security and quality of open source projects. These efforts will increase the number of security and quality issues discovered and the number of versions released.
But are you currently managing your open source usage correctly and are able to benefit from the better maintenance? You need to take a proactive stand in order to benefit from this transition.
It’s your responsibility to follow license policies, stay up-to-date about security issues, and stay on top of patches and updates. Without knowing exactly what open source components you are using, including all dependencies, and tracking CVEs and versions – you are not keeping your code as safe as you should.
Most software companies are tracking and managing their open source components manually, but it is extremely hard to do. With automatic solutions like WhiteSource, it’s easy to gain full control. WhiteSource also provides real-time alerts when you add any problematic components in your build. You’re also notified as soon as security issues happen, or patches get released. Remember when you catch an issue as it happens, you significantly reduce your operating and development costs.