DevSec For Scale Podcast Ep 2: Minimum Viable Security

Let’s be real. Security is not at the top of the priority list for developers… especially at smaller companies that are pushing to get out an MVP as quickly as possible. Well, there is a solution, and it’s called MVS or minimum viable security.

This approach lays the groundwork for companies to ensure they build security best practices into their development lifecycle in a non-intrusive way and gives organizations a roadmap for securing their most sensitive assets from day one while recommending more security measures over time.

This episode, with David Melamed, CTO and co-founder at Jit, was a real eye-opener with tons of great ideas that can definitely make security truly shine in any organization.

Watch the episode below

TRANSCRIPT

Jeremy Hess: Welcome to the DevSec for startups podcast- the show that makes security a first-class citizen for small businesses. My name is Jeremy Hess- head of developer relations at Akeyless, the secrets management SaaS platform. This interview podcast brings security experts and practitioners together to offer practical and actionable ways for startups to implement security best practices using shift-left principles without interrupting developer lifecycles.

My latest guest is David Melamed. He’s the CTO and co-founder at a startup called jit.io. We had a really great discussion about minimum viable security and how startups and small organizations can really introduce security in a lean and iterative way. Have a listen and let me know what you think.

I’d like to give a very warm welcome to David Melamed, co-founder, and CTO at Jit, a really cool startup that offers a continuous security platform that takes a minimum viable security approach.

Now, David, before we get into a little bit more about Jit and yourself, can you give us a little bit of background on what is minimum viable security, as it’s known, MVS? I know it’s been written about for a while, but we haven’t seen it implemented practically as much. Can you give us a little bit more detail about what MVS is?

David Melamed: Sure, first of all, thank you, Jeremy, for having me on your show and, yeah, about MVS. So basically, if you’re a fast-paced startup like us, when you’re building a software product, you want to add security easily. The first thing you would do is typically go to the internet and find a checklist or an existing standard. But the problem is that usually this is big and you really don’t know where to start.

So, the concept of MVS comes from the original concept of MVP, which is popular for the product world where basically you’re building a minimum set of features that are needed to test the market, ensuring that the business plan and the product are viable. It’s done iteratively, and it’s focusing basically on delivering a minimum baseline value in each single iteration.

So, we believe that we can apply the same approach to security with the MVS concept, where basically you need to start with some baseline, some bare minimum requirements. And after that, you iterate in order to add more and more security. So, instead of starting with a big list of things, a bucket list of all the things you need to do in terms of security because you’re a startup and you don’t have enough time to focus on that, you should only start with the minimum, and yeah!

Jeremy Hess: Okay yeah, that’s a perfect introduction, I think. And what we’ll do it now? Let’s hear a little bit about yourself. Do you want to give us a little bit of background about who you are, what you’ve done, and what brought you to Jit?

David Melamed: So, I’m David Melamed – one of the five co-founders and CTO at Jit, the content security platform for developers, and I was born in France most 44 years ago. I’m holding a Ph.D. in bioinformatics. I moved from France to Israel about 13 years ago. I got married, and I have four kids. Professionally, I’ve been working for the past 20 years as a full-stack engineer, as a CTO, a technical evangelist most in the cloud, and in particular in cloud security. And I’ve been working for a couple of leading companies so far.

MyHeritage, when I arrived in Israel Cloudlock, which was then acquired by Cisco, where I led some strategically and technical projects for the CTO of the cloud security business. I’m also very curious. I like sharing my knowledge empowering people, and as part of this, I was part of a couple of local communities like python and AWS ones throughout the last couple of years.

Jeremy Hess: Really cool, and so what was the impetus to get Jit started? What did you guys see that was happening, and what was the problem you’re trying to solve?

David Melamed: Okay, so basically, and I’ve been living this situation over and over. Nowadays, everything, when you’re building software, is done towards increasing velocity, whether you’re talking about microservices and microservice teams or CI/CD, everything is done in order to be able to get some really quick feedback, feedback loops with the market.

And so, in the past, for example, you had QA that was something that people that were doing QA weren’t sitting inside the teams, the developer teams, and there were frictions, and so what happened is that QA was included now and is a complete part of what the microservice teams are doing. They’re developing the service. They’re also testing it and supporting it.

You know the famous sentence – you build it; you own it, you test it, you deploy it. One thing they’re not really doing is “you secure it” because security is still some kind of an afterthought, and security engineers are not sitting inside the engineering organization.

And so, all the time there is this game of catching up with the velocity and the deployments that are happening inside the organization of the engineers and basically that creates a little friction because the requirements of security are all the time arriving late and they’re creating some kind of overhead and context switching for the developers. And so, the situation has been going on for a long time. And even if you’re thinking of trends like shift left, it’s still not there yet. Still, their initial requirements are done by security engineers.

