Moving from “shift left” to “born left”

[00:00:01] Chris Sienko: Is Cinderella a social engineer? That terrifying monster trying to break into the office? Or did he just forget his badge again? Find out with Work Bytes, a new security awareness training series from Infosec. This series features a colorful array of fantastical characters, including vampires, pirates, aliens and zombies as they interact in the workplace and encounter today's most common cyber security threats.

Infosec created Work Bytes to help organizations empower employees by delivering short, entertaining and impactful training to teach them how to recognize and keep the company secure from cyber threats. Compelling stories and likable characters mean that the lessons will stick.

Go to infosecinstitute.com/free to learn more about the series and explore a number of other free cyber security training resources we assembled for Cyber Work listeners just like you. Again, go to infosecinstitute.com/free and grab all of your free cybersecurity training and resources today.

Today on Cyber Work, David Melamed of Jit brings us a new wrinkle in our ongoing series of developer security topics. David introduces us to the idea of moving beyond shift left, shifting the security earlier into the CI/CD pipeline; and into the concept of born left, a platform in which security tools are in the hands of the developers at the point of creation.

David talks about his early programming experiences, his PhD in bioinformatics and the delineation of responsibilities between developers and the DevSec team. All that in a little bit of CTO talk today on Cyber Work.

[00:01:38] CS: Welcome to this week's episode of the Cyber Work with Infosec podcast. Each week, we talk with a different industry thought leader about cyber security trends, the way those trends affect the work of infosec professionals while offering tips for breaking in or moving up the ladder in the cyber security industry.

Dr. David Melamed is the CTO and co-founder of Jit, the continuous security platform for developers. Over the past 20 years, David has been a full stack developer, a CTO, a technical evangelist mostly in the cloud and specifically in cloud security.

He has worked for leading organizations such as MyHeritage, Cloudlock, acquired by Cisco, and led the advanced development team for the CTO of Cisco's cloud security. This is a 500 million ARBU.

David, thanks for joining me today. Welcome to Cyber Work.

[00:02:26] David Melamed: Thank you. I'm very glad to be here.

[00:02:29] CS: Yeah, just to give the listeners a little preview. We're doing a bit of developer security DevSec, AppSec, all that sort of thing. David pitched us on the idea of moving from a shift left, which is to put the security portions of the developer pipeline further left in the process, I.E. earlier, into something that he is calling born left, which is sort of baking the security process into the entire system.

Before we get into that, I just want to sort of start with your own origin story. How did you first get interested in computers and tech? Because I see, in college, you started out studying biology. You had a master's in biochemistry and molecular biology and then a PhD in biomathematics, bioinformatics and computational biology.

Obviously, these all probably have a strong tech and computer component. But I don't actually know what all those degrees are. First of all, could you tell me about bio mathematics, bioinformatics and computational biology? And how they sort of tied into your interest in computers and tech?

[00:03:37] DM: Yeah, sure. Let's start with the fact that I've been passionate about technology since I was a kid. Actually, I got my first computer at the age of 10. And it was some kind of educational toy made for kids, which included a lot of questions about general knowledge.

But the most fascinating part about it was that it included some programming language, basic. This is basically the first time I started to get interested into programming.

And at the same time, I was a big fan of an educational animated series that you may know called Once Upon a Time... Life, which is about the human body. And so that was basically what drove me to start my studies in biology.

But every time I had this hobby of computer science, and it's only at some point that I managed to mix both, both my hobby for computer science and my studies and ultimately got a PhD in bioinformatics. And that was actually eye-opening for me in terms of understanding how to apply programming to something like a real-life use case. Also, lit inside me the sparkle about creating, innovating and building software.

[00:05:05] CS: Mm-hmm. Yeah. Just to catch me up. Bioinformatics, is that something to do with like data collecting around sort of topics in like sort of biology and –

