Shauli Rozen:
This is something that developers do not want to be wasting time on. They don't like to think about policies, about regulations. They hear the word compliance, they get the chills. They care about security, they just look at it as an engineering problem.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open-source projects and the communities that make them. I'm Eric Anderson. I'm joined today by Shauli Rozen, who's the creator or one of the creators of Kubescape. Shauli, thanks for coming on the show.

Shauli Rozen:
Thank you for having me.

Eric Anderson:
And you've had quite a couple months here. Kubescape has kind of come out of nowhere to be a big project.

Shauli Rozen:
Definitely. You know, we were aiming for success and we were sure it's going to be successful, but you never know how much successful it's going to be, until after the fact. So, it's great to be in this place.

Eric Anderson:
Yeah. Congratulations. Maybe before we go on, tell us what Kubescape is, for the uninitiated.

Shauli Rozen:
For sure. Kubescape is basically your tune to assure that your Kubernetes deployments and clusters are configured and are deployed in a way that is secured. And you know, there are so many things you need to test and check for that what we found is that many of the people, what they really are struggling with is what checks should we do. And the approach that we took to that problem is reused frameworks that are acceptable and that are actually published by governance bodies. And specifically the most popular one that we are using is the NSA and the CISA guidance program and it is hardening, which we found to be very practical. We know many of the guidance and the governance bodies use things that are more of check the box type stuff, but we felt that there was quite a bit of thought actually in that specific framework. And we of course, took it to the next level and thought about, what does it really mean for me as a Kubernetes operator and implemented that. And I think that what made a lot of sense to many of our users.

Eric Anderson:
Totally. Yes. And I imagine there's a couple ways to accomplish this. I imagine some people do this manually during code review, having experts kind of scan with their eyes for typical problems.

Shauli Rozen:
Yeah. I think there are different approaches and many of the companies will have some kind of guidance and some kind of rules that developers should follow, but it is usually very complicated to manage and more that to enforce.

Eric Anderson:
Totally. And so Kubescape scans at code submission for these types of issues and then maybe breaks, builds, or just alerts users to the problems.

Shauli Rozen:
Exactly. One of the things that we made a decision on, as we went into the project, is that we want to enable our users to use it in many different ways. So, we made it flexible. You can run Kubescape against the running cluster. You can run it against your IaC, Infrastructure as Code, your hand charts, or your Yammers. And you can decide whether you want to build according to that, whether you want to fail the build or not, when maybe you just want to get an alert. The good thing about our audience is that they're developers. These are not like users who don't know what they're doing. These are guys that like to get their hands dirty. They like to take the tool and make the most out of it. We also see that in the responses and in the contributions that we get, and that is super helpful, and the flexibility of the tool is super helpful.

Eric Anderson:
Yeah. That's quite accommodating. Now that we kind of understand Kubescape a bit, maybe take us to how you got here. Tell us your story.

Shauli Rozen:
Well, we found ARMO I think almost two years ago, with the aim of being the go-to company for Kubernetes security. And as we started the company and we interviewed many CESAs and many security architects, and we kind of like started to get engaged with the community or with the industry, I would say, it wasn't a community back then, we realized quite quickly that there's going to be a huge shift or there's already a huge shift in how security is being implemented. And also the decision making around security. We saw CESAs were struggling. You tell them, we would like to do many security. They know that they have Kubernetes in their organizations. They don't know what's going on either. And they would bring the developers straight to the first or second call and say, you need to speak with our dev engineers with our DevOps.

Shauli Rozen:
So, we said this is shifting and we need to give these guys the tools. And that's kind of like how we came up with thinking about a tool that will actually be very easy to use by developers and will fit transparently into their existing processes and the existing CI/CD pipelines, and will not create overhead for them. And that's kind of like how we came up with Kubescape. We talked about what type of tests are you going to do. This is something that developers do not want to be wasting time on. They don't like to think about policies about regulations. They hear the word compliance, they get the chills, right? And for a good reason, compliance has a very bad reputation for being just check the box type of thing. You know, one of the things that I believe is a super misconception is that developers don't care about security.

