Supply-chain security and servant leadership

Chris Sienko: 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 and offer tips for breaking in or moving up the ladder in the cyber security industry.

Manish Gupta is the founder and CEO of ShiftLeft, an innovator in automated application security and the leader in application security for developers. He previously served as the Chief Product and Strategy Officer at FireEye where he helped grow the company from approximately 70 million to more than 700 million in revenue growing the product portfolio from two to more than 20 products. Prior to this he was the VP and product management for Cisco's two billion dollar security portfolio. He also served as a VP GM at McAfee and iPolicy networks. Manish has an MBA from the Keller Graduate School of Management, MS in engineering from the University of Maryland and a BS in engineering from the Delhi College of Engineering.

Our topic today is supply chain security. We're going to learn about risks and cyber attacks related to the continuous integration, continuous deployment, or CI/CD pipeline, which given the high profile attacks of things like SolarWinds will give us plenty to discuss this week.

Hello, Manish, and welcome to Cyber Work.

Manish Gupta: Thank you, Chris. Looking forward.

[00:01:28] Chris Sienko: So I always like to start out by getting people's origin stories here. How did you first get interested in cyber security and computers and tech? Because I look at your career history and it seems that you started out in the engineering field along with an MBA in finance. So when did the cyber security itch get you?

[00:01:44] Manish Gupta: Yeah. Actually one of the things that's not on my LinkedIn profile is my first job. Right after my master's I work for a company called Cheyenne Software in New York. And while Cheyenne became famous for its tape backup systems, it was one of the early companies working on antivirus, AV. And that was sort of my first exposure to cyber security, and it was very intriguing because I just graduated and this whole notion that another piece of software could unknowingly infect a machine and do things that it's not supposed to do was very intriguing and that there were people who wanted to do, write that kind of software.

[00:02:38] CS: Right. Yeah. So that was sort of a whole new area of exploration for you and you were able to just sort of make the move away from what you were doing before.

[00:02:47] MG: Indeed. Yeah. Well, this was my first job right after my master's in engineering. And so typically when you leave school and you go get your first job, you learn a ton because that's the first time you're getting exposed to the industry. And this is ’94. So this is pre-Internet, etc. There is not so much uh readily available to learn that it is now on the Internet.

I was there for a short time. I realized that I was not very good at software development. Whenever I wrote software, it was all about trying to get it out as soon as possible with as many features as possible, and I hated unit testing. I hated to test my own code. I realized that therefore software development was probably not it for me.

[00:03:37] CS: Yeah. Well, I think that's also a good thing to keep in mind for our listeners who are often listening to these things to try and figure out what they want to do. It's really important to know what you want to do, but it's really important to know what you don't want to do. And just because you think, “Well, this is a very prestigious type of job or it pays well or whatever.” Like if you're going to be miserable doing your code tests and stuff like that, then there's no reason to just keep going just because you thought you were going to do that before you had all the information, right?

[00:04:03] MG: Indeed. Indeed.

[00:04:03] CS: Yeah. So tell me a bit about the major stepping stones in your career, especially your cyber security career. So you had some pretty impressive company names in your background, Cisco, McAfee, FireEye. Like what were some of the accomplishments or successful projects or just aha moments in these jobs that help you moved up to the next level of your career?

[00:04:22] MG: Sure. From a cyber security perspective, a company where I had a lot of fun was iPolicy Networks. A few today remember iPolicy, but back in 2005 we were the first company in the industry to create a next generation firewall. Would you believe it when I tell you that Gartner coined the term next generation firewall for our product in 2000?

[00:04:49] CS: Wow. Okay. Yeah, that's a historical moment.

[00:04:55] MG: Indeed. It was super fun, but we were clearly early. Yeah, at the end of the day, there is also I guess a lesson to learn in the sense that sometimes you have the right product, perhaps not the best implementation because you're still trying to figure it out, but the market is just way too early. And so iPolicy didn't really have a great outcome. But that, truly after my Cheyenne days, gave me exposure back into cyber security. So I left iPolicy to go join McAfee.

