 Welcome back to our coverage of cloud native security con. I'm Dave Vellante here in our Boston studio. We're connecting today throughout the day with Palo Alto on the ground in Seattle. And right now I'm here with Michael Foster with Red Hat. He's on the ground in Seattle. We're going to discuss the trends and containers and security and everything that's going on at the show in Seattle. Michael, good to see you. Thanks for coming on. Good to see you. Thanks for having me on. A lot of market momentum for Red Hat. The IBM earnings call the other day. They announced OpenShift as a billion dollar ARR. So it's quite a milestone. I mean, it's not often, it's hard enough to become a billion dollar software company and then to have actually a billion dollar product alongside. So congratulations on that. And let's start with the event. What's the buzz at the event? People talking about shift left. Obviously supply chain security is a big topic. We've heard a little bit about, quite a bit about AI. What are you hearing on the ground? Yeah. So the last event that I was at that I got to see you at was three months ago with QCon and the talk was supply chain security. Nothing has really changed on that front. Although I do think that the conversation, let's say with the tech companies versus what customers are actually looking at is slightly different just based on the market. And like you said, thank you for the shout out to a billion dollar OpenShift and ACS is certainly excited to be part of that. We're seeing more of a consolidation, I think, especially in security. It's the money's still flowing in security, but people want to know what they're running. We've had some tremendous growth in the last couple of years and now it's, okay, let's get a hold of the containers, the clusters that we're running. Let's make sure everything's configured. They want to start implementing policies effectively and really get a feel for what's going on across all their workloads, especially with the bigger companies. I think bigger companies allow some flexibility in the security applications that they can deploy. They can have different groups that manage different ones, but in the mid to low market, you're seeing a lot of consolidation, a lot of companies that want basically one security tool to manage them all, so to speak. And I think that the features need to somewhat accommodate that. We talk supply chain, I think most people care, it's continue to care about network security, vulnerability management, shifting left and enabling developers. That's the general trend I see. Still really need to get some hands on demos and see some people that I haven't seen in a while. So a couple of things on consolidating, we talk about the macro economic climate all the time. We do a lot of survey data with our partners at ETR. And their recent data shows that in terms of cost savings, for those who are actually cutting their budgets, they're looking to consolidate redundant vendors. So that's one form of consolidation. The other theme, of course, is there's so many tools out in the security market that consolidating tools is something that can help simplify. But then at the same time, you see opportunities open up like IoT security. And so you have companies that are starting up to just do that. So there's like these countervailing trends. I mean, I often wonder, Michael, will this ever end, this, you know, that's like the universe growing and tooling. What are your thoughts? I mean, I completely agree. It's hard to balance trying to grow the company in a time like this. At the same time, we're trying to secure it all, right? So you're seeing the consolidation, but some of these applications and platforms need to make some promises to say, hey, we're going to move into this space, right? So when you have like Red Hat, who wants to come out with edge devices and help manage the IoT devices, well then you have a security platform that can help you do that that's built in. Then the messaging's easy when you're trying to do that across different cloud providers and move into IoT. It becomes a little bit more challenging. And so I think that, and don't take my word for this, some of those IoT startups, you might see some purchasing in the next couple of years in order to facilitate those cloud platforms to be able to expand into that area. To me, it makes sense, but I don't want to, I bought the size too much. But I do, we just did our predictions post and as a security, we put up the chart of candidates and there's like dozens and dozens and dozens, you know, some that are very well-funded, but I mean, you've seen some down, I mean, it down rounds everywhere, but you know, these many companies have raised over a billion dollars and it's like, uh-oh, okay, so they're probably okay, maybe. But a lot of smaller firms, I mean, there's just too many tools in the marketplace, but it seems like there is misalignment there, you know, kind of a mismatch between what customers would like to have happen and what actually happens in the marketplace. And that just underscores, I think, the complexities in security. So I guess my question is, you know, how do you look at cloud native security and what's different from traditional security approaches? Okay, I mean, that's a great question and it's something that we've been talking to customers for the last five years about. And really it's just a change in mindset. Containers are supposed to unleash developer speed and if you don't have a security tool to help do that, then you're basically going to inhibit developers in some form or another. And I think managing that while also giving your security teams the ability to tell the message of we are being more secure, you know, we're limiting vulnerabilities in our cluster, we are seeing progress because containers, you know, have a shorter life cycle and there is security and speed. Having that conversation with the C suites is a little different, especially when they might be used to virtual machines and managing it through that. I mean, if it works, it works. From a developer standpoint, you're not taking advantage of those containers and the developer speed. So that's the difference. Now doing that and then first challenge is making that pitch. The second challenge is making that pitch to then scale it. So you can get on board your developers and get your containers up and running. But then as you bring in new groups, as you move over to Kubernetes or you get into more container workloads, how do you onboard your teams? How do you scale? And I tend to see a general trend of a big investment needed for about two years to make that container shift. And then the security tools come in and really blossom because once that core separation of responsibilities happens in the organization, then the security tools are able to accelerate the developer workflow and not inhibit it. You know, I'm glad you mentioned separation of responsibilities. We go to a lot of shows, as you know, with theCUBE and many of them are cloud shows. And then the one hand cloud is, you know, obviously made the world, you know, more interesting and better in so many different ways and even security. But it's like new layers are forming. You got the cloud, you got the shared responsibility model. So the cloud is like the first line of defense. And then you got the CISO who is relying heavily on devs to, you know, the whole shift left thing. So we're asking developers to do a lot. And then you're kind of behind them. I guess you have audit is like the last line of defense. But my question to you is, how can software developers really ensure that cloud native tools that they're using are secure? What steps can they take to improve security? And specifically, what's Red Hat doing in that area? Well, I think there's, I would actually move away from that being the developer's responsibility. I think the job is to give the operators and the security people the tools to give them the ability to see the vulnerabilities they're introducing. Let's say signing their images, actually verifying that the images that's running in me in the cloud are the ones that they built. That can all be done and it can be done open source. So we have a DevSecOps validated pattern that Red Hat's pushed out and it's all open source tools in the cloud native space. And you can sign your builds and verify them at runtime and make sure that you're doing that all for free as one option. But in general, I would say that the hope is that you give the developer the information to make responsible choices and that there's a dialogue between your security and operations and developer teams. But security, we should not be pushing that on developer. And so I think with ACS and RTool, the goal is to get in and say, let's set some reasonable policies, have a conversation, let's get a security liaison, let's say in the developer team so that we can make some changes over time. And the more we can automate that and the more we can build and have that conversation, the better that you'll, I wouldn't say the more secure clusters, but I think that the more you're on your path, they're securing your environment. How much talk is there at the event about kind of recent high profile incidents we heard, you know, log4j of course was mentioned in the keynote. Somebody, you know, I think yelled out in the audience, we're still dealing with that. But when you think about these, you know, incidents, when looking back, what lessons do you think we've learned from these events? Oh, I mean, I think that I would say if you have an approach where you're managing your containers, managing the age and using containers to accelerate, so let's say no images that are older than 90 days, for example, you're going to avoid a lot of these issues. And so I think people that are still dealing with that aspect haven't set up the proper, let's say disclosure between teams and update strategy and so on. So I don't want to, I think the log4j, if it's still around, you know, something's missing there, but in general, you want to be able to respond quickly and to do that, you need the tools and policies to be able to tell people how to fix that issue. I mean, log4j fix was seven days after, so your developers should have been well aware of that your security team should have been sending the messages out. And I remember even fielding all the calls, all the fires that we had to put out when that happened, but yeah. I thought Brian Bellendorf's talk this morning was interesting because he was making an attempt to say, hey, here's some things that you might not be thinking about that are likely to occur. And I wonder if you could, you know, comment on them and give us your thoughts as to how the industry generally, maybe Red Hat specifically are thinking about dealing with them. He mentioned chatGPT or other GPT to automate spearfishing. He said the identity problem is still not fixed. Then he talked about free riders, sniffing repos essentially for known vulnerabilities that are slow to fix. He talked about regulations that might restrict shipping code. So these are things that, you know, essentially we can, they're on the radar, but you know, we're kind of putting out, you know, yesterday's fire. What are your thoughts on those sort of potential issues that we're facing? And how are you guys thinking about it? Yeah, that's a great question. And I think there's twofold. One, it's brought up in front of a lot of security leaders in the space for them to be aware of it because security, it's a constant battle, a constant war that's being fought. ChatGPT lowers the barrier of entry for a lot of, let's say, would be hackers or people like that to understand systems and create, let's say, symbol manifests to leverage Kubernetes or leverage a misconfiguration. So as the barrier drops, we as a security team, a security, let's say, group organization need to be able to respond and have our own tools to be able to combat that. And we do. So a lot of it is just making sure that we shore up our barriers and that people are aware of these threats. The harder part I think is educating the public and that's why you tend to see maybe the supply chain trend be a little bit ahead of the implementation. I think there's still, for example, like S-Bombs and signing an attestation, I think that's still a year or two years away from becoming, let's say, commonplace, especially in something like a production environment. But again, so stay pleading edge and then make sure that you're aware of these issues and we'll be constantly coming to these calls and filling you in on what we're doing and make sure that we're at the speed. Yeah, so I'm hearing from folks like yourself that you're thinking of future of cloud native security, we're going to see a continued emphasis on better integration of security into the dev sec ops. You're pointing out it's really the ops piece, that runtime that we really need to shore up. You can't just put it on the shoulders of the devs. And using security focused tools and best practices, of course you hear a lot about that and the continued drive toward automation. And my question is, I get automation, machine learning, how, where are we in that maturity cycle? How much of that is being adopted? Sometimes folks are, they embrace automation but it brings, unknown, unintended consequences. Are folks embracing that heavily? Are there risks associated around that? Or are we kind of through that knothole in your view? Yeah, that's a great question. I would compare it to something like a smart home. You sort of hit a wall, you can automate so much but it has to actually be useful to your teams. So when we're going into playing ACS and using the cloud service like one, you want something that's a service that you can easily set up. And then the other thing is you wanna start in inform mode. So you can't just automate everything, even if you're doing runtime enforcement need to make sure that's very, very targeted to exactly what you want. And then you have to be checking it because people start new workloads and people get onboarded every week or month. So it's finding that balance between policies where you can inform the developer and the operations teams and that they give them the information to act. And that worst case, you can step in as a security team to stop it. During the onboarding of our ACS cloud service, we have an early access program and I get on calls and it's not even security teams, the operations team starts with the security product. And sometimes it's just, hey, how do I set this policy so my developers will find this vulnerability like a log for shell. I just wanna send them an email, right? And these are, they have the tools and they can do that. And so it's nice to see the operations take on some security, they can automate it because maybe you have a netsec security team that doesn't know Kubernetes or containers as well. So that shared responsibility is really useful. And then just again, making that automation targeted even though runtime enforcement is a constant thing that we talk about, the amount that we see it in the wild where people are properly setting up admission controllers and it's acting, it's again, very targeted databases, qubits x, things that are basically, we all know as a no-go in production. Thank you for that. My last question, I want to go to the hardest part and because you're talking to customers all the time and you guys are working on the hardest problems in the world, what is the hardest aspect of securing? I want to come back to the software supply chain. Hardest aspect of securing the software supply chain from the perspective of a security pro, software engineer, developer, DevSecOps pro and then the hard B of that is how are you attacking that specifically is Red Hat? Sure. So as a developer, it's managing vulnerabilities with updates as an operations team, it's keeping all the cluster because you have a bunch of different teams working in the same environment, let's say. From a security team, it's getting people to listen to you because there are a lot of things that need to be secured and just communicating that and getting it actionable data to the people to make the decisions this hard. From a C suite, it's getting the buy-in because it's really hard to justify the dollars and cents of security when security is constantly having to have these conversations with developers. So for ACS, we want to be able to give the developer those tools, we also want to build the dashboards and reporting so that people can see their vulnerabilities drop down over time and also that they're able to respond to it quickly because really that's where the dollars and cents are made in the product. It's that a log per shell comes out, you get immediately notified when the feeds are updated and you have a policy in action that you can respond to it. So I can go to my CSOs and say, hey, look, we're limiting vulnerabilities and when this came out, the developers stopped it in production and we were able to update with the next release, right? Like that, that's your bread butter. That's a story that you want to tell. Again, it's a harder story to tell, but it's easy when you have the information to be able to justify the money that you're spending on your security tools. Hopefully that answered your question. Yeah, it does. It was awesome. I mean, you got data, you got communication, you got the people, obviously there's skillsets, you have of course tooling and technology is a big part of that, Michael. Really appreciate you coming on the program, sharing what's happening on the ground in Seattle and can't wait to have you back. Yeah, so thanks again for having me. Yeah, our pleasure. All right, thanks for watching our coverage of the cloud native security con. I'm Dave Vellante, I'm in our Boston studio. We're connecting to Palo Alto. We're connecting on the ground in Seattle. Keep it right there for more coverage. We'll be right back.