Shauli Rozen:
This is in my mind, super wrong. They care about security. They just look at it as an engineering problem. They don't want to think about policies and enforcements and rules and reports and check the box and tell the board, what is my risk level. This is just not the type of people that are going to be in charge of your security. And I think it's a good thing. I think it's an engineering problem and you need to address it as far as you can with engineering and after that it's response and see and CESAs, and those type of things.

Eric Anderson:
Got it. So you had all this experience working with security teams, learned that they were always turning to developers, and then set out to solve a developer security problem.

Shauli Rozen:
Yes, that is exactly that. And we spent so much time with developers because what happened is we sold to security, but we walked with developers. That's part of the paradigm shift that we've seen. Yeah, we got the budget from the CESA, from the security architect and then the project starts and okay, this is my development team, work with them on implementing it, and it's a very different, I would say, experience working with developers, because it's much more practical, let's get things done type of environment, right. Instead of asking questions, like how do I do this? How do you do that? Can you give me process? What's the documentation? They say, it's a [inaudible 00:07:06] or it's a, [inaudible 00:07:07]. Okay, get me a [inaudible 00:07:08]. I know what to do with it. It's that type of behavior that we get from developers. And that's what we love about it, because it's, maybe it's, I don't know, maybe it's because I'm Israeli, I'm very straight forward, kind of like let's get things done type of guy. And those developers guys are also like that.

Eric Anderson:
Yeah. Fantastic. So, you kind of knew you needed a developer tool, you understood, you needed the... To create it in a shape, which they already understood and knew how to use, but kind of, how did you arrive at Kubescape and maybe what's day one at building Kubescape like? That's you at the keyboard, or?

Shauli Rozen:
I consider myself a technical guy, but it's been a while since I've been at the keyboard, other than Excel and PowerPoint. So, I've been fortunate enough to have two co-founders who are PhD level smart. And these are the guys on the keyboard. We have an amazing team that has been very very, I would say, aggressive on the need and their requirements to do Kubescape. And how did you decide on Kubescape is, basically we started at the beginning. We thought about, we want to be an end-to-end security company and like end-to-end, where is one end and where is the other end? And we need to put a stop to what we start.

Shauli Rozen:
And very honestly, we decided that we are not going to start at the code level. We're not going to start that type of things, even though they can be very developer oriented, we decided to start, that was a business decision from the development deployment type. So, when the image is already built and now we're doing configurations, we're doing deployment, we're doing Runtime. We wanted to start there and we still have the target to starting with Kubescape and growing it to the far end of Kubernetes and solving your, if you have a Kubernetes cluster Kubescape is going to be there for you. That's the idea.

Eric Anderson:
Fantastic. And how did you kind of verify you were building the right thing? Do you test it with users along the way, or, I mean, you turn this around quickly enough that maybe the launch was kind of the first test.

Shauli Rozen:
Well, the launch was the first test of the technology, but not the concept. We've been working with customers on different Kubernetes security initiatives. And we've seen one thing coming again and again, is the requirements for those users, which is the basics. And that's actually how they call it. Say, can you give us the basics? Can you just give me the basic understanding that my configuration is okay, that I don't have vulnerabilities? And then, then I would like to go to the next step and to the next step. And that was kind of a common denominator of pretty much everyone we speak with that's where they want to start. And that's why we went that way.

Eric Anderson:
Now, there, there are other kind of Kubernetes scanners, if you want to call them that, that help with Kubernetes hardening. Were folks not satisfied with these, and what made you feel like you could kind of improve upon the situation?

Shauli Rozen:
I think there are a few things that were missing and that our users, and this is something which is after the fact, okay, which I get the feedback from our users are very pleased of. And the first thing is that the time to value of Kubescape is very, very quick. And the requirements from you are very, very low. So, you don't need to install it in your cluster. You don't need to give it very high permissions. You know, we are very proud of the fact that if you got into our Kubescape GitHub project page, two minutes later, as long as you have a cluster, you can have the results in the output. And I don't remember where I read it, but this is a rule that I put for Kubescape, from day one, is that you need to give value to your customers in the first five minutes that they experience your tool.