[00:05:18] DM: Yes, exactly. It was mostly about genomics. Collecting a lot of data around genes and then applying an automatical model. For example, my PhD was about showing the DNA curvature with different models and gene expression for yeast. Something really applied. Trying to apply computer science to biological problems.

[00:05:45] CS: Yeah, that makes sense when you mentioned that it's related to sort of genome issues. Because that's certainly the most number-crunch-intensive biology thing we're working at right now.

From your academic career, I want to briefly turn to your professional career. Because, again, this is how our guests get to know you and sort of seeing your career journey. There's a pretty natural progression as far as I can tell. You started as a web developer/project manager for MediFirst. Then backend architect for subscription-based ancestry website, MyHeritage. Followed by a series of Chief Technology Officer roles. Can you tell me how you chose each of these roles and how they kept you on the path that you wanted to be on?

[00:06:27] DM: Yeah, sure. Right after getting my PhD, it really felt natural for me to look for a job related to the biological field. That's why I kind of joined the first startup called MediFirst, whose purpose was to build medical software. Because in addition to provide me with the great feeling of helping people, it actually gave me a really good overall view of how to build a software from talking to the doctors to kind of understand their needs and then build the product, supporting it. The whole the whole process was kind of really interesting from end-to-end.

And then I moved to Israel. I was originally from France. Moved to Israel, got married and found another very promising startup called MyHeritage. Which again, kind of the same theme. Beyond the commercial aspect of the company, it kind of helps uh building family trees and reunite families worldwide.

[00:07:34] CS: Right. Okay.

[00:07:35] DM: Again, still in the magical field but a little bit further. And there, I learned a lot about how to be a back-end developer and just more about scaling issues. Because family trees worldwide, there's a lot of data there.

Then I got the opportunity to be a CTO the first time. And I learned a lot about cloud. And I did a lot of things as part of being a CTO. It was a very young startup. And so, frontend, backend, everything. This was my day-to-day. And beyond that, it also gave me a good understanding of the business, which is something that I didn't have before. That's the first time that I actually thought about starting my own startup. But I wasn't a founder there. I was only CTO.

A couple of months afterwards, I decided to jump into the cybersecurity field. And this is where I joined Cloudlock. I was very quickly in the CTO office there. And then it was acquired a couple of years afterwards by CISCO. And I continued working for the cloud security CTO office basically for four years until the Stars aligned and I decided to start my own startup together with the three co-founders of Cloudlock and a fifth co-founder. And that's really got me super excited. And this is where I am now.

[00:09:20] CS: I want to drill down in a minute just more about what a CTO does. Because, again, we're helping our listeners to understand what the different job roles are so that they can sort of decide where they want to focus their studies and their experiences.

But it sounds like it was a pretty natural progression. But do you feel that you specifically chose your career path based on the work you do now? I.E., you always wanted to found a company? Or did you choose your job roles knowing that this was the type of information you need to be able to do that? And then sort of adding on to that – I guess that's it. Yeah. No. I mean, which came first? Were you always sort of moving towards co-founding? Or did that just kind of happen as you were sort of learning and on your journey?

[00:10:11] DM: I would like to answer to you that this is something that I thought about 20 years ago. But it wasn't the case. It's actually really something that came naturally with the jobs I kind of tasted a little bit when I was CTO. But it wasn't the right start, the right setup.

And then I learned more. And the more I learned and the more I saw how startups are working, the more it actually got me into it. And when I got the chance, I just seized it.

[00:10:40] CS: That's great. Yeah. We've had a few people on the show who sort of described themselves as serial startup creators. They've done three, four, five startups in a row and then they just jump to the next one, jump to the next one. But this sounds like you were interested in – obviously, you talked about biology, and genealogy and the intersections with tech. And it just sort of chose you almost, the company calling.

We talked to a fair few CISOs, chief information security officers; and CEOs chief executive officers, but we don't get as many chief technology officers on the episode. For listeners who are just learning about this sector, can you tell our listeners about your day-to-day work as CTO at Jit and how that work differs, if at all, from past CTO roles that you held at companies that weren't toned by you?