My biggest accomplishment at McAfee was one of my flagship product lines is the network IPS, network intrusion prevention system, back then called IntruShield. And we grew that business from about 100 million run rate to about 300, 350, grew that product portfolio. But for me the key learning was at McAfee and at – Truly, at McAfee, was my first sort of visceral understanding of malware. This is a problem that is just going to continue to expand.

[00:06:08] CS: Yeah, that was really when I remember it like being like everyone knows about it. It had been around before that, but then it was like, “Oh! This isn’t just like for eggheads or this isn't just for people who are on computers all day long.” Like this is going to start hitting everybody, right? That was sort of the tipping point.

[00:06:24] MG: Indeed. And with the IPS, especially with the network-based IPS, it was a technology designed to find worms. And if you remember back then, Conficker kind of worms were very, very fast spreading. So, yes, we had the early days of the viruses, but they were not as fast spreading as worms because that was the very intent that they were written for is to spread through the network very, very quickly.

So at McAfee that was my key learning. That took me really short stint at Cisco, nothing great to write about that except the eighth months that I was there. My key accomplishment at Cisco was to create an M&A strategy, which unfolded after I left in the sense that cisco went and acquired Sourcefire because security was one thing that John Chambers and the team agreed that was going to be a lot of – There was a lot of potential for growth for Cisco. And we had a good product portfolio. It was about two billion dollars strong back then, but we really didn't have security. We had what I call firewall business or policy business, but truly nothing that detected malware. Because to me that is where how I break down security. Yes, firewall is a security device, but unless you're detecting bad stuff, you truly don't have an appreciation for what it takes.

[00:07:48] CS: Yeah. Right. Yeah, that makes sense. Now I want to jump back to a thing that you said. You're talking about your work with iPolicy and that you had created this this product that you think was a few years before its time and it sort of withered on the vine. And you hear those kind of stories all the time. And I mean do you have any lessons that you took from that? Like if you're working on something and you're so ahead of the curve and you can tell like the market might not be ready for this yet or you can just see that happening, like the demand's not here yet, but it will be soon. Do you have any like thoughts on how to sort of keep it going? Is there anything you would do differently now based on that sort of thing? Or is it just we took a gamble and it didn't work out.

[00:08:33] MG: No. I think you always have to learn lessons because there is at the end of the day some mistake that you made. To just blame it on the market, I think it's short-sighted. You're not taking the time to learn and grow as an individual. So in hindsight, and I’ll tell you, I left iPolicy. I joined McAfee, and at McAfee we were wondering. People were asking me, “Hey, should we invest in next generation firewall?” We had the basis with the network IPS, but we could have developed a firewall on top. And for longest time I kept saying, “No. That market is dead. That market is going to be dead.”

And as I started analyzing it, and to be honest it was admittedly based on also the success of Palo Alto Networks, and the thing that Palo Alto did really well was it did not come out of the gate and say, “Hey, you know what? We have a next generation firewall and it will replace your Checkpoints and Cisco’s and Junipers.” No.

What it first came out with was here is a device that is complementary to a firewall. It will sit on the network as a passive device telling you what's going on port 80. Because port 80 was relatively new, the usage of Internet was relatively new. And so very few people really had an understanding back then of, “Hey, what all is going on HTTP?” Yes, you're going to Facebook, or Google, or maybe something else. And that strategy of a Trojan horse, planting a Trojan horse and then growing it from there I think was the key distinction between Palo Alto’s strategy and iPolicy’s strategy and why Palo Alto was successful but we weren't.

[00:10:21] CS: Okay. That's fascinating and I think that's a really important takeaway for our listeners here. So I want to talk about your average work day. Like what is what is it like as CEO of ShiftLeft? What are some tasks and projects that you do every week? Do you have a favorite part of your job? Do you have parts that stress you out on Sunday nights as you contemplate your work week?

[00:10:42] MG: Wow! That is a good question, long answer.

