Presentation: The Common Pitfalls of Cloud Native Software Supply Chains
This presentation is now available to view on InfoQ.com
Watch video with transcriptWhat You’ll Learn
- Find out what are some of the common security vulnerabilities found in cloud-native environments.
- Hear why it is important to take security measures immediately to protect instances in the cloud.
Abstract
Today modern cloud native infrastructure is composed of various CNCF projects to build, manage, and deploy containerised applications in an automated manner. These tools provide great flexibility, ease of use, and speed up development, but the ecosystem is developing at a blazing fast pace, which in turn causes various little mistakes in the products that could leave the supply chain up for grabs for a motivated adversary.
Tell a bit about the work you do.
Currently, I'm working as a senior security researcher at the Palo Alto. My main mission is to find vulnerabilities in the cloud native ecosystem which includes Kubernetes and deeper stuff like the Linux kernel. Sometimes we do broader research, checking what things are being seen in the wild in the Internet. My latest research was to test how many exposed Docker instances are out in the wild and how many of them belong to big corporations, how many are home instances. I would say more than half are exposed openly to anybody.
Your talk is about pitfalls of cloud native software supply chains. Tell me a bit more about what your intent is here.
I'm going to address this by pointing out a few specific pitfalls that we saw that were in a widespread, in almost any of our customers and in the wild overall. For example, I'll talk about how to use image signing and how to securely sign your images, how to verify signatures, how to not allow unsigned images into your environment. Another. problem is the overall server exposure, people tend to leave servers exposed without realizing that the IP is listening and anybody can come and connect to this server, and they usually leave them without authentication on or with default authentication.
Who is the main persona?
I target security persons because they should already be familiar with these concepts. An architect would be a good target because they're responsible for the stuff when they're building their products. As I said, we saw a lot of products that do not apply fundamental security practices. In the end, it brings pain to our customers because it leaves them exposed.
What do you want people to leave with?
I would want them to leave with the idea that they shouldn't postpone security, at least not the very fundamental stuff that has to come to any product that you're willing to release to the public. If you're taking the responsibility for release something and you want people to use it, you need to make sure that it is compatible with modern security requirements.
Similar Talks
Evolution of Edge @Netflix
Engineering Leader @Netflix
Vasily Vlasov
Mistakes and Discoveries While Cultivating Ownership
Engineering Manager @Netflix in Cloud Infrastructure
Aaron Blohowiak
Optimizing Yourself: Neurodiversity in Tech
Consultant @Microsoft
Elizabeth Schneider
Monitoring and Tracing @Netflix Streaming Data Infrastructure
Architect & Engineer in Real Time Data Infrastructure Team @Netflix
Allen Wang
Future of Data Engineering
Distinguished Engineer @WePay
Chris Riccomini
Coding without Complexity
CEO/Cofounder @darklang
Ellen Chisa
Holistic EdTech & Diversity
Holistic Tech Coach @unlockacademy
Antoine Patton
Exploiting Common iOS Apps’ Vulnerabilities
Software Engineer @Google
Ivan Rodriguez
User & Device Identity for Microservices @ Netflix Scale
Senior Software Engineer in Product Edge Access Services Team @Netflix