Software at Scale - Software at Scale 11 - Barak Schoster: CEO, BridgeCrew

Episode Date: March 4, 2021

Barak Schoster is the CEO of BridgeCrew, a cloud security platform that was just acquired by Palo Alto Networks. He’s also the maintainer of Checkov, a popular static code analysis tool for infrastr...ucture-as-code.In this episode, we discuss both aspects - the experience running a DevOps company and a popular open-source tool.Apple Podcasts | Spotify | Google PodcastsHighlights1:40 - The story and history of BridgeCrew.9:30 - Why should engineers run both Checkov and BridgeCrew checks in their infrastructure? In other words - why is static analysis of infrastructure config files not enough?15:00 - The BridgeCrew VSCode plugin17:00 - The community response towards Checkov (it’s grown from 50 checks to over 500 checks in one year)20:00 - The software design behind Checkov made it easy for the community to contribute. Awareness of good software design principles is important, but also responsiveness to community needs - for example, Barak helped out with a refactoring effort to make additional cloud providers (like GCP) easier to check for25:00 - Fostering an open-source community to ensure inclusivity30:00 - Future of security in software organizations - the simplification that’s bound to happen34:30 - Advice for founders of DevOps companies This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

Transcript
Discussion (0)
Starting point is 00:00:00 Welcome to Software at Scale, a podcast where we discuss the technical stories behind large software applications. I'm your host, Utsav Shah, and thank you for listening. Welcome, Barak, to another episode of the Software at Scale podcast. And let me give listeners a little bit of an introduction on Barak. So Barak Shoster is your full name. Did I pronounce that correctly? Yeah. So Barak used to be the head of big data engineering at the Israel Data Defense Forces of CFI and
Starting point is 00:00:37 Cybersecurity Directorate. Then he made his mark at FortScale and RSA Security. And finally, now he's the CEO of BridgeCrew, which is, I think the best way to describe it from my limited understanding is it's like a cloud security system where it enables you to make sure that you're keeping security first in mind when you're building new products or you're spinning up new infrastructure. Does that sound reasonably correct? It is. One of the things that we are trying to do differently at BridgeCrew is we don't only help you to secure the cloud,
Starting point is 00:01:12 it's also about the audience that we aim for. We believe that a lot of the cloud infrastructure is maintained by developers, SREs, DevOps engineers. It's a different paradigm from what it used to be in data centers where you had an IT team and security team. So we are trying to do a shift in responsibility and to give developers the tools they love, IDs, open source tools, NCICD enhancements where we can help users to catch misconfigure early on. Okay. So yeah, can you walk me through a little bit of the history of BridgeCrew? What gave you enhancements where we can help users to catch misconfigure early on.
Starting point is 00:01:45 Okay. So yeah. Can you walk me through a little bit of the history of rich crew? What gave you the idea that you should work on this? It's an important problem. Yeah. So taking a step back and looking on the IT space, when you wanted to create a new application like seven years ago, you would go to your program manager and then to your IT team and data center management team and you would tell them, Hey, I need a new server, you'll get one provision first, like years ago, it would be a physical one, then a VMware, a VM being provisioned. And then you need you were you were required to open a ticket and get everything transitioned from one team to another, from the IT provisioning team and the imaging team into the networking team and then security team. And you had this whole process of getting an enterprise application up and running in your data center. It would have taken you months. Back then we used to
Starting point is 00:02:47 work in waterfall, not in agile, not in sprints. It was a lot of heavy lifting. And then came the cloud. Everything changed. Everything was API first. You wanted a new server, that's an API call. You wanted a new networking configuration, that's another API call. So you don't have, well, I used to carry firewall blades and servers to the data centers and to connect them manually with all of the cables on data centers that had thousands of servers. And today it's just an API call. And the next phase was, hey, we have all of those APIs.
Starting point is 00:03:24 We can create a huge automation on top of that and have auto scaling groups, spot instances, and just basically scale our business just as Google scales their own business and Amazon scales their own business. So then came the third transition from it to API and from API API to infrastructure as code. Um, basically this third wave was the ability to declare and plan.
Starting point is 00:03:58 How do you want your application to look like and to have a predictable deployment of that application? So infrastructure is code frameworks at the beginning like Chef and Puppet and then Ansible, Terraform, CloudFormation, CDK, Pulumi came out to the world helping us to create a predictable state in a fast-moving environment. We can change our cloud infrastructure very fast and we can have a lot of teams benefiting
Starting point is 00:04:29 from those changes and a lot of teams contributing back for infrastructure changes. So now I don't need to open a ticket to the IT team and another one to the networking and another one to the security. As an engineer, I have a lot of power in my hands to describe how I want my architecture to look like, how I want containers and images to look like, and how I want my
Starting point is 00:04:53 application to look like. And basically the whole process of building application was democratized to a single engineer. And Bridge wants to support that movement, we actually do. We want to take that movement of infrastructure as code, where each developer have become a crucial point and a productive point in creating application and business on top of them. And we help those engineers to see that they are developing those cloud infrastructure without having any mistakes. So instead of having pen testers or alongside having pen testers and IT department and security guys checking your infrastructure, we let you as an engineer see that while you're writing your cloud infrastructure, you're doing that with best practices in place. And we came into that conclusion because myself, with my experience as an SRE, a DevOps engineer, or an architect, I tried to have so many applications up and running in enterprise environment. And I always got kind of stuck or had a lot of bureaucracy to do to get this application up and running. I tried to understand why. And it had good reasons. I didn't know the best practices by back then. So I've decided to create an open source that will incorporate all of the best practices of all of the community within it.
Starting point is 00:06:26 We called it Checkout. It was open sourced about a little more than a year ago. And we had, I think the goal of it is to statically analyze infrastructure as code. And we had tons of community members from cool companies contributing content back, sharing with us what are their best practices. Okay. Yeah, so what it seems like to me is that, you know, product developers or application developers, they want to write applications as quickly as possible,
Starting point is 00:07:00 spin up infrastructure as quickly as possible. But there might be these other incentives of the organization. Take things like cost you like you don't want to have really expensive infrastructure or security right where everybody's not thinking about how do i keep all of my s3 buckets like encrypted all the time like it's it's just there's these two different goals that an organization has and usually since everybody is always focused on shipping faster, these other things get left behind. And that's where like BridgeCrew and other tools can come in.
Starting point is 00:07:33 Is that a good way of explaining what it does? Yeah, definitely. So BridgeCrew is part of the movement of democratizing infrastructure development. And there is a subset of features called policy as code. Policy as code is the ability just to give a hint to an engineer of, hey, you provisioned the server in the cloud. It's going to cost you a lot.
Starting point is 00:07:59 Are you sure you want to do that? It can be a hint, and it can also stop a build from happening. So provision, you have a code provisioning that server and we can say, hey, before you're provisioning it, we're stopping the build. We're telling you, hey, this is going to cost you a lot or going to impact your security posture. And you need to fix that before applying the build to its next step. You can also report that to other team members, have a data review. And BridgeView essentially is just like another team member doing code review based on your code.
Starting point is 00:08:39 So if you have the server defined in code before BridgeView, you might have had someone, your colleague, giving you a pull request comment saying, hey, you should really define the server in another way. Different amount of storage, memory, CPU, or you don't need that much. Or you should have this bucket encrypted. And BridgeCrew is actually a GitHub bot automating the code review process and telling you, hey, this is really the best practice, try to follow it. I've certainly seen, you know, infrastructure team reviews all Terraform changes, things like that.
Starting point is 00:09:11 And this is, and first of all, it's easy for humans to miss really large issues, especially when they trust the product engineer working on it. Whereas like a bot is definitely better. And also there are so many more policies. And as you said, right, if the community comes in and they help contribute more policies, there are so many more policies. And as you said, right, if the community comes in
Starting point is 00:09:25 and they help contribute more policies, there's so many things that you might miss. You might not know best practices of every single AWS service. So overall, this makes a lot of sense to me. Can you talk a little bit more about, you know, the difference between like Chekhov and BridgeCrew, right?
Starting point is 00:09:41 So Chekhov, as you said, is a static analysis tool, right? So to me, what that sounds like is you run a basic set of validations on Terraform configs without hitting some kind of like API and you can run it all locally and it works fine. So that sounds really amazing. It sounds, that sounds like what I need.
Starting point is 00:09:59 So how does BridgeCrew help? Like what additional stuff does BridgeCrew do? Yeah, sure. So the challenge of having policies and best practices in your cloud does not stop at static analysis. There are other things that you'd have to have in place to make sure that your cloud infrastructure is governed and in a good shape.
Starting point is 00:10:22 You need to have runtime analysis. You need to analyze everything from code to cloud. And some resources are managed only on cloud, directly through the console, or you got to pay your duty overnight and you change manually through the console. You won't get that on the static analysis because it's relying on everything being in the loop,
Starting point is 00:10:43 file in code. So you have to have runtime analysis in place to make sure that you don't have any drifts between code and cloud and best practices are enforced in both. So you should have the ability to analyze both and tell you what's the change, the ability to fix directly in cloud or in code.
Starting point is 00:11:02 So there are in Bridge, there are automated fixes and the bot will actually fix your code for you if you have a set of best practices in place. It also comes with the ability to integrate to IDEs like VS Code and soon to be IntelliJ. And also vast integration to other stuff in your CI CD pipelines. From logging systems to version control systems, CI CD systems, while Chekhov is just a CLI.
Starting point is 00:11:35 It doesn't have a UI, does not have collaboration capabilities, and also a lot of the compliance related components are in the platform of the bridge. So as an engineer, you might be required to a business decision of being compliant with CIS benchmark or SOC 2, or if you are a credit card company with stuff like PCI DSS or FedRAMP, if you're doing business with a government agency. So to prevent and less juridical on you as an engineer, BridgeCrew will just fix that code for you and streamline a lot of that process. Interesting. So it basically completes the picture where like check off is like a great first step towards making sure that you have some process that works but bridge crew makes sure that yeah if you allocate a bunch of hosts because you got paged overnight those don't just get left
Starting point is 00:12:30 behind and they're caught by the auditor during like a compliance check or suddenly your cloud bill is extremely high for some reason that's that's super interesting and a lot of what i see on like bridge crew's website and like even on the acquisition page, like the PR page of follow all the networks acquiring BridgeCrew is this idea of shift left. Can you talk a little bit about what is exactly shift left? What does that mean? Definitely.
Starting point is 00:12:56 So it's like software design. If you design your software in a good shape at first place, it costs less to fix issues later on in the development lifecycle. So it's very similar in security. If you have your cloud security infrastructure secured in the first place before provisioning anything, while you're writing code, while you're writing the Terraform manifest or Kubernetes manifest or CloudFormation, you are preventing from so much overhead, not only the issues,
Starting point is 00:13:32 not the misconfigure themselves, but think of all of the people that are involved in touching a production running environment. You have SRE teams, ops teams, stock teams, IT teams, everybody are looking at production. And as an engineer, you don't want all of those people launching over you when you did a small mistake in the cloud. You want the ability to know while you're writing code that you've done a mistake. And you should solve it just like a unit test. So if you solve everything early on,
Starting point is 00:14:03 you get a lot of the headache being solved for you. So I think that the shift left movement started actually with QA. You test things early on, you don't have production bugs. And it's a similar transition happening now in security. If you test things about security early on, you're saving a lot of the issues
Starting point is 00:14:24 that are to come in production. Okay. So the idea is to move security checks earlier in the development workflow. So right now with BridgeCrew, you might get a GitHub PR, like a comment on your GitHub PR saying, you should probably fix this thing. It looks like a security bug, but here you can get this locally when you're testing your change. Definitely. So you can have it in your ID or as pre-commit hook. So it will actually prevent it from arriving even to the PR stage. So if you're working on your workstation, writing code, you get a code edit, or you can get a pre-commit preventing you from committing, you're working on your workstation, writing code, you get a code edit, or you can get a pre-commit preventing you from committing.
Starting point is 00:15:08 You can have a distributed code review process in your CI CD pipeline, whether you're editing your code directly on GitHub or locally on your workstation. And you can have a process of analysis to plan just before provisioning. And also after provisioning, you'll have the cloud monitoring and runtime monitoring that will monitor that there are no drift. Okay. And I just heard that you're releasing
Starting point is 00:15:36 like a VS Code plugin for BridgeCrew. So there's already something that works with Chekhov, but now there's gonna be this end-to-end flow that you get. So with the VS Code plugin, does that mean you're going to get both checkoff and bridge crew working locally or like testing stuff locally? Yes, definitely. So the VS Code plugin is one of the places that you integrate both the open source and the SaaS APIs.
Starting point is 00:16:00 Get the, all the goodies of community policies, which are more than 500 policies by now. And you also get the automated fixes experience very early on while developing using BridgeCrew's APIs that are integrated as part of the VS Code extension. And I'm really excited about that because as an engineer, I just have, I don't need to commit anything to GitHub
Starting point is 00:16:28 and then wait for the entire CI CD pipeline. I get a very fast feedback. It's all about that. GitHub pull request, might take you a few minutes. You have another unit test that are running in the background and you want to get feedback as soon as possible. And in VS Code, it takes seconds. So if I need to say the time to fix in VS Code is seconds,
Starting point is 00:16:50 in CI pipelines, it's minutes because it takes time to run. It takes time. In CI pipeline. And on runtime, that can take hours. Up until you get the DRT kit and you identify who provisioned that resource it just takes time so okay yeah i want to talk a little bit about the traction of checkoff because i assume that you know checkoff was released like some four years ago and that's
Starting point is 00:17:17 how it's gone into its current state of like 500 checks and all that but it's only been like a year i would say january 2020 is when i saw like the release and it was released with like 50 checks and now it has more than 500 checks according to like the readme so when you when you release checkoff like did you expect this kind of community response because I'm assuming most of the checks are actually from the community? Yeah, so most of them are. So, I think the first question is why to open source? Because it could have been a paid product only. And then is how did we build the community around it? Some of it is locked, but some of it is planned. So, the reason to open source it is because DevOps engineers are used to consume products at first as open source products. Think of Airform, Chef, and others. Those are open source
Starting point is 00:18:17 first products. And if your audience is used to do it that way, it's a business decision, honestly, to think, hey, I want to be in the same space, and this is my way to distribute tools. The second is, is there a community play here? And for us, there is an obvious one. There is a lot of best practices, a lot of APIs to secure in the cloud. To assume that we know it all, it's not possible. And we wanted engineers everywhere, security engineers at the best companies that you can think of, helping us to build
Starting point is 00:18:55 those set of best practices. And Chaco is really the framework that enabled us to do so. We know that if we write a policy, it will fail a build in some server of one of those amazing Chekhov customers. And they will tell us, hey, we like that policy, or they will just fix that and submit a pull request. So it became a huge bank, a huge library of best practices contributed by everybody for a vast number of infrastructure as code frameworks. And we really tried to advocate the benefits
Starting point is 00:19:32 of using Chekhov and built in content to as much engineers as possible, because as we have more engineers, the community gets more. And if the community gets higher number of policies and higher quality policies and higher quality analysis engine, everybody are more happy. Yeah.
Starting point is 00:19:56 Yeah. The thing about open source is it's not as easy as it sounds. You just release something and everybody just starts contributing to it. There's multiple aspects. There's both the software design, like your software has to be easy for people to extend and then you have to foster the community so can you talk about the first aspect like how did you design checkoff in a way that it was really easy for like somebody to contribute a new check
Starting point is 00:20:18 yeah so we tried to design checkoff like a testing framework think of j unit or python unit tests we wanted it to be super simple to check a policy of best practice so the first thing that we uh we wanted to do is that policy should be no more than nine lines of code. Which meaning you have to create the writing capitalization in code that it would be super simple for the user to integrate a new policy. So this is where we got most of the contribution. The second thing is we have a lot of analysis engines. We call them runners. One analysis engine for Kubernetes, another one for Terraform,
Starting point is 00:21:09 another one for CloudFormation. Each language, each framework is a little bit different. And we wanted it to be super easy for engineers to contribute another framework, another runner to be analyzed by Chekhov. So we made it relatively simple to inject an engine that will analyze another framework. And the third thing is we wanted it to be super easy
Starting point is 00:21:36 to analyze a provider. So provider can be a cloud provider like AWS, GCP, Azure or Kubernetes and relatively easy to add another provider. So if someone wants to add Alibaba tomorrow morning, which is currently not in check-up, they are super welcome to add that support. We will gladly accept that as a pull request and as a contribution.
Starting point is 00:21:59 So if you have those aspects in mind when you're creating open source tools and you're asking yourself what can the community help me with what can the community help me maintain what can they teach me basically um and you design your software in a way that it will be easy for them to teach you and you're really willing to learn um you get a lot of contribution back. Okay. That's fascinating because I could have predicted that you wanted to make adding checks easy,
Starting point is 00:22:36 but also being able to add those other things like making cloud providers as easy as possible, that's actually a fairly hard design problem, right? You need to think a lot about the encapsulation to make all of those different things easy. You don't have to think of all of those different things easy? You don't have to think of all of it before creating an open source product, but at some point one of our open source users, actually his name is James, told us, hey, I want to contribute a new provider. How can I do that? And we realized that we should make it simple.
Starting point is 00:23:03 If James wants to contribute a provider and wants to monitor his Lino, which is another past service, we need to enable James the ability to contribute that as content for checkout. Luckily he did that. He contributed more than 100 checks. And at some point we asked him if he want to come
Starting point is 00:23:21 and join us as one of our crew members. But it's one of those stories where you don't design the open source to do one thing, but the community will tell you, hey, we wanted to do those things. How can we help? Yeah. So you can start off with a project that makes it really easy to add things like checks so that it provides a lot of value up front and then it shouldn't be too hard to re-architect parts of it so that you can add
Starting point is 00:23:51 things like providers and then you need to foster community members so when james comes and says i want to add linode as a provider you as the maintainer have to be like yeah go for it and then give like fast pull request feedback and make sure or request feedback and give some guidance on this is how you would refactor the whole thing. Yeah. You need to be very accessible. We try to be accessible over email, over our community Slack, in some cases over phone, and to guide contributors what would be the best place to start?
Starting point is 00:24:25 And you also need to maintain a set of GitHub issues. GitHub would be the best framework to start an open source project that is telling the contributors where is the best place to start if they want to contribute code. And the users, where is the best place to start working with that too.
Starting point is 00:24:44 Yeah, so like a common meme in in startups is that people don't care about the quality of your code they just care about the product but in this case checkoff is the product in a sense and therefore the quality and the ease of adding new checks is really key right so you have to care about having good code quality which is which appeals to the builder in me because I don't like it when you just have to try to ship stuff as quickly as possible without caring about code quality.
Starting point is 00:25:10 It's great to have to work on something where both quality of the code base and the end product is useful for people. Yeah, so on open source projects, everybody are seeing your code. So it's a lot of pressure. You can feel naked in some cases because people know how you think. And people know if you put bad code in there.
Starting point is 00:25:35 And some of them will actually do comments and fix your code and make it prettier. But you need to think of, hey, I'm doing an open source project. Everybody will see it. And you need to design your code in that manner. Yeah. And I think if you have a useful project, like 85% or 90% of users will be really thankful when you release something new. But you'll still have like a few open source horror stories is what I think.
Starting point is 00:26:00 Have you dealt with any like issues where a user was just complaining about stuff or like you had to deal with the community in a certain way? Or do you feel like your user base has mostly been super nice? And how do you foster basically a welcoming and an inclusive community? Yeah, two great questions. So let's start with the second. I think we probably answer the first. So you try to be accessible and reachable and have fast feedback as you can. So let's say you have an issue, you try to comment on it as fast as possible.
Starting point is 00:26:37 We even have monitoring in place. Our entire engineering team is getting a Slack message once a new issue is being Oh, wow. Okay. And then someone will jump on it and we'll try to do their best to answer it or give an ETA on when this can be fixed. Or a guidance. It might be a misunderstanding or a documentation fix.
Starting point is 00:26:57 This is one thing of how to support a user. Another thing would be support the contributor. Encourage a user to become a user. Another thing would be support the contributor. Encourage a user to become a contributor and instead of just saying, all right, I'll fix that, you want to scale your engineering efforts maintaining open source projects. So you can fix that, that's one option. Another option would be to guide the user that had opened thatub issue where would be the best place to start and investigate and fix so this is another way to encourage people to participate and once they participate you can have more developer advocacy activities like have joint session let them know what you're
Starting point is 00:27:38 planning about the open source project and let them be part of the decision making of that open source project they will be grateful to make that impact. And impacting, Checkout have more than a million downloads, so impacting tons of users that are using that open source tool. And the third would be summits. Try to expose your tool to as much developers as you can,
Starting point is 00:28:04 at KubeCon, at DevOpsCon, as much summits as possible and try to get feedback of what's working for people and what you should really improve. And if you're really listening to those open source users and helping them and helping yourself to get better, the entire community is getting better and people give you more trust and more credibility.
Starting point is 00:28:27 Okay. So you have these open roadmaps in a sense initially, or you can talk to people like this is what we're planning in the summits that you were talking about. And then you can do some outreach, which is go to conferences to where your users most probably are and tell them, this is something that might be useful for you.
Starting point is 00:28:45 That makes sense. I've certainly learned a lot of stuff from just attending conferences. And I'm really hoping after like COVID and all of these things, we can start going back to conferences a little more. And we've been talking about this term of DevOps a lot, I think in this conversation.
Starting point is 00:29:03 And one thing that I've read more recently about is this concept of like DevSecOps. Can you maybe walk us through a little bit about, you know, first of all, why is DevOps such a really large thing? Like, what do you think it means? Or like, what does DevOps mean to you? What is DevSecOps? Like, where does the security part of that DevOps come in? And how is that different? And what are some trends you're seeing with both of these? So is DevSecOps increasing, DevOps reducing? Your thoughts on this. Yeah.
Starting point is 00:29:34 For me, those are terms that are related to velocity. You just want to move faster. So on classic software design, you moved from waterfall, which is a slow process of developing code and getting feedback on that code and that product to a faster pace where you deliver small chunks of product deliveries and you get feedback very early on or as the process goes. And then the same transition happened to IOT instead of doing data center planning and doing networking changes that are very slow, you split it into chunks because the API movement
Starting point is 00:30:16 enabled that. And you can get very fast feedback on those chunks. Those can be builds, pipelines that are starting to give faster feedback, those can be infrastructure changes that you can get very fast feedback early on, and even containers where you democratize the usage of provisioning images to developers. So you have those in place, you have good practices over DevOps, and it's all about you can move faster now. And security is another transition. Dev stack ops mean we want,
Starting point is 00:30:50 like the IT team have a movement change. You want to have the same technology in security teams that are up until that point can be slow moving at a lot of slow processes and slow iterations to a smaller chance of iterations and faster feedback loop so it's all about now integrating security into the early on into the development cycle into ids like vs code into cicd pipelines like github actions through cim jenkins and into continuous production monitoring both into CI CD pipelines, like GitHub actions, CircleCI and join things, and into continuous production monitoring.
Starting point is 00:31:34 What do you think the future of security will be? Is it that most of it will get abstracted by things like tools like Chekhov? And will tech companies need a dedicated security team? And what is the role of that security team in this new world? Yeah, I think that a lot of the security market can be simplified and it's the process of being simplified. It can be simplified by that. If you shift a lot of the knowledge back to engineers, you just push it into their
Starting point is 00:32:03 CIC CD pipeline. So a lot of the obvious stuff or the basics can be solved very early on. And more advanced use cases, there is still place for security advocates and practitioners to come in, educate people about complex processes, to examine a system as a whole. And after all the basics are being cleaned up by the engineering team, there is a very good place for expertise in pen testing, cloud security analysis that is harder to do today
Starting point is 00:32:37 in CI-CD pilots. So threat modeling is a concept that is there to stay. Some of it can be automated, but a lot of the rationale is still, it comes with a lot of human thinking and experience. Okay. Yeah. So that makes me think that there's going to be tools like BridgeCrew on the infrastructure side, helping with automating a lot of the security bread and butter. And even on the front end side, like I can think of you know checking that you have csrf checking that you have cores and all of that there could be another set of tools or maybe bridge crew can encapsulate that at some point making sure that you're following like the front end like best practices and then those covered the basic cases
Starting point is 00:33:19 and then you have maybe some kind of like consultants who come in or like as or experts who come in and say, you know what, we actually need to focus on this particular part of your stack because that's the most vulnerable. And instead of having a large security team that's reviewing every infrastructure change, you have something just like experts attacking or thinking about certain parts of the stack. That's what it sounds like. Yeah, so it's definitely the direction.
Starting point is 00:33:49 And I'm also thinking that, so think of QA as being distributed into teams. You have QA engineers, testing engineers embedded in a lot of the squads and teams. The same transition is happening now for securities because it's all right that you have rich in your CI CD pipeline, but you still need to advocate security to your engineering team and educate them on what would be the best practice.
Starting point is 00:34:16 And there might be new challenges for automation that you cannot solve using tools and you have a place to configure them to tweak them and to have additional set of tools on top of them to automate as much as as possible of your team needs and to have as much as possible of your security process streamlined into developing life cycle so it's a continuous work it's like you have a devops engineer that is always making cloud provisioning better and better. You need a security architect or DevSecOps engineer to make your provisioning more productive and more secure over time. Yeah, that makes sense. And I think that seems like the future of how things are going for sure. Maybe like a last question here is,
Starting point is 00:35:05 what advice do you have for, you know, potential entrepreneurs or potential founders in of like DevOps companies? I think there's a lot of different kinds of companies or tech companies that people can create, but DevOps is like a special beast that has its own set of challenges, right? Like, as you mentioned earlier,
Starting point is 00:35:23 like first having an open source tool, because that's a funnel that can be used to sell like a larger product that can provide more value. Like what other advice do you have or like some guidance for potential entrepreneurs? Or just something interesting you've learned on the way. Yeah, so you need to be a good listener. Before writing the real first line of code in our product,
Starting point is 00:35:47 I think that we've interviewed something like 120 or 180 practitioners in the DevOps and security spaces. And we just ask them, hey, what issues do you have today? How do you solve them? And what you've learned over the years? Those are the only three questions. And we haven't suggested anything. We just absorbed.
Starting point is 00:36:09 And we learned that a lot of cool companies are public about what they're doing in cloud security. Netflix is an amazing blog about it. Salesforce is an amazing set of open source tools. And we reached out to those people and asked them to teach us. And they were really happy about it. They are community members. They want to create new open source tool.
Starting point is 00:36:28 And we asked them how they automate and solve some of those issues from what they could tell at that point. And they just told us what's broken in the process. And we decided to go into that process and automate as more and more pieces along the way. So if you're a good listener to community members, you can then generate a community of customers that is helping you to create a better and better product and just listen to feedback, absorb it and make the product better. And the second thing is have very fast iterations we are doing between one to
Starting point is 00:37:08 nine deployments to our production environment a day to keep up with the place um and it gives us great agility and it gives us a very good way to handle scale and customer requirements um and that's the first thing that we made sure that we have in place, an ability to run fast. And those are my two advices to you. Yeah, that makes a lot of sense. So you had this hunch of, you know, that cloud security needs something different, but you didn't just start writing code. You spoke to a lot of people, refined your ideas, and that's how you started. And at the same time, you're following best practices and you're releasing
Starting point is 00:37:46 as quickly as possible and just iterating as quickly as possible to provide that value as quickly as possible to your end customers. Cool. That makes a lot of sense.
Starting point is 00:37:57 Awesome. Yeah. Thanks for being a guest. I think this was a great conversation. Yeah, it was super fun. Thank you. Thank you for having me. And I know it's pretty late there, so have a good night. And I super fun thank you thank you for having me and i know it's pretty
Starting point is 00:38:06 late there so have a good night and i hope to see you

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.