Mandy MooreDavid Melamed is one of five co-founders and the CTO at Jit, the continuous security platform for developers. He was born in France and holds a Ph.D. in bioinformatics.
Professionally, he has been working for the past 20 years as a full-stack engineer, as a CTO, and as a technical evangelist mostly in cloud and, in particular, in cloud security. He is very curious and likes knowledge-sharing and empowering other people.
In this episode, David talks with host, Kirk Haines, about frictions between developers and security engineers because security is mostly an afterthought, the concept of minimum viable security (MVS), and really common things that people forget to think about when they are building their applications but that are very easy things to fix.
Links:
Jit (Twitter | LinkedIn | Facebook)
David Melamed: Twitter | LinkedIn | GitHub
Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!
Give us a follow: @PolyglotShow
Transcript:
Kirk Haines: Welcome to Polyglot. My name is Kirk Haines. You can find me @wyhaines on Twitter and pretty much anywhere else on the internet. And today, I'd like to welcome my guest, David Melamed.
David Melamed: Thank you, Kirk, for inviting me. So hi, everyone. I'm David Melamed. I'm one of the five co-founders and the CTO at Jit, the continuous security platform for developers. And a little bit about me maybe, I was born in France almost 44 years ago. I hold a Ph.D. in bioinformatics. I moved from France to Israel about 13 years ago, got married, and I have now four kids.
Professionally, I've been working for the past 20 years as a full-stack engineer, as a CTO, a technical evangelist mostly in cloud and, in particular, in cloud security for a couple of leading companies like MyHeritage, CloudLock, which was then acquired by Cisco where I led some strategical and technological project for the CTO office of the cloud security business unit. I'm usually very curious and like sharing my knowledge and also empower other people. And as part of this, I've been involved in a few local communities around Python and AWS throughout the last couple of years.
Kirk: Fantastic. Why don't we just start at the beginning? And we'll just work up to what you're doing right now and then talk a little bit about what you're doing right now. So you were born in France, and you have a Ph.D. in bioinformatics, correct?
David: Yes, exactly.
Kirk: How did you go from the Ph.D. in bioinformatics to working as a full-stack engineer? What was that transition like?
When I finished high school, I didn't know what to do. I was always very curious, so I didn't want to choose between different domains. And so I decided to do studies where I shouldn't have to pick. And so I found at the beginning of my career path where I had a little bit of a mix of mathematics and biology, and a little bit of all the sciences together. But I was interested in biology, actually, and most of my studies were in biology because I think it was interesting.
But I have a hobby, and my hobby was computers. And so, at some point, I actually mixed both, and that's how I ended up doing a Ph.D. in bioinformatics. After I got my Ph.D., I started to look for a job. And so it was natural to start to work in a company where they were building software for hospitals. And so I started to work there for a couple of years and then I moved to Israel.
And gradually, I moved from being only a back-end engineer at the beginning at MyHeritage, and then after a few years, I actually moved to my second position in Israel, and I was a CTO for a couple of months. And there, because I was CTO, I had to deal with a lot of different stuff, so naturally, I became full-stack. That's how I ended up being full stack from starting in biology field, actually.
Kirk: [laughs] I love how the evolution of careers works that way sometimes. We just go in directions that if you could go back in time and ask us back then, we'd have no idea where we're going to end up.
David: Yeah, definitely. I like to do so many stuff, so writing a book or writing poems. So I could do really different kinds of stuff, and I ended up just being a software engineer.
Kirk: That's fantastic. So I assume, you know, when we were talking earlier, you mentioned Python. I assume, because of the bioinformatics and the fact that Python is used a lot in that field, Python was probably one of your early heavy influencers as far as the languages that you use.
David: So actually, not at all. When I worked in the bioinformatics field for my Ph.D., I actually ended up writing a software to visualize DNA in 3D, and I wrote it in Visual C++. And actually, most of the popular tools in bioinformatics back then were in Perl, so I learned Perl. And then, I worked in a company that used Java, so I learned Java. And then moved to Israel and got to MyHeritage, and they were using PHP, so I learned PHP. And then, as a CTO, they used Node, so I learned Node.
Kirk: [laughs]
David: Then I entered in the cybersecurity field in CloudLock, and there was Python, so I learned Python. So every time I'll learn something new, and that was really exciting, actually.
Kirk: Yeah, that's awesome. I always love it when I'm talking to people, and they mention Perl because Perl was the first language that I was, I guess you'd say, I was really, really good at. There are a lot of languages that you get exposed to in your career. But Perl was the first one where it was like, I know this language inside and out. And yet I don't think I've written a line of Perl in 10 years.
David: Yeah, me neither. [laughs]
Kirk: Yeah, that's fascinating.
David: Same thing for PHP. Every time I moved around to another language, I just wrote something. I learned something new and then moved on.
Kirk: Yep, it's fun that way. So, what are you doing now?
David: So right now, I am a co-founder and CTO in a small startup in early-stage called Jit. And what we do there is that we're trying to solve a very hard problem that nowadays seems more and more critical to solve, and that's how to deal with delivering secure cloud applications. And it's a hard problem because security engineers are not the ones that are owning the cloud application. That's the engineers. That's the engineers that are living in the engineering organizations.
But the problem is that if you're looking at today's world and trends, you'll see things like microservices and CI/CD. All those different trends are all in favor of making sure that you can deliver fast, and you can have a small feedback cycle with the market. And the problem is that if you're looking at engineers, they would say, "Yes, we're owning our microservice. We're building them; we're testing them; we're deploying them. We're supporting them." But one thing they're not doing is securing them because most of the ownership of security is not within the realm of the engineering organizations.
And so, there are a lot of frictions between developers and security engineers because security is mostly an afterthought. And it's not built-in inside the process of writing the software. And you cannot blame really engineers because most of them are not super experts in security. Most of them are not even measured upon their technical knowledge of security and how secure is their code. They're mostly measured by how many bugs maybe they're writing, the performance of the application, but not so much about security. That's a real problem.
And there are a lot of organizations that are progressive today that are trying to solve this problem. And they're saying the following, like in the past where QA was actually a separate function, and there was actually friction between test engineers, QA engineers, and developers, and so the way organizations actually ended up fixing the problem is by incorporating QA inside the microservice teams.
Well, the same way security should work, meaning that the engineering organization should own the risk. They should not depend on some external team in order to be able to secure the microservice they're building. And so more and more, you see those trends how to be able to make security not an afterthought but something that is really part of the whole process of building the application.
Kirk: That makes sense. You mentioned when we were chatting earlier about the concept of minimum viable security. Do I have that right? MVS?
David: Yes.
Kirk: What is that?
David: The thing is, if now you're asking engineers and the engineering organization to own the risk and to be able to deal with security, there are a few challenges they need to overcome. One of the challenges is that they don't know what to do. If you're asking any startup at the beginning if their product is secure or what did they do in terms of security, everyone will tell you something different because there's no real standard. And so, the first thing they need to actually know is what to do.
The second thing is that if you're talking with engineers, you definitely do not want to disrupt them and make them do something that is outside of their normal flow. And so, if you want them to own security, it should be part of agile processes. And so the way agile is working is that you're starting with something, and then you iterate.
The concept of MVS of the minimal viable security is to say the following: you don't want to take a whole list of security requirements like you can find online. This is actually the first thing that any CTO would do. They will check online for some security checklist. What do I need to do? Most of the lists are actually big, and so that's scary.
But basically, the MVS concept says that if you can start with something that is minimal, only the critical stuff, the baseline, the thing that without it, you would actually be ashamed to release your application to production. And then, like in any agile process, you would iterate. You would iterate, and you would add more and more security. And that's what the concept is actually trying to express. You will start small, and then you iterate.
And so, of course, when you're hearing of something like minimum and security in the same sentence, it seems weird because usually, you want as much security as you can. The problem is that in many startups, they don't have enough focus on security, and so they end up doing whatever they believe is critical, but it's not all the time the best thing or the minimal thing to do.
And so what we're doing at Jit, for example, is that we want to provide this list of minimal thing. And so this security plan is this list of requirements that are tailored to your environment. And basically, you start with it. It's not the end of the journey; it's only the beginning because security is always a journey. There's no really end. You can always add more. And so you iterate every time, and you add more. But the thing is to do that continuously.
Like in agile, you have CI. You have continuous integration. Every time you add something new, you don't want to break other stuff, so you have sanity test, regression test, the same thing here. Every time you add new security, you still want to be able to monitor the things that you already did. And so that's why we're talking here about also the concept of continuous security, which is another paradigm on top of CI/CD we can think of CS.
I can actually give a few examples of things that are minimal because there are a lot of different interesting items or controls that we can talk about. And there are different areas actually that are involved here when you're talking about product security. For example, you can, of course, take a look at the code. In the code, you can look at things like vulnerability in the code and add some SAST scanner static analysis. That should be very basic.
You can also take a look at dependencies, and you can add some SCA control. So you're checking the dependencies to see if there are some vulnerabilities that are known there. And we're talking a lot about it in the media right now with Log4j and all the other vulnerabilities because that's a critical problem.
But there are things beyond code, of course, because you can secure your code as much as you want. If, for example, you're not securing your GitHub accounts with, let's say, something like MFA, then you actually leave a door and a hole wide open for any attacker to insert malicious code in your pipeline. So you also need to take care of the pipeline.
You need to take care also about the runtime of your application. And there is something minimal that you can do. For example, if you're using AWS, you need to make sure that, of course, you use MFA for your accounts. You need to make sure you're not using your root accounts. There are a lot of things that are really minimal. And if you do some automation there, it can be really done with a simple click of a button. But beyond that, I'll only talk here about the technical controls.
There is another category of controls that are also very interesting, and most of the time, they're kind of overlooked, for example, all the things that are related to processes. If you think of an employee leaving a company, you have a whole process of onboarding. And so making sure that you remove access from the employee that's something that's usually overlooked because it's hard to maintain the list of all the services that employees have access to.
And so I think that if you want really to take care of your product security, you need to have a combination, a mix between technical controls and actually human processes. And both need to be managed in a way that you know exactly what you have done so far and what you need to do.
When I look at most of the cybersecurity companies, every company is giving a different product, and each one is actually focusing in a different area. But the problem I see in the current industry is that you can buy, I don't know, maybe ten different products, and you know what you'll get because each product will focus on a specific area.
What you won't know is actually what are the spots that you're missing? What are your hidden spots? And that's why it's important to have a list so that you can have a frame, and you can see the big picture, the map of all the different areas that you need to take care of and all the risks, and then you can buy all the products that you want in order to cover those risks.
Kirk: So does Jit then…do you focus on helping people to understand what that list is for their particular environment? Is that what you do or?
David: Yeah, exactly. So at Jit, we believe that tomorrow every cloud application should start by adding security from the zero. And the problem is that it's hard because there are a lot of things to do. So what we want to provide is the list of the minimal stuff that you need to do when you're starting your project. And then we can talk about more advanced plans in the future, something like, I don't know, you want compliance because you have a business need for that. That's afterwards.
But the principle is that you will start with something minimal. The list will be entirely automated, so that's by applying your list, you would be able to see all the integrations in your environment, whether it's in the CI/CD, whether it's in your runtime, in your pipeline, all the different areas that are relevant to your product security. And of course, we also provide this list, and it's displaying as code. Because we believe that we're dealing with engineers, and so they probably want to do some customization because every organization is working in a different way. So the processes that they have may be different. That's one reason.
And the other reason is that basically, if you're looking at the risks, when you're looking at, and you're trying to analyze a cloud application, most of the risks are the same between all the applications that's based on the architecture, 80% are the same. But there are still 20% that are really specific to your organization. And because we don't know that by advance, by expressing the plan as code, it allows you to actually add your own risks or an item in the plan.
And so, first of all, we're developing everything as code because we also are thinking that the communities that we want to build will help us add all the different controls. We don't want to reinvent cybersecurity. And so we're not writing our own tools, or we're not starting there, at least. We want to be able to leverage all the awesome open-source tools that are existing already in the industry. And then we want to be able to add to that companies and commercials that also are doing great products.
And so, we want to orchestrate all these different tools in a way that you have a list with different options for different controls. If you want something free...and we believe MVS should be free for everyone because this is our vision. We believe in a world where every cloud application should be secured from the zero, and that's why MVS should be free. But then you have some more advanced business needs. And for that, we think that integrating with some commercial product will certainly be required.
Kirk: Okay, let me pose a hypothetical to you then because I'm curious how this actually works. So let's say that I have an application, a Ruby on Rails application with a very standard typical Ruby on Rails architecture. We're hosted on AWS, and we've got a Postgres database. And maybe there are a couple of other services that we hit for pieces of data. But it's nothing terribly sophisticated because it's a fairly young application. And we want to start concentrating on security, and we want to apply the MVS principle to it. So we come to Jit. And what do we do? How does this work?
David: So basically, right now, you're just installing a GitHub application. And once you install the application, you automatically get the basic plan, so the MVS plan. And we add this MVS plan to your GitHub in a specific repo to your GitHub organization so that you can see the plan as code. And you can also see it in the UI, and you can review the plan. The plan is actually grouped in different layers. So you have the code, you have the architecture, the infrastructure, you have third-party services. You have a list of different layers.
And in each layer, you have a list of items, the things that Jit will do. And so, by just committing the plan as you would do for some code that you would commit to Git, you're committing the plan. The plan is getting sent to your GitHub organization. And also, automatically, we're adding integrations. So let's say, for example, integrations with the code that would be in the CI. And so what we're doing is that we're generating from the plan a list of...let's say in the CI you're using GitHub Actions. Then we generate a GitHub workflow file that would include all the different tools that we believe you need because each one is tied to a different item in the plan.
And that's how we automatically monitor your code in a central way because we actually built some nice innovation here that you don't need to touch all your repos. We actually built something central. So we have only one repo that you define the security. And we're listening to all the PRs, all the pull requests in your environment. And basically, for each PR, we're triggering those tools in a central way. And then you have a very great experience as the developer because you see everything into the PR itself. So we would do a security review like a peer review of your code. That's the experience in the code.
In other areas, for example, we have also integration with AWS. So there, we have a role that is trusting your organization. Basically, you're giving us read access to AWS, and we can make sure that you have CloudTrail enabled. So we can do that either as code if you're using Infrastructure as Code like Terraform, or we can actually check that in your environment. And let's say one of the basic stuff that you need to do when you're using AWS is, for example, making sure you have audit logs using CloudTrail.
So we would actually show you the list of the tests that we're doing. The test would be here that you have CloudTrail enabled, and you would fail for that because you don't have CloudTrail enabled. And then you can remediate to that by just clicking on a button. You would be able to enable CloudTrail either by adding a PR in your code, or if we had write access, we would be able to trigger it through API.
Kirk: Very neat. So the MVS plan, you said it's expressed in code. What is that implemented in?
David: So here, it's interesting because we had a lot of thoughts how we express something like that because it would look like to the list. But on the other hand, we wanted really a powerful language. So we went with something that isn't really code; it's actually declarative code. So it's actually a bunch of YAML files that are defining the different concepts. So we have the concept of items, and items can actually be part of multiple plans. So you can have a plan that is MVS. But the same item can also be part of a bigger plan like SOC 2.
And so if you're actually implementing and applying the MVS plan, and let's say you're adding an incident response plan in your environment, you're automatically also making progress towards SOC 2 because it's the same item that is also present in a second plan. So we can think of a grid when you have all the different plans mapped with all the controls mapped from different plans one to each other. And basically, when you're applying some of the items in plan A, you're also making progress in plan B, C, and D because they share the same items.
Kirk: Okay, so you have a bunch of YAML files that define portions of your plan. And then you have some sort of a central engine then that interprets those YAML files and applies the plans. Am I understanding that correctly?
David: Yes. So the plan right now is expressed in YAML. And for each item, you have a list of workflows that are implemented. And those workflows can run in different, let's say, runners. One runner can be GitHub Action. One runner can be our cloud; one runner can be your cloud. That's the way the engine is actually translating the plan into something that is executable, and that can run in any of the environments that I mentioned.
Kirk: That's a pretty neat implementation. So is it language-agnostic in the sense that okay, so we talked about Ruby on Rails. But what if I have an Elixir app, or I have a Crystal app or something like that? Are you language-agnostic, or are there certain language families that you support better than others right now?
David: So right now, we have already a couple of controls, and some of the controls are language-agnostic. For example, we have a control that is checking for secrets where you are leveraging the open-source, a great open-source Gitleaks. And it's completely language-agnostic because it's searching for certain patterns, certain patterns in the code such as RegEX for secrets, so that's completely language-agnostic.
Other tools that we're using, for example, for SAST, are dependent on the language. And for that, we're already supporting a couple of languages. And we're adding more every time because what we've built for the last couple of months, actually, is the ability to wrap all those controls into containers that can be integrated with our platform very easily.
Kirk: So I'm curious about something. We've been talking about the things that people should do. And I know from my experience with Rails applications sometimes it's really easy to, as you've mentioned, overlook simple things just because you're focused on the features that have to be delivered and your deadlines. And you're not focused on even sometimes very simple aspects of security. So I'm just kind of curious, what are a few of the really common things that people forget to even think about when they are building their applications but that are very easy things to fix? Are there some patterns there that you've noticed?
David: Yeah. So, for example, and I can tell you that from the users that are already using our platform. We got some great feedback from people telling us that "You saved us because we managed to identify secrets that were in the PR." It's really easy today to forget some secrets in your code because you're testing something locally, and you're not reviewing enough of your code while you're committing it.
But the thing is that once you commit that to GitHub, basically, even if it's a private repository, it's already not really secure because you don't know who can read it. And so, even if we discovered that you still need to recycle it. So that's really a basic thing. And one way would be to add something in your CI. One other way would be to add some pre-commit hook in your own machine so that actually you're checking your code before committing it so that secrets won't be leaked.
Another thing if we're always talking about secrets is that also a pattern that is common is that a lot of people are actually working with AWS keys. And the right way to actually or the better way to work with that is to use tools like AWS Vault so that your keys are never stored in your own laptop in plain text because otherwise, it can be committed by default. Or if you're not paying attention, for example, you would have that in some environment variables, and by mistake, you would commit your file. With Bash profile file, it can happen. So I would say that secret is very, very basic, something that you need to check.
Also, if you're working with an AWS environment, I know a lot of people that are still using and abusing the root account. And at Jit, we actually spent quite some time trying to find the best way to work with securing and bootstrapping AWS accounts. And I'm actually writing a blog right now about it. So I want to share how to do the first step of bootstrapping an account that would be secure so that, for example, you don't have to define users in multiple places. Let's say you have multiple accounts. You shouldn't define your user in multiple ways because you're actually increasing your attack surface all the time with that.
And so we ended up creating a dedicated AWS account for the users, and they're actually switching roles. And that's everything is code using Terraform. They will actually switch roles between the different accounts in order to get access. And there, you can be secure because you can enforce MFA, for example. So you would make sure that if someone manages to grab the credential of the users, he won't be able to get to production, for example, because he wouldn't be able to bypass MFA so easily.
So there are a lot of things that actually are not that hard to do, but if you don't know what you need to do, it's kind of hard to find them. Because, for example, for AWS, I was looking for hours online for a simple tutorial on how to secure my account, and there's no such resource. There are a lot of things you can find, but you're not even sure that that's the best way to do that, or these are the most critical things you need to do.
And that's why also we want to bring that to everyone. That's why we believe that MVS should be free because it's really easy to overlook those things. And it's not that complicated to apply them once they're automated, of course, and that's why we're working hard on automation.
Kirk: Very neat. It sounds like what you've got is you've got a concept here, and you've got a service here that regardless of whether someone is using a mainstream language or something less mainstream, whether it's something that you have specific language support for or not, pretty much every project out there probably can benefit some from what you're doing because of those simple things like the AWS security and the secrets you're monitoring.
I know that (I'm not going to name names.), but there was one company that I worked with where exactly what you said, the AWS stuff was all under the root user. There were no IAM profiles for different users being used. And that was a very simple thing that helped lock things down because when you're off-boarding people who leave the company, if they have access to that root user, you've got a huge vulnerability, and it's an easy one to miss.
David: Yeah, exactly. And that's why, for example, the way we implemented that in our companies that we have everything as code in Terraform and basically adding and removing a user is a matter of one line in the Terraform code. And so I can grant access to another environment by adding a line. I can remove the user by just removing two lines in the code.
Kirk: That's fantastic.
David: And also another thing is that I defined in each environment a role that has only read-only access and another that has write access because the same thing; you want to apply the least privileged access. So, on one hand, you want your developers to be able to debug things in production sometimes. There's no other way to do that. But on the other hand, you definitely don't want to give them write access there because of the possible consequences. And so the basic stuff that you need to do is to have two roles. That's where I would start.
But then you can think of, okay, maybe I can actually scope my read-only access down to only the services that the developer is supposed to check. For example, if he needs logs, I will give you access to logs. And I wouldn't give him access to the Lambda code or, I don't know, to any other services because he doesn't need that. And that's how you implement gradually least privileged access. You can also do that differently by, for example, checking CloudTrail and seeing exactly what are the APIs and the services that are used. And so you can scope down all the roles.
So there are a lot of things you can do, but the thing is, and that's my main message, is you need to do that gradually. And especially if you want developers that are really, really busy with writing the code, and testing the code, and deploying, and supporting, you don't want to give them a lot of work on top of that. So that's why automation is really key here.
And you want also to give him access to data just in time. This is what we're called JIT, just in time. Because what kills developers is actually context switch. And so every time that you can give him information about security issues when he's actually working on that, then he will definitely fix it. But if the bug is already in production and then he needs to fix it, there's a huge cost associated with that.
So people sometimes say that developers don't care about security; it's not that they don't care about security. That's not their main job, maybe. But all the time, they're getting the thing that they need to fix out-of-band. And so that's terrible for them because it's a lot of context switch. And that's what we're trying to achieve here is giving them the proper context and the information right in time.
Kirk: Fantastic. You wrapped everything up so nicely there. So I think we should probably start segueing towards concluding this episode of the Polyglot Show. So I want to thank you very much for coming on the show. And I want to give you a chance to let people know where they can find you online if they want to talk with you more about this or find out any other information. And also, if there's anything that you just want to mention that we haven't had a chance to bring up yet, go ahead and mention it now.
David: Sure. First of all, that was my pleasure. That was really, really nice for you to host me in your show, and I really enjoyed our conversation. For anyone who is interested to know more about the concept of MVS that we've actually taken from the concept of MVP, the minimal viable product in the product world, for anyone who wants to know more about that and is interested even to test our platform, we are currently in early release, just visit our website jit.io. And then there's a simple button, get started, and then you'll be able to start and test our platform.
And we have a big vision about where we want to go from here though actually, our motto is that we don't have...you know, Toy Story with their motto, right? To infinity and beyond. So this is definitely our motto. We believe that there's no real limits to what we can cover because we want in the future to ask the community to actually help us write controls and integrate that with our platform because we want, at the end, the world to be a more secure place.
And so this is what I would like to wish to everyone is to have better, secure product. If I can help anyone or you want to find me, you can find me on GitHub, dvdmelamed. That's really easy because I was a big fan of movies, so it's dvdmelamed, same thing on Twitter. You can also find me on LinkedIn. I will be around in many conferences for the upcoming month. And so I'd be happy to talk with anyone who is interested in security. And thank you again for having me on your show.
Kirk: Thank you for joining me. It was a great conversation. And thanks everybody else for listening to us. You can find us on Twitter @PolyglotShow. And this is Kirk Haines for New Relic. Thank you, and we'll catch you again next week.