And so, a lot of companies are trying, the progressive ones especially, are trying to think of a way to fix this issue and like you in the past. They’re trying to include and incorporate security inside the process of developing the product, and so in order to do that, the engineering organization needs to own the risk. It needs to own the security and not being tight and dependent on an external team for that.

And that’s why as part of the MVS, what we believe is that the way to properly do. That is that you need to start lean and small, and then you need to improve your security in a continuous way like the Agile principles are doing, because of everything here – you don’t want to add some overhead for the engineers, so you need to add security as part of the natural process. So, because they understand Agile, you need to do that in a natural way.

So, you start small, and then you iterate, and also because you’re talking to engineers, you want to automate as much as possible because you want to remove the need to do things manual, which is definitely an overhead. And finally, because you’re talking to engineers, you also want to do that as code. So, the security plan, that is part of the MVS approach, should be something that is as code from day zero because this is the way engineers are working, and they want to customize it, and everyone is working differently. So, these are a couple of principles that we thought about when we’re thinking about this, and this is what we’re doing at Jit.

Jeremy Hess: Got it, okay! Really cool. Now one of the questions I like to ask, any cybersecurity company or developer security or security in general as a security startup, do you actually eat your own dog food? Do you use your own platform when you’re developing or when you’re building your product?

David Melamed: Of course! And actually, it started on the first day with the first engineer. When he arrived, I was kind of thinking, okay, I want to build a product and a company where security is at the heart of what we do and not an afterthought. And so, on the first day he arrived, I told him, okay you’re now creating your first microservice. I also want you to add CI/CD on the first day, and he did that. The problem is that on the second day, when we added the second microservice, it wasn’t the case anymore, and that’s because it wasn’t automated.

And so, the first thing we did actually as part of building the product is finding a way to have a centralized CI/CD or at least a way for us to be able not to think about adding CI every time you’re adding a new microservice. And this is also at the basis of what we’re doing when we’re adding security. We want to add those security tools in a centralized way so that you don’t need to think about it. A developer should basically concentrate on his work as much as possible we want to ease the fact that he doesn’t need to think too much about security because there are a lot of things around the ecosystem that gives him the ability to test his code, show him in a just-in-time manner, and that’s why we’re called Jit, just-in-time manner, the security issues that his code is generating or things that are misconfiguration in the cloud and things like that.

So that’s why we build that in a central way. We are thinking that you want the developer to be able to concentrate on his work. But if you’re giving him the proper context with the security findings that you’re that all the tools are generating, then he will be able to deal with them, because I all the time here the things that developers don’t care about security. I don’t think it’s true. I think that some of them don’t know too much about security because they’re not, it’s not part of the common knowledge, when you’re, you know, learning a new language. You’re thinking more in terms of syntax, in terms of libraries, but you’re not thinking too much about security.

And also, developers are not measured by how secure their code is? They’re measured by the number of bugs or performance, but rarely people are checking how secure the code is. So I don’t think they don’t care about security. I think that they are thinking of a lot of things, and everyone wants to write secure code, but just you need to give them the proper context and the proper information at the right time. And this is what we want to do at Jit.

Jeremy Hess: Great. Well, actually, that brings me to the next question because we were talking just now about how it’s been difficult for developers, in general, to think about security from the beginning, and you know, on that same vein – why do you think it is that security is still so hard and not really developer-friendly until now?

David Melamed: I think that mainly security is so hard because there are so many things you need to think about, and I think it wasn’t developer-friendly until now because most of the tools are not targeting developers. I mean, until the shift-left trend, most of the security products are meant for security engineers and not really for developers. And so, basically because now everything is turning as-code and people are trying to target developers, they’re thinking a little bit differently. It’s not there yet; even the tools today are not thinking too much about how they can incorporate, how can they integrate themselves into the regular flow that developers are using every day. For example, making sure that the results are returned into the PR and not in a separate dashboard.

So, there are other things that need to be done yet. For most of the security products, but we’re getting there. I mean, more and more people are understanding that at the end, the code and the product is in the hands of the developers, and so we need to help them to get better at security instead of trying to help the security engineers catch up with the developers.

Jeremy Hess: Yeah, and of course, being in a cloud-native world these days, how do you think that security will be able to keep up with those engineering cycles that you know is constantly moving constantly changing?

David Melamed: I think that at the end, if we’re getting ahead and moving forward in this everything-as-code trend, it will get better and better because if you can modulize everything as code, you can more easily analyze things. For example, when you’re thinking of infrastructure-as-code, there are tools today that can detect security misconfigurations way before you deploy that into production.

