 Good morning, good afternoon, good evening, and welcome to another edition of DevSecOps as the way I am Chris Short, host of the most of Red Hat Live Streaming, and I'm joined by the one and only Dave Muir and the about to break some stuff, Jamie Scott. Dave, how's it going today, buddy? It's going awesome. Another great day down here, you know, in Tampa Bay, and that's right. I think we have a really good show this month. And Jamie's not only going to break stuff, he's going to hack some stuff. We're going to actually hack some Kubernetes today, which will be very cool. Yes. Before I do that, I just want to let the audience know some of you already know this is part of the monthly security series called DevSecOps is the way we've broken each month into different security categories. This is actually according to a framework Red Hat has developed around DevOps and security and what, how to make sense of all the different security categories and methods out there. We've actually got 34 different distinct functions underneath some of these categories that we detail. But this all consists of a lot of publications during each month. So this is one of two Red Hat Live Streaming shows we publish at most three podcasts per month. There's always a blog on that topic. Talk about, you know, the definition of what this category is and how it integrates within DevOps lifecycle and then any other sort of publications, webinars and things that we do with Red Hat and with our partner ecosystem. So stay tuned for a lot of that stuff or look at the old months. And if you're interested in any one of those categories, find more information. You can go to red.ht or slash DevSecOps or just contact us at that email. You see there. So without further ado, I want to bring Jamie in. Jamie, as we've said, is going to start breaking some stuff, which is great. But before we do that, Jamie, why don't you tell everybody who you are, where you're from, what you're doing at Red Hat? Awesome. So my name is Jamie Scott, I live in Santa Clara, California. Thanks. One of the most beautiful places in the world because it is either scorching hot or 60 and there's not really anything in the middle. I haven't seen snow in about three years, so I envy you, Dave, occasionally. But I haven't cleaned my car off in 10. So it's nice. Straight off. Oh, I think Chris is the one who sees snow. There's no snow down here in Florida. I mean, I get more snow than I know what to do with most of the most of the winter. So, you know, I mean, that's it's just life in Detroit. We're used to it up here, right? Like it's cold. It snows. That's the nice part, right? Like if it's going to be cold, at least it's snowing. That's awesome. So at Red Hat, we came over with the acquisition of Stack Rocks and we were a bunch of developers and security professionals who really wanted to take on the world and transform how security is done with a focus on Kubernetes. So one of the things we saw really early on was that Kubernetes is very holistically allowed you to have the context in order to make more informed risk management decisions. And we've tried over the last few years to put that context together in order to enable security teams. So our team came over with the acquisition and product manager of that team. Very cool. You had Stack Rocks is actually one of the partners that I dealt with before the acquisition. So it's interesting to see guys all come over. It's a great acquisition. Really helps to, you know, add that what we call Red Hat, the layered approach to container security or defense in depth. Of course, ACS, as it's now called advanced cluster security, there's a lot of things this month. We're going to talk specifically about runtime security. And in the show, we'll we'll look at actually how to hack a running Kubernetes cluster. But in terms of runtime analysis, how would you how would you define that? You know, or what would you say about that, I guess? Sure. So runtime analysis is the ability to look inside of a container and understand what processes are running. So I know that's a self-explanatory thing, but there's really two methods of doing that in the market today. One is the identification of what is known bad activity. So for instance, you don't want someone to be running a crypto miner in your side, one of your production applications. So looking for crypto mining processes is a potential way of runtime analysis. And the only alternative way to do it from known bad is to look at known good activity and differentiate between what is known good and what is anomalous from known good. So typically that's in the form of process baselining or establishing a list of what the container should run at any given time. Gotcha. Yeah, because typically, if you first think about it, the opposite might seem optimal, try to understand what's bad activity. But that doesn't necessarily lead into the right answer. Correct. Yeah, so there's two ways to look at it. In terms of known good activity, there is a higher likelihood of a false positive anomaly. So for instance, you could have an application running. Someone could be trying to troubleshoot that and exacting into the pod to troubleshoot it. And maybe they forgot to detach the container before they did that. So the commands they run would immediately be identified as anomalous from what is known to be good. So known good has a higher risk of a false positive and known bad has a higher risk of a false negative because an attacker could either leverage something that you have that is known good in the environment and try and use that as the basis for an attack or you could have just missed a process or they could have renamed a process, which is a reasonably standard way of getting around these things. Yeah, it's almost like you don't know what you don't know. So attackers can exploit all sorts of ways that you don't count for. Which is pretty interesting. So before we get to the demo, what we were talking earlier about the MITRE attack framework, can you comment on that? Like what is that? Are there different revisions? Is that helpful for understanding attack factors? Yeah, so there's actually a few industry standard ways of monitoring for attacks and mapping out a defensive strategy for and doing gap analysis. So MITRE attack specifically is one of the solutions in the market that defines ways that an attacker, the techniques and tactics that an attacker is going to use in order to get into your environment. And these range from the tactics, which are what you see at the top from initial access execution, which is I want to run delicious code in your environment, persistence, which is I'm trying to be able to establish a foothold into your environment, privilege escalation, which is I'm trying to get additional privileges to do more defensive evasion, meaning I want to delete all the logs and ensure that you can't find that I did it. Credential access, which is I am trying to get access to credentials, discovery is a basic understanding of your environment and impact, which is really your action on objective, which can be anything from hijacking your resources, such as the example of crypto mining to a denial of service attack, if say I'm a competitor trying to shut you down. So ultimately we see these tactics and techniques be used in order to map defensive strategies and prioritize where people are trying to target their instant response procedures. So for instance, something that is initial access might be a lower priority than something that is an indicator of privilege escalation. So this is an industry framework, which we see people using in order to map defensive strategies, but there's also ones that in my opinion are a little bit more mature. So for instance, the Microsoft threat matrix for Kubernetes also has a very similar mapping that's more Kubernetes specific. So really there are many industry standards and they help users to understand and prioritize where their gap analysis is and their instant response procedures. Yeah, it looks like this one has a bit more on cloud things like using cloud credentials and resources. So really interesting from a multi-hybrid cloud perspective. Yeah, cool. And in your experience, StackRocks and other places, where do you see most of the attacks in terms of mapping it to these matrices? Like do you see mostly execution attacks, privilege escalation, what do you see most? Yeah, so in terms of, so we don't actually get that information from our customers because we do sell the commercial off the shop software. So I'm gonna speak to what I've seen in things like hacker news, for instance. And usually what we see in hacker news and the attacks that are reported in the wild are mostly financially incentive. So crypto mining, for instance, we all know that Bitcoin and Ethereum have gone exponentially into a curve at this point. And we also know that most attacks not from complicated things, they're actually from gross misconfigurations, right? So for instance, an unauthenticated Kubernetes API endpoint, well, by default, most cloud providers, open shift, they're gonna have an authentication mechanism that prevents that. But if you're rolling your own Kubernetes, then it's really low hanging fruit to just start scanning the internet reports and trying to authenticate and then stealing all of those resources and doing what you want with them. So I mean, I'm gonna do this a bit ad hoc, but I can even show you that, like showdan.io is where a lot of these port scans are. So if I wanted to just search for 6443Cube, I don't know if I'll actually find anything, but here I can start to look to under, oh, perfect, container one is this image. So I found a Kubernetes API server here and I don't, let's stop showing this one. Thank you. So it is reasonably easy to do. It's public information and there are tools like showdan who ultimately are publicly accessible that are very easy to use and scrape the internet to understand that both defenders can use to understand if their network is vulnerable, but attackers can also use to target things. And ultimately, people test with these. Yeah, it was interesting you mentioned configurations because my mind, my past, it's all about applications and vulnerabilities in those applications as well as maybe credentials. But even, we did a show yesterday with a partner where we talked about the reports that Red Hat has put out and it was Aqua and Aqua that they put out and the reports on the Red Hat side listed that 60% of issues security instance were because of bad configurations. So it's really sort of been now the primary issue for getting hacked for security events is these bad configs that are, and there's so many different configs and Kubernetes that it's obviously tough to keep track of. Yeah, I mean, ultimately we do see that the basics of hardening and using compliance benchmarks like the CIS benchmarks are really effective methods to compete with attackers trying to exploit basic misconfigurations. So like ultimately, I think you'll realize that a lot of attacks are script kitties. An advanced nation state attacker is going to have a lot more of a budget in order to run a dedicated attack on you. So one of the largest exploitation methods that you hear about is someone launching a scan of a generic exploit and just seeing what they hit without any real intent of targeting any specific individual. Yeah, interesting. Cool. Well, I think we should probably get to the demo. Now, I guess in order to introduce it, you mentioned what it did before the show. What can you just tell everybody in a couple sentences? What are you planning to do? Sure, so first I wanna show you some examples of known good and known bad activity by going through a reasonably realistic attack scenario that to preface this is definitely set up in a way that will help me, but I wanna show you places and the steps that an attacker would go through in order to identify known bad attack vectors so that you can get a better idea to understand how to approach runtime analysis. So I wanna show you known good and how that works. I'm gonna do that through ACS and its baseline technologies and then we're gonna try to hone some Kubernetes and in running application in a more realistic scenario to see if we can get to the host and ultimately destroy the host. Nice. Sweet, let's do it. Yeah, so the goal would be to have the demo break at the end, we can't use it anymore. The cool thing though about this demo I believe it shows most of these minor attack columns, right? So we're doing privilege escalation, execution, credential access. Yep, so we'll start with initial access. We will then move on to some forms of execution and privilege escalation. I'm not gonna show you persistence but show you representative examples that could be used for persistence and we're gonna take care of impact and credential access as well. Nice. Cool, if you want, I can get started. Let's do it, have at it, man. Yeah. So this is Red Hat Advanced Cluster Security and the view that you're seeing here is a prioritized risk view. So this is used to identify what is known to be the potentially most risky deployments in your environment. So up here we see visa processor backend atlas and master card processor, master card processor and visa processor both in the payment namespace. So it's reasonable to assume, hey, maybe the potentially contained credit card information. So I'm gonna click on master card processor and get some identification of what the risk indicators are and why people are saying this is the riskiest in my environment. So I see I have several policy violations, I have suspicious processes running, images with vulnerabilities and some potential misconfigurations. So if I look at process discovery here, what I can see is that cat is being run and LS is being run in a way that is anomalous to what is the standard activity for master card processor. So I wanna look at this a little bit more because cat and LS don't really tell me much. It really just tells me maybe someone's troubleshooting something. So I click on cat and I can see they're catting the file of our lib processor card data and now this is beginning to concern me. So rather than understand, it looks like the LS was really just understand what was in the processor. So let's look a bit more about what's happening. I can see you name is a standard, they're not running arguments. There's a Java process running. Looks like this is Tomcat. So maybe they're exploiting a Tomcat vulnerability. I'm not sure how someone could have gotten in this or if someone just looked at that. Then I look at Carl and what I see here is that someone is posting the card data that was just catted to innocent.site.web. So obviously that's an innocent site and I'm going to completely overlook that for now because it says it's innocent, right? I'm gonna go to a visa processor now and basically do the same thing. And this is a lot more representative of an attack that you would see because you can see people are accessing the entry point, RM is standard, SH and sleep are standard. But if I look at what's actually happening in this environment, I can see a package manager was run. The package manager was used to install Netcat. Then Netcat was run and it looks like it's being used to initiate or reverse shell over port 9001 to shell.attacker.com. So ultimately these are the types of things that we can start to look for in terms of deviations from known good activity. Well, these are more drastic examples that you can get the value proposition of I understand what my container should be running, containers are ephemeral and if my container does not standardly run this process and I have not hardened it in order to remove processes that are not standardly run, then this is my best option. And this is some of the value add that you can see with I trying to identify the differences between known good and what could be anomalous. So that's just an example. But now I wanna talk about known bad because that's way more interesting. So I am going to move this and move over to our shell shock site. So if you're not familiar with shell shock, shell shock was a remote code execution vulnerability, I believe back in 2014 and it allowed users to effectively input trailing commands to as part of environment variables. So it impacted a large portion of the internet ranging from SSAH to Apache for instance. So what we're gonna do is we're gonna put exploit Apache. So I wanna show you just how to do that here. So what I'm doing here is Apache. So this exploit is about running trailing commands when you use environment variables. So Apache is using the user agent header here that I'm defining and it's inputting that as an environment variable. So now I'm escaping that, running echo really just for legibility and I wanna test to see if this works. I'm port forwarding to this instance because I don't wanna run random vulnerable things on the internet. So I can see here, I've got the command that I've tried to do, I'm just running ponage as a test and I know what I can do now. So I wanna see, now that I know I can exploit this, I wanna see what permissions I have. So I wanna see who I am. So this is disappointing to me because I'm running as www slash data which ultimately means it is a default configuration within Apache. So what saddens me is I now know that I won't be able to get root and it'll be incredibly more difficult for me to exploit this container, which is why users always say, don't run your containers as root. And they also say to harden it because I've just run two commands that are likely anomalous activity and ultimately this was not caught. So if you're looking at known good behavior and looking for deviations, I should now have lit up the sock to help people look and say, who's checking who am I? So now because I'm not root, I wanna see what I can get. So I'm gonna check my environment variables. And I can see here that we have a host we've identified. I can see my present working directory but there's nothing good here. So now I wanna see what commands I can actually run in my environment. So I'm really just gonna run an LS to bin to understand what I have access to. So now I have a list of the processes within the container that I can run. And this list is going to form the foundation for how I approach it because I have a few methods of approaching this at this point. I can either try to download tools so I can use a package manager, I can use WGIT for instance. But I need to put in the tools, if I do not have the tools here that I need in order to continue this hack, I'm screwed. But if I do, then I need to download them. So ultimately what I'll end up doing is I don't have WGIT, I have access to a package manager so let's see if we can do that a bit later. But ultimately I've already tested this, this is a pre-setup environment. So I wanna see how I can begin to escalate privileges. Kubernetes itself has a standard place that it puts service accounts in your environment. And if you don't explicitly say I do not want to mount a service account, then it will just add that a full service account. So that's why guidance like the NSA guidance, for instance, says to turn the auto mounting in your deployments for service accounts to a false. So this container specifically has not turned that off. So I am going to cat a token that can then be used to authenticate to the Kubernetes API server with whatever permissions the service account has. And at this point, I don't really know what service account it is. I can reasonably assume that given I can access this in the first place that it's going to be the default. So I now have used a remote code execution vulnerability in a website, initial access, run and executed multiple commands and use those commands to get an authentication credential to the API server. So I know that as the WW data user, if I explore this more, I'm really not going to be able to do anything effectively. So I need to begin to access the actual API server itself in order to launch as a mount point. So what I'm going to do is I'm going to exit this. I know that we do not have the actual information in the environment variable because this was not a root user to link to the Kubernetes API server. So let's assume for a second that I have managed to get that API server end point in a different way and that I would have access to it. So I'm going to export this token. Let me just copy paste that. Okay, I've exported that as environment variable. I'm just going to OC log out to make sure I am not, there we go, perfect. So now I've used this token to authenticate to the Kubernetes API server. So I've now begun to take initial access and I've begun to privilege escalate. So let's check OC project, OC projects. And I can see, okay, now I can begin to understand more about this environment that I'm trying to hack now that I have access to the API server. So ultimately, I don't want to set off a bunch of alarms. So I want to check very slowly what level of access that I'm given with this account. So ultimately I would go through, I would do kubectl, can I? And I would check, hey, can I exec into pods? Because if I can exec into pods, then I can begin to run commands within them to try and see if I can access data or get other credentials. Or even run a crypto miner. So let's try kubectl, can I? And yes, I can exec into pods, perfect. And let's see if I can create pods because this is gonna allow me to create a backdoor. Yes, okay, perfect. So I now own this. So first off, I want to go back to that shell shock deployment that we had. So I'm gonna exec into that to really show you how I would have done this if we were running as root. So OC exec, IT shock, it's in the default namespace. So I'm not gonna put in namespace. Okay, so now I've exec into this shell shock deployment. I'm gonna run who am I? Okay, now I am root. And here's an important thing to say. Now that I am root, I have the information directly here in order to have authenticated to the API server in the first place. So I know the service host, I know exactly where it's hosted and I know it's port. So this has given me sufficient information in order to authenticate to the Kubernetes API server if I was not running as the WWW data user. So what do I wanna do here? I wanna install crypto miner on this service because I just really wanna see how insecure this is. So first off, I try and install WGIP because I wanna download a crypto miner. Looks like I can't do that. So the reason all the next step is to get update. Okay, it looks like I'm failing. I am failing because I am unable to reach out to places where packages are. I see that this is based on a really old container image which is also an alarming sign and no doubt the reason why this is vulnerable. So I am going to remove its sources and update them so that I can actually download packages because I do not have the ability to do a BI. I'm gonna have to print this and type it into the sources list itself. And now if I do app get update, I can see that I've now successfully updated. There are a few things I couldn't download but I think that'll be fine. So now I wanna begin to do an ingress tool transfer. So what an ingress tool transfer is, is it's the ability to download tools that can then be useful to me to continue the attack. So there are two types of tool transfers. I can either do one from a place within the network or I can do it from a place external to the network. This is an ingress tool transfer because it is getting tools from an external network. So I am gonna download Wget and curl. Perfect. And this is taking way slower than it should. Perfect. Now I'm gonna CD to temp. I am going to go to, I'm gonna Wget ethminer which is a standard tool for mining Ethereum. I've now downloaded ethminer as a tarball file so now I have to unzip it. And I'm not actually going to run this full command because someone told me that I shouldn't put my own crypto mining wallet in this. But ultimately at this point, I can now, I now have ethminer in bin. So I can CD to bin and LS, now I have ethminer. So I am going to just run this. Ultimately what I'm doing here is I'm using the tool to connect to an Ethereum mining pool. I am checking the farm and rechecking it. I'm using the stratum protocol and over encrypted transport. If I wanted to actually use my own crypto mining wallet, I would insert it here and then I would put in the worker name which is really just the identity of the mining pool and go to ethereum.org. So I'm gonna run that. This won't actually work in real time because I don't have my worker name or Ethereum wallet in here but it'll be used as a representative example or maybe not, that's probably a good thing. But you will see at the end of the day that I have attempted to run ethminer in solutions that monitor this and that this is a known bad process. So ultimately I wanna go through and see what I would do next. So this is my impact. Assuming that I could run ethminer, I could have gone through and really taken some of these resources but I'm still logged into the Kubernetes API server. So I can do a bunch of things but first before I do those because my now next goal is to destroy this entire cluster is I wanna show you what the identification of known bad activity looks like. So if I look at the shell shock deployment in here you can see we have run a crypto mining process. Now sure that crypto mining process did not actually function but you can see here that process did not work because it doesn't have the worker name or the eth wallet and you can also see that someone's running a crypto miner in my environment with the shell shock deployment which really is alarming. Yes. Do you think? Yep. You can identify that the package manager is executed. So this is an indicator of that ingress tool transfer. I'm port forwarding because I don't wanna expose any of this to the public internet. So ignore that for now. And you can see even that I've exacted into this backdoor container. So exact is that means of execution and monitoring for known bad activity like ingress tool transfers and crypto mining services is what's really important in this context. So I wanna move on a bit to how would I begin to finally escalate my privileges and show more about this environment? So I have a few things I can do but first I have a privilege container here. So I'm gonna use this privilege container and schedule it because I have access to create containers. And because I have access to create the containers create pods, I can schedule a pod that is purposely designed to give me access to the host. So this is designed to insecurity by me and by the attacker in order to facilitate a container escape. So the reason I can container escape here is because I'm a privileged container and I have a host mount. So what I'm gonna do is I'm gonna schedule this container that has privileges and I'm gonna treat to the host in order to get in. So first I'm going to OC apply F to privileged. Perfect, now I've now created my backdoor. So I also have access to exec in. So this is all of the access I need to get onto the host. So now I'm going to OC exec, IT. My container is called the back, my pod is called the backdoor pod. Looking for names like this is obviously alarming but the one thing I do wanna call out is that attackers aren't just going to schedule things called backdoor pod. They're gonna pick a random UID or something, right? Exactly, actually what I'm gonna do is I'm gonna look for the names within the actual name space I'm scheduling in and I'm going to try to name it as similarly as possible. So we showed the visa processor and the master card processor deployments in the payments name space. I'm gonna schedule this backdoor pod. I'm gonna call it the Mx processor. And see if anyone notices that they don't take Mx. So going to your security team, they might not know that. Exactly. So that's pretty good. But yeah. It's all about business context. So now I'm on this pod. I know that this pod is privileged and has a host mount at pwned. So I'm gonna LS check that that host mount is there and that I'm in the red container. I see pwned. I'm gonna true to pwned and I can now see that I'm on the host. So I'm going to check who am I. I'm root on the host. I LS and I can see, okay, this is different from the file system that I was on previously. And if I want to say cat at sea, cat at sea, let's see what's here. Oh, wow. What a terrible command, right? Yeah. You said you enjoyed watching people make blatant mistakes when they're not following scripts. Cool. So now I can see the configuration or if I'm really just bored, I can rmrf slash, right? So, oh wow. There are real file saves here. That is wonderful. Perfect. Preserve root. Man, it's gone. Bye. You can't touch anything in proc anyway. So, but yeah, it's Ninja Vanish. And now I go to back to the service and I wait slowly for everything to be deleted and nothing to function. That's not gonna take too long, I don't think. Exactly. So, ultimately, that's the way we tend to look at things. There are known good, bad. There are known bad. There are known good. We can monitor for those things. And if you look at it from a security perspective, you want your SIM to be notified near instantly. You want to initiate incident response activities as you start to see these things. And you need the business context in order to make more informed risk management decisions. Because like I said, if you see AMEX processor, you don't know. If you see AMEX processor and that's privileged, then that is terrifying. So, that's why a lot of guidance that people give are minimize privileged containers. Because, yes, they're absolutely going to be needed for something like a monitoring program or for a security solution within Kubernetes. But the reason why they say minimize is because we want to prevent backdoors. So, that ultimately is an example of a real world attack. And that's how we want to go through and monitor and initiate runtime analysis and why runtime analysis as a security program and I've visited DevSecOps program is important. So, there's a few things I could have done. If I wanted to, I could have initiated those policies that were catching and alerting on the things I was doing and I could have killed that pod, right? So, that's why as a DevOps program, it's really important that you have liveliness and readiness probes so that you can kill that pod effectively without business impact. So, DevOps does need to care about security and security does need to care about availability. And that is how ultimately you as a DevOps team can help identify what is known good with your security program for the most important things in your environment. And that's why those security controls are set up in DevSecOps. So, that is the value proposition for why DevSecOps is the way. That is awesome. Well done. Thank you. That was very cool. That whole thing though, interestingly, right? It all started with a vulnerable pod, right? So, one thing that you'd probably know, hopefully before you even push that into prod is, hey, you've got some vulnerabilities in here that you should resolve. And so, you talk about DevOps, DevSecOps, that stuff should always be caught early on in lifecycle during builds. Now, of course, vulnerabilities happen all the time. Your image is clean today, it won't be tomorrow. So, that's why it's good to have what Jamie was talking about. Some sort of, well, the liveliness probes and everything. So, you can kill a pod or you have some sort of remediation in place. So, you can take care of that. Because DevOps ultimately also speeds up, helps you to fix production issues quicker, right? You don't wanna be sitting there with one legacy app, it gets hacked, you gotta shut down your payment processing application for any amount of time. Yeah, exactly. And that's why ultimately a security program and a development and application delivery program really have to care about informed risk management. Because monitoring and just securing all the things, like that's an anti-pattern. Security is about risk management and there is literally no point in trying to ensure that your rules apply to the least critical application environment that's locally hosted, not even externally exposed in any way versus your visa processor like you wanna monitor that, you wanna make sure that your program treats visa processor very differently than a cron job that really just sends a report to single developer. In a way, I noticed ACS pointed out how old the container was, right? To an extent, uptime is a bad metric nowadays, right? It's kind of flipped on its head. Those containers should kind of be cycled out more often, I feel like, right? So there's patches you can apply constantly, you should be swapping those containers out and updating them as you go. And that's why I always say security is interest-subshifted, right? So you'll hear a lot of people say like security is viewed broadly as a blocker. And security has stopped my application from being deployed. Now, why did they stop that? Okay, there's a critical vulnerability in it that they blocked you on, they want you to go fix it. Okay, that critical vulnerability is already there. So what is your next step? You do need to escalate that. You need to identify if you are actually vulnerable to that. But ultimately, fixing it is going to need to occur quickly. So DevOps is in the best interest of the security program because being able to deploy and remediate things quickly and having a mature testing program is going to be the ultimate indicator of success. And that's why I say there's no such thing as DevSecOps before DevOps. Absolutely true. Yeah, security was always part of DevOps from the beginning. We're just trying to put the focus more on security so that it isn't a blocker like it was. I always say I always remember when I deployed my apps as a developer, I'd get a spreadsheet from a security team saying your app is vulnerable but they wouldn't tell me any details. Right, your baby's ugly, sorry. Yeah. So yeah, so that's DevSecOps. You're totally right, Jamie. It's always been a part of DevOps. We just want to make sure to focus on, they give security a seat at the table, let them be part of the group, the lunch team, whatever. And so that you're all working together. Obviously DevSecOps is more of a culture shift initially at least than anything. Like getting security right and integrating it at the right time will definitely allow you to not make it a roadblock. Awesome. Well, cool, that was very sweet. Any other things you want to chat about, Jamie? Or is that, wrap it up? Wrapped, that might be the first time of VARMRF to know it, but. It's first time. I have to admit, right? Like I've never done that. I don't even want to type those words on a terminal. Well, cool. I want to thank you, Jamie, for coming on to DevSecOps is the way. So a really neat topic and loved how you hack some stuff. And so that probably is a wrap for today's show. Stay tuned for a blog, which will be coming out hopefully in the next week or so around the category. And then next month, October, we're going to have another exciting category and then all the way up until December. December, we're going to start talking about platform security. That's going to be a lot of red hat-ish type stuff, like SElytics and those type of good stuff. We'll see if we can get some good guests on for those shows. But with that, I want to thank you. Thank everybody. And Chris, I'll let you wrap things up. Yeah, awesome. Thank you very much, Jamie. Awesome demo, as always. Coming up next on the channel here in an hour. So, oh, I don't have my UTC clock up. Sorry. We're going to have the StackRox office hours with we're going to be talking about Kubernetes network policies with, if I can say the name, right? No, I lost it. Nevermind. It's not on the screen anymore. So one of the StackRox team members is coming on. Going to kick tires on some network policies and show us the why and the how behind it all. So yeah, please stay tuned for that. And when in doubt, subscribe to our calendar or look at our calendar and you can see what's coming up next on the channel. And thank you, Dave, for coming on. Again, thank you, Jamie. And stay safe out there, folks. Here's Tyler.