[00:10:48] CS: Yeah, it’s a bundle.

[00:10:50] MG: Yeah. I’ve subscribed to the servant leader philosophy, Chris. What that really means is I do what is not getting done. I do what perhaps someone in the company is not having as much fun doing. And being a startup there'll always be times when a certain role you've not hired for yet. For example, in the first two years at ShiftLeft I was doing product management. Then we hired a VP of product management. And product management came natural to me. That is my background. Once we hired the product management leader in the company, I started doing sales. And so I have been the acting VP of sales at ShiftLeft for the last two years. And I just hired our VP of sales early this week. So now I’m going to be shifting into sort more of an outbound role, where at ShiftLeft we've been very focused internally trying to develop the best product we can. We have it now. We are seeing success in the customer base. We have hit the product market for it. Now it's time to scale. And so, yeah, my role is now going to be more outbound.

There are a few common themes across regardless of what – At the end of the day my day job is still being a CEO. And there are certain common themes. Those common themes are mostly revolving around people. We are a remote-first company. Even though we are about 50 people strong, we have employees in about 10 countries. So we are highly distributed. So how do you keep that employee base engaged, motivated? How do you hire? What HR and compensation strategies do you put in place? How do you enable teamwork? How do you reward employees? How do you make sure? One of the things that became a new thing during COVID was how do you prevent people from burning out?

[00:13:03] CS: Yes, for sure. That's something you take on personally as well then as CEO.

[00:13:10] MG: Right. Yeah, and that's one of the things – Those are the things that perhaps that keep me awake on Sunday nights. Going back to your question, is how well is our team doing? How well are our employees doing? Because there are three key stakeholders at ShiftLeft. The number one for me is employees, because if the employees are doing well, they'll develop a good product, which will please our customers. And if customers pay money and they like ShiftLeft, then our shareholders get paid at the end of the day. So perhaps a slight twist on usually most companies will put customers first. And very much we are a customer-first organization too in that sense. But, no, for me it's the employees that are most important.

[00:14:00] CS: That's great. So I want to talk today. Our topic we chose was supply chain security, which obviously is a big part of what ShiftLeft does and is a very large topic. That's probably more than we could get to in an hour today. But to start briefly, bring us up to speed on the issues around supply chain security especially in regards to the concept of the CI/CD pipeline, short for continuous integration, continuous deployment, or continuous delivery. So what's the scope of the issue as you see it based on certain attacks that have been happening lately?

[00:14:32] MG: Yeah, I think the scope of the issue is the software that we are developing today using the modern CI/CD approach. Now that software fortunately and unfortunately has lots of bits and pieces. It includes custom code that the organization has written. It includes dependencies, libraries, open source libraries as they're called, because why should someone develop everything from scratch if, for example, there is a library that gives you a shopping cart functionality and then third-party APIs? Modern applications especially SaaS applications do a lot by talking to each other. You get customer support function through another company and you don't need to build in the product. So at the end of the day that is the unit that creates value for any company. That is software-based, which is the software. It has lots of bits and pieces into it that go into making that software. So that's one part.

The other part is, as you pointed out, modern CI/CD. Gone are the days when we would get one soft release in six months. There are now companies like AWS, let’s say, that they're making 10,000 changes a day. That’s a huge disparity between where we used to be and where we are. This is a great space to be in, because when did we get such feature functionality on an hourly basis?

[00:16:05] CS: So fast. Yeah, sure.

[00:16:06] MG: Exactly. You log into Netflix, and wow! There's something cool now that I didn't see.

[00:16:11] CS: Yeah, a three-second upload change, and suddenly the whole thing's repopulated. Yeah.

[00:16:17] MG: Exactly. And so that is to me the unit of value but also the unit that we need to do a better job at securing.

[00:16:27] CS: Right. I mean if you have 10,000 updates, that's also 10,000 open doors waiting to be exploited.