[00:11:31] DM: Yeah. I would start by saying that the role of CTO is kind of one of the most versatile that I know. My day-to-day is really dynamic. It really pans on the priorities. I'm trying to constantly assess how to support the various teams in the company, whether it's engineering teams doing some consulting for them regarding technology and feature implementation or talking to architects. Supporting customers, of course. Everyone is customer obsessed. We're too, of course.

And beyond that, I'm also trying to help with strategical conversation about technical partnerships, or preparing conference talk, or podcasts like this one. As you can see, really rather busy days.

The difference between this role and the past role, I would say that, here, in addition to being CTO, almost a co-founder. And so, the big difference is that I have a different impact on the company. Whether it's in the vision. Talking to investors, something that wouldn't happen otherwise. I'm really trying to be a joker here and help everywhere I can. This is kind of my muzzle here. How can I help? Right?

[00:13:02] CS: Right. Speaking in a more abstract sense, what are some of the big responsibilities of a CTO in terms of the types of experiences, and certifications and qualifications you would need to have to be considered as an interviewable candidate for your type of role?

[00:13:19] DM: That's a great question, because, as I said, the role is very versatile. And so, I know very different types of CTOs. I know CTOs that are more hands-on. Those that are more strategic, business oriented. But I would say that, overall, I think that having a deep and wide technical background really helps. It's something that you want to be on top of what's going on. And so, you need to follow the technical trends.

One of the key elements is to be able to constantly focus on what's the most urgent and important. It may be true for a lot of roles. But as a CTO, because you can have an impact in very different areas of the company, it's really tempting to be drawn into various tasks. And at the end [inaudible 00:14:13].

I think that thinking out of the box is something that is a really nice addition to the role. Being good at multitasking, for example, is also something. I have a lot of context switch and being able to constantly – I know how to refocus and work on different stuff at the same time. That's really, really something important to be successful in this role.

[00:14:38] CS: Yeah. Yeah. And I think that's something we're keeping in mind if you're doing any kind of c-suite role, but especially CTO here, is that it's really important not to be sort of pulled into everyday emergencies. You have to be able to, I suppose, kind of lift over it and think in terms. Because as someone who is terrible at refocusing, it's real easy to just jump from crisis to crisis and then suddenly your three-month long-term plan is still on point one or whatever.

Do you have any particular strategies or tips for CTOs or c-suite people trying to keep the people who are putting out the fires on track with their long-term goals and the company's long-term goals?

[00:15:23] DM: There is one thing. Like beyond doing something like OKRs every quarter, there is something that I started to do not a long time ago that really helps focusing, is that every Sunday, in the morning, I'm writing an email to myself and actually to the whole leadership in order to get some visibility about what are my goals for the week. Because that really helps focusing.

And I'm getting back to this almost every morning to see how much I managed to get some progress in those goals. That helps me focusing on the things that are the most important to me. And also, it also helps me reassessing every week what should be the goal for the week.

[00:16:06] CS: Yeah, that's great advice. I think you can't go wrong by having a really, really clear picture in your head of what your week or your month has to look like. Because then you know how to sort of push through sort of these immediate crises and keep on top of things.

[00:16:23] DM: Yeah. And also, the fact that I'm sending this email to the whole leadership team, it also helps with setting expectations. They know exactly what they can expect from me in terms of time allocation. And so, hopefully that I don't get a bothered too much.

[00:16:38] CS: Yeah, absolutely. I want to move over to our topic of the day here. One of the things I mentioned on our last episode with Nir Valtman is that people in the DevOps space and, for all purposes, DevSecOps specifically, are always kind of listening to other thinkers in the space and are always building on each other's ideas. And I say that because we've now had several DevSecOps and developer guests in a row each of whom, like yourself, heard past episodes and wanted to keep the conversation going.

