The Top 3 Strategies To Reduce Your Open Source Security Risks - A WhiteSource Webinar
•Download as PPTX, PDF•
1 like•67 views
In our latest webinar with IMA, we presented The Top 3 Strategies to Reduce Your Open Source Security Risks.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to The Top 3 Strategies To Reduce Your Open Source Security Risks - A WhiteSource Webinar
Similar to The Top 3 Strategies To Reduce Your Open Source Security Risks - A WhiteSource Webinar (20)
More from WhiteSource
More from WhiteSource (19)
Recently uploaded
Recently uploaded (20)
The Top 3 Strategies To Reduce Your Open Source Security Risks - A WhiteSource Webinar
- 1. Combler le fossé: les trois principales stratégies afin de réduire votre risque de vulnérabilité concernant la sécurité des composants open source Presented by: Reut Netzer
- 2. Open Source Components Account For 60%-80% Of The Average Software Product 5%-10% 1998 30%-50% 2008 60%-80% 2016 Proprietary Code Open Source Code Source: North Bridge Future Of Open Source Survey
- 3. Number of New CVEs Discovered More Than Doubled YoY in 2017 0 2000 4000 6000 8000 10000 12000 14000 16000 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 # of Vulnerabilities
- 4. Open Source Is The Weakest Link
- 5. What Makes It The Weakest Link? Awareness Responsibility You carry 100% responsibility over your open source usage • 97% of enterprises do not have a process in place to detect usage of components with known vulnerabilities • Current DAST/SAST tools cannot detect open source vulnerabilities • The information is public and available to all
- 6. 01 It’s Time To Change Your Mindset
- 7. Potential vulnerability detected (SAST & DAST) No public information Need to research to find a fix During development Detection Publicity Remediation Scan Phase Known vulnerability All information is publicly available Actionable remediation(s) are available Continuous monitoring (incl. post release) PROPRIETARY VULNERABILITIES OPEN SOURCE VULNERABILITIES Open Source Security is a different game - change your mindset 0 1
- 9. On average, 70%* of reported security vulnerabilities in open source libraries are not referenced by the developers’ code. Effective vs Ineffective * Based on preliminary research by WhiteSource Open Source Code 70% 30% Ineffective Effective 0 2
- 10. 03 Shift Left Is At Its Best With Open Source.
- 11. The cost of fixing security and quality issues is rising significantly, as the development cycle advances. Source: Ponemon Institute Research Coding $80/Defect Build $240/Defect QA & Security $960/Defect Production $7,600/Defect 0 3Detect Issues As Early As Possible
- 12. What Can WhiteSource Do? RemediationPreventionDetection
- 13. Detection
- 14. How Does It Work? Step One • Local agent calculates Unique Identifier for each file • All identifiers are sent to our server • No proprietary source code scanning Step Two • The UIDs are matched against our master DB • All data – security, licensing and quality – is then compiled for the specific OSS inventory Step Three • Your account is updated • All data is available online
- 15. Prevention
- 16. Not all open source components are created equal… We’ll help your developers to make the right choice the first time. The Web Advisor detects open source package references and provides full information including meeting company’s policies, license type, if it’s used in the organization, security vulnerabilities and more. WhiteSource Web Advisor
- 18. Remediation
- 19. Of Open Source Vulnerabilities Have A Fix Get actionable suggested fixes from the open source community with direct links to new patches, version, configuration changes and more.
- 20. The #1 Choice of Our Ecosystem “We want Microsoft’s users to have access to the best industry solutions for open source management. WhiteSource is a thought leader in the Rugged DevOps space and we are happy that this partnership will bring the confidence, time and money savings they deliver to their customers” Sam Guckenheimer “We conducted a thorough search to identify the right solution to embed into our product and WhiteSource’s combination of the most comprehensive security vulnerabilities database in the market, alongside their unique remediation capabilities, made the solution an easy choice for our team.” David Marshak “Checkmarx is delighted to be working with WhiteSource to offer a complete solution for our users. We both share the same approach of creating solutions developers actually want to use” Emmanuel Benzaquen “The deep integration with Dimensions CM helps our customers to boost the security and efficiency that Serena’s ALM customers are looking. With this partnership No longer will teams collaborating on projects have to manually track open source usage, or speculate whether they are using vulnerable components.” Ashley Owen Application Security Tools: ALM suite:
- 21. GAMING COMMUNICATION ENTERPRISE SECURITYINTERNET IOT & EMBEDDED BANKING & FINTECH HEALTHCARE Some of Our Customers
- 22. Q&A Session
- 23. THANK YOU
Editor's Notes
- Open source components are the core building blocks of application software nowadays, providing developers with a wealth of possibilities that they can use for assembling their products faster and more efficiently. According to several analyst firms, nowadays, Open source components, the libraries and frameworks which are written and maintained by the open source community, account for 60-80% of the code base in modern web applications.
- The challenge is that with the massive usage of more open source components in applications, there will statistically also be a rise in the number of newly discovered vulnerabilities that developers will have to address. In 2017 alone, more than double of the open source vulnerabilities were added to the CVE, impacting tens of thousands of components. As open source usage continues to rise, 2018 is likely to see even more
- Therefore, open source clearly is the weakest link your code. Why?
- Despite the heavy reliance on open source, the software industry has been generally lax when it comes to ensuring that these components meet basic security standards. This is due in large part to their underestimation of the amount of open source components that they are actually using in their products, and that the nature of open source vulnerabilities are fundamentally different than those found in proprietary code. It was found that 97% of enterprises do not have a process in place to detect usage of components with known vulnerabilities. In addition, Unlike proprietary code, which uses tools like Static Application Security Testing (SAST) to detect vulnerabilities, the technology for open source vulnerability detection works in a different fashion. Application security testing tools that can detect vulnerabilities in your code, like SAST, are not applicable on open source components, as they depend on following a set of guidelines that are laid out in white lists. This model works just fine when the code is being managed by a single team, working under a single logic. Open source, however, is run more as a distributed group of contributors adding their work to the code. This makes solutions that rely on white lists untenable for testing the code, and will only lead to a mountain of false positives that no developer wants to run down. The information regarding vulnerabilities is easily findable on public databases. These known vulnerabilities, with the details on which versions are affected and how the exploit can be carried out, are available to all with the necessary information to help security and development teams perform the necessary fixes to secure their applications. The flip side is that hackers will also follow these publications in order to gain free knowledge of how to carry out attacks with minimal effort on their part, saving them the work of having to find their own way into your backend. Therefore, you carry 100% of the responsibility over your open source usage… but who is carrying the responsibility? The developers? Security teams? This is not always very clear.
- Therefore, we have developed 3 approaches and best practices that security teams should implement in order to enable their developers to harness the power of open source and to reduce your organizations exposure to open source security risk. Approach number 1 – it’s time to change your mindset
- (all written in the slide)
- Now once you have distinguished between proprietary and open source vulnerabilities, and have identified which open source vulnerabilities you are exposed to, you need to prioritize the security vulnerabilities you need to remediate.
- developers need to find ways to prioritize which issues need to be fixed first. There is an obvious consideration for wanting to tackle the vulnerabilities with the highest CVSS scores, such as vulnerabilities that could give hackers remote execution access to their systems. However, there are additional factors that need to be taken into account when prioritizing your team’s plan of action. You need to first tackle the vulnerabilities that have the highest impact on the security of your product even before concerning yourself with their CVSS scores. How? Open source components are reusable and are usually developed to fit different customers and use cases. Therefore, open source components tend to package many functionalities. As developers are using open source components “as is”, meaning using the entire package and not just a snippet for supportability purposes, in most cases the application is making calls to only a rather small percentage of the functionalities in each component. These are called effective functionalities. So, what is the impact of the functionalities that are not being effectively used by the product? They are not having an impact on the product as the proprietary code is not making calls to that functionality. This can be understood as being an ineffective functionality since it is essentially cut off from the rest of the chain that comprises our functionalities which serve our application. Our preliminary research on vulnerabilities in Java products shows that only 30% of the vulnerabilities are deemed to be within functionalities that are effective and can have an actual impact on the security of your product. Conversely, this means that the remaining 70% of vulnerabilities detected in these products that while still considered vulnerable, do not have an impact on your product as they lie within ineffective functionalities. By being able to narrow down our resolution of which vulnerable components are effective, and which are not, developers can considerably improve their efficiency by allowing them to focus on the critical issues that require their attention.
- Improving your ability to detect and remediate open source vulnerabilities is not enough to secure your application, since the minute an open source vulnerability is published, developers are in a race against time to implement their fixes before they are targeted by hackers. In order to ensure you will be able to detect issues as quickly as possible and remediate, you need to automate the entire process of detecting and remediating open source vulnerabilities. It is also very important to understand the unique opportunity of shift left when it comes to open source security when automating your processes.
- The growing challenge of speeding up the development process without compromising on the quality of each release was one of the main drivers to the mass implementation of the shift left concept. The idea behind “shift left” is to incorporate software testing earlier in the process and automate it. By moving software testing closer to the developer (that is, to the “left” of the delivery chain), teams are able to detect issues earlier in the development process when it is easier, quicker, and cheaper to fix. Shifting security testing “left” helps developers to detect issues before it becomes complex “tear and replace” operations, and therefore become more complex and costly. According to the Ponemon Institute’s “The Cost of Data Breach” research, the cost of replacing a vulnerable component during the coding stage of the development process costs only ~1% of the cost of replacing the same component post deployment. When it comes to securing the open source components in your software, the potential for shifting left is much greater than in proprietary code. The reason is that with open source security, all the information is already public and available and you do not need to run time intensive tests in order to detect the issues. This means that you can actually detect components with known vulnerabilities before even downloading a component and integrating it with your product. Providing information on open source components to developers will help empower them to make better choices when selecting the open source components they intend to use. This is a huge advantage that shifts security all the way to the left. SCA tools are shifting left open source management as a whole, and not only the security aspect, since software teams need to ensure compliance with open source licenses, ensure the quality of the newly added open source components, and detect newly released versions with performance improvements, new functionalities, and/or fixes for bugs.
- This section you know super well, so based on your time for the parts before, feel free to dive in as much as possible or to be more light on it