Today’s engineering teams want to develop and deploy as fast as they can. The velocity of these teams is growing at a rapid pace. The challenge that they face is that they end up managing everything in the service — all the way from writing the service, building, deploying, testing and ensuring it runs smoothly. However, what’s not under their control is ‘securing’ the service. It falls under the ‘ownership’ of security teams. That’s where the friction starts. It slows engineering teams down. David Melamed, Co-Founder and CTO of Jit, believes that if we can move the ownership of security to engineering teams, they can maintain their velocity and have a much better experience.

However, that leads to a multitude of challenges: First of all, engineering teams are not knowledge experts and the talent is rare in terms of knowing exactly what needs to be done for security.

The second is that they also need help with the exponential number of tools and technologies out there. So they don’t know exactly what tools they need to use and how to configure them, making sure they work. There is a major gap in terms of orchestration of those tools.

And finally, most of the current processes and workflows in security are currently manual. A lot of things are still living in textbooks, in documents online, as well as in spreadsheets. And this is something that developers are not really their natural language. They prefer code. And the fact that things are not qualified yet, it actually adds a lot of complexity to that. So, if you add all these different challenges, you can think that there is a lot of work to do there, in order to help those engineering teams to secure their service.

That’s where Jit comes to the rescue with its ‘minimum viable security’ approach. In other words, it helps developers get started with security with what’s needed at minimum and then scale gradually.

“That’s one of the major things that we want to provide: built-in security plans, where you can have a list of all the things that you should start right now,” says Melamed. ”What are the tools that need to be implemented in order to meet these requirements that this plan is listing? Also, what are the things that you want in the roadmap? Once you have this whole frame and you know exactly all the areas that you want to tackle, viz. the code, the pipeline, third-party services, processes, and operations, then you’ll be in a much better place.”

Jit just came out of stealth with its ‘minimum viable security’ approach and $38.2 million in seed funding. And we sat down with Melamed to not only learn about how they are going to help engineers by making ‘security’ easy, but also what their long-term plans are. Check out my discussion with him in the video above.

Connect with David Melamed (LinkedIn, Twitter)

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to another episode of TFiR Let’s Talk and today we have with us David Melamed, co-founder and CTO of Jit. David, it’s great to have you on the show.

David Melamed: It’s great to be here. Thanks for inviting me.

Swapnil Bhartiya: It’s my pleasure to have you here on the show. And this is the first time we are talking to each other. So, I want to understand some basics, which means since you are a co-founder of the company, tell me what problem you saw in those space? Which you wanted to solve. And the problem was so big that you were like, you know what? Let’s just start a company to address that.

David Melamed: Great. It’s a great first question. So, let’s start there. Basically today, there’s a lot of the current trends that are helping engineering teams to develop and deploy faster and faster. So the velocity of these teams is really growing, but they’re managing everything in the service, from writing the service, building the service, deploying the service, testing the service afterwards, what are not really the owners have is securing the service. And for that you have security teams. The problem is that those security teams are currently outnumbered. And because the ownership of security is not currently held in the engineering teams, there’s a lot of frictions there. And this is a major pain point because security is currently slowing down development. And so what we believe is that if ownership could migrate it to the engineering teams, then they should be able to deploy faster and having a way better experience.

Now, in order to do that, there is a few challenges. First of all, engineering teams are not knowledge experts and the talent is rare in terms of knowing exactly what needs to be done for security. It’s not something that is trivial and there’s a lot of experience needed there. The second is that they need also help with the exponential number of tools and technologies out there. So they don’t know exactly what tools they needs to use and how to configure them, making sure they works. There is a major gap in terms of orchestration of those tools.

And finally, most of the current processes and workflows in security are currently manual. A lot of things are still living in textbooks, in documents online, in spreadsheets. And this is something that developer is not really their natural language. They prefer code. And the fact that things are not qualified yet, it’s actually adds a lot of complexity to that. So, if you add all these different challenges, you can think that there is a lot of work to do there, in order to help those engineering teams to secure their service.