Until now you had, for example, to call all sorts of API in AWS to ensure that your infrastructure is secure, and maybe sometimes it’s too late. But if you’re adding those tools and you’re a part of the shift-left trend, if you are testing your code, that is the plan of what you want to deploy in the product, then it’s actually easier to build tools for that and also easier to catch things earlier.

So, I think that if you can add more and more tools inside the CI/CD pipeline and before you get to production, the fact that you have more and more tools that are checking the code and inspecting things statically allows you to have a better grasp at security and help developers develop things more securely.

Jeremy Hess: Absolutely, that sounds like a good plan, and it really, I guess, at the end of the day, it becomes more of an implementation issue, right? I mean, it’s a lot of time and effort that goes into all these different things, right? So yeah, how does a company, a startup, especially who’s really focused on their MVP, focus more also on MVS?

David Melamed: So basically, and this is also one of our key principles, that you want you to want to add minimal overhead for any startup. As a concept, you would like to just like add one line of code, include security, and that’s it, I’m done. Basically, we’re starting with the same concept that if you’re installing, you know our Github application where we know about your environment, and we’re providing you with this MVS plan, this minimal viable security plan, something you can start with. And just by committing your plan like you would commit your code, we’re installing ourselves, integrating ourselves in all sorts of all the different layers that your product security requires.

For example, we can integrate ourselves in your CI/CD by for example, adding some Github actions there. We can integrate ourselves in your pipeline by checking that, you know, you have enforced your Github MFA. We can integrate ourselves with the runtime and making sure that your AWS infrastructure is working correctly and it’s not misconfigured, and you can think of a great number of things that you need to check there. We can also integrate with your code. We’ll also thinking of managing processes.

For example, one of the things that is often overlooked is the fact that when an employee leaves, you need actually to manage the process off-boarding. Now in many startups, this is done basically in some kind of excel sheet and that’s it, and that’s not a good way to make sure that you’re not forgetting to remove the access from a former employee to a service that is critical to your investment.

Jeremy Hess: A random public key that’s just sitting on a server.

David Melamed: I know, like a public key. There are all sorts of best practices – same thing when you’re bootstrapping your AWS infrastructure. I’ve been looking, searching online for a couple of hours how to do that properly. Because, I believe, that when you start something you want to do it in a great way. Now you don’t want to spend hours or weeks to find the proper template to do that.

Most of the tutorials I found were not as-code, so it was hard to implement and reproduce. I can interpret that in different ways, and so, I believe that if you can provide startups with some, you know, basic templates to secure your AWS infrastructure and a basic set of tools to check your code inside the CI/CD and making sure that, you know, your pipeline is secure.

If you start there and everything is automated, it shouldn’t be a big burden to add it, and add it on the first day because otherwise, you’re just accumulating security debt that you need at some point to pay. In order to, you know, to be able to comply to some security standards at some point. So, I think that if you know how to manage your debt, and I’m not saying that you need to do everything on the first day, but at least you need to know what needs to be done.

You have some kind of roadmap, like you have a roadmap for your product, you need to have your roadmap for security, and so, if you want to invest a little bit of time, every week you’re investing on two hours, make sure you invest them in the best places in the most critical places.

And that’s why we want to provide you with a minimal plan at first, and then, of course, it’s not only the beginning, right? Security is a journey. It’s not a destination. So, I know that it sounds worse to put minimum and security in the same sentence, but it’s only a start, right? You need to do that iteratively, otherwise you will just be overwhelmed by the number of things you need to do.

Jeremy Hess: And then you actually potentially compromise on the product itself right? So you definitely need a balance.

David Melamed: Yeah, take a look, for example, at the SOC II list, right? It’s maybe, I don’t know, 200 items. Where should I start? Right? So, when I talked to different people in the industry, everyone was saying something different regarding what he did for his products… all start-ups, right?

They didn’t have time to invest, but everyone knew a little bit what needs to be done. The problem is that the roadmap was only in the head of the CTO, which is definitely something that is not good enough. Where is the transparency for the rest of the organization? So, this is why I believe that if you’re starting with a plan and a plan that can be shared with the rest of the organization, then you’ll be able to manage correctly your security.

Jeremy Hess: Absolutely yes! It’s always great to plan ahead, I guess, and that’s if we’re focusing on planning, then we’re definitely heading in the right direction. Now, before I get into some practical tips that you could give us which we could actually use, I like to go a little bit higher level. Do you think you give us a couple of you know interesting trends that you’re seeing in general in terms of the security ecosystem?