[00:16:34] MG: Indeed, and therein lies the challenge. That is precisely the reason I started ShiftLeft four years ago, Chris, because having been at FireEye and Cisco and McAfee, we talked about malware, that was what I was focused on for 15 years of my career. And it was at FireEye, when I was leaving, we were seeing hundred thousand pieces of malware a day, new malware a day. Wow! And this problem, we talked about this earlier, this is going to continue to grow in size and magnitude and complexity. And it's like, well, I’ve spent 15 years of my career trying to detect something after the bad guy has already taken the initiative. We are always fundamentally reactive in security. So that's one part of the problem.

The other is, as you pointed out, hundreds of changes in a given day and that software is automatically enhanced and deployed in the public cloud for the world to be able to access. It's like, “Really? Is that how security is going to work, is we’ll constantly just keep writing algorithms for detecting new malware and trying to protect this ever-changing software?” I came to the conclusion that that's just a recipe for disaster.

[00:17:45] CS: Okay. So talk about that then. Like what is your alternative in that regard?

[00:17:50] MG: Yeah. So I felt, and I still feel today very sincerely, that the only way we are going to get better at security is if we learn how to write secure software. If you're going to make 100 changes every time you make a change, you have to ask yourself, “Did this change cause of vulnerability that a bad guy might exploit?” Now, SolarWinds showed us another aspect of that problem. Is this change made by a legitimate software developer who works for me? Or was this change made by someone rogue?

And so if software is the engine of innovation all around us, and if that software is changing hundred thousand times a day, every time it changes we have to be able to inspect it for all of these things. And what are those things? Number one – So this perhaps is like your question of supply chain of software. What are the various issues that we need to think about? So it starts with, “Well, does this application have vulnerabilities that can be exploited?” Number two, “Does this application have secrets that it is leaking?” So, for example, some developer unknowingly hardcores AWS key and puts it on an HTTP. No hacker needed to do anything. You just ended up leaking information. Third, am I using any software library dependency that is vulnerable and makes my application vulnerable? Same thing for the APIs. By using an API from a third-party company, that has a vulnerability and makes my application vulnerable.

[00:19:47] CS: Yeah. Yeah, and a lot of people aren't even thinking about that.

[00:19:51] MG: And lastly, with the SolarWinds attack, has someone, be it a rogue developer, be it a rogue contractor who works for me, or be it an APT actor that penetrated my perimeter and became a developer and started contributing code? So that's the fifth part, which does my software contain back doors implanted by someone for malicious purposes? Now, that is today's definition of I think what software supply chain security means.

[00:20:27] CS: Okay. Now, I want to sort of move from that to some of the large-scale responses that are coming out. So as reported last month, the president signed an executive order directing federal agencies to conduct a review of supply chain security risks in industries including information technology, which clearly shows the scope of the issue and its relevance on a federal and countrywide level. What do you think the actionable consequences of this executive order can or will be? Have you seen federal supply chains enacting reviews or recommendations based on this request? And what's the plan of action based on these reviews?

[00:21:07] MG: Yeah. First I’ll give you my perspective on the whole software bill of materials, the S-bomb as it is being called. The intent is correct. Let's just start with some of the most security conscious organizations, three-letter agency, Department of Defense, etc. If they are building an application, if they're building a widget, if they are building some module for a fighter jet that contains software, they should know whether that software contains dependencies that were written by someone that they didn't want, they weren't aware of. And so, yes, to that extent I think it makes sense.

But largely I believe that the value of something like an s-bomb is limited to those extreme examples, because imagine, a modern app company, which has a SaaS application like Amazon, like Workday, like Salesforce, the code that they have is humongous. If we asked amazon today to publish their S-bomb list of dependencies that they use, I bet you it runs in the hundreds of thousands. Okay? So now the S-bomb asks Amazon as one company to, “Hey, publish your list of dependencies,” and we get a list which is a hundred thousand long. Okay. What are we supposed to do with that?

[00:22:35] CS: Right.