Swapnil Bhartiya: Yeah. First of all, thanks for explaining the problem area in detail. Now, a lot of things that you mentioned there is also what we are seeing already in this space. If you look at the whole DevOps movement, shift left movement, the things are moving more and more toward depths. But as much as there is a lot of awareness about it, when I was listening to you, I felt that yes, people do talk about security a lot, but it is still not reaching in practice. There is still a lot of friction areas. So from your perspective, what are the areas that you have seen? Which are, is this culture? Does it companies, they still have the same mindset? Whether it is availability or the tools, whether it’s also about the shortage of talent, the skill set, who know about technology and also the whole new approach that security’s everybody’s problem, which also means it’s nobody’s problem.

David Melamed: Yeah, exactly. I think that’s the awareness is starting to rise. And as you said, there’s this domain that’s called DevSecOps, which tries to combine both words like security and developers. But the problem is that there’s still a lot of tools. And even if they have some knowledge, they need to learn each tool by itself. They need to do a lot of research to know exactly, how do they need to use this tool, how to configure it, how to make sure you remove the noise. And beside that, I think that there is a major problem today because in the security field, most of the companies, and even all the DevSecOps, they’re only talking about tools, but they’re not talking about the big picture. And the big picture is what we’re calling a security plan. So instead of dealing with the tools themself, what you really should take care of, is actually having a plan. Manage your whole security debt, have a list of all the things that you need to do now and in the future.

And that’s one of the major thing that we want to provide, built-in security plans, where you can have a list of all the things that you should start right now. And what are the tools that needs to be implemented in order to meet these requirements that this plan is listing and also the things that you want in the roadmap. So once you have this whole frame, once you know exactly all the areas that you want to tackle and the areas can be in the code, in the pipeline, in third party services, in processes, operations. Once you have the big picture and you know how you will implement all these different areas, then you’ll be in much better place.

Swapnil Bhartiya: You talked about security debt, I can understand. First of all, I would love to hear your definition. How would you define security debt? We can also, when we look at companies who have been around for a while, they did not invest in security, they were using supply that I understand, but when there are new companies, sometimes they start and security become the, Hey, it’s not an afterthought. So how would you define security debt? And how is different in…? Let’s say the companies who have been around for a while versus later with new companies.

David Melamed: That’s a fantastic question because basically as soon as you open your company and as soon as you run your first line of code, you already have security debt, if you didn’t think about it upfront. The way I would define security debt is basically all the things that you didn’t put in place in terms of security controls, in your code, in your pipeline, in your runtime, in all the different areas, that are part of your product security. So everything that you didn’t manage or is actually your security debt. And I’m not talking about only the vulnerabilities that you may have in your code. I’m talking about your security planning as one, right? All the things that you need to monitor, the list of all these requirements, that is something that you need to take care of. And it’s interesting that you’re mentioning, started that is just opening its store. Because what we believe is that security is not about maximizing the number of measures.

Actually, especially for startup. And especially if we’re targeting engineering organizations, they should start small. And we’re calling that the minimum viable security. So what is the minimum viable security? And basically why do we pronounce in the same sentence, minimum and security? Usually it’s the opposite, right? You want to maximize security, that’s because, well, you cannot boil the ocean at once, you cannot do everything at the same time. What you want to do basically is the same thing, the same principles that engineers are applying for years already, which is agile methods. And what they’re doing is that they’re starting with something that is very small. They’re building first the MVP. Right? So you have the MVP and then you are iteratively adding more and more feature to your product. In the same way, you should start with your minimal controls, the critical controls that without them, you cannot actually release any product. So you have your MVP, it should have the minimum control, the MVS, and then gradually you’re getting more mature in terms of security. And at the same time, you’re also adding more feature to your products.

Swapnil Bhartiya: Excellent. Now we do have shared such a great kind of insight there, and there are so many things to interrupt there, but if you just look at all these aspect, whether you talk about security debt, whether you talk about cultural aspect, talent shortage, having a concrete plan for security to start with, where does Jit enter the picture? Although which aspect of this problem do you deal with just the technology aspect? Or it’s like taking a holistic approach because security is not a product, it’s a process. So, talk about what approach you are taking to help with some of these problem areas.