David Melamed: Sure, so I think that one of the trends that are really one of the most interesting ones is the shift-left trend. And so, basically the ability to test your code and making sure that you find your security issues before they get deployed in the cloud. And the other would be that everything now turns into code. So, you have a security-as-code, policy-as-code.

For example, OPA, the Open Policy Agent, has been very popular lately in the cloud-native world in order to be able to manage the policies. And I think that in the same way, and this is why because this is the reason why we also want to provide the class code, I think at the end, developers have the keys to the realm, right?

The product security will be in their hands, and so everything that can be codified will be easier to manage, will be easier to modify, the GitOps principles also are something that is very strong, and that’s why we also comply to that. So everything should be stored in Git and so that you can have auditing. You know exactly who committed what you have, versioning all the things that are really central to security.

So, I believe that these are the couple of trends. I would add another trend that we’re trying to promote. And instead of thinking of shift-left, we’re like the borne left, meaning that basically when you start a new project, it should be already secure from day zero, and that’s what we’re trying to achieve here by providing something that is so simple that you just need a couple of clicks to get going.

Jeremy Hess: Right! Yeah! That sounds like a great way to take shift-left and shift it even more left. Although there is a lot of talk I hear about how much more left can you shift at this point? But look, I mean, I guess at the end of the day, if we get to day zero, then security wins finally, right?

I mean, we could stop, hopefully, some of the leaks and attacks that have been plaguing some of the large organizations lately. So we’ll see where that goes.

So now that we’re, you know, basically at the end of the show here, I’d love to get a couple of practical tips that you think startups and developers within those startups can put into practice today to bring them to a start of you know what would be minimum viable security.

David Melamed: Sure. So, there are a couple of things I can think of, and if we’re starting with the code layer, we’re trying to talk about different layers in the code, the pipeline, the runtime, and the processes. If we’re thinking about code, I think that one of the most critical things that any of the publishers should take care of is making sure that he’s not committing hardcoded secrets. And if you’re thinking about that, everyone will say, of course, I’m not committing any hard-coded secret. But it’s so easy to actually overlook that and, by mistake, commit them.

So, I believe that there should be at least something in the CI/CD that is making sure that your secrets are not committed or not deployed to production – before that even better. You have some pre-commit hook on your own machine so that even in the first place things are not committed. Because one is committed, it’s not enough to just remove that from the code. You will need first of all scrap that from the Git history, and beyond that, you also need to recycle your secrets, right? So it’s not something minimal, so definitely better to make sure that you’re not committing it in the first place.

That would be the first thing. The second thing is really tied actually to what we’ve been hearing lately with the log4j vulnerability. I would say it’s making sure you’re scanning your third-party dependencies. And it can be there, can be multiple sources of vulnerabilities in third parties. First of all, it can be that they’re really dependent on a new dependency in your code that has some security issue that just has been found. So it’s not enough to just scan that once. You need to scan that all the time.

But also, there’s this new trend of you know type of squatting. A lot of malicious actors are trying to introduce you know malicious packages that have just a misspelling in the name, and so it’s really important to just make sure that you’re scanning all the time your dependencies because if you’re making sure that your code doesn’t have any dependencies and then you’re adding any vulnerabilities and then you’re adding some dependencies that do, then, well, you just left the door open to big troubles ahead.

I will also say that MFA is something that is minimal and very easy to add. So, making sure that you’re adding that to your email, to your AWS infrastructure, to your Github account, same thing here; otherwise, you’re just leaving the door open to malicious actors to introduce, you know, fast and something really bad in your code, right?

Jeremy Hess: Yeah! Absolutely I think MFA is pretty much becoming, you know, almost built-in standard these days, any sort of IDP as well. It’s kind of now seen as if you don’t have it, then, you know, what you are doing right? You haven’t even started. You really need to have that implemented really day zero; otherwise, you know how do you grow? And how do you make sure everything’s under the same umbrella?

David Melamed: Yeah, exactly, and in the same way, I think that is a trend also. We’re talking about trends, one of the trends is the password-less trend, right? No one wants to build a new product with, you know, email and password anymore. You have the social login. You have a password-less way to connect. I think that’s also something that, at some point, a password will be something antique that no one wants to deal with, right?

Jeremy Hess: I feel like we’ve been saying that for 30 years, 40 years maybe. Everyone wants to get rid of passwords. It has to happen at some point, so we’re looking forward to that day. Every security engineer, everyone is looking forward to the day where you can actually get to that level. David, thank you so much for your time. Good luck with Jit.

We look forward to hearing more, and hopefully, we will have you on again in the future. So for now, thank you very much, and have a really great day!