Name: Securing Containers Across the Lifecycle: From Code to Runtime
Uploaded: 2025-04-03T16:50:55.874Z
Duration: 25 min 56 s
Description: Securing Containers Across the Lifecycle: From Code to Runtime

Transcript for "Securing Containers Across the Lifecycle: From Code to Runtime": Let's start. So hi, everyone, and thank you for joining us today. I'm Nicholas Ehrman. I'm a product manager here at Wiz. And today, I'm joined with Aisha Hart, product manager, team lead for everything related to container security and runtime protection. We'll work us through a live demo in just a few minutes after some few slides. We're very excited to talk about, like, a topic that is top of mind for a lot of security and platform teams today, and I would say the perfect way because that's the cubic one in EMEA. And the that topic is how to secure container across the entire entire life cycle from code to run time. Let's move to the next slide. So what we know as a challenge is, like, you know, let's start with the big picture. The thing is, like, cognitive apps and especially containers, they're they bring massively, massive agility, but they also introduce, like, complexity and some risk across the development and runtime environment. For instance, you know, when you think about the cognitive application, you are you have to think about that all the developers, they're gonna start to use, like, open source libraries. They're gonna start to use, like, Docker image can coming from, like, sometimes public public container registry or at least using base image that are, like, from the outside world. And the thing is, like, how to make sure how do can you make sure that the code that is used in my application, I can understand it, and I can understand also if I if it is introducing, like, kind of vulnerabilities in my environment or even, like, other miss potential misconfiguration that I can have it there. And how I can, like, also enforce some kind of guardrails because, again, because they are they are using, like, potential, you know, container image that are not, like, trusted and so on. How do I make sure that I can, you know, enforce and at least ensure that I'm not deploying something that is not, like, really secure in my environment? From a current perspective here, the thing is, like, the other challenge is as I'm using, like, most of the time, Kubernetes clusters or even serverless container, I still need to manage kind of an infrastructure that is using the cloud. So how do I have that complete visibility? How do I understand, like, what the platform engineers are doing or the DevOps engineer are doing when they are deploying a new cluster and if it is secure or not? And how do I make sure that all my containerized environment is well configured? The last piece in there, and that is something that is very, very important in the container in the container security space is like, okay. I pretty much secure the code, and I also try to secure my cloud environment and my Kubernetes environment. But what about the potential, like, breach that I can have in there? And the last ingress nightmare that we released, like, a couple of weeks ago in regards of the fact that, in the Ingress NGINX controller that is, one of the most, like, used services and projects in in Kubernetes clusters was renewable and was renewable and could, like, allow an attacker from the outside to take over from the complete clusters is how can I, like, from the how can I be protected from those kind of, specific breach? And how can I understand, like, what is happening in my environment, and how can I block them in some way? The thing is when you are thinking about, like, alternative application, you also have to think about that what I said at the complete life cycle. And it start always on, I would say, a prevention. The prevention starts with the understanding the container risks that you have in your environment. That's what Wiz is doing, agentlessly giving you a visibility across all your cloud and Kubernetes environment that are very tightly coupled together. Because, again, you can have a Kubernetes cluster that is, like, running containers that are using service from the cloud providers, using, especially, I would say, the what, I would say the the services like a bucket or whatever. So that the first thing, understanding how it works. Oh, they said it can hear anything. Do you can you hear me? Shahar, do you hear me? Yeah. Okay. Yes. I thought I thought it was me. Okay. Sorry. Because I saw the chat. So I'm I'm continuing. So the thing is, like, again, you have that understanding of what how your cloud is working, how your Kubernetes cluster are working. And now the the the good thing is, like, okay. I build all those different standards, then I understand how it works and understand the behavior of the different teams when they are how they are working with the cloud or they are working with Kubernetes. So let's move those policies directly into the developer's environment, and let's make them, like, kind of empowered to, like, build more secure application in the way that they can use their IDE and they can see exactly what, what they are doing and if it has an impact on, like, having a vulnerability because they are using a specific libraries and and so on with a with a bad version that I mean, not a bad version, but that adds vulnerability in there. Or they are, like, pushing secrets that will be used inside the container image, all those things. It's important to see this, and that's what we provide with with code, giving you that visibility directly from the code environment and also, like, being able to help the developers to understand, like, what what they are doing, as soon as they are writing codes. And the last piece being, and that's something that we released yesterday as the GA, by the way, is to withstand giving that capabilities to outside of, you know, doing being very good at preventing all the risk in your environment. It's like, how do you can, like, have real time context and have that capability to detect real, detect, threat in real time and being able to have that full context, understand exactly what happened, and even, like, take automated auto exempt automated action, like, blocking the different process that people are trying I mean, when I say people, of course, it's hackers are trying to, are trying to do inside the containerized environment or even in, in the workloads themselves and do those things and being able to have, like, again, all that context, all that, capabilities to understand all the stories that happen, you know, in that specific attack and also that capabilities to, you know, I would say, respond faster. So the thing is, like, of course, that's what we are thinking when we think about container security, and I'm gonna go pretty fast on that one. It's like the first thing, of course, is having the complete visibility, being sure that you understand all the environment, and every time having, like, an up to date visibility on what is happening, preventing the risk because you have that capability to reduce and focus on the critical risk in your environment, democratize the security because you can, like, share that same visibility with all the other teams, up to the cluster level, like having that capability to give to make sure to give, like, a visibility on the name space specifically for specific teams. Hot guardrails like to block specific image that are not trusted or a misconfiguration. And the last piece being, of course, like, detecting and respond to, the potential threat that you have in your environment. From an architecture perspective, because I really want to spend a lot of time also on the demo for Shahar, It's what it looks like from a width perspective. If you look at the reference architecture, it's looking on the right at all the platform from a platform engineering view where you have all this visibility from the cloud context and the runtime context correlated together to have, like, maximum visibility, I would say, and then being able to remediate back to the code because we can map the code the application the application back to the code and making sure that the developers are aware of what they have to do in in in what they have to remediate directly in which, like, container image, layers, and so on. And that's, that's where I, lend the hand to to Shahar to for the demo environment, and I you know, you can you can share your screen. Perfect. Can you hear me? Okay. Yes. Very well. Let me share my screen. Okay. Can you see it? I can see see you. So, hopefully, you can. Perfect. So, hey, everyone. Nice to meet you all. And thank you, Nico, for introducing that old concept of container security and both including both run time and prevention in the code and shifting left and shifting from shifting from the left to the right. And this is basically the portal. This is basically, where everything starts. And just before we start that, the demo entirely and moving and showing you all the moving pieces together, I want to highlight that right now I'm looking at Wiz portal from a container security lens. That mean right now as a container security, a team member, as a container team member or someone that works with container either ECS or Kubernetes or whatever containerized environment, I'm looking about the old portal from a lens perspective or container team member. Starting from that, and I think this is basically, summarize the old and maturity frameworks that Nick Nico showed you, this is the dashboard, which basically start from a visibility. So right immediately after you, deploy with into your environment and connect that via an agent scanning, we first and foremost scan the environment and get an inventory for everything running on top of that. So all the different Kubernetes clusters, the host, the images, the containers, all the different moving pieces within Kubernetes, and, of course, the visibility in-depth for the pods, the namespace, and so on. On top of that, of course, we have, like, visibility for, where we are blind spots, where we should deploy, both the Kubernetes components and the with sensor as a top of that, and I will touch that in a moment. And all the different component that allow us to both enforce and prevent the attack surface. And maybe everything sum summed up into the this first container security score, which allows to assess how is how are we from a container security perspective. So at Wiz, first, we start with the preventative part of that, and this is basically reducing the attack surface. And we're doing that as we did that for the cloud. We did it. We are doing that for container of the environment as well, and we do that by risk modeling. So we are not taking individual risk factor individually. We combine them together. We look for the toxic combination, and we look for the and most the most critical, assets with toxic combination. This is where we start. This is where we reduce the attack surface in the most proactive way and the most efficient way. And this is basically how issues was introduced. And I I I think I will just walk you through a specific issue. Of course, I will take the most critical one so it will provide you, like, a a a more, broad information and understanding how it look for by combining a multiple risk factors together. So by navigating to the issues page, basically, we can start to see everything related to with container security and Kubernetes security, of course, by all the different risk controls, basically, allowing us to correlate multiple risk factor together. I already pre choose some specific issue which I wanted to which I want to cover, and this is that specific issue. So this issue actually includes multiple risk factors together, as I mentioned, and let's just, like, walk in one by one. So first, we have a publicly exposed container using an image with initial access vulnerability that were valid in runtime by the runtime sensor, of course, with a clear text, cloud keys, also data access to a sensitive data. So so many risk factors together. We can see them all listed one by one under the risk array and the risk, basically, factor, all of those. And, of course, like, a general information overview of what is that. And maybe we'll start looking at them one by one before we look about the big picture. So I will go back to you in a moment. So first, what is the context? So as we are in the Kubernetes environment, we start with the primary resource. We start with the resource that actually includes this specific issue and all this specific issue, which is a deployment. Of course, I can navigate the deployment, see all the information on that, all the specific containers running on top of that, the namespaces, and so on. But looking about the, first risk factor is the vulnerability risk. So right away, we can see the critical vulnerability that's mentioned in the title of that. Of course, I can click on the vulnerability, look about all the details of that, the criticality, where it is in was detected on, by which com by which component was detected on, and all of this information. Quickly moving to the next one because I'm short of time, so I will just quickly review each one of those. The external exposure, we can see that this specific container this specific containerized component is exposed to the Internet main application endpoint, and we can also see that it was validated from the outside to inside by our dynamic scanner, which actually allows to reduce the false positive. Few insecure use of of secret piece, few and unprotected principle risk, which allows an abuse or a lateral movement. The container that actually owes this vulnerability, which actually owes the image with the vulnerability, the context of the cluster itself, the port, and, of course, all the unprotected data, which which covers both PII, PCI, and we can see what type of information was discovered and what is the criticality of that. Combining all of the all of those together, and here comes the magic, is basically by the attack pass visualization. And here we can see everything unfolding together. So starting from the container itself, we can see that it has an Internet exposure via an application endpoint, which we just covered. And we can see all the topology of the containerized environment of this Kubernetes. We can see that this specific container is actually connected by this sorry. Container is actually connected by a deployment, which or by that pod, and this specific container has the image associated to that. And only by that, we can see the finding that's associated to this specific container. And the double check means we have a runtime sensor that cover this specific container, and also the runtime sensor was validated this specific CV in runtime, which means it was loaded into the memory. So this vulnerable package, zlib b one j was wired into memory, was loaded into the memory as well. Taking a step back, we can see that the container image not only holds vulnerability, but also also secrets, which allows someone if it will be, compromised to actually gain access to this IAM role user. And if it will be assumed, assumed this IAM role user can describe and get access to buckets with sensitive data. And by clicking on each bucket, we can see, of course, all the sensitive data, all the PII that were identified, and, also, what was the classifier, what was identified, what is the PII that was detected. And that actually covers everything together and correlate all the different risk factor together. And for first, this is basically the way that we, identify risk, and that's like the first milestone. K. Identify the risk. I know what's happening in my environment. What next? And this is basically where we are moving through the remediation part of that because we want to reduce the attack surface as fast as possible. And first, we can see that this specific, SBNginx container which has which host that container image have all the software development life cycle of the image covered. So starting from the cloud, the container image itself with all the vulnerability, mapping to the deployment time, the container registry, the CICD scan that actually cover that, to the actual, GitHub repository and the and the breach and the report and all the different stuff, that's from shifting, like, back left, that all this information, and even the Docker file itself. By clicking the vulnerability that was also identified and correlate with the data repository, we can look about all the vulnerabilities that were detected. And, also, some of them, where we have the access to actually do that, we can one click and, actually, by one click, remediate this specific CV and open a pull request directly to the branch that actually holds and create a new branch under the main branch that actually will provide and solve this specific CV. And that actually, covered all the risk issue end to end by first identifying them and then, of course, starting to remediate one by one each risk factor. And this is basically focusing on the preventative side of that. And because I'm short of time, I will cover just very quickly, like, the shift right approach of that, and this is using the runtime sensors that actually deployed on each machine. And the random sensor can be deployed both on containerized environment such as ECS or Kubernetes. But once deployed, we start to see and monitor everything happening in run time. Once it is deployed and monitor everything, we it start to run out of the box threat detection rules that's managed by our own threat research team. And once some detection rule is matched, it actually create a threat. And a threat is just a representation of something happening within the environment. And by actually looking for all the threat, I can see that I have no threat right here covered by the s b n g n e. So I'm good from that perspective, but I can see different threats that actually includes on different containerized environment. And I'm looking for the, I think that the first one that haven't resolved yet. So clicking on the threat. First, I can see that, this specific threat is actually detected on some DNS query for a known cryptominer domain. And cover that maybe super quick, we can see from the investigation graph. And once again, the graph, it just unfolds everything. It just provide you provide us the full picture, the full visibility for everything happening, and not only from the cloud perspective. And this is where it started, so providing information about the cloud perspective, the container on which instance it's running on, which replica set. Of course, clicking on the, e c two instance, we can see all the information of that specific instance. But let's focus on the run time just for a moment. And we can go back to that specific graph, and we can see all the processes or all the, like, a huge or mega process tree or and and what are the execution of those processes and what actually happened. So we can see the Java process actually executed some Chrome driver, and this Chrome driver actually executed the Python, three point zero, process which which actually, detected a reversal in my environment. Followed by that, this specific reversal is executed some bash command with first w get some some information, some file. We can see this specific file in the command line itself. But followed by this specific w get information and downloading the file, we can see a no op command, a different weird bash. We can see that this specific bash was downloaded, which eventually communicating to this DNS query, which associated with a with a known cryptominer domain. And this is just a graph representation. Of course, we have the timeline to actually dig that dig more in-depth for everything related to that. But looking only on the reversal, for example, I can click on that and go get more granular information, more granular details on those info on this specific detection as well. Of course, cover the process tree, what happens. I want to see everything that's happening in my environment, all the different chain of processes that run and actually create this reversal. And, of course, in that in this example, we can see an actual remote code execution using a Python three and some information on top of that. But as this is a reversal, I want to see everything that I was identified on this reversal. And this is why I can quickly pivot to the run time event or the raw telemetry collected by the run time sensor. And I can see all the process execution, the network activity, the DNS queries that were actually created and generated and executed by the time of this detection, and, of course, not only correlate them to what actually happened on the reversal, but also use them as an hunting to actually look for different IOCs in my environment and different threat actors maybe that maybe I already uncovered and I want to cover as well. And this is briefly cover all the shift right piece of that. But going to the shift left, and I will finish by that, I will go to the dashboard, and this is basically the maturity frameworks that we just seen. So starting from the preventative side of that, covering the shift left, so the detection, threats, all that that I just covered. And, like, the middle step of that is to actually proactively engage a a a way to reduce the attack surface and reduce the upcoming issues by actually prevent, insecure components to be deployed to the production. And we are doing that and enforcing that by an admission controller that deployed on the cluster and can enforce policies such as an image image trust or post security standard policies, to actually prevent, insecure component or a misconfiguration to be deployed at the first end to the production environment. For example, prevent from privileged code to be deployed into the production. And this is basically, cover that end to end by first reducing the risk. Second, maybe proactively reducing any potential risk to, be introduced in the production. And lastly, of course, looking for any suspicious, things happening in the run time and, of course, proactively responding to them. And I'll stop my screen sharing. And Thank you. For q and a. Thank you so much, Saur. And I think it was a very good demo to show, like, exactly what you say. Like, how we cover all the present preventive aspect from from, like, the cloud itself, then to moving to the left, finally, with the code, and finally, like, finishing to the right with the threat detection. So we have two question in the time that we have left. How do we, so you know, sorry. I was looking at the yeah. The more granular details and investigation which you showed is only possible by the installing with sensor on the server, or is it by default with with API? So, basically, this is the combined approach that we are taking here. What we are start everything that we can do agentless, we will do agentless. We want to cover as much as possible using the agentless approach. We can do that via API. It's much, it's much more performance focused and much more performance sensitive from a workload perspective. And then we can gather most of the information using an agent that's scanning both the vulnerability, the external exposure, and so on. But on top of that, we are using the runtime sensor to get a runtime only signals to go on top of that. For example, the validation of vulnerabilities that were loaded into the memory. The, runtime validation, the double check, and next to the CVE. This one we can get only by the runtime sensor deployed as well as the proactively looking for any detection, any suspicious activity on the runtime. So I would say the guidelines here is go agentless as we can. Where we where we need runtime telemetry, runtime information, go with the sensor. Of course, it's complementary one one the other. Thank you so much, Sarah, for that very clear answer. One last question because we are way over time. How can I identify all the workload that communicated with the malicious IP? Okay. This is a great question. There is the portion. I won't, like, reshare my screen, but, when I pivot from the reversal into the runtime events, actually, I just mentioned that it covered, all the raw telemetry collected by the runtime sensor regardless of if it's suspicious or not suspicious. So, basically, edit DNS query, any IP connection, any files, any process execution is covered by this event this specific, event explorer, I would say. Using those this event explorer, let's say that there is a some new emerging IOC that can be identified in the wild. We can actually query using the explorer for any DNS query. Let's say the IOC is DNS related. So any DNS that were queried that actually were queried from my environment, any workload, any resource that actually queried to this specific, DNS and start the investigation, maybe the hunting by that. So using a single query, I can actually investigate or look for any suspicious any new or emerging suspicious activity on my environment. Okay. That's very clear also. So I'm sorry, but we have to wrap it up because we have so many question, but we will not have the time to answer them all. But we will share, like, answer after, the recording of that webinar. So char so char Shahar. I'm gonna say it right. Shahar, thank you so much for that time using for that time using demo. And, yeah, let's let's wrap it up, and thank you again for your time for for the audience and so on. And let's see in the next one in June. Thank you all.