Nir, my past guest, talked about creating security protocols in the developer space with a view on how developer behaviors can be utilized productively. And how they need to keep in flow while developing? And how do we avoid severely compromising the security of allowing these sort of time savers into the flow.

But as I said at the top of the show, your philosophy and the tools you're creating specifically aim at shifting the overall tactics of software development from shift left. I.E. moving security earlier in the pipeline. And changing instead to born left, in which security is more seamlessly integrated into the process in a way that doesn't require lag times and slow down a project.

David, can you tell me more about the concept of born left? What's the actual process at work here?

[00:17:59] DM: Yeah, sure. First of all, shift left is a trend that everyone is talking about. It's built on the idea that developers needs to get information about the vulnerabilities of their codes before it hits production. The earliest you get this information, it actually helps you reducing the cost and the time of fixing the issues.

And mostly, it means that it starts by running the tools inside – some secret tools inside the CI/CD Pipeline. And sometimes if you're actually taking that even further, you can also use some ID plugin in order to actually get alerted right away while you're working on the code.

But one of the problems that I witnessed a lot of time is that the ones that are picking those tools are usually the AppSec team and they're not always sitting in the engineering organization. And so, that leads uh to a lot of developer frustration and friction. Because, basically, the AppSec team is trying to catch up all the time with developers towards their main goal is basically to deliver, to build the product and to deliver it to production.

And so, if you're a high-velocity team and you want to deploy your product multiple times a day, you probably are putting in place a lot of automation. You have infrastructure as code. You have a lot of processes that helps you doing that. But the kind of poor prioritized – the thing that is still not fully automated is security. And so, the fact that the AppSec team is kind of slowing every time, it is really a source of frustration.

The concept of born left is basically a process where not only you're moving, you're shifting the ownership of security to the engineering team. You're also embedding the whole security detection. All the aspects of security are now embedded in the software development life cycle.

And so, at the end, developers can treat security just like another developer software bug. W what does it mean in practice? It means that you can add security basically from the first line of code. But developers can pick the tools that are friendly. That helps them also with fixing the issues that can be automated, that can be integrated very easily into the CI/CD pipeline. That doesn't require them to enter into a different UI to see the results. All the things that at the end give them the proper information just in time in order to fix them.

[00:21:07] CS: Got you. One thing you mentioned in our discussion before the show was that your born left process in part was an orchestration platform to allow lean startups to implement security tooling while reducing the burden on developers. As such, unless I'm reading this wrong, it sounds like this is more like a baseline coverage program for understaffed new companies. Is there any reduction in overall security quality by using the system versus having dedicated AppSec members doing the inspection and audit work themselves?

[00:21:36] DM: Not really. The idea is that if you want to apply born life security in a viable way, you need some kind of platform that orchestrates all the required tools in order to have some kind of single pane of glass that would deal with all the aspects of product security in a consistent and centralized way.

And so, on the contrary, it doesn't reduce your overall security. It increases it. And the reason for that is basically that, nowadays, when you have security tools, most of the time, you're also relying on developers so that they will integrate those tools into their repo, into the CI/CD.

By having something that is centralized, you're basically reducing the load on the developer to introduce those tools and you're enforcing that at the level of the whole organization. And so, basically, all your assets are monitored in the same centralized way, the same consistent way.

And so, it doesn't reduce the security. You basically needs to decide what type of tools you want? How many tools? What areas you want to cover? And then you let the platform enforcing that policy consistently across all your assets.

[00:23:02] CS: Got you. Well, yeah, I mean, turning to the developer side of the equation. And you basically just said this. But I want to reiterate it. You had a blog post where you said when developers build solutions for their own kind, they do things differently. After all, nobody understand the pains better than they do.

