Last month, Coverity reported that the defect density in open source projects has gone below the level of proprietary enterprise software for the first time. The number of defects in open source C/C++ projects was 0.59 defects/1000 lines of code, while the same metric for proprietary enterprise software is 0.72. This is great news for those of us who believe that open source software has better quality code than even the best of proprietary software. (It must be added that this is only for C/C++ code – most of which is in mature projects such as the Linux kernel.)
While the security of open source can surpass proprietary software, not all open source projects are created equal. The Heartbleed Bug has painfully demonstrated this fact. Just because a project is open source, doesn’t mean that it is immune to vulnerabilities. Vast chunks of open source projects don’t get sufficient eyeballs necessary to reduce the code defects. In fact, the project demographic statistics on The Black Duck Open Hub, show that 90% of the open source projects are either inactive or have very low update activity. If you are using one of these inactive projects, without paying sufficient attention to what’s under the hood, you could be risking major security vulnerabilities.
Source: Ohloh, The Black Duck Open Hub Project Demographics
Here are some best practices to keep in mind when using open source components in mission critical applications:
- Make sure you use the latest version with all the patches: Research done by White Source Software states that 85% of the projects analyzed use outdated open source libraries. This is a big risk. Keeping the code constantly updated with all patches is a big challenge. Companies like Microsoft, Oracle, Apple, and Adobe have built a strong regime for distributing the updates. However, most open source projects don’t have a strong update infrastructure. Thus, it is your responsibility to make sure that you are on top of all the security patches. Since the bug fixes in open source are immediately disclosed, unpatched software runs a big risk of criminals making use of these vulnerabilities after it is made public.
- Monitor community activity: Pay close attention to how active the community is and how frequently updates are made. An active developer community around the project typically means better support and better code quality. If the project is inactive, be prepared to do a lot of heavy lifting in-house.
- Know who is behind the project: Dr. Ian Levy, technical director at a top UK intelligence agency, has this piece of advice: Being able to evaluate the security of software relies heavily on having knowing the developers and having some insight into their future plans for the software. The security evaluation is about the developer relationship, it’s not about source code.
- Audit the code: If the project is not updated often, you should consider doing a deep security audit to explore the vulnerabilities. There are professional tools that look for major security defects. Chances are that many critical security patches from related components might not have been applied in an inactive project.
Open source software can be quite secure, especially when it comes to mature projects like the Linux kernel and Apache HTTP server. However, you can’t take security for granted. While it is true that many eyeballs can make all bugs shallow, not many projects have enough hands or eyeballs to support them. Also, not all eyeballs are equally talented in debugging code and providing fixes. You must remember to stay on top of all the security updates, as the infrastructure to distribute automatic security patches can be non-existent for most open source software.