[00:22:36] MG: So the first, really what we are after, is, “No. No. No. We don't want all the list of dependencies that you have. That's for you to know, Amazon, to make sure that you're doing the appropriate diligence. To making sure that you're using software written by people who you want to be consuming software from.” But really as consumers of software, what we want to know is, “Hey, are you using dependencies that have vulnerabilities?” Okay. So out of the 100,000 maybe ten percent of those, so let's say ten thousand dependencies now have vulnerabilities. Now is that really what we want? And, again, I come to the answer no. What are what are we going to do? We are going to force Amazon to say, “Yeah, you got to upgrade all of these 10,000 dependencies?” And I think this is where the software composition analysis, which is a part of code analysis industry has fallen short, is all they talk about is, “Hey, here is a list of dependencies that you need to upgrade,” and dependency upgrade process is not free. It takes time.

So really what we are after, and I think this is the key, really what we are after is for organizations to tell us if they are using vulnerable dependencies that make their application vulnerable. If we continue to whittle down to that – I mean, our analysis amongst our customer base, Chris, shows that using our approach of what we call prioritized software composition and analysis where we are not just detecting for dependencies that are vulnerable, but we are actually looking at dependencies who, which have vulnerabilities, that are attacker reachable, because that's what we're after. Then we can reduce the list of dependencies that need to be upgraded by 93%.

[00:24:26] CS: Okay. Yeah, you're not just pulling everything out of your closet. You're actually getting the points where things can get in.

[00:24:32] MG: And I think this at a higher level is where I believe the code analysis, code security industry has failed, because we have historically just given a bunch of information, lists of hundreds and thousands of vulnerabilities and dependencies to the developer. Application security kind of did its job, “Okay. Developers, here is a long list of things that you got to go fix.” Now, what is a developer supposed to do? He's got a day job. He has to write code. He has to deliver features. Remember those exciting Netflix features that we talked –

[00:25:03] CS: Oh, yeah. Yeah. Yeah. You can't stop doing that.

[00:25:05] MG: You can’t stop doing that. That generates revenue. So of course, we essentially force the developer to choose between writing a feature, delivering new functionality, or fixing a security issue –

[00:25:16] CS: Or burning them out. Like you said, is the big problem as well.

[00:25:19] MG: And 99% of the organizations in the world will choose delivery of the feature, and here we are.

[00:25:26] CS: Yeah. I guess two questions. If you were to rewrite the legislation or the executive order, what would you recommend versus this full-scale audit? And, two, does such a thing even need to exist or I would you have sort of gone at this problem in a different direction?

[00:25:44] MG: I would have gone off to this problem. Again, as I said earlier, the intent is right, but many times government regulations look at technology that is available a decade ago as opposed to technology that is available today. Again, if my logic of what the government wants out of S-bomb is to get a list of vulnerable libraries that makes the application vulnerable, then they ought to be using something like prioritized SCA to get at that accurate list of dependencies.

Now the question – To be honest, there is a bigger problem with the whole S-bomb, but maybe the government, maybe they can come up with a third-party where this information is stored. Because the list of dependencies that a company uses, if that company tells it to the world, the company is giving out a lot of information, which is their intellectual property. So I am not so sure companies are going to be that willing to just disclose the world, “Hey, here is how my software is developed. Here are all the dependencies that I use.”

But nonetheless, the intent is that if software is becoming as ubiquitous as water for example. And if SolarWinds infected a particular piece of software, it's kind of like infecting the water supply. And if that analogy can be extended to supply chain, meaning as a hacker I could implant over time a back door into a dependency, which then gets used by hundreds of thousands of companies around the world. Then imagine how far-reaching my impact can be as a hacker? So those scenarios in mind, the intent of S-bomb is correct. But like I said, it just needs to be informed by the latest technologies that is available.

[00:27:46] CS: Yeah. Now I want to pivot from policy like this into the sort of day-to-day work of this type of work. This is obviously a cyber work podcast. What types of jobs are there to be had with working on strengthening the security of the supply chain? Like what are the main skills, backgrounds, or certs, or experiences that someone would need to do, the type of work that needs to be done to sort of patch these holes or find these vulnerabilities or make these changes?