As you were just saying, this sounds basically like born left is essentially putting the responsibility of security defects and issues into the hand of the dev team to resolve as they swim in the code all day and will find it easier to take on. Is there any concern here that devs will use this newfound autonomy to implement solutions that might be faster or more efficient but are less safe? Is there any accountability issue for quality at work here?

[00:23:43] DM: I don't really think so. Basically, if you're looking at it, developers are ultimately the ones that are building the product. Now, usually, they're not necessarily security experts. And so, if there are some security issues, that's not because they're doing that on purpose. They just don't have enough tools, enough knowledge. And they are not getting the information in time in order to fix it.

But if you think for a minute that you would provide them with all the information about the security vulnerabilities of their code while they're working on it, and you also suggesting them what the fix can be, I don't think it will actually be an overheads to fix them. They will definitely – no one wants to deploy code that is not secure in production. In the same way that they don't want to deploy code with bugs in production.

If you manage to provide them with the proper information at the right time while they're working out without the overhead of context switching, basically you're considering all the security tools like security review of a peer. And that would include also some suggestions for fixing. I think that's all the developers will be able to fix them like they're fixing any bug before production, you know?

[00:25:07] CS: Okay. Within this framework, what role does an AppSec professional play if any? Are we looking to remove the sort of application security department in moving towards born left?

[00:25:24] DM: I don't think so. First of all, I think that if you're thinking about what would be the most efficient engineering organization, there is definitely a place for AppSec. But the AppSec needs to be closer actually to engineering. It's instead of uh sitting outside of it, especially for the part that is focusing on the product, you definitely want them to be as close as possible to the engineers.

[00:25:54] CS: Got you.

[00:25:54] DM: Now, AppSec, DevSecOps, they all need to be there. And they will be the one who actually can influence and impact what tools and what area of your product you need to secure. And if there's some questions regarding how to fix, or can I ignore this vulnerability, they can definitely help there. I really don't see a future where there's no AppSec or DevSecOps. The fact that you have more automation is just a way to facilitate and help with the velocity.

[00:26:30] CS: Okay. Yeah, I appreciate that. I'm trying to sort of square this all in my head. Apologies if I'm sort of stretching this out a little bit. Basically, what I'm hearing, and you can correct me because I might not be hearing it correctly, is that, by using born left, you're dealing with security issues that are happening in the moment of creation. Things that are probably easily fixed with applications and solutions. Whereas the sort of SecOps, DevSecOps roles would be more of like an overall sort of security plan that would sort of look at like sort of like the final product and make sure that it's secure? Or am I getting that wrong?

[00:27:18] DM: No. You're not getting that wrong. But if you're thinking about, let's say, adding security not on day one, at the end, you also have some kind of backlog that you need to deal with. You also have to prioritize the issues there.

And though platforms can help with prioritization, at the end, I think that it's also the role of the DevSecOps to actually help triaging the right thing in order to see what are the most important critical stuff you need to fix.

[00:27:52] CS: Okay. In that regard, the platform, the born left platform type thing, is also sort of a prioritization thing. Because there might just be too many problems to fix and to still get it out on time. Is that sort of the idea?

[00:28:09] DM: Yeah. The way I see things that, not everyone can introduce security from day one. That would be ideal. But if you're not, then what should happen is that you're getting the information about security issues in real-time. And so, you're fixing the new stuff before dealing with the backlog.

There are some physical backlog that you want to fix. But basically, you're ensuring that you're not increasing your security debt. And then as a separate effort, you're dealing with the backlog. Because usually, a backlog is huge, you know? And so, you want to help with prioritizing the backlog. While on the other hand, you're still uh dealing with the current new stuff that are coming –

[00:28:54] CS: And also, you're not adding to the backlog by just letting the errors go through. Okay, that helps. I'm trying to imagine it in my head. A little ADHD. And it almost sounds kind of like the way like Grammarly works. Grammarly doesn't like change your writing style. But it'll make sure that you hit those apostrophes in the right spot and stuff like that. There still has to be the overall sort of crafting of the app. And as you said, going through the backlog.

