>>Hello, everyone. Welcome to this cube conversation. I'm here in Palo Alto, California. I'm John furrier, host of the cube, and we have a great guest here. Barack Shuster. 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 Brock. 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, you know, people doing incubators all over the world, having open source and having a builder, people who are starting companies, it's coming more and more, you 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 lot going down at the network layer, but developers just want to build security from day one, right? They don't want to have to get into the, the, the waiting game of slowing down their pipelining of code in the CIC D they want to move faster. And this has been one of the core conversations this year is how to make developers more productive and 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've got you're in, tell us, tell us what you guys are dealing with that, >>Right? Yeah. So I hear these needles working fast, having a large velocity of releases from many of my friends, the SRAs, 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, then 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 fixings the remediation of security issues to the level of the code. So we started doing infrastructure is good. We Terraform Kubernetes manifests cloud formation, server less, 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 the democratic side is 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 S3 bucket into production, or before applying a misconfigured Kubernetes cluster into your production or dev environment. And the goal, >>The goal, >>The goal is to do that from the ID from the moment that you write code and also to inspect your configuration in CGI and CD and in runtime. And also understand that 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 really two problems you're solving. One is the organizational policies around how things were done in a environment before all the old way. You know, the 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 there's 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 provision this instance, I am the most suitable person as a developer to fix that piece of code and reapply it to the runtime environment. >>And then it also sets the table for our automation. It sets the table for policies, things that make things more efficient scaling. Cause you mentioned SRS are a big part of this to dev ops and SRE. Those, those folks are, are trying to move as fast as possible at scale, huge scale challenge. How does that impact the scale piece become into here? >>So both themes Esri's and security teams are about a link to deploying application, but 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 provision concurrencies on your serverless functions or the amount of auto-scaling 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, good benefits scales a security team. It 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 two cloud summit. What are we going to see there? I'm going to host a panel. Of course, I'm looking forward to that as well. You 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 shifts, 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 dev ops side, the chaos engineering and the security practitioners, and everybody are having their opinion on what's the current status 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 CCD itself, making sure your actions are not vulnerable to a shut 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 software composition analysis infrastructure as code security. Obviously Ron thinks 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. >>You know, one of the things that you bring up when you hear you talking is that's the range of, of infrastructure as code. How has infrastructure as code changed? Cause you're, you know, there's dev ops and SRS now application developers, you still have to have programmable infrastructure. I mean, if infrastructure code is real realize up and down the stack, all aspects need to be programmable, which means you got 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 servers where you carried the infrastructure on our back. I, I mounted them on the rack myself a few years ago and connected all of the different cables then came the revolution of BMS. 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 into the data center then came the cloud and made everything API first. And they bill and enabled us to write the best scripts to provision those resources. But it was not enough because he wanted to have a reproducible environment. The is written either in declarative language like Terraform or CloudFormation or imperative like CDK or polluted, 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 kinds of risks that we haven't thought about before as security practitioners, for example, you should vet all of the open source Terraform modules that you're using because you might have a leakage. Our form has a lot of access to secrets in your environment. And the state really contains sensitive objects like passwords. The other thing that has changed is we today we rely a lot on cloud infrastructure and on the past year we've seen the law 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 Asbell and understanding the different risks there. >>You know, I think this is a really great point and great insight because new opera, new solutions for new problems are new opportunities, right? So open source growth has been phenomenal. And you mentioned some of those Terraform and one of the projects and you started one checkoff, they're all good, but there's some holes in there and 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 is open source goes to the next level again, another generational inflection point it's it's, there's more contributors there's companies are involved. People are using it more. It becomes a really strong integration opportunity. So, 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 can factor in some of the things like, 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 huge system. It's not just one piece of code. You talking about cloud is becoming an operating system. It's a distributed computing environment, so whole new area of problem space to solve. So I love that. 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, or a piece of hardware, you got to watch where it came from and you gotta track track that. So, or scan it and validate it, right? So these are new, new things. Where are we with? >>So you're, you're you're right. We have a lot of moving parts. And really the supply chain terms of came from the automobile industry. You have a car, you have an engine 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 than the first. 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 war. 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 these, 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, we tools to analyze all of the dependency tree of your software, bill of materials. We will scan your infrastructure code, your application packages that you're using from package managers like NPM or PI. And we scan those open source dependencies. We would verify that your CIC is secure. Your version control system is secure. And the thing that we will always focus on is making a fixed 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, 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 run time environment. So we will understand that your environment is secure from code to cloud, or if there are any three out there that your engineering team should look at, >>That's a great service. And I think this is cutting edge from a technology perspective. What's what are some of the new cloud native technologies that you see in emerging fast, that's getting traction and ultimately having a product market fit in, in this area because I've seen Cooper. And 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's existing every fortune 100 companies. So you can find anything, every large growler scale organization and also serverless functions are, are getting into a higher adoption rate. I think that the thing that we seeing the most massive adoption off is actually infrastructure as code during COVID. A lot of organization went through a 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 at other 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 depth infrastructure as code for the folks that get it right. There's some significant benefits. We don't get it. Right. We know what that looks like. What are some of the benefits that can you share personally, or for the folks watching out there, if you get it for sure. Cause 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 wanting to be impactful, to work fast and learn new things and not to get a PagerDuty on a Friday night. So if you get infrastructure ride, you have a process where everything is declarative and is peer reviewed both by you and automated frameworks like bridge and checkoff. And also you have the ability to understand that, Hey, once I re I read it once, and from that point forward, it's reproducible and it also have a status. 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'd done doing infrastructure as code. You have one resource change by one team member and another resource change 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 Bonser without the obligation being aware of that. So infrastructure skullduggery enables you to do those changes in a, in a mature fashion that will foes Le less outages. >>Yeah. A lot of people getting PagerDuty's 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 rock, do you know? Well, thanks for coming in all the way from Tel-Aviv really appreciate it. I wish you guys, everything the best over there in Delhi, we will see you at the event that's coming up. We're looking forward to the code to cloud summit and all the great insight you guys will have. Thanks for coming on and sharing the story. Looking forward to talking more with you Brock thanks for all the insight on security infrastructures code and all the cool things you're doing at bridge crew. >>Thank you, John. >>Okay. This is the cube conversation here at Palo Alto, California. I'm John furrier hosted the cube. Thanks for watching.