 Welcome everybody to this OpenShift Commons briefing today as we like to do on Fridays. We try and do things that are sort of transformational cultural shifting. We have a kind of a leaning this past couple of weeks towards security and dev ops and dev sec ops. And we're really thrilled to have Steve Jagir from Stack Rocks with us to give us his layer cake approach to security. And I'm going to let him introduce himself and talk for as long as he likes and then we'll have live Q&A at the end. So welcome and welcome Steve. I'm really pleased to have you here this morning. Yeah, thanks Diane. This is great. Shall I just kick off then? Amazing. Please do. All right. Good. Yeah, all right. Thanks for watching. This is layer cake. My name is Steve Jagir. I am a cloud native security advocate with Stack Rocks. And what I want to talk about today is how we can move security to be more deterministic over probabilistic. Now first thing I'll do is introduce myself because you may not know who I am. My actual title is Director of Solution Architecture and Community Building for Amia. But as I am kind of the only technical guy here, I do a lot. I wear a lot of hats. On the screen you can see, you can follow me on Twitter. That is a, I like to live dangerously. That is a QR of my LinkedIn. So if you want to connect, let's be friends. I have a podcast called the Continuous Security Podcast. You can check it out on any good podcast source. I also run a meetup along with some friends from Stack Rocks called Cognitive Security. Check it out. And I also am a huge beer fan. You'll see that and it'll be part of my presentation. Be friends and untapped. Why not? I also have a YouTube channel where I talk about beer if you're really geeky. That's extreme though. All right. So the first thing I'd like to really get into is Kubernetes, transformative. It wouldn't be a presentation about involving Kubernetes at all unless I had some kind of nautical themed photo. I like to have a picture of containers, shipping containers, that joke. Word clouds are great. People have word clouds. And then I'll talk about how it's changing the world. Amazing. Which I actually am going to do. I am going to talk about how it's changing security. But I'm going to have to put that into the context of the people who have to deal with security. And in our case, as Kubernetes and OpenShift enthusiasts, the people handling security is often the Infosec team. There is kind of a separation in security of apps like an Infosec. They haven't quite embraced that DevOps collaborative bit yet. And because it's kind of, they still think of it as like a virtual data center, they have the same approach. And some of the struggles that they have to deal with are the idea of tooling being noisy. So they're looking for a needle in a haystack versus not noisy, in which case it feels dangerous. Like what are we missing? Primitive versus expensive. And I think I might change primitive, but it's more like when you're trying to cobble something together on a budget versus buying some epic security platform and then wondering if you're getting value out of it, right? This is a common struggle. The historical security in the space has been a little bit reactive as opposed to proactive. And that's not intentional. Developers have control over the app. They didn't use to really factor security again. We're trying. We're trying to shift left. So the result was generally, here's an application. It's running on a VM or a data center. How do I watch it really closely and make sure that nothing bad happens? So the struggle generally isn't that they don't want to be proactive, is that they don't necessarily know how to be proactive. And that's what I'm going to talk about. It ends up being probabilistic versus deterministic or probability versus certainty. And it comes down to changing the equation. So risk equals likelihood times impact. If we can change either likelihood or impact or ideally both, then we're off to a fantastic start. And we can do that with everything as code. This is the Nirvana. Have we achieved it? Well, kind of. I'll get a high five for that. There are a lot of standards at the moment for creating everything as code. Different platforms have different ideals and different people have different levels of expertise. I mean, you've got your terraform, your cloud formation, YAML. Everyone loves YAML. And then you've got interesting changes like CDK, some Pulumi, and of course, Helm and Ansible and all the other ones that people know and love. And I'm sure there will be more in years to come. Why do we need everything as code though? Because of humans. Humans are, we're idiots. We're our biggest own problem. We make mistakes. We produce non-repeatable results. No change control. We love tribal knowledge. And many other reasons humans don't tend to make good decisions. So we need to change the battlefield. And I feel I'm, I think I stole that from the art of war, but I'm not sure. What we want to do is reduce likelihood of risk. We can do that by employing checks earlier and often. You may have heard that before, but you need to know how. And we can do this by scanning our everything as code for misconfigurations or just insecure defaults or just operational risk. We can do that. And that's something we can heavily leverage. Can we reduce impact? Absolutely. What's great about declarative environments and particularly Kubernetes is that we can leverage chaos engineering. We don't have to cuddle all of our pods and our nodes and our clusters. We can embrace that cattle versus pets analogy. And I'll apologize to the vegans because that's kind of a brutal analogy. We need a new one. Add comments if you got a better one. But the overall idea is that we want to be able to utilize the context of that deterministic and declarative definition when we're looking at risk. And we can do that. The importance of context. Now, what's fun is that I can see in the guest list for this that there's Byron on, Byron is watching this. This is a true story. I'm stitching him up by saying that. We were in a morning meeting one time and he was telling me that he had a beer last night and he feels terrible. And I thought, oh, okay, well, that doesn't seem so bad. What beer was it? It was this Imperial stout. And this one on the screen is from Brew by Numbers. It's amazing. Tell me more about it. He went, all right, well, you know, it's a delicious stout. It's got American oak barrel age. And this is all sounds amazing, right? I have this 10% maybe and like, okay, right, that's, that's a factor that's important. It kind of made me feel like that's like the vulnerability. That's the CVSS 10 in the container, right? But it doesn't matter. It still didn't make sense why it was a problem. I mean, so he explained the situation. Let's take a look at his deployment YAML. So it's the Bimbered BPA. It's the Imperial stout and the dinner he had that night was a salad. He's trying to ease off on the Christmas indulgence. You know what I'm saying? There were three replicas. He left that detail out. He was watching this super surreal TV show called American Gods, which is only 45 minutes, which means he went, he had basically a bottle of wine and 45 minutes, like that's no good. And it was a break from dry January. Everything about this is a disaster. That is a, that's an actual risk. And that's kind of what I mean when I'm talking about vulnerabilities versus risk. Vulnerabilities are indicators only. All right, let's get started talking about the layer cake. But first, another prerequisite of these sort of infrastructure as code talks is I have to say get ops three times. Get ops is great. And I really like that we've works has acknowledged Victor Silva, who normally tweets in Portuguese, his, his get ops in one slide, which is essentially get as the single source of truth, get as the single place where change happens, which is, yes, it's great. And we are gung ho on it. It's a little odd though, like being somebody who wrote code since the 90s, I've been writing code, putting it in source code control, creating pull requests, like this is not new. It's just funny that now that it's used for infrastructure as code and for just everything is code, it's like a wild new cool thing. But it's a good necessary thing. All right, now we're in the layers. The big moment. Look at that cake. Isn't that good? I made that cake. It's not a picture I downloaded off the internet. That's that I made it. All right, let's, let's talk about the layers. And then we'll go through each one and talk about what we can do at each phase. Layer zero is the cloud. And I often get asked, why did you start at zero? Because it's an arrays. I'm a geek. Everything starts at zero. Layer zero is the cloud. That's our buttery biscuit base. The pipeline is number one. So the pipeline itself, that ubiquitous part of our entire supply chain, the application, the applications, friends and dependencies, the image, the image goes into a deployment. The deployment goes into our runtime. Those are our phases. So let's talk about what we can do. Layer zero, we can secure the base. Infrastructure is code. There are tools for making that happen. There's, and I'm being wide open about this, like open source tools you can get for free. And some are built in like check off kicks, Tara scan, these all work. There are free tools for maintaining state. Open CSPM is one. They all, Gartner's definition is CSPM. If you don't, if you're watching, you don't know that cloud security posture management. And there are other ones out there. Now, why do we need this? Again, humans are creating a code. So verification prior should be standard. We're used to doing this with code we write. And yet we feel like we have to say it for code that is infrastructure as code. But that's probably more important than the actual code. All right. So there are tools we can use. And there's just a quick run through on how easy it is. So what I've done is I've downloaded this probably super dodgy Terraform for AWS. Okay. And I've just picked one at random. And I like that this one actually outputs a variety of formats. By the way, human JSON, all the machine consumables, it's all really good. And it's as easy as writing Tara scan in this case and check off the same. And whatever the Terraform is in the directory, you see the problems. So it's one of these things I just want to lower the barrier of entry. The install for this was brew install. I'm on a Mac. I can go find the low hanging fruit that I know I need to fix. SSH port open. Yeah. Okay. That seems bad. I am wondering actually now, why is that open in a WordPress AWS? Like this is a great example of don't just download stuff and use it. Hey, scan it with stuff and take a look. I can go down. I can just delete that. Because I don't understand why that's there in the first place. And I just run a quick scan to make sure that my highs go from four to three. And we're good. Right. So that's the idea. I can just take a few more seconds and I can go through the rest of this. And I'm done. So that's just lowering the barrier to entry for the tools like this and knowing how you can do it is super easy. And you can embed these things into a pre-checks and CI CD pipelines. It's pretty simple. The pros of doing it, of course, infrastructure is code controlled and observed. Great. So infrastructure is code is chaos engineering friendly because if we just destroy our cluster or our note or our pods, we should be able to put it back exactly in a known state. And it reduces the dependence on tribal knowledge. This is why infrastructure is code is good. And this is why we should check it. The cons of infrastructure is code from scratch is it's never from scratch. It's just like real code. It can be an amalgamation of stack overflow, cut and pastes, and GitHub clones. And just like the one I just went and got, I just googled WordPress Terraform. And that was the first link, right? Which is kind of what people do. There are some bad defaults in there. Another thing that we're starting to see is that if, say, a template like that became standard, people will do what they're already doing with images. They will template, squat, they will change a one, an L to a one, and they will try to look like the one you want to use. But they will add changes to the trust boundaries that are bad. Another thing which is more operational, this kind of code can age over time because it's not getting as many updates and feature driven changes as actual application code. So you have to make sure you keep on top of it and you don't have an application of some ISE that is secure one day and insecure the next due to changes in your cloud provider. So worth knowing all that. Layer one, securing the pipeline. What I mean by that is software, supply chain, integrity, and provenance. This is your internal supply chain. We focus a lot on things coming into our organizations and making sure we check those packages and make sure it's all good and hashes are right. Amazing. But what about internally? Now, I don't mean to pick on SolarWinds. It's just everybody knows about how that, well, I don't know if you know how that breach happened, but that is a supply chain compromise where malware was installing malware because it was able to inject during the build by watching a build its own prebuilt package that had malicious intent. It was possible for them to not just hack SolarWinds. That would be small. It was it was they were able to manipulate their signed result and therefore deploy malicious malware to a much larger audience. Now, what could they have done to prevent that? Well, something but probably not enough. There are tools out there like in Toto, Recore, Graphase. These things are looking at your supply chain. And in Toto is easy to demo. It's a CNCF project. It's really cool. And it can prevent man in the middle of tax like that. But it's hard to deploy at scale. So I'm giving you the honest cons about it, right? In order for your supply chain to be managed for each component and each developer, everyone has to buy into a deployment like that. It can't just pick and choose and that could be problematic to do. But there are options to make it happen. It would be cool to see people work more on things in this space. I don't actually know of any commercial solutions that do this yet, but it could be given it's become front and center that things will start to happen. Securing the code. Familiar territory, right? These kind of scanners are called SAST static application security testing tools in the code pipeline. I've singled out. You see I've got IDE SAST there. I've singled that out intentionally because I just don't think there's enough attention to that. There are many, many things you can put into your CI pipeline, which can scan all the code you wrote in a variety of languages. Great. Developers kind of hate those tools because they slow things down or they're poorly implemented. What they would really like is something that integrates directly into their environment, their IDE or their VS code or whatever it is they're using and just tells them as they go in an unintrusive way. That's the ideal and there's just not enough good answers to that. Why do we need it? Same as infrastructure as code, humans are writing it. I used to work at a static analysis company and we had stats on this. One in every 1,000 lines of code contains some kind of bug or insecurity. It doesn't take long to get to 1,000 lines, so it's worth doing. What are the pros? Some really obvious ones. Many open sourcing commercial offerings are available and I've got one there. I'll show you in a minute how that I really like. Cost benefits, finding anything early. Developers finding problems. There's numerous reports on like 100x cost differences between finding something in development versus finding it in testing versus pen testing versus support case versus a breach, the last one being probably the rarest. Support case is probably being the most common, super expensive. Lastly, people don't talk about this enough. Static analysis checking is one of the few ways you can automatically traverse all your paths. Testing rarely does this. Pen testing doesn't do it. It's a really interesting thing and even if you run a static analysis slow out of band, occasionally it has my value because of that. What are the cons? Slow and potentially disruptive. Has a bad rap. I didn't write that down, but it kind of does. There can be a lot of false positives. Implementation is difficult, particularly in a modern microservice organization where the tech stack can be in multiple hands and can be different and security choices are in the developer's hands and you can't impose something like this. So finding a one size fits all solution for static analysis is very hard. Few good ID integrations. I'm going to hammer that again and limited reach on next gen languages. Now, let's next little demo. I'm going to go to guardrails.io and move fast be safe. I like that. What I like about this is it's free. It says get started free. You get a lot for free. You log in, you log in with your GitHub repo and you can see all sorts of like, I just got some of the repos that I like to collect for multiple languages. I turned off scanning some of them and I left one particular one on, which is juice shop. That's the OWASP known vulnerable with a lot of fun actually. You should go try it out for a known vulnerable application for node. And I scanned the master to see what it would find, which is great. By the way, I did this. This is all yesterday, like where we went and did this. And I can see obvious SQL injection. I like that. Integrated directly with my GitHub, showing me really bad things. And it's got some integrations out of the box. If you need them, I can look at my scan history and see whether it's recent. I can see what I'm scanning, what I'm not scanning. I was blown away that this was here and I could just do it. I was even more blown away at the breadth of languages that it covers. It was cool. I tried a lot of them. The Kubernetes and the Terraform one was not that good. So other tools are available. We just looked at one. Now we're going to look up another one in a moment. So it's really pretty impressive. All right. Layer three. We're going to get there. Securing the open source supply chain. This is what I referred to earlier as the applications friends. The dependencies or the family. This is referred to mostly in the industry as SCA or software composition analysis or just dependency checkers, people call it. Free and open source solutions are available, which is awesome. A lot of these kind of things are becoming embedded into certain areas. Why do we need this? So there are some commercial solutions on there and they make great reports. I like any company that makes awesome reports is great. And they all kind of agree that about 80% of a modern software application is open source. Open source vulnerabilities are known to the bad guys. Even the script kiddies that just like to go to show down and exploit DB and just try and write stuff and mess with you, they're out there. And really we have to deal with them. The pros. We're finding the known vulnerabilities. That's more important than the unknown ones. Everyone knows about them. It's the low hanging fruit and something we really should do. The cons and there always are being completely open about this. It can be difficult to prioritize the results of these things. The dependencies are they used and what context are they used. Occasionally when I'm writing code, I start using a whole bunch of packages and then I realize I don't need them and I don't remove them from my package JSON or I'm lazy so I end up bloat and it really confuses a scan like this. That's one reason. The other reason is there's more than 15,000 CBEs released every year. 15,000 I think last year was 16. And it's how do you manage that, right? So there can be false positives in areas where it just doesn't matter. And context is important. Securing the image. One of my favorite layers. Finding known vulnerabilities in base images and dependencies. And you get a good one. One that will also look at package managers that are in the image and do a bit of that SCA we just talked about. So there's a bit of overlap there, which is good. You can also, there are also tools out there for checking Dockerfile best practices and there's open source. Like when I say Dockerfile best practices, there's a lot. There's a lot of articles out there. I just chose a couple like using an ad instead of copy is bad. Leaving the default user in, which is root, like January, I think it was 2019 was the run C vulnerability that if the image is left running as root, you could swap run C out and get remote code executed on the host as root really bad. Why do we need this? Well, as I just indicated, defaults can be dangerous. Images are introducing user space open source operating system dependencies that have critical vulnerabilities. For me, it's a must do. Well, the pros, once again, we are finding vulnerabilities and we can do it anywhere and it's really quick. It teaches you developers best practice when done right. So they get better and you get less noise. It does some of that SCA. I think the kind of like the bare minimum critical SCA, a lot of good tools, those certainly the commercial ones can do that. Just be perfectly honest. DAGROX does that. It's good. Plenty of open source free tools are available and that's great for getting started. Cons, image scanning can become a bit of security theater because it seems to do so much. Some organizations start thinking, all right, let's scan our images and they scan a big bloated registry and it becomes overwhelming because they don't have context. So nothing happens. So worth knowing that when you start. Context again is important. It can confuse vulnerability management if you're using an SCA tool and because you get overlap. Let's take a quick look at how easy this can be. I'm most familiar. I'm not being biased but I'm just very familiar with Truby. I like it because it works on the desktop. It scans images. You can scan a file system. You can scan a GitHub repo. You can put it in quiet mode so you can bet it into your CI. It kind of has all the bells and whistles that I need for doing the basics. But I am going to show a caveat in a moment. So let's scan an Alpine 3.1.3, which I think is the latest. And it maintains its own database so sometimes it takes some time and I thought that was going to have nothing because normally Alpine is the safe bet but those are pretty new vulnerabilities. So there we go. Two modules with the same ones. Fixed version available so I could take action on that. I would imagine there'll be a new version in like seconds but if I scan something a little larger, this is where as a developer we get in trouble. This is kind of why the notion of DevSecOps and ChefLeft can be troubling for a developer because if they do what you want and they use something like Truby, I hate that tar vulnerability, then they look what they get and they're not going to use the latest Nginx. They're going to do it. So if we take a look at the top of this to see what we might have to contend with and we'll get like the total of what L them are, we can see that, okay, a bunch of vulnerabilities, one critical. So maybe I should look at that, right? And what I like about this is that it's using WNNx. I like that it shows me the base. So if I clear the screen and we look at the latest but I'm going to filter on that just the critical vulnerability and I'll get rid of that because I it's not going to blast through the whole screen. And it's warning me you should never use the latest tag. Bad practice. Do as I say now as I do. CV 2019 and less. So what would I do with that as a developer? I don't know if I can fix that. There's no fixed version. I just kind of got to let it go. I can, I could if I'm really keen I could go to show it and I can see there's no exploit and I could feel maybe it's okay. That's a little more than I would expect the developer to do. But you see what I mean this is one of those sort of eternal conundrums when we start pushing security in the hands of developers. All right, so I'm going to stop and let's all go to the lobby and think about where we are right now. We hopefully have scanned our infrastructure as code. We've cleared everything off. We provision our resources. Hopefully we've got something looking at our application. Maybe we have something in our supply chain making sure that we've got, we know that the ingredients to our cake are the same ingredients we put in the cupboard earlier. Probably we're scanning the application. Most likely we're doing image scanning. Great. So we're, we're starting to amass a certain amount of vulnerabilities and that's where vulnerability management can come become a bit of a burden. So let's talk about how we can get some risk context here. How can we add that? Securing the deployment. What can we do here? Well, the same as we did for that Terraform scan, we can learn best practices for Kubernetes objects, both operational risk and security risk. Why? We can bring a central context to image deployment and vulnerability management because defaults once again can be dangerously insecure. And I'll show you what I mean by that. First, what's great, many open source tools are available. I love that. There's a few there. KubeLiner, KubeScore, check out, blah, blah, blah, blah, blah. That was a whole bunch, right? A few weeks back, I think, well, there, there was a great demonstration on KubeLiner. I'm going to give you the two second version of it. So KubeLiner is super easy to use. You stall again with brute. So if you're on a Mac, dead easy. And if you want to know how to use it, there's not a lot of options. So you can digest this pretty quick. If you want to see what the checks that exist are, it's easy. Just write checks, list, and you can see the things that you're looking for. Things you would expect, unset CBU requirements, open SSH port again like we had before, run as non-route. You see some of them are true, some of them are false. I like that actually because the default, not all of them are on by defaults, but the must haves are. So it's kind of a good way of doing it, I think. If you want to scan, it's very similar. You just type KubeLiner lint. You pick your file, and you can see I've got one called rushed. This is typical of a YAML. Why is it rushed? Well, did I put the CPU request? No, no one does that when they're rushing. I'm not asking the server to set to run, like not set to run as root. That's really bad. I like that I get some information in a link so I can go over here and I can go right. Set security context for the pod. Probably the single most missed section of YAML is the security context. Makes me sad. So what I've done already, I'm not going to go fix it. I fixed it already, and I've got the one that I should have. I scan it. No errors are found. And if you're wondering what changes I made, I'll show you the difference. It's nothing hardly. I've got some resource requests in there. They're a little bloated at the moment, but I'll adjust them later, and I've got a security context that makes me safe by default. Amazing. Super easy to do. I do have a caveat for that when I talk about scanning YAML files. There are some growing popularity of abstraction layers. So CDKates is one. I think Pulumi is another one where you can embed the generation of Kubernetes right into some code. It sounds awesome. I see these things and I get super excited because I'm thinking I can type TypeScript and I can create a service in my TypeScript and I can interact with it like live. That's neat. I like that until I start thinking about security. What if I KubeLinter the resulting YAML and there are insecurity faults? How do I translate the results back into the other code I wrote? It's kind of, there's a bit of extra security headache going on there if we do that. So worth knowing that. The same thing happens when you're writing JavaScript for the browser. You might write it in TypeScript. You generate the code that goes into the browser. You find mistakes there. What is it locally in TypeScript? There's a lot of mapping you got to do. It's a pain. So that was the one caveat. But the reality is many open source tools are available. The cons, and it would be cool if we did this more in open source, but maybe I should write an open source project that doesn't, Steve. Few, if any, of the open source tools combined the scanning for image vulnerabilities with the linting of the YAML. Wouldn't that be cool? Because the images are there. They're called out. If we could double that in and use that context, that would be pretty nice. There are, I mean, I'm from Stack Rocks. The Stack Rocks commercial tool does that, which is cool, but it would be cool to see an open source version that did it. Now, to talk about what we do at Stack Rocks, just a little bit of a, we have those vulnerabilities. Why is it cool to get the context? Just like the Canter Bureau with the 10% that Poor Byron had. If I know the vulnerability is going into test only and not going into prod, that's different. It changes the risk profile. If I know the criticality of the app based on in-system metadata, if I know whether it's running privileged, that's really bad. If I know if it has access to certain secrets, I know it's blast radius because there's a load balancer in front of it. I know it's a simple pod with an easily characterizable process. Very simple app. Engine X is a good example. Then I can characterize it. I know what an anomaly looks like. All these things matter because if we think about a CVS as 9.8 in a back-end service with no external connectivity, not privileged with a recorded small baseline of activity, cool. I actually might let that go. If there's a 7.6 that's in my front-end API behind a load balancer with an exposed port by accident, a complex base image that maybe has all those tools hackers love like curl and WGet and NMAP and all those, right? That's so much worse. But the prioritization of vulnerabilities just based on CVS score wouldn't agree with me. So this is why we need to start looking at the context. We need to focus on deployments in YAML, look at things in the context of Kubernetes objects. All right. Layer 6, the icing on the cake. The runtime. Maintaining the state of security. This is also great. There are some very cool things out there, EBPF-driven like Bowco was awesome, Tracy from Aqua. Anomalies as Kubernetes objects can be found. Prevention by admission controllers via policy. Security as policy with things like OPPA and Kyveron I just started playing with is pretty neat. All of this is a great move to runtime. Why do we need to do it? Well, there's only so much we can do in layers zero to five, right? We shouldn't do nothing. We want to make as little happen here as possible. And we want to get as much information so that when we are making runtime decisions on alerts, we're making them data-driven. Zero-day exploits of new attack vectors are going to happen. We need runtime. What are the pros of runtime? This is a cynical pro, but InfoSec people understand things like EDR and IDS. They understand the world of runtime. So when you've got runtime and you're speaking of it in terms of Kubernetes, this speaks the language of InfoSec and it goes down very well. Zero-days and anomaly detections are still required and it's an essential safety net for all the things you didn't do in zero to five. The cons, this is still reactionary. It's still probabilistic. It's labor intensive. It's expensive. It's one of those horse bolted door close kind of things sometimes. Something does happen, but it's all still required. So the key takeaway is, before I wrap up, shifting left is good. People say it a lot in security. Actual developers probably never hear it very often, but what it means is we're trying to push security over there. The problem essentially is the more people you involve in your security problem, the better it gets, but the harder it is to deploy. Shifting middle. People are starting to say this. Actually a recent report called BSIM 11, I think it was called the shift everywhere, which I kind of like until it wears off. Simpler checks, but more often. And this is what I'm trying to convey. It's actually all the things I just showed you are pretty easy because they're just little things. It seems like a lot of things, but they're all little easy things. And they mean that when you get to runtime, a lot of the easy stuff's gone. Context is a huge advantage. I like to drive that home. We don't use it enough. And it can be absolutely critical for ensuring that our image vulnerabilities are prioritized correctly. Everything in this code is great. Reduces imperative intervention, but remember the same security concerns are there that were there for when we wrote application code, as are they are for when we write infrastructure as code code. We should scan it. We should put it and get and control it. Treat it with the same respect. Getups from plus Kubernetes enables us to do that. And declarative equals deterministic equals less probabilistic. Deterministic security through Kubernetes. So that is the end. Thank you very much. That is me. Well, that was wonderful. You deserve a really good beer for that. And you deserve to track it untapped and talk about it. That's wonderful. What was wonderful is there were so many different projects and products and small things people could do and take a ways. And like trivia, I hadn't even seen trivia yet, so I'm going to go play with that sometime soon. And just last week or the week before, we had the Cube Vinter folks on Michael Foster and Vishu, I think from... Vishwa. Vishwa. Thank you. I kill his name every time. And I think that's the biggest, one of the big takeaways from this is that there are lots of small things you can do to make security part and parcel the DNA of any workflow or any deployment pipeline. And that's really been one of the mantras that we've had in some of the conversations we've been having about DevSecOps and the shift-left conversations, too. And I really think, and I think the more we talk about context is king or queen, shall we say, that, I think, is the key here is that... And I forget which slide it was you were on where you were talking about combining Chekhov and Cube Linter and a few other things to create that solution or something. And those are the things that, because CVs are so noisy, there are so many of them out there, it's the context, I think. And I like how you speak to that piece of it. And I think that's the thing that people miss. We create great dashboards for when a CV is there, when we've created an image that has something that needs to be patched, and this is the patch you should do. But many of the tools that you have, there are pieces of it, but creating an environment and workflow that takes advantage of it and doesn't notify me at two in the morning that some new thing, yeah. And as Mike is saying, observability is key. And that's really... That's another key piece of it. So I think that's a wonderful thing. And I'm so glad that StackRocks and Red Hat are gonna be working together closely and doing more of this work. I'm looking to see if there's any questions in the chat. I think people are one first blown away. We all want the cake. Did you actually make that cake? No. That's the beauty of the... We'll cut this out when we put it on YouTube. Yeah, I definitely made... I did not make the cake. I'm a terrible baker. It would have been a disaster. I love Great British Bake Off, but I'm a bad baker. Yeah. No, I think that's pretty... You covered a lot there. I think we'll get some feedback from folks when we post it. One of the things that I'm probably gonna try and go back to is annotate your talk with links to some of all of these wonderful tools that you've pointed out. I think that's really an amazing tour de force on what's available out there. And I do think you need to start your own open source project. Got it. And somewhere soon. So we'll definitely take you on on that. And we'll be seeing some really fun stuff coming out in the not too distant future. And we'll definitely have you back again soon to talk about other things related to this topic. And wonderful. And please, if you are listening to this, take a look at the Continuous Security Podcast and check out Hube Native Security. Steve, you're one of the best presenters of this information that I've heard in a long time. So thank you very much for joining us today. Thanks, Diane. It's been great. All right. Take care all.