 My name is Lee. I am coming from a company called Aqua and I'm a security professional as you can see from my alphabet soup after my name and If you have people in your organizations with that alphabet soup, then that means they're security professionals, too So the question is what do we want? except from life happiness and the rest of the world security people want to make sure that applications organizations Businesses run securely, so I'm going to start with a very very basic premise of Where security actually fits in in the world? I? Been new to the DevOps world. I've been security professionals for about 20 years or so been in the DevOps world maybe for a couple of years and Somebody had to explain it to me So I'm going to explain it to you the way that it was explained to me So let's start if you take a piece of code that does something useful and you Put it on a server where it can run and you take that server and put it in a data center that's accessible from the outside world You're going to get an application that people can use so far so good like so Where does that fit into the security world and why do we care about this very simple or simplified? Construct of how applications are running well because we need to Not just run that application in isolation. It needs to be to do something and unfortunately there are Dangers in the world that it needs to to deal with so if we overlay security over that We actually get a business because you can you can take an application and you can have a great idea until you've done the security work until you can run it in a way that is going to be Wholesome and predictable and safe for people to use. It's really not an application It's not really not a business. So so where does business fit in when we write the code the code needs to be secure meaning that the Program that you write is going to be predictable in its behavior. It needs to run on servers that can only Run the software that you want them to run that they're not going to be used for any other purposes It means that your operations need to be secure meaning if you people start to rely on your applications It has to be available. It has to be up and running It has to be done in a way that gives people the confidence to run it and Your users are your users that you intend to the application to be used with but there also could be the users that We don't want to use our applications. They are the bad people of the world and Unfortunately, they're there and as we've seen too many times There is a tendency to Maybe assume that everybody is going to use the application the way that you want it to be used But a lot of times we need to take care of cyber security. So what do? Security people want Security people want low-risk code meaning that it you know doesn't do More or less than it should do running on hardened servers in a controlled environment with constant vigilance and Proving compliance. So let's break that down a little bit low-risk code is the guarantee or close to a guarantee that the Way that you write your applications is using good coding practices. It's using the The latest technologies but in a way that's safe to do and it is not going to allow for Weaknesses in the code to be exploited So that the application might be used to do other things Running on hardened servers means that the servers that we are running on are Dedicated for the set of applications that we want them to run on and that they are not susceptible to excess administrative action That they are not susceptible to misuse and that is there is relatively or as much as we can guarantee No backdoors and no misconfigurations that will allow those servers to execute A controlled environment is the same thing just scaled up So our entire data center from physical security if you're running your own data center to Security in the cloud to multi-tenancy to backup to recovery All the services that are used to guarantee the sustainability of the application and constant vigilance which is a term that encompasses a lot of things means that Security needs to guarantee that we know what's running. We know who's running it We know under what circumstance. It's running. We can see what happens. There is auditing in place There is a lot of elements that deals with just monitoring how things run not for you know, CPU usage or memory usage or the the scalability but for security the ability to to really understand and then do root cause analysis, right all the Intrusions that we've seen over the last few years all had to be analyzed and over analyzed And we need to make sure that we know exactly what happened and then proving compliance is kind of the odd job of security professionals nobody likes to Issue reports about the inventory of situ of the the applications What the maintenance window is? whether or not we've changed passwords or we don't have a password that is admin like somebody did not too long ago and Really getting to a point where you can certify that whatever that you're running is running based on compliance, right? So again so far so good. It's really simple I know that you feel like super dumb right now, but that is the basics of Security and you really got to understand Where security people are coming from because all the things that they request from Developers from operations really come to address these now There are other things that are not here because they they deal with user security endpoint security You know don't click links and emails and all the other good stuff that happens But from a data center operations, this is this is what what we're dealing with so how does that fit into? The DevOps process right because so far the previous slides had a little bit of a waterfall situation as far as the rollout of the application We start with the code. We also do a server and and eventually they meet what happens when infrastructure is code What happens when code is infrastructure? What happens when we start to? automate things in a very fast moving way where we fail often where we do agile development when we have Multiple releases of the applications when we run in the DevOps and not even containers even even DevOps pre containers there is still a lot of Elements that are kind of killing the security model and in return security is probably going to kill the DevOps model because if you try to introduce The existing security controls or the security controls that security people expect into a DevOps process Things start to break down if we need to analyze Our code and it needs to be done in a tool. That's not integrated into the environment That means that there is a break in the chain if we need to have configuration management done Before the infrastructure as a code runs before we have our automation Build our server and then we want to start to deploy on it immediately because that's part of the same function If we have to stop and ask for configuration management, that's a break in the process And the same thing with network with host access controls. How do we separate automations from humans? How do we make sure that our intrusion prevention and protection is still laid intact when everything is? moving so fast, so I put DevSecOps as a question mark because I Have the feeling that everybody pays lip service to the idea of this DevSecOps It would be really nice if everybody collaborated and talked together But it is really really difficult and I have experienced with organizations that we work with and I think everybody has their own story either from the security side talking to DevOps or from DevOps talking to security and really not being on the same wavelength and that's that's pretty much the Problem with DevSecOps today and that it's hard. Those are different domain expertise automation Enterprise management data center management are things that deal with Aspects of IT that are very different than what security deals with. There are different motivations You get measured in different ways in your organization different cost structures And and all of the things that are just different domain expertise all together Another thing is that security is not really automation friendly Security controls are by their nature a little bit messy. There's a lot of opinions in there Vulnerability management, for instance, is not a clear-cut operation. There's no good or bad. There is good until we Get some mitigation on it or bad until we have a way to deal with some of the Risks that we have in in vulnerabilities Even configuration management we always deal with exceptions. They're always rules, but they're always broken. So there's not a lot of clear-cut answers that can be answered by a program and security is not really automation friendly And the flip side of that is the DevOps is built for speed. We need to deploy quickly We need to to get our applications out there And it is not easy to do that when we have security as gates preventing us from doing what we need to do And then we add on top of that Dynamic cloud environments that deal with constant change And the predictability is not there and there's nothing that security people hate more than not being able to predict and not being Able to do something and then make sure that it doesn't change anymore. So DevOps is hard There is though something that is Going to be very counter-intuitive and that is that as we move to more Containerized environment as we move towards the delivery of microservices It seems to be a continuation of this mess because now we've taken at least three aspects of the DevOps process and kind of merged them into one right so we not only Have infrastructure as code and code as infrastructure. They're actually all pulled together in one image, right? Your image now has infrastructure. It has An operating system. It has prerequisite software. It has your own application The way that it's rolled out is rolled out with with automation So now we've rolled out and compressed the ability to deliver our applications in an automated way The consumption of application is still there, you know, the hackers are still there It's still being attacked more or less the same way, but the way it's delivered is really really different So it's it's a problem and and the knee-jerk reaction of security organizations when when we start to convert some of our Applications to microservices roll them in DC OS with orchestration underneath is to basically say no, right? We just don't want to deal with this too too much too much change too much of a sensory overload how do we actually get get from under that and There's got to be some way in which you guys who are DevOps people I assume we'll need to engage with security people and Come to terms with the fact that this is a really big disruption to To running it so where does that leave us? It leaves us first of all with security on the outside looking in so all those services that were you know A little bit disruptive or annoying with pre-container DevOps are almost done right impossible with post-container DevOps It's it's very hard to do static code analysis or stop for understanding what the networking requirements of an application is or how to Monitor the environment for intrusion on how to do configuration management Where everything is bundled together everything is shipped together everything is running on the same host everything is broken apart to microservices and there's a lot of API work around that so the old model is just not going to work and just Psychologically, you really need to understand that the when when you start to do a containerization effort when you start to do a Migration of the application. It's really going to cause real stress to security people so Let's flip a page a little bit and see what is really our way to maybe make things a little bit better So here's a promise what what if we can actually merge that what if we can actually make security part of the process and not having it from the outside Looking in and I want to propose two scenarios to you. One is a very security operated Security program oriented approach and the other one is more of a pipeline approach and we'll explore this together a little bit and see See where we get to so the way that Remember what security people want they want safe code Unhardened servers in a controlled environment with vigilance and compliance So let's put a security program in place that is using the inherent Properties of containerized applications to deal with some of those those aspects So the first thing is is running secure code. How do you run secure code? Well, we do code analysis and there are services out there There are a lot of times are being used today in the pre-container world or in the DevOps pre-container world to do code analysis your vera codes of the world and so on those are Services that are pretty well integrated into the DevOps process. There was usually in your in your tools that do Compilation in the tools that do the packaging there's usually a step out there that does the code analysis And that's pretty well integrated and that's actually should be our model, right? because that part because it's been with us for a long time is Actually a model that we can employ to Use with other parts of the containerized environment, and I'm talking specifically about the base Operating system and the base images that we're going to use to build our containers on and if you think about Why why are we having this this step and why not just you know do? Ubuntu off the internet or sent us off the Docker hub and build our images that way is because even Even in the server world every time that you install an operating system you install your own organizations version of the operating system There are controls in place that need to be there. There are regulations that need some hardening There are vulnerability assessment things all these need to be part of the deployment of an image so one of the things that we see and we talked to a lot of organizations is that the practice of having a pipeline for base images is starting to emerge as a way to kind of jump start the collaboration between Dev Ops and security because that's an area that everybody can agree on and there's some know-how in the organization So how do we actually do that? We take the people that used to build servers, you know the ones from the kind of middle of the the waterfall process and take That organizational know-how the processes of what vulnerabilities should not be there. What is a good configuration? What is your password policy? What is your naming convention? What is your? Key strength all of those can be co-opted and can be put together to create your own base images and we start a cycle there and you're gonna see that does those these arrows that kind of do a cycle here because The same way that you will you know fail a code analysis and then have to fix your code and you run it through it again Until you get it right is the same way that we're gonna do our base images We're gonna take something maybe off the internet we're gonna take a sent us image or a boom to image or Alpine image and we're gonna test it for compliance with the organizational needs and We're gonna build on it and we're gonna have some iterations assessing the risk again and again until we get to a Configuration that is gonna be at least from a security point of view pretty much the same as your servers used to be Because we know that those servers are in line with your with your policies And that's a great way to do a little bit of collaboration with security on and stuff that is Probably don't matter to you as much right because it's it's not your code Once we have the this system in place What we want to do is we want to build an image that is actually going to be that image That's gonna run as our container and we do the same iteration again We're gonna do the image risk and the image build Until at the other side of the pipeline we get an image that is Absolutely tailored to both your application, but also for the organization security needs and that means Reducing bloat that means that the image really should have the minimal moving parts that it needs to do its job That means that the image is gonna be well configured. That means that we have the right Security posture to it and remember this has to go up with reports right the same way that security people needs to provide For compliance reason, what is the state of the server environment? We anticipate that eventually they're going to need to provide what is the state of the image environment So might as well do that and gather that that information Because of the nature of containers from there on it's really just preventing Deviation from that image so as containers are being rolled out We want to make sure that there is integrity so that What you put in the registry and pull to the registry is the exact same image So you know sign your images calculate hashes of your images, you know Make sure that you follow the image ID basically make sure along the way that you have some integrity of the image and then once you're deploying it Really this should not have any more disruptions in it. There should not be any human interaction There shouldn't be any more patching. They shouldn't be any more Touching of the image there really nobody should exact into any container Nobody should even SSH into any node that is running in the in in the the data center And that's actually that represents one of the biggest changes for security because their role basically stops, you know about three quarters away from the Left-hand side of the slide once something goes into production There's really little way in which we can affect change on it and by change We mean even fix things that that that may be broken and we got to get in the habit of fixing security problems In the pipeline and if we need to fix a security problem that's been discovered afterwards to actually go and do that From from the pipeline so let's take a look at patching as an example of that when we talk about patching again We audit the server we have we found that there is a configuration problem on a server And we're talking pre-container. What do we do? We go into patch the server We update a package or we change a file or we we update that server in production means maintenance windows means Disruption means downtime means we need to audit we need to see what administrators did on it So there's actually a lot of trouble that goes on with patching Contrast that with the ability to identify that there may be a vulnerability or something wrong with an image down the line in production Let's leave it where it is go back. Let's say to our base image Update the packages on the base image so the next next shell shock of the world comes on We need to update our bash in all our images Instead of going to a thousand servers and update that manually or have something like chef or puppet or answer We'll actually try and do that Let's patch our base image run our CI because that's going to be very predictable and then slowly You know DCOS marathon Kubernetes is going to deploy that new patch over in the environment That's something that is very hard to secure for security people to understand But once they understand it it it really points out that all the benefits that we know about running micro services Can actually be extended to security and all the things that we know and like About DCS about marathon about about Kubernetes the ability to automate things on a large scale Security can co-op that and actually make it part of That of the flow to fix security problem So this is this is the DevSecOps security programs if we are being Container oriented the things to remember is we need to make sure that we have a good base image program And we need to make sure that we understand where security stops and that is as the the images is deployed We really don't have a way to affect it. So anything that we need to fix has to go back to the the beginning So that's that's one picture Another way to look at things is from a pipeline point of view And I think that's probably going to be a little bit more relevant to to how you actually operationalize this this whole thing so This is our pipeline And our pipeline has distinct phases, you know build chip run whatever the flavor between two two and three of those but basically Securing the build phase when when when we have an image what do we need to do? So as we said use an organization endorsed base image that has already been corrected and published And it's not just base image. It could be a library of this base images You could have your basic sent us basic sent us plus Java lean and mean go go and do it basic image plus node JDK JRE all these web technology can be packaged together and be made available and create consistency across your development streams And not it's not only going to be good operationally. It's actually going to be good for for security We need to evaluate the risk based on both configuration and Content so what you put in the image besides the executables. Did you leave an SSH key in it? Do you have? The right controls is your HTTP server Managed with SSL certificates. Where do the SSL certificates come from? How do we actually mount them and that we'll talk about a little bit later when we talk about secrets But basically what's in the image is important because those are going to be distributed Along the the pipeline and may result in a in a large footprint along all the servers Scan for vulnerabilities. That's usually what people are concentrated in but scan them against a policy Don't just you know send me an email with all the vulnerabilities that I have in my image because if everybody has The the service on the Docker hub where you get your vulnerabilities Does it make any sense to you? Do you know what is what CVE this or that actually means? No, because there is really no Straight way to know that because we need to compare it against the organ the the Paul the organizations policy for Vulnerability and something that might be relevant to one group of of services may not be relevant to another group of service So scan for vulnerabilities, but evaluated Against a policy and then make sure that everybody's on the same page There are the information. Let's say about an image is what that image is what it contains. What is it going to run? What's the entry point? What's the vulnerability posture what the risk posture of the image that those bits and pieces are Going to be at different places And we got to make sure that everybody's on the same page at both development and security and operations Know that this image is good enough to run because it has the right entry point We've assessed it We know what the risk posture is the risk posture is relevant to what that image is going to do if that image is in scope for Pick your favorite regulation PCI HIPAA whatever that is We need to make sure that that is the right way and everybody should agree that this image is good enough to run And that usually happens from again the CI side Probably at the end of the build going into test, right? We don't want to waste test time on images that are eventually going to be out of compliance for for the organization The next step is to start to accept only those known trusted images that we've been that have been through the Evaluation process into your test and then beyond in the pipeline So only accept note images approve images based on the risk again relevant to the environment that it's going to run in Maintain the integrity of the image. So sign it take ashes of it Do whatever you need to do in order to make sure that that is the same image And then start to keep inventory, right? One of the things that security needs to provide is measurement of control measurement of compliance inventorying and Understanding what has been pulled where what is running where is an important part of the process the next thing is to operationally as we start to then deploy things into our data center into our clusters is to differentiate between what's going to be out of automation which is More predictable less error prone than what humans can do even though there could be errors in automation and we've all seen those But they are a lot more predictable So if things go bad, they go really really bad and if things go well usually they go well But we need to separate what is automation and what is human and that's really really important because one of the things one of the artifacts of this whole program is that your auditing becomes binary everything that you Get out of your container system is either something that is part of the application part of the intended use or deployment of the application or something that is not and I think it's kind of a good time to tell you a little bit story and Imagine yourself as working in a security operation center and you get all these screens and everything is is Flushing you know logs of everything and suddenly you have a cluster and there's a lot of of Networking events and suddenly you see on one of your production servers that runs an application a you know call out to I Don't know Google for a search or trying to get into a Microsoft website or to a Linux website Or basically anything out of that server. So that's usually out of the ordinary right a production server should not kind of you know Send an HTTP request outwards or at least attempt to do that the question on the security operation center is What what is the significance of that? Is it good? Is it bad? Should I be worried right every security professional in their head is going to do an immediate triage on that and The question is well, I don't want to raise alarms because it's it's a pretty harmless operation Especially if it goes into a familiar site and not somewhere in Russia But on the other hand, you know, is it in the maintenance window? Is it something that an administrator might do? Maybe somebody's debugging a problem and they had to go on the server and while they're on the server They you know used a curl command to search something or to upload a file. So there could be a lot of Situations where it's a gray area. We really don't know if it's a problem yet That's the problem of separating human action and dealing with people that have to go in a server environment And actually do things that even though we think that we run a very automated environment in the cloud and everything is scripted And everything is code. There is always going to be that instance where somebody needs to fix a problem And they're going to go on a host and actually fix it That really should not happen in containers, right? Because even the most fundamental Problems with containers is take that note offline your automation is going to spring up another node so we're not going to lose service and Let's debug this offline so so separating those those automation from human actions is something that is very fundamental to the way that we run With microservices and with containers and with that now that we control human action. We can control privilege elevation We can make sure that whatever is running inside of the containers Nobody patches them nobody adds software to them and we also need a continuous audit trail off the containerized environment so that we have a good understanding of what is a human operation versus and and an automated operation and that is going to be really what's going to eventually Create a lot of trust between development and ops and security is the fact that if we put out all the rules up front We're going to get a situation where all our data is such that it's very easy to decide if something is bad or not And we don't have to do that triage and do all this data management in the security operation center And that extends into what containers are running so so keep track of the user context in containers understand what is the appropriate level of access that you should get inside of the application if you can use a Service account to run the application Please use a service account to run the application do not think that you can run everything on the route Limit your executables of what you have in the image to only the approved functions something that is really needed so don't don't put a whole bunch of just a bin directory from your vanilla flavor or eunuchs in something that maybe needs RM LS and you know ping and Make sure that you have some context to where network controls, right? So there's a benefit talks this this week and and the the networking the ability to put overlay networks the ability to associate containers even on the same host with the right Networking controls is important and then secrets management Because we can't put anything sensitive in the image We have to distribute that in real time into the containers and luckily for us all the major orchestration tools Have the ability to then have secrets management and that's something that Can be augmented with third-party solutions and you can even integrate it with your Organizational secrets management in case you need to access services that are outside where your environment is So if we do all that we start to give security what they actually want right because we can give them low-risk code on Hardened images not hardened servers anymore hardened images by the way the servers themselves. They're going to be hardened by your Clusters, they're going to be hardened by the manufacturers of the operating systems Mesa's fever is going to take care of the hardening of the orchestration tool the fact that nodes can communicate securely Docker does a lot of good things with making sure that Docker nodes can communicate securely in Kubernetes at the far end Who has trust between nodes so that there's a level of hardening on the platform itself That needs to extend into the image so that we have good overlay on the image Controlled environment doesn't you're not going to have a more controlled predictable and secure environment if you do containers the right way and that is something that we start to educate security people on because we need to give them the tools to then go to their management and prove that There is security and there is compliance in the system and then the constant vigilance becomes a lot easier because now We don't have that gray area again if we do this right every time something needs to be stopped That means that it's not part of the application. There's not going to be triage anymore We don't need mountains of data in a security operation center when we talk about containerized environment We can pretty much predict what we're going to be Part of the application and what's not so I'm going to leave some time for questions But one summary slide which is about communication so Please talk to your security colleagues Understand what your security needs are right the security needs of a bank are different than the security needs of a hospital And are different than the security needs of a manufacturer. There are some basic things that everybody should uphold but the level of Security might be be different ask about compliance really try to try to ask what security people need to convey further Either to compliance or to their own management and please offer your expertise around automation Tell them what automations can do for them. Tell them that there is a great deal of benefit that can come from given the patch Management example or give them the ability to view the containerized environment You know in a containerized Environment again if it's well built it's pretty self-documented We don't need cmdb's anymore with a lot of data on them And if they still resist tell them that I said that containers are good for security because they truly are and I was convinced basically The five minutes after I did my first docker run command it Shocked me and then later. I said well that actually is really cool But we're going to need to do a lot of education. So please be patient with your security people please understand what the motivations are please offer your support and Whatever you do Don't steam don't don't don't steamroll over them because at one point even if you do get the permission to run your Application or start your your containerization project at one point you're going to hit compliance and you can steamroll security You really can't steamroll compliance. So that that's my sub box. Thank you very much. I'm going to open it up for questions Yes, sir Yeah, so so no They're counterintuitive if you try to think like this that's that's where the problem is and I think security is still Stuck in this model where everything happens sequentially where there are Distinct gates between things when there is time to do things when there is When security basically had more clout, you know, maybe 10 15 years ago That's where I think the mindset of more security and compliance people is I think what we need to do is we need to tell Them that they can execute even a better version of this model in the DevOps world With containers because the middle part of trying to do security where where all these things are are Automated and fast, but also in a server environment that is that is very prone to change and Where you still have administrative action where we're so so that that's the middle world of DevOps before containers is is where we have a problem and and my view is that we can execute a model that is going to kind of leapfrog that with containers and And break that that problem so think think think think about the the tolerance for change, right, so so Well, the problem is that there's still a lot of moving parts there And I think it's the distinction is that you're still running a configuration tool to configure Servers that are still multipurpose where there are still a lot of processes that run on them that may or may not be needed For the application that is put on them. And there's a lot more noise There's a lot more complexity in there that makes it hard for security to discern between Lawful and unlawful operations. Oh, we're getting there No, but but look if so think think think about it this way in Maybe in the organization you run a super controlled super tight super predictable DevOps, which is awesome But in most organization what's going to happen is that the way to put that discipline into the real world is Where containers come in because you cannot? Run in any other way a server that is single purpose and dedicated Because once you got the image running and it has an entry point then as you deploy it It's going to remain the same only in super tight super control organizations do the DevOps of servers and the provisioning of machines happen in such a way that that it does remain the same as the day It was provisioned awesome Any more questions? Yes, sir. Well, does it give you code host operations and cyber security? Yeah, so so that's that's where there's really no right answer right in in most organizations What we found is that? Docker is going to take care of Docker So the security of the platform is awesome on the other hand, you know 80% 90% of the code That's going to run in a cluster is not going to be dockers. It's going to be your code So how do you protect your code vulnerability management is one thing? configuration management which Docker doesn't touch the ability to Identify images so image signing is one of them But image signing only tell you that they're intact and who provisioned them. It doesn't really associated with risk so there are some things where Docker security is going to fill a lot of those requirements It may not be the whole picture, but that's okay a single service usually doesn't fill the whole picture But it's but it don't don't go into a discussion with your security people and telling them Okay, Docker is going to take care of all my security because that's factually not true And they're going to see right through it and then you're going to lose credibility, right? So so we got to understand tell us what your security requirements is I'll tell you what Docker can answer and if we need to fill those gaps with policy with with solutions with Open-source solutions, whatever then then we can do that and that makes the discussion a lot more intelligent Yes, sir So I think it's a multi-pronged approach, right? We need to scan the images now It's it's not just that humans are fallible It's also that over time things get discovered that you might have not seen before right so we need to understand what our Risk posture for an images continue to evaluate it all the time and see if something needs to change in our replacing or patching but also the way that the way that containers are run If we reduce the bloat if we reduce the attack surface the less stuff that we put in an image The less stuff can be exploited the less stuff is subject to to to to vulnerabilities. So one of the things that I personally am not a big fan of is to Scan actually running containers all the time because that's a very costly operation CPU resources and so on so I'm more of a proponent of Let's make sure that we have good control over the integrity of the images and of the containers as they are run and Then if we know the risk posture of an image, we're then able to Reflect on the containers that run from it and extrapolate that data and find that That vulnerability in the container So it's it's an operational model that that relies on the fact that that the the lifespan of containers is fairly short and We're able to replace them and we're able to replace them on a large scale So if we if we do good assessments of the image we can then roll them out Well, I'm not I'm not saying that the container is gonna run But but we've seen that people release Multiple times a day and it's not because containers are not gonna run for very long But because just the way that software is is updated. They're just gonna be replaced over time I would also say that that so in principle I agree with you that that containers don't have to basically be replaced but what we've seen in reality is that because of release cycles and Because of the fact that you run with orchestration that is free to kind of move containers around and when they do that They actually re instantiate them from the image so so the The life's the lifespan of container is Relatively short especially when when when concerned with with servers But that's really where we are right if we if we limit what's in the image to begin with and then not allow any addition executables or or administrative action on a container We can With a great degree of confidence make sure that we do our security vulnerability assessment Ongoing on the images and that will give us an accurate picture of where we are vulnerability-wise on the Containers and if something needs to be fixed we can fix the image and then roll a new version of all the containers As see you're not convinced Well, you Know no see so is gonna ever tell you that they're damn center about everything Okay, well, okay when I say should I actually mean that 99 plus percent. Okay, that's that's that's where I am but but What's one thing that you'll see with security professionals that we are we are a non-committal bunch because we've been burned so many times All right people I'm standing between you and beer so Thank you very much