Okay, that's very helpful for me. I didn't mean to sort of bang on that. But I wanted to make sure that we weren't putting security people out of business or closing off their job opportunities.

Near the end of your piece, you noted that born left is still in its infancy and is being improved in real-time. Using this approach, what do you see born left and your platform looking like in two, three or even five years down the road? In your prediction, would the entire process of DevSecOps look different by then?

[00:29:53] DM: Well, I believe that in the future no one in its right mind will start a new project without introducing security from day one.

[00:30:03] CS: Yes. Okay.

[00:30:04] DM: From the first line of code. I think it will be an integral part of developing software. And like in the past, QA was something like an outside function. Usually not part of the development team. And progressively, it's an integral part of building and deploying some code to production. And developers now are writing unit integration tests, end-to-end tests.

I believe that, at the end, security will actually follow the same path. It will be part of the same embedded way of writing software. And like you're writing unit test, integration test, you will write security tests. And you're unsure that all the tools are in your environment. When you want to deploy some code using CI/CD, there will be the tools in production in the CI/CD pipeline from day one.

[00:30:58] CS: Got it. That's great. I appreciate the clarification there. That makes sense. I want to talk with regards to people entering this particular space. Because, again, I feel like we threw a lot at people. And especially if you're a newcomer and so forth, for students and people trying to get into the software developer space and especially the security aspects of the job, or just being a developer that has a little bit of security in their toolbox. Can you talk about some skills, or experiences, or projects, or other indicators of competence that they should be doing and listing on their resume to help them stand out?

[00:31:34] DM: Yeah, definitely. I think that one of the major drawbacks of most of the programming course that I know is that they're not dealing with security. They tell you how to write either code that is clean, with good hygiene, that can support scale, with good design but they're not really touching security.

And so, for example, for any student that wants to have the first encounter with security, I would really encourage them to take a look at the OWASP top 10, which is no the most common risks that you can encounter when you're dealing with code.

And so, that's one thing. And the other is basically getting familiar with the basic tool for code scanning, like static SaaS, SDK, dependency-check and secret detection. That would be my advice how to kind of stand out. Because most of the people that are applying for a job, usually they're listing the frameworks or the language that they know. But very few are actually showing that they know how to write secure code.

[00:32:49] CS: Right. Yeah. Yeah. And one of one our 12 sort of career paths is secure coder. And we're always encouraging people even not – who don't want to sort of lean right into that to still have that knowledge in their back pocket. I mean, there's so many other applications for it.

Yeah, I mean, do you think – because you were saying that there is – there is kind of that divide between like developers? And we say, "Oh, well, developers don't need to know security stuff. Or they don't know security stuff." And so, we need to sort of like have this support thing. Do you think there's a benefit to having developers have at least a little bit of security knowledge? And then vice versa, SecOps people having more than a little bit of like developer knowledge so that there's more of a give and take there?

[00:33:39] DM: Yeah, definitely. I think that, first of all, any company that has kind of evolved from a very immature in terms of security, to a little bit mature, or doing some compliance process needs to go through some security training.

And so, yes, of course, it helps. If you have some basic background in security when you're a developer, it's definitely helping write secure code from the start and not having to deal with that afterwards.

I think that if you have some great tool in your environment, they can definitely help you with getting the knowledge that you need. Every time you're getting some vulnerability, you need to understand why it's a vulnerability. And you can learn on the way. But definitely, starting with some basic baseline, it helps.

[00:34:35] CS: Okay. I guess one last piece of advice I would like for people who are a little nervous about dipping their toe into this. Could you suggest like one thing they could do once they turn this recording off? What's the first step they could do if they feel like they're stuck in a help desk role? They feel like they're stuck in their current job and want to make a big shift. What's something that you could do online tonight, today, whatever, that would put you one step closer to being someone in a development space or the DevSec space?