[00:28:13] MG: Oh, this is an exciting time to be a software developer. You just graduated in the last three or four years, you have started coding for the first time in a Git-based environment. You are used to microservices, agility, dependencies, pull requests, peer review, you're just used to inherently all of these concepts as opposed to having learned them over time. So in terms of supply chain, look, there are so many things at a higher level, and we can then double click. But at a higher level, if we agree that software is one of the most important things in the world today then how that software gets developed is equally important. And the various bits and parts that result in that software development are equally important.

And so as a software developer, if you're working on any of those pieces, you have just tremendous value to create. And if you can innovate – For example, in case of SolarWinds, what really happened was at the very last minute when the code was being compiled, the APT actor had infiltrated, penetrated the perimeter, landed up on the build server, put a malicious DLL on that build server. And at the very last minute, in a matter of milliseconds, compiled that malicious DLL into the application that SolarWinds was shipping. Hard problem, hard problem. But all kinds of things come up, “Hey, what about access control of the build server? How limited should it be?”

Now, one could come up with some easy solutions like, “Hey, maybe we should just do hashes of the software that is being shipped versus the software that is being developed.” But hash collisions mean that we can bypass issues. We can do what ShiftLeft does, which is let's just analyze this software from the ground up again to see whether it has back doors. But perhaps there are other more creative ways to think about this approach as well.

So there are just so many facets about software development, which is why you see so much innovation in this space. Application security until about three four years ago was an afterthought on cyber security. While we spent about 30 billion dollars on network and endpoint, i.e., the perimeter, which is mind-boggling to me even though I was part of that industry. For 20 years we've been spending about 30 billion dollars a year and still we continue to get breached. Whereas the number one thing that is important today and especially for SaaS companies, because 100% of the revenue is being generated by this very piece of software or application that is deployed in the public cloud, 100% of their revenue is being generated by this application, yet the amount of spend that we make on application security in a year is a billion. So a billion for protecting or getting better at writing software securely, 30 billion dollars to protect the perimeter, which we know well just never works.

[00:31:26] CS: Yes. Right.

[00:31:28] MG: So that is I think the upheaval. That is the soul surging I suppose that I did four years ago, and I think we are starting to see the industry uh starting to realize in the last year, year and a half. I can't tell you how many companies I’ve talked to who tell me, “Manish, one of my key priorities is shift left.” Not the company shift left, but this notion that I got to move security left as a developer.”

[00:31:55] CS: Nice. So what tips or advice would you have for people who are trying to get into this type of work? So if you're just studying cyber security now, or as you said, you're just a couple years out of your studies and you're casting around for your first job. What are some things that you should be working on now and putting on your resume to let employers know that you're ready to sort of defend the supply chain?

[00:32:15] MG: Yeah. That's a tricky question to answer because there're so many aspects. I suppose you just have to find your passion as a developer. What aspect of the software supply chain really interests you? Because there's so many problems to be solved. And if you don't really have a good sense, there is no better way to just jump in and figure out. And maybe you go work for a company and maybe you'll work on a problem that you don't get so excited about, but at least now you know what is one thing that you don't get so excited about.

[00:32:48] CS: Right. There you go.

[00:32:50] MG: Right? Not knowing what is it that you want to do. And every job, no matter how bad it might seem, is a learning experience. You have to look at it that way. And you're going to be better regardless of what part of this problem you work on, because this problem is not going away. This problem is only going to get worse.

[00:33:10] CS: So for people who are looking for their first job and have that sort of can't get experience without a job, can't get a job without experience paradox, do you have any sort of suggestions for sort of showing your aptitude for this type of work for people so that you can get your foot in the door?