Shauli Rozen:
And I think the focus in that made it very, very successful, but that's honestly just a part of it. The second part is really the structure of the solution and the structure of the results, structuring it around common frameworks, known frameworks that you can actually trust and actually put meaning into that framework, because many times a framework will give you a headline of what you need to check. But what does that mean? How does that translate to an actual check of configuration? And we put a lot of thought into that, and I think that's another part of the things that users love about Kubescape.

Eric Anderson:
Awesome. That's great. Tell us a bit about the launch. You developed this thing over a number of weeks.

Shauli Rozen:
Yes. We actually timed the launch basically to the NSA guidelines, the publishment. And I think that was the key part of the initial success. And then we basically built on that.

Eric Anderson:
Did you work with the NSA, then? I mean, you were familiar with the guidelines during development?

Shauli Rozen:
Yeah. We were familiar with the guidelines. I can't say that we were working with the NSA. Okay. It's not that they were collaborating with us, but we know that it is coming and we knew more or less that was going to be in there. And honestly, we've been working on many other different frameworks ahead of time. So, we have the [inaudible 00:12:10] framework already set up. We have CIS already set up and we decided not to launch it. We decided to actually launch the NSA one as the first framework. Exactly because of that. Exactly in order to be very, very timely. And that was one of the decision.

Shauli Rozen:
And by the way, I have to say till today, this is one of, I think the most important things about security tools and opensource tools is to be very, very up to date and very, very responsive. So, whenever we learn about the new configuration, like two weeks ago, there was a new CV found in the NGINX that could be mitigated with the right [inaudible 00:12:46] configuration. So, the day that it was published, we already actually added another test that checks your cluster, if you are basically exposed to that or, is your configuration okay. And that's, I think, a big part of... That's the good things about being part of the community, because we learned about that CV from the community. They told us, do you check this? And then just a matter of having a very, very [inaudible 00:13:14] resolve time.

Eric Anderson:
What a fantastic open source project, that users can post issues and you turn them around in 24 hours.

Shauli Rozen:
Well, we are, I have to say, fanatic about being on top of the GitHub. We opened this culture, we are just starting that. Well, you're there, so you know. But we are just now ramping that up and we hope to get that and we will have someone monitoring that 24/7. And yeah, we expect listening to the community to be probably the most important thing in this road that we're taking.

Eric Anderson:
Got it. And so you launched with NSA, you had these other frameworks mostly ready to go. And then do you push them out with their own PR on individual launches, thereafter?

Shauli Rozen:
Yes. We basically issued the [inaudible 00:13:58] about two weeks after that. And we're going to issue DevOps best practices in the next couple of weeks. Yeah. And it's not, you say with a different PR you know, I don't think it's about PR, it's about really motivating the functionality and we are going to have a lot of functionality, not just frameworks to Kubescape. We have a lot of things that actually we've been thinking about it for a while, so we have a lot of things ready and it's about introducing it to the market and to the users in the right pace.

Shauli Rozen:
And also before we launch something, we want to get some feedback from the users of their priorities and what they would like. So, for example, one of the things that we get a lot of question around is role based access control and identifying excessive privileges. Again, something that we had in our roadmap and had in our plan, so it's going to be issued in two weeks. We're going to issue, RBAC-related tests in Kubernetes, in Kubescape, I'm sorry. And also what I believe to be a very sophisticated graph of connections between the halls, the capabilities, the resources, so the verbs. Yeah. So, I think there's a lot of things you can do. And the fact that we do it with the community is a big driver for us in terms of prioritizing what to do first.

Eric Anderson:
Got it. And where does this user feedback come... The discord is new.

Shauli Rozen:
Yes.

Eric Anderson:
So most of this is over GitHub that folks are reaching out to you and that's where all the action is.