[00:35:06] DM: Well, like I said, beyond maybe asking some security questions to ChatGPT. I would say that going to OWASP is a great resource. You have a lot of tools there. You have a lot of code. So you can really experiment how security can work. You can see how code can be vulnerable and why it's vulnerable. Definitely a great set of resources there.

[00:35:29] CS: Nice. As we wrap up today, we discussed your job, task the CTO of Jit. And you talked about this platform for born left. But if you want to discuss your company more and go into more detail with the types of services you provide, here's your chance to do so.

[00:35:43] DM: Thank you. Basically, Jit is the only DevSecOps platform that is built by developers for developers. It comes with a lot of built-in security tools that are applicable to any cloud application where, basically, you can onboard and be operational minutes. And that's really something that stands out when you compare to all the platforms.

It's based on a security as code framework. And the idea is that it's very extensible and can support a lot of different tools. We're currently orchestrating some tools. But the idea is that, at some point, we'll open that to the whole committee. And so, anyone can add the tool that they. We're not vendor-specific.

[00:36:32] CS: Right. Right. Yeah.

[00:36:33] DM: And beside that, our goal is to cover all the aspects of product security. Meaning we are currently covering code security, pipeline security, infrastructure security, runtime security. All these different aspects are covered under the same roof. And that's something that is really important. Because as I said, if you have a single pane of glass, you can have really an overview of all the different fields.

But what's really important here is that the platform is very friendly for developers. And what I mean by that is to let the developer work in their own environment, in their native environment, and don't need to go into another UI. That's why we're providing them with all the information about security in PR, in the PR, as comments really at the right time. Just in time for them to fix that. And hence, the name of the company, Jit, just in time.

And beside that, we're also offering a lot of visibility on your whole assets. And something that is very important when you're thinking about security tools is that we're also providing security performance KPIs in order to evaluate if, thanks to Jit, you're basically progressing with your security posture. If you're getting better. If you're developers are doing a better job, thanks to the comments that we're adding inside the PR and the suggestion for [inaudible 00:38:14]. They're also learning with the time. And so, Jit is supposed to catch less and less security issues and the velocity will increase.

[00:38:25] CS: Yeah, never a bad thing when we increase our security posture while making things easier.

[00:38:31] DM: Yeah, definitely.

[00:38:32] CS: Yeah. One last question, then I'll let you get on your way here. If our listeners want to know more about David Melamed or Jit, where can they go online?

[00:38:39] DM: First of all, they can find me on LinkedIn or Twitter. And if they want to know more about what we're doing, visit www.jit.io or send me an email directly at david@jit.io.

[00:38:53] CS: Great. And you encourage our listeners to get in touch with you? Because I know they will. I know they will. All of our past guests have said that they've had some very nice interactions with our listeners. I'm thrilled to hear that.

Well, David, thank you for joining me today. I really appreciated you sort of breaking down some more innovations for DevSecOps here.

[00:39:15] DM: Thank you very much. Thank you for having me.

[00:39:17] CS: And thank you all who have been listening to and watching the Cyber Work podcast on a massive scale in 2022 and 2023. We're awfully glad to have you along for the ride.

Now before you go, I just want to invite you to visit infosecinstitute.com/free because we've got a whole bunch of free stuff specifically for Cyber Work listeners. Our new security awareness training series, Work Bytes, features videos with a host of fantastical employees, including a zombie, a vampire, a princess and a pirate. Making security mistakes and hopefully learning from them.

Also, make sure to check out our free Cyber Security Talent Development ebook. It's got in-depth training plans for the 12 most common roles, including SOC analysts, penetration tester, cloud security engineer, information risk analyst, privacy manager, secure coder and more. Lots to see. Lots to do. All you got to do is hit www.infositeinstitute.com/free and check it out for yourself.

Thank you once again to David Melamed and Jit. And thank you all so much for watching and listening. Until next time, have a great week.

[00:40:16] DM: Thank you.