Open DevSecOps 2019 - Securing the Software Supply Chain - Sonatype
•Download as PPTX, PDF•
0 likes•273 views
This document discusses securing the software supply chain. It notes that 90% of services use third-party components which can increase security risks if not properly reviewed. The speaker recommends automating security and legal reviews of open source components used in software to address this issue, rather than relying on manual reviews. The benefits of automation include faster and more comprehensive reviews that can occur continuously rather than just during development phases. Automation is presented as key to effectively securing the modern software supply chain.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Open DevSecOps 2019 - Securing the Software Supply Chain - Sonatype
Similar to Open DevSecOps 2019 - Securing the Software Supply Chain - Sonatype (20)
More from Emerasoft, solutions to collaborate
More from Emerasoft, solutions to collaborate (20)
Recently uploaded
Recently uploaded (20)
Open DevSecOps 2019 - Securing the Software Supply Chain - Sonatype
- 1. Ryan Sheldrake Sonatype - Principle Architect, International Securing the Software Supply Chain
- 5. The software supply chain
- 6. Software development lifecycle + Secure development lifecycle Learn Design Code Build Verify Release Operate
- 7. The importance of open source software (OSS)
- 9. Why? • How does this affect you? • You – Developers – are the front line of security - 90% of services are third-party components. - The use of 3PP and open source components can increase the security attack surface and legal risk. - Security reviews of each 3PP component have unknown status. • The unknown security posture of open source components can increase the security and legal risk of all products.
- 10. What is REALLY inside your components? • Food? Is it organic or grass fed – who do you trust to tell you the ingredients? • Your car? Engine size & design materials? • Your House!? The foundations and roofing material? • Your software! Are you still using components from 8 years ago when you first created your product?
- 11. How do these attacks work? • Infrastructure as code • Apache, DNS, Bind, Docker, etc. • Code as code • Best case scenario: deletion • Worse case scenario: distribution of malware • Patching • Coordinated vulnerability disclosure • Upgrade minor versions vs. major versions • Trust but verify your upgrade source
- 13. How do we fix the problem?
- 15. • Pre-approval required by both security and legal teams - Each team using a component needed to submit a review request - Even if that component was used in different teams – each use case can differ • Security teams - Manually check if the request was using the latest version - Manually review change notes - Manually search Google/NIST/MITRE for CVEs - Manually code review • Legal teams - Manually review licenses What Salesforce Used to Do!
- 16. Automation – World Class Data! World Class Data
- 17. Automation phases • Awareness, awareness, awareness • Administrators and developers – bring these OSS components into the ecosystem • Integrate these components in the design and security review of your application and infrastructure lifecycle • Consider the legal risk for compliance requirements • Decide workflow for 3rd Party Proprietary/OSS ownership
- 18. Automation phases • CRAWLING • Scan source code repositories - Command-line scanning of repos - Git integration • Sonatype Nexus IQ Server REST APIs - For bug integration
- 19. The software supply chain: Crawling
- 20. Learn Design Code Build Verify Release Operate Software development lifecycle + Secure development lifecycle
- 21. Automation phases • WALKING • Scan and integrate with build - CI/CD integration is your friend/point of control - Sonatype Nexus IQ Server can scan for security and legal issues
- 22. The software supply chain: Walking
- 23. Full Application Bill of Materials
- 24. Learn Design Code Build Verify Release Operate Software development lifecycle + Secure development lifecycle
- 25. Automation phases • RUNNING • Scan and integrate with repositories and IDEs - Nexus Firewall with Nexus Repository • Scan and integrate with IDEs - Nexus Firewall with Eclipse/IntelliJ/Visual Studio • Continuously Monitor for new threats
- 26. The software supply chain: Running
- 27. Learn Design Code Build Verify Release Operate Software development lifecycle + Secure development lifecycle
- 28. Results! - Minutes to scan via weeks to manually review - Comprehensive view of security risk - Multiple points of feedback and control - Continuous scanning - Complete understanding of legal risk • Impact to security and legal reviews
- 29. Automate or Die Every CISO
- 30. Secure your software supply chain • Verify the integrity of your software supply chain • Increase awareness of the threats to the software supply chain • Examine your infrastructure and software development lifecycle • Pilot with manual workflow until confidence is gained • Automate, automate, automate • Ask questions. Be curious.
Editor's Notes
- This announcement came out about a year ago now. Who remembers this malware attack? Who knows how the attack worked? Can you imagine yourself in the shoes of this product VP that had to publish this blog post? Such an attack not only attacks the software itself, but also the core premise of the company’s purpose: remove crapware from computers. Imagine 2.3 million of YOUR users with this installed malware, potentially compromising all information on their computer. More recent research has indicated that a future version of malware would have included a keylogger as well. https://www.ccleaner.com/news/blog/2017/9/18/security-notification-for-ccleaner-v5336162-and-ccleaner-cloud-v1073191-for-32-bit-windows-users
- A few months later, this article comes out talking about how Ccleaner was just one of several high profile software supply chain attacks that year, and it marked a turning point in how infrastructure and services are compromised. Why target a single person with an spearphishing email when you can get huge swaths of entire companies by targeting an open source component?
- This whitepaper released in July 2018 talks about the financial cost of cyberattacks and specifically focuses on four supply chain attacks, including Ccleaner (targeting 18 companies), Netsarang, MEDoc ($300M in cost to each company affected), and Kingslayer. The cost of the Experian breach was $4B devaluation in stock and $400M in immediate costs. There’s actual cold hard cash that’s impacted if one of the open source software components gets forgotten about.
- So, let’s level set and talk about what is the software supply chain. You’ve seen these traditional supply chains of how the latest toys and physical products get to retail stores for consumers to shop. The software supply chain is the equivalent in how software gets created. Whether you have 5 developers or 5 teams of developers or 50 teams, you are merging code from many different places. The software supply chain also applies to the network and to deployed systems. Do you know what software is running on your network switches? Or in your datacenters?
- The stock value hit The customer hit The brand hit
- Do you really know what’s in the cake???
- Coordinated vulnerability disclosure means that the security researcher works with the vendor to notify and then wait for public disclosure when the patch is available. This also means that the exploit path is also known before patching happens.
- Agility Reuse existing component Reduce writing new code Recycle old code Availability As we enter the holiday season, think about 24x7 shopping Security Who performs security reviews of third-party software?
- Cons: Time consuming Redundant Tedious No responsibility after initial approval No additional reviews after initial approval Redundant reviews between multiple security teams Bouncer – motivation, get the job done, leaving the company? Rock star, meeting deadlines Short cuts Pros: None
- World Class Data
- Administrators and developers – you are the security gateway – you have the right intentions. You’re increasing the agility of the company. 5 Whys: Ask one level more of questions. Does it have to be that library or component? Can you use a smaller library? Do you need every version of that library or component? Don’t hide your head in the sand Integrate this type of security review into your application lifecycle Consider the legal risk for compliance requirements Decide workflow for 3PP/OSS ownership
- Shift as left as possible
- 800 jars * 15 minutes = days Automation: 5 minutes Minutes to scan via weeks to manually review Increased agility for using 3PP/OSS You can be the hero and release a feature or product months earlier Comprehensive view of security risk Improved awareness of security posture due to 3PP/OSS usage Threat modeling will Continuous scanning Improved awareness through development, build, and deployment stages, not just at intake Single list of legal risk All OSS licenses available for review and for sharing to public
- Scaling Expanding Increasing coverage Reducing time to market
- Threat model – Ask questions. Ask the questions that no one else is asking. Ask the difficult questions. You’ll have been at Dreamforce for a week by the time you get home. You drop your bags, and then it hits you that you’ve only had airport food all day. So, you look in the fridge and figure out, what food in here is a week old and should just be thrown away. Applications don’t age like wine, they age like milk. For your house, you’ve been away a week, and you might have to clean out the cat box. For your car, maybe you’ve been putting off changing the oil because you’ve had to get extra work done before you left for the conference. Administrators Look at your infrastructure. What goes into your Docker containers or app exchange containers? Read about how these software supply chain attacks can work. Ask questions about each component, its interaction. Figure out how to detect if a component is behaving in an unexpected way. You are the best person to figure out if a component is not working right. Figure out the risk profile of the components and determine how much scrutiny each should get. Automate: integrate with YUM repositories, scan Docker images, Developers That cool JavaScript library that you added 5 years ago will likely have cross-site scripting vulnerabilities in it The authentication module might have oauth or sql injection vulnerabilities The glue that integrates the authentication module might have vulnerabilities Learn what’s inside the libraries. Verify update and patch expediently. Pushing off updating your open source components is like pushing off car maintenance. It will catch up later. Don’t take shortcuts. Complete your due diligence. Try everything once, twice if you like it. Use tooling and automation. Find a solution that works best with integrating into your existing ecosystem. Something that requires you to go out of your way won’t be sustainable long-term, and Sustainability is one of the Salesforce themes this year. Yes, it is meant to be for the environment and planet, but also think about your work/life balance