Trust, But Verify Your Open Source Software

| | by


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.

 Open Hub Project Demographics

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Follow Us: Facebooktwittergoogle_pluslinkedinyoutubeinstagram

Tags: , , , , , , , , , ,

3 Responses to “Trust, But Verify Your Open Source Software”

  1. Ramaiyer Ramesh #

    Hello Balaji,

    I have a tangential question.

    I understand the value in Blackduck products and have used Protex in the past.

    Consider the following scenario.. The universe of open source is evolving, albeit slowly. BD updates their open source database periodically. What is the expected time frame by which all commercial software from any for-profit company will have some pattern from the open source? Even if this for kernel code, I would be happy to learn about such an eventuality.

    Thanks and regards

    June 12, 2014 at 4:23 pm Reply
  2. All great advice. I’d offer one more, although it seems counter intuitive: make sure that open source software actually is open source software. The Open Source Initiative (OSI) is seeing more and more “Fauxpen” software and “open-washing” marketing tactics.

    Be sure that the software you’re interested (and possibly contributing to) carries an OSI Approved Open Source Software License.


    General Manager, OSI

    December 16, 2014 at 3:59 pm Reply


  1. Why you need to evaluate sustainability | OSS Watch team blog - June 16, 2014

    […] posted on this subject many times here at OSS Watch, but this graphic from the folks at Black Duck is a good visual reminder of why this is […]

Leave a Reply