Back Ground

I recently attended BlackHat and DEFCON and saw some interesting trends. Several researchers are diving deep into open source code to look for security vulnerabilities. I suppose that after the publicity of “Heartbleed” and the way it occurred many people decided to look harder at open source code.  The debate over the value of public review  of code has strong proponents on both side of the issue and their arguments make sense.  But, I think that we as security professionals dealing with open source must fall back on accurately creating “Threat Models” that reflect the reality of our world.  Specifically, we need to properly assess the threats in the trust boundaries between our proprietary code and any open source code and then take the appropriate mitigation steps for making sure our products are secure.  I do not believe we can rely on open source code reviews to catch all the potential security vulnerabilities. To assume that this is true has already proven to be dangerous. Therefore, we need to look at how the open source code we use interacts with our code and whether or not it may provide some potential for access to assets that we are protecting. It may also include performing our own security assessments on open source code.

Static Tools and Open Source

I recently read a white paper titled Securing Opensource Code via Static Analysis by Raghudeep Kannavar  published with the IEEE 5th International Conference on Software Testing, Verification & Validation, 2012.  In it the author presents some very interesting analysis on open source code and source code analysis (SCA). Here is a short recap:

“Complexity Analysis

• Files of higher complexity have higher probability of errors when fixing, enhancing, or refactoring
• In most opensource projects, most of the development effort is communicated through mailing lists
• The developers are spread across the globe and varying levels of software development skills
• A challenging task to any central entity responsible for coordinating the development efforts

Analysis Trends

• Higher probability of bugs in components with higher complexity, e.g., ‘drivers’
• Complex components such as ‘drivers’ received higher code changes – thus susceptible to introduction of bugs.
• Critical components, e.g., networking, tend to have higher incidences of security bugs being reported.
• These patterns enable us to concentrate the scope of SCA to Critical/Complex components”

The author goes on to recommend that users of open source should apply static code analysis to the open source code that they are using. The paper also discusses some approaches for doing this, which may help prioritize the code to which these static analysis tools are applied. This is because testing all the opensource code may result in huge overhead. He also points out the challenges that could be encountered in adhering to the opensource licenses, which may be impacted by the static code analysis results and associated code changes which may be required by based upon what the static tools find. He also suggest the SCA alone may not be enough, we may need to employ peer code reviews, fuzz testing and other security validation activities as well.

I also found the references the author used very interesting – “International Space Station to boldly go with Linux over Windows”;  “85 percent of companies using opensource”  – Gartner; and “...by 2014, 50 percent of Global 2000 organizations will experience technology, cost and security challenges though lack of open-source governance” – Gartner.

Conclusions

We need to own the security due diligence required for our use of open sourcecode. In the end if some opensource vulnerability provides access to an asset we want to protect we may own the responsibility and associated liability for the issue.  The other side of the source code question  was highlighted by the Keynote BlackHat speaker Dan Geer in the section of his talk dealing with Source Code liability. He talks about the relationship of criminal law and how it could be applied to damages if it was due to intent or willfulness.  As a mechanism to improve security of software in general he is proposing two items:

“1. If you deliver your software with complete and buildable source code and licences that allow disabling any functionality or code the licensee decides, your liability is limited to a refund.

2. In any other case, you are liable for whatever damage your software causes when it used.”