David Melamed: Yes. First of all, in terms of vision, we believe that there should be a world in the future, where every software project should start with the first line. The first line of code should be include MVS or something like that, right? So that you can instantly achieve continuous security from day one and then improve all the time while you’re developing your project. What Jit can do for you, is basically the first thing is to provide this security plan, this built-in security plan as code, because you want to be able to extend them. You want to be able to customize them to your needs, tailor them to your security stack. And then we’re orchestrating all these security tools. So you have the plan. The plan is a list of those security requirements. And for each requirement you have a different tools.

So, what we are providing is not only the plan, but the automation of the plan, the automation of the implementation of the plan, the monitoring of the plan. Meaning that for each requirement, you have the tool that we’re orchestrating. So for example, in the code layer, if you don’t have a secret scanner, we provide you with a secret scanner, that is automatically integrated in your CI/CD pipeline. And will actually manage the whole life cycle of defining the requirement, orchestrating the tool, making sure it runs, making sure that it’s monitoring all these different repos and dealing with your security posture.

So everything about your vulnerabilities, how you can fix them. And at the end, ultimately what you want, is to reduce your risk. So we’re helping with all these different stages. And we have a very holistic way of seeing security, security as a whole. So you have this big plan, this big picture where we want to be able to help you both with orchestrating those tools, these technological tools, but also human processes. For example, we’re planning also to help you with offboarding process, which is a very important thing you need to do when someone leave the company, because it’s a security risk. But here again, we want to be able to do that as code.

Swapnil Bhartiya: If somebody’s leaving the company, that could be a security problem. You also talk about technical debt. One more thing, a couple of things that we talk about also not just the security debt, but there is technical debt. There is also tribal knowledge, in terms of security, if the security team is looking at the problem and the folks move, they take that knowledge with them, which can also leave you vulnerable. So how do you look at that problem and how does Jit kind of helps companies address or at least tackle that?

David Melamed: I think that’s one of your beauty of having these security plans code, basically because it’s stored in a Git repository, the documentation of everything that is done in terms of security in a company. And it’s visible to everyone who has access to this repository, it’s audited, so every time something changes in the plan, everyone can see it basically. And you can also verify that everything works. So you have a dynamic way of verifying that you have continuous security here. So everything together, both the documentation as code, the fact that you can extend it, the fact that you can audit it, and the fact that it’s visible by everyone makes a great solution and a way to solve the problem of security team, with the knowledge that can be hard to track, or that can be dispersed in the company, or someone leaves the company and then you’re out of luck because you don’t know what has been done or what needs to be done.

Swapnil Bhartiya: When we talk about security, we talk about kind of reduce all the risk, security should be at max. So, talk a bit about your approach there.

David Melamed: Actually I’ll give you an example, that I like to use in order to explain what minimum viable security is. You remember the movie, Home Alone, right? With Kevin. So in this movie, basically his family is leaving on vacation and he’s alone in the house. Now he has, I don’t know, a few hours to come up with a plan in order to secure his house against the burglars. And he doesn’t have either time to hire security guards, or to install fancy security. He only has time to come up with the minimal things that he can do in order to limit the entry of the burglars. That’s basically minimum viable security. He does a minimum set of things, of controls that he starts with the parameter of the house in order to prevent them from entering.

Now, at some point they manage to enter. But again, like in security, the challenge is not whether or not someone will attack you. It’s when and how, and will you be quick enough to be able to investigate and remediate the entry? That’s the same thing with minimum viable security. By the way, it’s a journey. So you start with something that is minimum, and then you add on top of it all the time. Like when you are developing a software, you’ll start with something minimal, you add some tests and then all the time you add a new feature, you’re checking, your sanity test, making sure that what you already have is still working, and then you add on top of that. In security is the same thing. You start with a few sets of tools and processes, make sure that they’re running correctly, and then you add on top of it. And that’s basically continuous security. It’s a continuous journey. It’s a continuous loop that is running all the time, basically. And with that, you’ll have a more mature, your maturity will actually rise all the time.

Swapnil Bhartiya: And that’s where Jit helps folks in their journey, right? To start with the minimum tools and then grow as they need is not, they’re not on their own, is that correct?

David Melamed: Yes, exactly. We’re starting with something minimal, but we’re not leaving you there. We actually guiding you throughout your whole journey because there are all the time new stuff that you can add. Your journey is, it’s a never ending journey. You can start with something minimal. At some point you may get to some compliance century plans also, some very advanced security plans. So we’ll here or there with you all the time.

