Security in the Age of Open Source

Editor's Notes

• #4: The broader use of open source has been great for businesses. They relieve development teams from writing many features from scratch, lowering development costs and speeding time to market. Many of the popular open source libraries are used by thousands of organizations, and have proven their effectiveness in large, enterprise applications. Our audits find open source in over 98% of the applications we test, and on average, about 1/3 of these code bases are comprised of open source
• #5: We’ve seen a trend recently in “named vulnerabilities”, and Heartbleed, Shellshock, Freak and the others are likely familiar to you. What do these all have in common? Each is a vulnerability in a widely used open source component Each existed for years without being detected by automated analysis tools and penetration testing methods. Each was ultimately identified and disclosed by security researchers conducting manual code reviews. If automated security analysis tools and penetration testing tools were effective at finding vulnerabilities in open source, these vulnerabilities would have been found long ago.
• #6: 2 most common automated security testing methodologies are static analysis and dynamic analysis. In both instances, these tools are looking for common security vulnerabilities – unknown to the developer – in the custom code written by development engineers. Static analysis works by scanning source code or binaries, and building a model of the applications data flow and control flow. Once built, the tools can then run pre-determined rules against the model. For example, a rule may look for an instance of a string copy, then traverse the model to determine if it is possible for the source buffer to have a value larger than the destination buffer. If so, a buffer overflow issue could be possible. Possible issues are mapped to the source code, making it simpler for developers to examine the issue, determine if it a true or false positive, and remediate. Dynamic analysis works on running applications in a test environment, therefore by definition very late in the development lifecycle. It will also look for common bugs resulting from coding errors, often by testing inputs to the application with unexpected data. An example could be using SQL commands in a password field to check for input validation. The results from these tests are mapped to the URL of the application (which page was tested), the input, and the results. Developers must then trace the issue from the web application to the source code for verification and remediation. These tools are very helpful in preventing common security issues in applications – but what’s missing?
• #7: Organizations should use static and dynamic analysis to find bugs in the code they write, but… Open source vulnerabilities are too complex and too nuanced to be found by automated tools If the tools were effective at finding vulnerabilities in open source, the vulnerabilities would have been found long ago HeartBleed was present in OpenSSL for 2+ years, despite constant testing using automated tools 50+ vulnerabilities in OpenSSL since Heartbleed have all been found by researchers. Vulnerabilities in open source are almost exclusively found by researchers manually inspecting the code and conducting experiments Of the 4,000 vulnerabilities identified last year, fewer than 10 we Very useful in identifying common security bugs in custom code Typically responsibility of security team Some can integrate into the build Provide a snapshot of security vulnerabilities that each tool can identify Exploitability of an issue can easily change Results require review and scrubbing #1 complaint – too many useless issues Typically used late in the SDLC Often require compiled application and/or test environment re identified by automated tools
• #8: Organizations should use static and dynamic analysis to find bugs in the code they write, but… Open source vulnerabilities are too complex and too nuanced to be found by automated tools They provide a snapshot of the perceived security of the code base – at a single point in time.
• #9: When a product is released or deployed, security testing usually stops. After all, the code base isn’t changing, so the automated tools would just return the same results over and over again. And while the code base may not change – the threat environment changes constantly as new vulnerabilities are discovered and disclosed. In 2014, over 7,900 new vulnerabilities were disclosed by NIST, a little over half of which were in open source components. These were often not obvious bugs, and very few were identified by automated tools. Instead, individual security researchers discovered and disclosed the issues.
• #11: Managing open source can be a challenge, since it can enter the code base in several ways. You may have policies, and even review and approve open source in design reviews, but developers may reuse internal code that includes older open source components, pull unapproved code from web-based repositories, integrate code from supply chain partners. The end result is deployed code that contains open source, often without the knowledge or review of development managers and security teams.
• #12: MIKE: Open source is not necessarily less secure, or more secure, than commercial software. There are, however, some characteristics of open source that make it particularly attractive to attackers. Open source is widely used by enterprises in commercial applications Therefore, a new vulnerability in a popular project provides a target-rich environment for attackers. Attackers have access to the code for analysis Vulnerabilities in commercial code are exploitable, but attackers don’t have easy access to the source for analysis. That’s not the case in open source, where everyone has access. Like researchers, attackers can also identify new vulnerabilities When new vulnerabilities are disclosed, we publish them to the world NIST maintains the National Vulnerability database as a publicly available reference for vulnerabilities identified in software, and other sources – most notably OSVDB – focus on all identified vulnerabilities in open source. Proof of the vulnerability (in the form of an exploit) is often included When a vulnerability is discovered, the researcher will typically provide proof of the vulnerability in the form of exploit code, making the attackers’ job even easier Attackers can use these as well – but if they are confused, there are typically YouTube videos available to provide step-by-step instructions
• #13: What’s the implication of using open source code? Something many organizations haven’t considered is that the support model is entirely different. With commercial code, there are often dedicated security researchers, whose findings are put out via a robust alerting infrastructure to all their customers. Regular patches means their customers need not worry too much about remediation, as long as their patch management process is fairly robust. And most importantly, dedicated support teams are able to respond to your issues should anything happen. With open source code, security research is often done by “white hat” hackers, academics, and the general open source community. There isn’t necessarily a clear process for making sure all code commits do not introduce new vulnerabilities. Security issues are usually announced on newsfeeds, email lists which you need to subscribe to. There is no proactive alerting for customers since there are no “customers” in the traditional sense of the word. When bug fixes go out, patching usually just means downloading the latest version, which may break the application. There is no one standard way of distributing patches to open source code. And finally, the biggest challenge of all is that your engineering and security teams are ultimately responsible for the open source code you use. In case of a security incident, when it comes to open source there is no vendor you can point a finger at. That means the imperative is on you to be extra-vigilant when it comes to open source vulnerabilities.
• #14: MIKE: In short, many companies are not addressing this. The best practices we have seen in large, multi-national organizations, with mature SDLC practices, would be similar to the 3 activities listed here – question development teams about what they are using, tally the results in a spreadsheet, and react to vulnerabilities that they hear about. Manual tabulation Manual tabulation occurs either at design review (and is therefore dependent on developers adhering to version requirements and not adding additional functionality) or at the end of the development cycle (therefore dependent on the dev teams' memory and best efforts).  In both cases, accuracy is dependent on static requirements or managers’ memories. Accuracy at the beginning of the SDLC ignores any changes in requirements, especially in an Agile environment. It is also dependent on developers selecting the approved version of a component Accuracy at the end of the SDLC is subject to recollection and level of effort Maintain results in a spreadsheet Updates to code that include new open source may not be captured Tracking of new vulnerabilities in the components used is decentralized, at best Manual tracking quickly becomes unmanageable On average, 11 new vulnerabilities per day What do you do if you have 100 internal applications, and each uses 10 open source components?
• #15: A best-practices solution would combine elements of TRUST, VERIFICATION, and MONITORING: 1 – Starting with TRUST, this is providing developers and architects a way to choose open source components that are free of known vulnerabilities, and have active community support. This is a proactive step that reduces risk downstream in the software development process, and is the most cost-effective means of risk reduction. 2 – VERIFICATION means two things, having an accurate inventory of open source and being able to map than against all known vulnerabilities, in any and all applications, at any point in the SDL 3 – MONITOR means being able to monitor the released code for newly discovered vulnerabilities and alert the right people for remediation. Many organizations end security testing when applications are released. After all, the code base isn’t changing, nor are the security rules in the tools, so why test simply to see the same results again? However, this ignores the fact that while the code base isn’t changing, the threat environment changes constantly. With over 4,000 new vulnerabilities each year, a comprehensive solution should be continuously monitoring this constant stream of new vulnerabilities, and automatically notify you of any new vulnerabilities in the open source you used in deployed applications, including: Which applications use the code How critical the vulnerability is, and How to remediate it
• #18: In summary, we’ve discussed: OSS is pervasive and important part of app development OSS has unique security and support challenges existing tools don’t fill the gap manual process isn’t sufficient Therefore, level of risk warrants action. If you agree this is a priority for you, the next steps are critical. Most CISOs we speak with want to find out more about the current situation at their organization. The best person to ask is often the head of application development. What you want to know are the answers to the following questions: What policies exist? Is there a list of components? How are they creating the list? Are they tracking vulnerabilities? How do they ensure nothing gets through? These questions will shed light on the current state of how open source is used and managed at your organization and give you a good starting point for further discussions. What would you propose the next steps should be?