Shauli Rozen:
So, GitHub is a major source of input for us. We have great users. I think we have over, I don't want to say the number, but probably like a hundred different PRs open that, that we are working on. We actually are not shy about approaching users directly and asking them. So, we see activity, we post things, we ask people about what they would like. There is an option to register, to solve our capabilities. And we send emails and, I get like five emails a day from users who are either telling us good things about Kubescapes, some will tell us problems, bugs that they found out about Kubescape. And as I said, we are fanatic about that. I write it in the email, right? We're not sending any automated email. I look at any email that anyone replies to me, I read all of them. They're all very important to me personally, and as a company and that's kind of like the way we decided that we're going to go about it. And I think it will pay off listening to every user.

Eric Anderson:
And how do you characterize the people that you're hearing from? I mean, I know they're developers and they're security-minded. Early in DevOps, we kind of said everyone's going to be doing dev and ops. And it kind of turned out that there was a DevOps team and then a lot of developers. Are these generalist developers or are these kind of a special breed of kind of security minded folks that end up engaging with you early?

Shauli Rozen:
Well, I would say that if you just look a titles, for example, like in GitHub engagement and those types of things, I would say that about 60%, maybe 70%, are DevOps engineers or DevOps leaders. And I assume that they are security minded just because they are speaking with us, but I do believe that many of them are actually security minded. There are about 10 to 15% who are various like, securities in their title type of people, security architects, security engineers, DevSecOps. And then there is about 10 to 15, another 10 to 15, which are, developers trying out like core developers, not DevOps. Honestly, I think this, this is, what I would expect in terms of like the distribution of users for our tool. And I expect DevOps to be the main focal point using our tool.

Eric Anderson:
So, I should've mentioned this at the beginning to kind of characterize what I meant when I said the project's going really well, but if GitHub stars is any measure, in the maybe six, eight weeks since you've launched, I forget the timing, you've got four and a half thousand GitHub stars, which is as many as any of the kind of other Kubernetes hardening tools out there that, many have been are around for a year or two. It's really quite an explosion. And maybe I'll go on to say this idea of kind of scanning your infrastructure producing scripts is a big trend. Folks are doing this, not only for Kubernetes, but also for Terraform and other infrastructures code solutions. And so maybe this is an area people expect to see tools now.

Shauli Rozen:
Yes. I think people are, are looking for those type of tools. I think Kubernetes specifically has made... Everybody was already convinced about Kubernetes, basically taking over the world in terms of orchestration about two years ago, but that was talk and now it's action. Now, every company you go to is going there. And I think that's why now you see this bump in actually people and DevOps looking for tools to kind of like take control of the clusters. Everybody knows Kubernetes is a monster, right? You know, no one, there will be, most of people will devote it as too complicated, right. Nobody will say it's too simple and everybody knows it. And I think they are looking for it. They know that it's probably vulnerable and they know that the human element and the configuration element is a big part of it, but they also know that they are going to need to go forward and I think that's what they're looking for, something that will actually solve in the problem might now, but also be able to work with them going forward.

Eric Anderson:
Shauli, we don't often get the chance to talk to somebody so early in the motion of, to kind of developing a community. And maybe you can tell us a little bit how you think about that. Some of our listeners are building open-source projects of their own, or they've heard many episodes about building a community. Now that you've got attention, you've got magic in a bottle, people are excited about what you're offering. How do you kind of harness that energy in a way that's productive for the community? What do you think about in terms of staffing, tooling? What are the next steps for you?

Shauli Rozen:
Well, as you said, I can talk about the early days and I can tell you what we are planning ahead. First of all, I would say to everybody building a community, it's a full-time job. It doesn't build itself, okay. The start, like you do need to get some indications that there is interest and that people want to be part of the community, but once you have that interest, I think it is a full-time job. You need to invest in it. That's the first thing I would tell anyone going into that area. The second thing is about being really, really, it's like a religion. You need to be very, very minded and commit to actually engaging with the community. And you need people who love it, who would like to engage with the community. And honestly not everybody's like that. You know, many of the developers, even in my company, some of the developers in my company, it's not what they like to do, build GitHub and on this code and the chatting and communicating and doing that.