[00:33:25] MG: Yeah, absolutely. Look, I would say, because I haven't done this analysis, but so it's a ballpark estimate, but 80% percent of engineers, software developers at ShiftLeft had no prior security experience. So one of the – Before ShiftLeft, when I used to hire engineers, the hiring process was very different, because when you’re hiring a software developer, you are trying to assess his or her ability to write a piece of software, to think creatively, to think about a problem and to think about creative solutions, and that was hard to do unless all of these things kind of happened at least in the same time zone, if not in-person. But one of the things that has happened anew in the last few years is the emergence of GitHub. You're truly passionate at what you do. You can start contributing to open source libraries. And guess what? That is actually how we find most of our talent.

[00:34:32] CS: Oh, nice. Okay.

[00:34:34] MG: Which is why this was not an organic strategy to go hire folks in like 10 different countries. This happenstance is we were looking for someone who was really good at graph databases. And guess what? We found that person in New Zealand because of contributing to an open source graph database and we really liked the code that he had written. Again, I think there is no substitute, and it might seem trite, but follow the passion. Follow your passion. Do what you really like to do. Just start contributing to open source.

[00:35:09] CS: Okay. That's a great place to wrap up here. So as we finish today, tell us more about ShiftLeft. What are some of the projects or services or initiatives that you're working on for 2021 that you're particularly excited about right now?

[00:35:22] MG: Yeah. So if you go back to the five problems that I talked about from a software supply chain security perspective, Chris, so far we have delivered the first part of it, which is static code analysis, to find vulnerabilities in your application. The next set of things that we're going to be launching are the prioritized software composition analysis so that we get to reduce – We give you far more accurate information on what libraries actually make your application vulnerable and reduce your workload by 93%. The third key initiative that we're working on is education. One of the things that we learned, we were asking our customers, “Hey, we're displaying these vulnerabilities to you, but your developers aren't fixing them. Let's go talk to developers.” And you know what? It's not that developers have bad intentions. The challenge is many of these developers, they've just recently graduated from college where they never took a cyber security course. So they're looking at the screen which says SQL injection and they're wondering, “What is it? How will it impact application?” Like, “What will happen if I don't fix it?”

And so in context, so right at that very time when they're looking at SQL injection vulnerability at ShiftLeft, we can now educate the developer. So just-in-time training, this is what this means. This is what might happen if you don't fix it. These are the implications. This is how you go fix it. So that's the third part. The fourth part is how to detect back doors software. And so this is an area where I believe we're going to be the first company to bring together two very important concepts in security, and that is code analysis and the MITRE ATT&CK framework.

[00:37:16] CS: Oh yeah.

[00:37:17] MG: And there are two separate things. Code analysis is looked at from a code perspective and MITRE ATT&CK framework is looked at sort of typical targeted attackers, but these two worlds are merging as it happened with SolarWinds.

[00:37:29] CS: That make sense.

[00:37:30] MG: So how to think about that cohesively is going to be sort of the next big aspect of innovation at ShiftLeft.

[00:37:36] CS: Okay. Well, last question then. If our listeners want to know more about Manish Gupta or ShiftLeft, where can they go online?

[00:37:41] MG: Shiftleft.io where you can find tons of information on the company, and of course you will find me there.

[00:37:50] CS: Okay. Working away and making sure that your employees are not burning out.

[00:37:55] MG: Indeed. Absolutely.

[00:37:57] CS: All right. Well, Manish Gupta, thank you very much for your time and insights today. This is a lot of fun.

[00:38:02] MG: Thank you, Chris. I enjoyed the conversation.

[00:38:04] CS: And as always, thank you all to our listeners for listening and watching today. New episodes of the Cyber Work podcast are available every Monday at 1pm central both on video at our YouTube page, or at infosecinstitute.com/podcast, or on audio wherever fine podcasts are downloaded. And don't forget to check out our hands-on training series, Cyber Work Applied. Tune in as expert infosec instructors teach you a new cyber security skill and show you how that skill applies to real-world scenarios. Go to infosecinstitute.com/learn to stay up to date on all things Cyber Work. Thank you once again to Manish Gupta and ShiftLeft and thank you all for watching and listening. We'll speak to you next week.