Swapnil Bhartiya: In terms of security, there are a couple of things that we used, some words and terms they tend to get confusing. One is that, especially depending on what kind of industry a client is operating at, compliance. Sometimes folks confuse compliance with security also. So can you also talk about the difference between these things? So that once again, the idea is to have holistic and minimalistic approach for security.

David Melamed: Sure. Basically, a lot of companies are trying to reach compliance and that’s [inaudible 00:17:16] because it’s a business need. But the problem is that sometimes they’re confusing between being compliance and being secure. In compliant basically means that they’re checking bugs and there are ways they can completely be compliant, but behind the scenes, they don’t have all the security measures that they need. For example, if you want to be compliant, you need to, I don’t know, upload some vulnerability report, that you need to manually ascend, manual upload. The thing is you’re doing that once and it’s not continuous. So, maybe once you’re compliant for one day, but basically it’s not something that is continuous in the company. And if you don’t have any best practices in terms of how things are running, you may definitely not be secure.

For example, compliance is not checking a lot of things. They won’t check in depth how you’re saving all your secrets and how exactly you’re dealing with all the different vulnerabilities that you have. They have some standards and they have some tests and you need to pass those tests, but that’s pretty much it. Security is way more than that. And so what we try to define here is that, Jit is trying to help you with security. If you do everything right, at the end you also be compliant. But the goal is to be secure first of all. And today, I mean, compliance is like theater. People are showing that they’re compliant, as an entry card to be able to be sold and integrated with a lot of different customers service. But the thing is, it doesn’t mean that they’re truly secure and that they have all the measures in place.

Swapnil Bhartiya: If we just look at analogy of automobiles or cars, you don’t buy a car and then install air bags, or brakes later on. It comes before the car is delivered. So, do you also see where we are moving in a world where security and a lot of other things will be baked into the software before it hits the public releases, where it says, you know what? Let’s release the software and then we’ll figure out security later on.

David Melamed: I think that, when you see all the different trends today and all the different hot topics in cyber security, like recently at RSA, the major topic was supply chain attack. A supply chain attack, there are multiple ways can happen, but one of them is for example, the CI/CD pipeline. Now, no one in the right mind would today release a project, a product in the cloud without having the basic CI/CD pipeline. Meaning that basically if he’s not protected against supply chain attack, that can be really dangerous. And so I think that the awareness around security is riding all the time. And today there are lots of discussions around being able to have security built-in, and not only added as an afterthought. So I believe that yes, in the future security will be really one of the first thing you want to look at, when you want to develop a new project and even at the level of design itself. And if you’re doing security as code, I think that you can definitely achieve that.

Swapnil Bhartiya: You folks are also raising $38.5 million in seed funding. So first of all, tell us a bit about, who are your investors? Also, what are the areas that you plan to invest in? What are the area they are looking at growth?

David Melamed: First of all, we’re so excited about that, but we have fantastic investors. We have Boldstart, which was the first investor and who trusted us from the first minutes. We have TechAviv, which is an Israeli fund. We have Tiger. Tiger and Insights, both are fantastic top-tier investors. They all believe that the mission that Jit wants to fulfill is something that is first of all, worth the money. And as I said previously, there are [inaudible 00:22:07] work here, because we want to cover so many things in terms of product security. We don’t want to be a niche company that is only tackling a specific use case.

We’re looking at product security as a whole. We want to provide product security as a service. And so our areas of expertise are very wide and we want to be able to help companies achieving the whole thing, having these kind of single pane of glass over product security. And for that, you need a lot of developers, you need great marketing. We want to be able to give to the world this idea that minimum viable security should be some kind of standard that everyone should start with and enable to fulfill this vision. Well, we need some good funding.

Swapnil Bhartiya: David, thank you so much for taking time out today and not only talk about the company, but also look that, I love the insight that you shared in terms of security, having a very kind of holistic approach towards it. And also it’s more or less like a process which are ongoing and how the minimum viable security that companies can easily get it started with because security can become intimidating. Then you really look at it. So, they get it started slowly and then gradually [inaudible 00:23:25]. So thanks for sharing those insights. And I would love to have you back on the show. Thank you.

David Melamed: Thank you very much.

[/expander_maker]