Managing Open Source in Application Security and Software Development Lifecycle

Editor's Notes

• #3: JOHN: Over the next 30 minutes or so, our goal is to give you a brief overview on the state of application security and the new challenges that the rise in open source software use is having on it. We’ll then share our perspective on a new holistic approach organizations can take to ensure application security in this new hybrid world.
• #4: JOHN: First, let’s kick things off with a brief overview on the current state of application security
• #5: JOHN: First, let’s kick things off with a brief overview on the current state of application security Security issues can be introduced at any phase of the SDLC. While a great deal of attention is given to security bugs resulting from coding errors, design flaws make up over half of the issues identified by Cigital. This emphasizes the need to “build security in” at each phase of the lifecycle and is why we aim to provide the tools and expertise at every stage. By ensuring security testing is injected at the right time, at the right depth with the right tools and processes with the right experience we resolve vulnerabilities earlier and more cost effectively.
• #6: JOHN What some tools or vendors won’t tell you is they don’t check open source. How can you possibly be secure when parts of your software aren’t tested? You need to have visibility into your systems so how do you do that. Some things to consider. NOTE – you can mention BSIMM controls SR2.4 (Identify Open Source) and SR3.1 (Control Open Source Risk)   Comments/recommendations: ·         The biggest open sources challenges facing organizations globally are alluded to in the second section of the data sheet (Gain visibility and control over risks…) and could use much greater explanation and punctuation. o    Indeed the “aha moment” for organizations and the conversation starter is : “There are oceans of open source in your applications codebase: 1.) Do you know where all of it is? (Visibility) and 2.) As new open source vulnerabilities are reported can you quickly, accurately determine if you’re affected and find the vulns and fix them? (Control) o    This is the punch in the nose. No organizations can control and manage what it cannot see. The explosion in open source usage worldwide in the last 5-10 years has not been accompanied by disciplined, thorough, comprehensive approaches to gaining open source “visibility and control.” The organizations that do “track” their open source use largely do so with manual approaches (spreadsheets, Share Point files, word of mouth.). These methods of course are inadequate and do not scale. ·         Organizations that think they have their open source security “bases covered” with SAST and DAST testing tools are mistaken. If it were that case that DAST and SAST approaches were effective in open source identification and vuln detection, IBM Security AppScan and HPE Security Fortify would not be offering Black Duck Hub in their solutions and telling customers “With the integration of Black Duck Hub, organizations using HPE Security Fortify will be able to detect, prioritize and fix known open source vulnerabilities as well as custom code vulnerabilities – all through a single view in HPE Security Fortify Software Security Center.” ·         Black Duck Hub automates the process of providing visibility into the open source in apps and containers and gives organizations the control they need to secure and manage that open source.  This is security and compliance value that demands attention. ·         As a way to dramatically drive home the need for such automated processes, I recommend referencing empirical data from our 2016 analysis of Open Source Security Audits of 200 commercial applications conducted by Black Duck On Demand as part of M&A engagements – 67% of the applications that were audited contained known open source vulnerabilities, nearly 40% of which were rated “severe”; organizations were using more than twice as much open source in their apps than they listed; and the average age of known vulnerabilities in the code was 5 years+. ·         Only after organizations understand the potential consequences of their lack of visibility and control, will they fully appreciate why automating the fundamental steps is the correct approach ·         Also, more clarity and specificity in exactly what open source security and control value Black Duck and its solutions deliver in the partnership would be helpful to the data sheet. Cigital brings expertise and experience with designing application security programs, conducting security testing, and remediation guidance with its professional services, managed services, and partnership with leading technology vendor Black Duck. Cigital provides a range of services, including: 1. Security Assessments covering Open Source • Integrate Open Source testing into a comprehensive security assessment project (e.g., as part of SAST, DAST, or penetration testing) or specific to Open Source. • Utilize Black Duck’s Knowledge Base to analyze Open Source components and identify risks. 2. Integration of Open Source Security into your SDLC and SSI, including: • Security policies for Open Source • Deployment of Open Source analysis tools and their integration into SDLC • SSI development or management 3. Remediation of Open Source security risks • Cigital provides expertise and resourcing to guide or manage your remediation of risks in Open Source
• #7: JOHN Cigital and Black Duck recently announced a partnership. The goal of our partnership is to empower organizations with a software security solution, that provides visibility into the security posture of applications across your enterprise, in both custom code and open source libraries. With the partnership and integration, security vulnerabilities identified from Black Duck can now be viewed through Fortify Software Security Center.
• #9: MIKE: When we talk about software security, we need to remember that applications are composed of a couple of different types of code. There is the code you write, which we will refer to as “custom code”, and there is the code you don’t write, largely comprised of open source components and sometimes commercial components. These are providing functionality that is required in the functional requirements for the software. Using open source relieves development teams of the task of writing these portions of the code, saving time and money while accelerating time to market.
• #10: MIKE: We’ve seen open source use grow over the past 20 years. Years ago, open source was rarely used. Black Duck’s early customers often wanted to identify open source in their code base so they could eliminate it out of fear of restrictive licenses. Today, open source is embraced by all industries, including the US government, and it’s not uncommon to see applications comprised of 75% or more open source. PROMPT TO JOHN – we are seeing better security controls added to these as well, and organizations can benefit from making sure these components are implemented and controls used appropriately
• #11: MIKESo while open source offers a lot of benefits to organizations, it’s not without risk. Like any software, it can include vulnerabilities. You may recognize the logo’s shown here, but think for a moment about what they have in common They are all vulnerabilities in well known and widely used open source components They were all present in the code for years, in spite of thousands of instances of testing using traditional security tools and pen tests They were all found by security researchers and disclosed responsibly to the public While vulnerabilities like Heartbleed, GHOST, ShellShock, DROWN are well known, they represent a tiny fraction of the vulnerabilities reported in open source. In fact, the National Vulnerability Database has reported over 6,000 new vulnerabilities in open source software since 2014 alone. As you can see in the chart, we see a pretty consistent flow of new vulnerabilities based on the work of security researchers. The spike in the graph shows how the discovery of Heartbleed 2 years ago spurred increased research and scrutiny of open source. And again, while Heartbleed made the evening news, there have been over 70 additional vulnerabilities – just in OpenSSL – since then. The problem this presents is two-fold, visibility to the components you use, and visibility to the vulnerabilities
• #12: MIKE It’s obvious that you must have visibility to the open source you’re using in order to protect your organization and users from vulnerabilities. This is not always how things work, however. Our recent study on open source in commercial applications showed: Go through stats We as security professionals need to recognize that open source and custom code require defense in depth -
• #13: MIKE: 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.
• #14: 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
• #15: MIKE: 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.
• #17: JOHN: As mentioned earlier, there are several security activities that can be implemented at each phase of the SDLC. When organizations think about vulnerabilities in open source, we often hear that they believe their existing activities in the “Coding” phase, specifically static analysis, covers open source. After all, the code is available for analysis, why wouldn’t these tools work?
• #18: JOHN: 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?
• #19: JOHN 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
• #20: JOHN: Regarding visibility to the open source being used, how are companies managing this today? In short, most companies are not addressing this well. 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?
• #21: NOTE – include discussion of security features/controls MIKE: 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 components and available controls, 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
• #22: MIKE: To bring this back to the Software Security Touchpoints, there are a number of activities specific to open source that should be considered. MIKE: A best-practices solution would combine elements of TRUST, VERIFICATION, and MONITORING: 1 – Starting with Policies. Just as organizations should create security requirements, so should they create policies about the type of open source or third-party code they will allow in each application. This, of course, will vary with the deployment model and criticality of each application. 2 – Next is providing developers and architects a way to choose open source components that are free of known vulnerabilities, have active community support, and are licensed appropriately for each appliication. 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 and automated controls mean three things, having an accurate inventory of open source, being able to map than against all known vulnerabilities, and being able to alert or block when components violate company policy, 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
• #23: MIKE
• #24: MIKE: In summary, we’ve discussed: OSS is pervasive and integral part of app development OSS has unique security and support challenges 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?