 Hello everyone, welcome to this CUBE Conversation. I'm here in Palo Alto, California. I'm John Furrier, host of theCUBE, and we have a great guest here, Barack Schoster, who's in Tel Aviv, Senior Director of Chief Architect at Bridge Crew, a part of Palo Alto Networks. He was formerly the co-founder of the company then sold to Palo Alto Networks. Barack, thanks for coming on this CUBE Conversation. Thanks John, great to be here. So one of the things I love about open source and you're seeing a lot more of the trend now that talking about people doing incubators all over the world. Having open source and having builders, people who are starting companies, it's coming more and more, you're one of them. And you've been part of this security, open source, cloud infrastructure, infrastructure as code going back a while and you guys had a lot of success. Now open source infrastructure as code has moved up to the stack. Certainly a lot going down at the network layer, but developers just want to build security from day one. They don't want to have to get into the waiting game of slowing down their pipelining of code in the CICD. They want to move faster. And this has been one of the core conversations this year is how to make developers more productive, not just a cliche, but actually more productive and not have to wait to implement cloud native, right? So you're in the middle of it and you got, you're in the, tell us, tell us what you guys are doing with that. Right, yeah. So I hear these needles working fast, having a large velocity of releases from many of my friends, the SREs, the DevOps and the security practitioners in different companies. And the thing that we asked ourselves three years ago was how can we simplify the process and make the security teams an enabler instead of a gatekeeper that blocks the releases? And the thing that we've done and we understood that we should do is not only doing runtime scanning of the cloud infrastructure and the cloud native clusters, but also shift left the findings and fittings, the remediation of security issues to the level of the code. So we started with infrastructure as code. We terraformed Kubernetes manifest cloud formation, serverless and the list goes on. And we created an open source product around it named Checkup, which has an amazing community of hundreds of contributors. Not all of them are Palo Alto employees. Most of them are community users from various companies. And we tried to and succeeded to democratize the creation of policy as code, the ability to inspect your infrastructure as code and tell you, hey, this is the best practice that you should use, consider using it before applying a misconfigured SRE bucket into production or before applying a misconfigured Kubernetes cluster into your production or dev environment. And the goal... Go ahead, go ahead, the goal. The goal is to do that from the IDE from the moment that you write code and also to inspect your configuration in CI and CD and in runtime. And also understand if there is any drift out there and the ability to fix that in the source code in the blueprint itself. So what I hear you saying is to really two problems you're solving. One is the organizational policies around how things were done in an environment before, the old way, security teams do a review, you send a ticket, things are waiting, stop wait, hurry up and wait kind of thing. And then there's the technical piece of it, right? Is that just two pieces to that? Yeah, I think that one thing is the change of the methodologies. We understood that we should just work differently than what we used to do. Tickets are slow, they have priorities. You have a bottleneck, which is a small team of security practitioners. And honestly, a lot of the work is repetitive and can be democratized into the engineering teams. They should be able to understand, hey, I wrote the code piece that provisioned these instance, I am the most suitable person as a developer to fix that piece of code and reapplied to the runtime environment. And that also sets the table for automation. It sets the table for policies, things that make things more efficient, scaling. Because you mentioned SREs are a big part of this too. DevOps and SRE, those folks are trying to move as fast as possible at scale, huge scale challenge. How does that impact the scale piece to come into here? So both teams, SREs and security teams are about a link to deploying application, new application releases into the production environment. And the thing that you can do is you can inspect all kinds of best practices, not only security best practices, but also make sure that you have provisioned concurrences on your serverless functions or the amount of auto-scanning groups is what you expect it to be. And you can scan all of those things in the level of your code before applying it to production. That's awesome. So good benefits, scales of security teams sounds like too as well. You could get that policy out there. So great stuff. I want to really quickly ask you about the event you're hosting, Code to Cloud Summit. What are we going to see there? I'm going to host a panel of course, looking forward to that as well. Get a lot of experts coming in there. Why are you having this event and what topics will be covered? So we wanted to talk on all of the shift left movement and all of the changes that have happened in the cloud security market since inception till today. And we brought in great people and great practitioners from both the DevOps side, the chaos engineering and the security practitioners and everybody are having their opinion on what's the current state, how things should be implemented in a mature environment and what the future might hold for the code and cloud security markets. The thing that we're going to focus on is all of the supply chain from securing the CICD itself, making sure your GitHub actions are not vulnerable to shell injection or making sure your version control system are configured correctly with single sign-on MFA and having branch protection rules, but also open source security like SCA, so through composition analysis, infrastructure as code security obviously, runtime security, drifts and Kubernetes security. So we're going to talk on all of those different aspects and how each and every team is mitigating the different risks that come with them. You know, one of the things that you bring up when I hear you talking is that's the range of infrastructure as code. How has infrastructure as code changed? Because there's DevOps and SREs, now application developers. You still have to have programmable infrastructure. I mean, if infrastructure code is realized up and down the stack, all aspects need to be programmable, which means you have to have the data, you got to have the ability to automate. How would you summarize kind of the state of infrastructure as code? So a few years ago, we started with physical service. We carried the infrastructure on our back. I mounted them on the rack myself a few years ago and connected all of the different cables. Then came the revolution of VMs. We didn't do that anymore. We had one beefy appliance and we had 60 virtual servers running on one appliance. So we didn't have to carry new servers every time to enter the data center. Then came the cloud and made everything API first, enable and enabled us to write batch scripts to provision those resources. But it was not enough because you wanted to have a reproducible environment that is written either in declarative language like Terraform or CloudFormation or imperative like CDK or Pulumi. But having a consistent way to deploy your application to multiple environments and the stage after that is having some kind of a service catalog that will allow application developer to get the new releases up and running. And the way that it has evolved, mass adoption of infrastructure as code is already happening, but that introduces the ability for velocity in deployment, but also new kind of risks that we haven't thought about before as security practitioners. For example, you should vet off the open source Terraform modules that you're using because you might have a leakage there. Terraform has a lot of access to secrets in your environment and the state really contains sensitive objects like passwords. The other thing that have changed is we today we rely a lot on cloud infrastructure and on the past year, we've seen the log for shell attack, for example, and also cloud providers have disclosed that they were vulnerable to log for shell attack. So we understand today that when we talk about cloud security, it's not only about the infrastructure itself, but it's also about, is the infrastructure that we're using is using an open source package that is vulnerable? Are we using an open source package that is vulnerable? Is our development pipeline is configured and the list goes on? So it's really a new approach of analyzing the entire software bill of material, also called Sbomb, and understanding the different risks there. You know, I think this is a really great point and great insight because new solutions, new problems are new opportunities, right? So open source growth has been phenomenal and you mentioned some of those Terraform and all the projects and you started one check off. They're all good, but there's some holes in there. I mean, it's open source, it's free, everyone's building on it. So, you know, you have, and that's what it's for. And I think now as open source goes to the next level, again, another generational inflection point, it's, there's more contributors, there's companies are involved, people are using it more. It becomes a really strong integration opportunity. So it's all free and it's how you use it. So this is a new kind of extension of how open source is used. And if you factor in some of the things like threat vectors, you have to know the code. So there's no way to know it all. So you guys are scanning it, doing things, but it's also a huge system. It's not just one piece of code. You're talking about cloud has become an operating system. It's a distributed computing environment. So whole new area of problem space to solve. So I love that piece. Where are you guys at on this now? How do you feel in terms of where you are in the progress bar of the solution? Because the supply chain is usually a hardware concept people can relate to. But when you bring in software, how you source software is like sourcing a chip or a piece of hardware, you've got to watch where it came from. And you got to track track that. So, or scan it and validate it. So these are new things. Where are we with all this? So you're right. We have a lot of moving parts and really the supply chain terms came from the automobile industry. You have a car, you have an engine. The engine might be created by a different vendor. You have the wheels. They might be created by a different vendor. So when you buy your next Chevy or Ford, you might have a wheels from continental or other vendors. And actually software is very similar. When we build software, we host it on a cloud provider like AWS, GCP, Azure, not on our own infrastructure anymore. And when we're building software, we're using open source packages that are maintained in the other half of the work. And we don't always know in person the people who've created that piece. And we do not have a vetting process, even a human vetting process on is everything that we've created was really made by us or by a trusted source. And this is where we come in. We help you, empower you, the engineer, with tools to analyze all of the dependency tree of your software build materials. We will scan your infrastructure code, your application packages that you're using from package managers like NPM or PyPy and we will scan those open source dependencies. We will verify that your CICD is secure, your version control system is secure. And the thing that we will always focus on is making a fix accessible to you. So let's say that you're using a misconfigured backup, we have a bot that will fix the code for you. And let's say that you have a vulnerable open source package and it was fixed in a later version, we will bump the version for you to make your code secure. And we will also have the same process on your runtime environment. So we will understand that your environment is secure from code to cloud or if there are any drifts out there that your engineering team should look at. That's a great service. And I think this is a cutting edge from a technology perspective. What are some of the new cloud native technologies that you're seeing emerging fast that's getting traction and ultimately having a product market fit in this area? Because you mentioned Kubernetes, that's one of the areas that have a lot more work to do or being worked on now that customers are paying attention to. Yeah, so definitely Kubernetes is has started in growth companies and now it exists in every Fortune 100 company. So you can find it in every large scale organization and also serverless functions are getting into a higher adoption rate. I think that the thing that we're seeing the most massive adoption off is actually infrastructure as code. During COVID, a lot of organization went through digital transformation. And in that process, they have started to work remotely and have agreed on migrating to a new infrastructure, not the data center, but the cloud provider. So a lot of teams that were not experienced with those clouds are now getting familiar with it and getting exposed to new capabilities. And with that, also new risks. Well, great stuff. Great to chat with you. I want to ask you while you're here you mentioned infrastructure as code for the folks that get it right with some significant benefits. And if you don't get it right, we know what that looks like. What are some of the benefits that can you share personally or the folks watching out there? If you get infrastructure as code, right? What does the future look like? What does success look like? What's that path look like when you get it right versus not doing it or getting it wrong? I think that every engineer dream is one to be impactful to work fast and learn new things and not to get a major duty on a Friday night. So if you get infrastructure right, you have a process where everything is declarative and it's peer reviewed both by you and automated frameworks like Bridge Crew and Chekhov. And also you have the ability to understand that, hey, once I read it once and from that point forward, it's reproducible and it also have a state. So only changes will be applied and it will enable myself and my team to work faster and collaborate in a better way on the cloud infrastructure. Let's say that you don't do infrastructure as code, you have one resource changed by one team member and another resource changed by another team member and the different dependencies between those resources are getting fragmented and broken. You cannot change your database without your application being aware of that. You cannot change your load balancer without your application being aware of that. So infrastructure as code really enables you to do those changes in a mature fashion that will pose less outages. A lot of people getting paid your duties on Friday, Saturday and Sunday and on the old way, new way, new, you don't want to break up your Friday night after a nice dinner either, Barack, do you? No. No. Well, thanks for coming in all the way from Tel Aviv. Really appreciate it. I wish you guys everything the best over there in WC at the event that's coming up. We're looking forward to the code to cloud summit and all the great insight you guys have. Thanks for coming on to share in the story. Looking forward to talking more with you, Barack. Thanks for all the insight on security, infrastructure as code and all the cool things you're doing at Bridge Crew. Thank you, John. Okay. There's theCUBE conversation here at Palo Alto, California. I'm John Furrier, host of theCUBE. Thanks for watching.