You are viewing content from a past/completed QCon

Presentation: The Common Pitfalls of Cloud Native Software Supply Chains

Track: Software Supply Chain

Location: Seacliff ABC

Duration: 10:35am - 11:25am

Day of week: Monday

Slides: Download Slides

Share this on:

This presentation is now available to view on

Watch video with transcript

What You’ll Learn

  1. Find out what are some of the common security vulnerabilities found in cloud-native environments.
  2. Hear why it is important to take security measures immediately to protect instances in the cloud.


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.

Speaker: Daniel Shapira

Senior Security Researcher @PaloAltoNtwks

Daniel is a Sr Staff Researcher at PANW, currently involved in security research of CNCF projects with a focus on OS implementations. For the past 11 years Daniel has found and fixed critical security problems for various enterprises, government agencies, healthcare and open-source projects in the US, Europe & Israel.

He is passionate about breaking and rebuilding stuff, and his work provides him the joy to do it on a daily basis in a productive manner.

Find Daniel Shapira at

Last Year's Tracks