Shauli Rozen:
But I think the people who are developers and also like to do that, they are rare, but they are the secret sauce of every company. And I was blessed, we are David and we have Ben, and we have people who are... They get energized themselves by being part of the community, by driving the community. And I think that's a super important part that you should have in the DNA of your company. Now, going forward, I need David to write code. So, we will bring a main community manager. We will bring the right people to do that. But you know, the fact that you have people in your company who are devoted. The fact that I, I like to get those emails and answer them and to be on Git, you know. I'm on Git myself all the time. I mean, how can you... You need to love it. That's what I'm saying. You need to want to do it. That's the first thing.

Eric Anderson:
Got it. And then at the same time, you also have a business to run and you'll be expanding both the open-source offering, as well of your commercial offerings. You've done some thinking about kind of the interplay between what's in the open and what is a product people can buy. Any thoughts you want to share along those lines?

Shauli Rozen:
Yes. The way we look at it and the way we expect it to develop is that the premium product or the paid product and the functionality that we give there will be a direct extension of Kubescape. And this is my personal belief that you do not want to... When you do that conversion into your business, you don't want to have your customers change the product that they're using. You want them to be able to use the same product. I think, as I said before with the five minutes and the simplicity, I think keeping it simple, keeping it, making sense to your customers and to your users, that's the first priority. And if you do that, they will move, of course, if they see value. And that's what we're aiming to do, we want to add value within the same experience of Kubescape. We want to make it easy for users to come to Kubescape and join us for our enterprise version.

Shauli Rozen:
And that's what we're building. And honestly, we are not very impatient to do that. We are taking our time because we want to see what our users are doing. We want to understand where they see more value. Many of the things that in the future will be premium will be free forever for the first users that join us now and give us feedback. You know, we have about, well, I don't want to say the numbers, but we have several users that we actually started to engage with on a biweekly basis. We have a biweekly call with them. We share with them our roadmap, they share with us what they would like. And we work with them in order to develop what they need. And in the future, I hope someone will pay for what they are now getting for free.

Eric Anderson:
Good. You said something at the beginning that I wanted to come back to real quick as we wrap up here. And that is that I think some people assume that the reason we're doing more DevSecOps is because people can grow faster, move faster if they target developers in a kind of a bottoms up motion. But I think you're also pointing out that even the traditional kind of top down sales motion is difficult in the world of DevOps because all the security leaders need buy-in from their engineering leaders and users. And you're kind of saying, it's almost a necessity now, that to kind of sell security, you need to come through the developer channel if you will.

Shauli Rozen:
Yeah, you know, I don't want to be like devil's advocate here, but what I think is that developers are not stakeholders. They are buyers. You need to treat them as the buyers. And when I say developers, it's a bigger umbrella. It can be the VP engineering, it can be the CTO, but we see budgets going into engineering, at least for security of the production environment.

Shauli Rozen:
Okay. I say to many people who come to me and say, I think the CSO world is going to split into two, there's going to be the, IT CSO, the legacy IT CSO, email security, policies, data policies, and it's going to be, I don't think it's going to be called a CSO. It's probably going to be the security architect. It's going to be [inaudible 00:25:20] to the CTO or the VP engineering. And they will decide on how to take the production environment. And actually, I think it's a better way to do it because it's a very engineering oriented environment. And that's the way I see it. So, if you ask me, it's not stakeholders there, if not this year, maybe next year, they will be the buyers. That's the organization that will have the budget.

Eric Anderson:
And understanding the new CSO, or at least the kind of the bifurcated CSO environment, that we'll have a kind of the traditional CSO that is kind of the CIO, the security of the CIO and the security of the TPO.

Shauli Rozen:
Definitely, and you know how the CSO of the CTO looks like? He is a 25 or 30 year old. He has a hipster beard. He's very, very, very smart and very, very practical, but you know, he doesn't close deals on the golf course.

Eric Anderson:
Right. Awesome. Thank you, Shauli. It's great to hear the story of Kubescape and good luck with all the work you've got to in front of you.

Shauli Rozen:
Thank you. It's a lot of work and thank you for having me.

Eric Anderson:
You can find today's show notes and past episodes at contributor.fyi until next time I'm Eric Anderson and this has been Contributor.