GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
Welcome to the fourth episode of Beyond the Edge, a podcast dedicated to exploring the dynamic challenges faced by modern digital businesses.
In this episode, our host, Lauren Bradley, Global Campaign Manager, chats with Michael Grimshaw Edgio’s Director of Platform Engineering, and Richard Yew, Senior Director of Product Management for the Edgio Security Platform, about Shifting Left. Specifically, how culture and technology change as web application and API protection become a native and inherent part of your DevOps lifecycle.
“Security is like flour for you to bake the cake, and when security is done right, you can't see it. The whole point of security is when it's done right, it should have been baked in and it's not visible.”
An Introduction to Edgio’s Beyond the Edge Podcast Episode 4: DevSecOps: Shift Left to Avoid Shifting Your Product Roadmap Right hosted by Lauren Bradley, Global Campaign Manager at Edgio.
Lauren Bradley: Hey there, and welcome to Beyond the Edge, where we dig into the ins and outs of modern digital businesses. I’m Lauren Bradley, your co-pilot for this episode, and today, we’re going to be exploring the topic of shifting left, specifically how culture and technology change as web application and API protection become a native and inherent part of your DevOps lifecycle.
Let’s start off with a shocking statistic from the Ponemon Institute. Today, it takes more, most companies, more than 200 days to even detect a breach. If you’re not detecting a breach quick enough, it’s going to cost you big. IBM found that the cost of fixed bugs found during the testing stage can be 15 times more than those found during design.
So, to put it simply, the longer you wait to catch a problem, the more it’s going to cost you. And, we’re not just talking about money, the rework, the time, and the energy can ultimately shift back product roadmaps. So, how can you effectively shift left and avoid wasting valuable resources and stalling your progress?
Joining us today, we have Michael Grimshaw, Edgio’s Director of Platform Engineering, and Richard Yew, Senior Director of Product Management for the Edgio Security Platform. Welcome, Michael and Richard. It’s great to have you on.
Michael Grimshaw: Thank you, Lauren. Great to be here. Thank you.
Lauren Bradley: Can you guys tell me a little bit about yourselves and your initial thoughts on this topic? Mike, we’ll start with you.
Michael Grimshaw: Absolutely. First of all, let me start off by just thanking, thanking you, Lauren, for having such an interest. In this very important topic and, and you’re digging in and ramping up and the conversations we have had and are having around this, including this one year here is, is just an invaluable and imperative to the work that we’re doing in the industry.
Michael Grimshaw: This understanding needs to be shared far and wide and, and really appreciate the interest. My name is Michael Grimshaw. I’m the Director of Platform Engineering here at Edgio. For those of you who aren’t familiar with, or, super familiar with the platform in industry terms, it is really thinking in terms of the unification of your applications and infrastructure into coherent units.
And, I come to the platform with a heavy security background, and this is an area that I’m pretty passionate about because it moves the needle in such a big way, as far as security, as far as profitability, and so many of the areas that are so important to our industry.
And I can go on around DevSecOps, but let me hand it over to Richard for his intro.
Richard Yew: Thank you very much, Michael. Yes. Yes. This is a very important topic. It’s very near and dear in my heart because I personally have lived through the entire software development lifecycle process as well as translating those to the business.
Now, speaking of what I do… Obviously, as Lauren mentioned, I run our security product management organizations at Edgio. So, my day-to-day life involves working with the R&D team, the engineering team to actually ensure that we’re delivering value to our customers. And, you know, everything that obviously would include like optimizing our development practice, our security, CI CD practice. to ensure that we are actually able to deliver secure products.
Right. That actually provides value to our customers, delivers them on time, on budgets, and ensures that we provide great experience to our customers. So, my lens in this is to really look at the entire DevSecOps, you know, from a perspective of people – the process as opposed to technology and how we can actually implement the best practice, for, the industry
What is DevSecOps?
Michael Grimshaw: To your point, Richard, let me just let me steal the ball there if you don’t mind.
And just I think let’s just standardize on what we mean by DevSecOps and shift left shift, right? There was Gartner, here’s the things for some people listening in on this DevSecOps, and the terms shift left, shift right, etc. might sound relatively new. This is not new, you know, it’s not like, oh, the newest hottest thing that just hit a year ago.
No, this has been baking in the industry for quite a while. And in fact, Gartner had a report from 2017 on the DevSecOps lifecycle. Was just really an extension of the DevOps, the DevOps trend in the industry, just extending to include security in the infosec into the feedback loop and your software development lifecycle.
And so, like I said, Gartner was writing around, writing about this, back in 2017, and it had already been, a process and a movement in the industry. For quite a while before that. So, these aren’t brand new concepts. It’s, just an extension of what we have been working on for years. And effectively what DevSecOps is, is it takes the similar model, of DevOps in that you have a development side and really an operation side.
And at the crux, it is building in all of your security needs as soon as possible, I mean, into from the onset of design, build the, you know, the whole process to where your developers on the ship left is on the development side, excuse me, shift right is more on the operations observability side. We’re going to focus on the shift left side here today, but it is basically baking in your testing your scans, and your validation, as early as far left. And as early in the development life cycle in your SDLC as possible. So, for example, one of the things that it talks about, and again, this goes back seven years plus, is things like having security, scanning and scanning your, you know, your open-source third-party libraries, repositories, code base, as well as the code that you write, the design, the architecture, the whole nine yards, and baking that in from the very onset. And one of the examples that I’ve been giving is building and security scanning into the very IDEs that your developers use. It’s just one example, and there are lots of them.
So that as they’re writing their code, they get immediate feedback. Oh, I just left the door open to, you know, credential stuffing or sequel injection, and they get just like a syntax error, they get a security error right there is the writing the code. So, they can immediately fix that, so they don’t have a customer complaining about the customer or end user getting pawned, you know, a month later, no, it’s handled right there.
Cheapest, fastest, easiest at the onset. Richard, you were going to say something.
Why is Shifting Left so Important When it Comes to Cost?
Richard Yew: Oh, yeah. Yeah. Like I think the cost is actually very important to talk about, you know, well, everybody knows a lot of operating costs, you know, any organizations, it’s like the development, right? The R&D process.
So, when it comes to cost, this is why shifting left is more important, right? Because we’re putting a lot of effort and talking about the why, you know, I’m sure we’re going to go into the “how” later, but we want to hit home on the reason why this is so important because, you know, we have data.
Yeah. That, according to our research, shows that you know, if you are fixing a security vulnerability that was found after you release your code and productions cost 15 times more than you know when it’s found in a design phase when you’re doing threat mounting. Obviously, we’re not saying that you know, the early phase of the development effort would completely catch all the security vulnerabilities.
This is why we need to implement defense in depth. But it’s very important that You know, as you look at the eight phases, you know, in general, of the debt cycles, life cycles from, you know, plan, code, build, test, all the way to like monitor and operate. Right. You look at them the further right you go, you know, like when you find a security vulnerability, the more costly it’s going to take, you know.
For your organizations to actually fix the issue. So, we’re talking about the difference between, you know, finding a vulnerability on a scan that happens after you already released a bunch of codes to the productions versus say, you know, like doing a dynamic application security task in the staging environment to actually detecting it early before you ship that code to the productions, right?
Richard Yew: You might be able to, you either remediate those issues, or you implement some sort of virtual patching right ahead of time before you release a code reduction to mitigate that. But, again, it’s very important to understand that security needs to be baked in from the first step of the process, even before you start writing the code before you put anything down into your IDE and start thinking about doing threat modeling. Hey, what part of the design could potentially be susceptible to exploitation?
Day-to-Day Implications for DevOps and Security Teams
Lauren Bradley: Yeah, and those are really good points, you guys. I mean, from a user standpoint, what, outside of costs, monetarily, what can that mean for a DevOps or a security team to experience in their day-to-day if they aren’t implementing this right from the get-go?
And, I also want to talk about how we effectively implement it into the DevOps lifecycle.
Michael Grimshaw: Great question. Great question. And, let me just be really blunt in my initial response. Is everyone in the industry, every CEO, CTO, CFO – everyone, engineers, users – what we all want is just a magic bullet that we can do, what we do day-to-day.
And then we have a magic security bullet that you just flip the switch and all of your work is suddenly made secure. That’s what everyone wants, but that’s not reality. That is, you know, people ask us. I want to ask them, how’s the weather in fantasy land? I hear it’s nice. This type of year is, and if you approach your security, your infosec, as well as your development, as this is just a bolt-on. You know, “oh, I’m going to buy some tools that I’m going to bolt on after we’ve got everything developed and built and deployed, and it’s going to go on and make everything secure,” you’re buying a very expensive paperweight, to be honest with you.
And this is why, you know, it was mentioned, it’s about people, processes, and tooling. This is why the coherent totality of this approach is so important. Is you, we are far years, decades, if it ever was even possible. To be honest with you, we’ve learned a lot of lessons from the idea of you just designing something and putting a security tooling and you’re, you’re good to go.
It impacts everything from your cost to your developer velocity and cost there to your customers. And, a great example of this is my suspicion is, almost everyone who’s listening to this podcast at some point in their career has been in a situation where a new feature or new service or something like that, or even just a patch and update was deployed. Everything seems good. Everything’s running good. And then suddenly you get a call from one of your customers or infosecs get a call from one of the customers. “We’ve just been pawned,” or “we’ve just had a security incident,” or something like that. And the reason is because, okay, you’ve deployed it, but maybe the scans hadn’t finished running, or you didn’t do scans, or you didn’t have them properly tuned, and you have just introduced a massive security vulnerability.
Maybe it affects you, but more importantly, it affects your customers. DevSecOps is about baking all of this together in a coherent process and avoiding that. It’s about cost cutting. Absolutely. Is it about improving margins? Oh, in a big way. But it’s also about removing the liability for your company and that of your customers.
Incorporating Security Into DevOps – It’s Like Baking a Cake!
Richard Yew: Absolutely. You know, speaking about, you know, speaking about baking it, you know, like Mike used such a term coherent totality. Like this is so true. This is very powerful, this is a very powerful word to show why is this important to have that baked in place, you know, like I’m known within Edgio to be the analogy guy.
I like to throw a bunch of analogy around and I’m, you know, I heard this great. Analogies I think would serve as a strong foundation towards pushing for the right cultures within any organization as we all know, as security people, a big part of our job is evangelism. It’s not just about implementing the right technologies and creating a process, but also really doing a lot of internal marketing.
To tell people are important of security to the business, right? Because, you know, as security leaders, it’s not just like, it’s like people often think of security, like adding additional layers of process into your workflow, but you know, the right way of thinking about this is that how can security accelerate the business?
How can security actually bring in more revenue, because this is a good way to justify a lot of the security, you know, additional security implementations that you have to do to ensure the organization’s secure. So, one of the analogies I heard that was great is that you know, security shouldn’t be treated like an icing on the cake, you know, how you bake out of the cake and just put all the icings as a last step, you know, that’s usually what people do when they don’t have a security, ICD workflow, and they just implement firewalls and, you know, API protection, whatever at the last phase in the production phase. What it should be, the security, it’s like flour, you know, it, it should have been something from the beginning.
Security is like flour for you to bake the cake. And then when security is done right, you can’t see it. And the whole point of security is when it’s done right, it should have been baked in and it’s not visible. It should not be something that creates challenges. It should not be something that slows the organization down.
Like analogies that, you know, I used to help show the business why this is important is that having a strong security process, security technology cultures, it’s kind of like having strong brakes. In a race car, you know why every supercar out there has big, you know, really big, fancy brakes because it allows them to corner faster.
It allows them to brake hard. It allows them to go faster and turn harder, right? It allows them to win the race. So, having strong brakes is as important as having a strong engine, right? This is how we should be looking at security on a philosophical. You know, obviously, we talk a lot about high levels, right? So, we obviously want to, you know, kind of like go deeper into that. The gist of like, okay, so all of this is fine, but how exactly are we going to implement that?
Michael Grimshaw: Yeah. I think that’s a great call out is braking. Powerful braking gives you control. There’s the current or the road we have ahead is filled with curves, hairpin turns, and all of that, and there’s, sure, there are straightaways where you floor it and you don’t touch the brakes, but to navigate everything, that, that brake, I think, love, I love both of those analogies, Richard, because that braking analogy, it gives you control, it gives you finer grain control when you’re facing curbs, challenges, and, and unexpected things.
Richard Yew: Great call. By the way I want to clarify, I didn’t come up with that analogy it’s from this guy called Dr. Eric Koh. He has, and he runs a great podcast. So, I recommend everybody go watch that. But yes, I find it so appropriate when explaining the concept to the business, especially with those who are new to this kind of concept.
Problematic, Siloed Teams & Shifting Roadmaps
Lauren Bradley: Richard, you talk about how you, you mentioned, you know, if, if it, DevSecOps is done, right? You don’t see it. And obviously, one of those glaring visibilities is cost. It’s also siloed teams. It also feels like there’s a disconnect between teams when there are these issues that arise and why weren’t they caught before?
What processes, what communication wasn’t taking place in order to resolve these quickly or effectively? So, my question to you is, you know, in your experience, which of… You know, there’s, there’s probably a lack of transparency. There’s slow decision making, there’s potential to waste resources.
When you have siloed teams, what problems tend to be the most problematic when teams do operate in silos in your opinion?
Richard Yew: Yeah, I’ll take this one. I think one thing that, you know, I personally experienced in my past life, right, is that you know, and this is when, you know, when we talk about like products, you know, like kind of planning, it’s important is that sometimes you have a security team who’s not kind of embedded within the R&D, like within the CTO organization.
Sometimes in many organizations, we observe silos between security teams and the CTO organization, and you’ll find that a lot of processes were done after the fact. So, for example, we run into a situation where we release a lot of products, release a lot of codes because there’s just not a strong kind of communication collaborations between the security teams and engineering teams.
What you ended up with is that, you know, an organization must be compliant. Sometimes, the specific examples is that you have teams coming in doing the scans like once or twice a year. What’s the result of those scans? Well, I’ll be told, “Hey Richard, we got to slow down next quarter because we just found like a hundred different big and small security bugs, you know, like maybe, maybe like 20, like of the top 20 are severity one and two and above, while the rest, you know, it’s about, you got to focus on fixing those things.”
And there’s an SLA within the organization for you to fix, you know, what ended up happening is that by doing that, you essentially just took my roadmap and you just throw them off to the next quarter. So, by not shifting left, by not really baking this process in place, by just doing these things only on the right side, we’re essentially pushing our roadmap, which is, you know, revenue-generating deliverables, potentially that could help expand our business. We’re going to have potentially move it right so that we can actually, you know, spend a quarter is trying to, after the fact, to mitigate those issues.
This is why I say, well, it’s tremendously expensive for the organization and for the business to imagine having, having to shift roadmap items by a quarter. So, all of your release schedules of your new products, features, and functionalities have to be shifted, right? Because you didn’t shift left into your practice.
And some of those things could have been improved with better collaborations especially between application security teams within an organization and yet and development team. This is why we see that many organizations are starting to have this new concept. You know, you guys heard about HR BP, you know, HR business partners that are embedded within different business units.
There’s now a concept of Application Security BP. So, you’re going to start hearing these terms like APP SEC BP that, that could become practice where you have people working. Almost like a semi-embedded manager of the engineering team to ensure that they provide the right guidance, tools, and processes in each step of development workflow from, say, you know, implementing software composition analysis, implementing secure ID, implementing all the black and white box tasks, you know, during the process to ensure that, you know, we’re able to capture some of those issues before, you know, right early in the development lifecycle.
Michael Grimshaw: And I love everything. Great question, Lauren. And I love everything you just said, Richard. Because there’s a cost associated with that. You know, if people, if someone is in a product where they hear, wait, you know, if I shift left, I don’t have to shift my roadmap right.
That’s music to their ears. But for maybe CFOs, or even operations, or other areas of the business, you might be saying, okay, well, what’s the impact of that? The impact is huge. You just kneecapped your sales department. You have impacted your customers because you’ve got, especially when it comes to security, lots of customers. I know on the platform side, when I talk to my vendors, I want to know what the roadmap is because, okay, maybe I have to go to my auditors and I need to get compensating control until you release something on your roadmap. Well, if you just told me, okay, what I was expecting to be delivered in a quarter is going to be three quarters. I’m going to start looking at other vendors. Why? Because I have obligations to my auditors that I have to meet.
And I also love, Richard, you brought up auditors and really the compliance process. That’s another example here to your point, Lauren, about where siloization can radically blow things up.
If you’re in the middle of a PCI, SOC, ISO, FedRAMP, any of these various compliance frameworks, and you haven’t really integrated, you’re still operating an asylum mentality, you’re probably going to have someone who’s in compliance or info sec talking to your auditors, they’re going to have to translate that through a layer or two to the engineering side that hopefully is going to implement everything intended, and then that’s just to get it implemented. And then all the evidence and the scanning and everything that you need to provide back to your others, good luck.
If that actually translates through, we’ve all played the, you know, that old rumor game from elementary school is a similar type of function where if you’ve got integrated teams that are working with the auditors that immediately know how to translate this into the specific technology and you’ve got scanning and you can turn that immediately around and put it in your rule set and scan and validate on that both real-time, as well as when you’re meeting with the auditors. You’ve got all your evidence all together right there. That is a radical game changer. It allows you to deliver things faster to your customers instead of like Richard said, keep shifting your road map right now.
Lauren Bradley: Yeah. So, to be more tangible on that, I mean, how can CISOs and AppSec leaders quantify their metrics to understand cost implications or even just general success?
How Do You Implement the DevSecOps Process?
Richard Yew: What, you know, it’s funny because we talk a lot about the why, you know what, but let, let’s dive deeper into the how, because I know that, that’s what a lot of our audience for. We’re not here to give you fluffy, high-level statements. What we’re here to hopefully provide is a bit of value for when it comes to exactly how to implement that.
So maybe we can pop out the DevSecOps chart that we have, and then we can kind of like just go through how we can optimize the steps. All right. So as you can see traditional security testing, you know, kind of like runs in a linear fashion, right? It’s, it’s kind of like when we’re talking about waterfall, like your plan, you have, beauty, a test, right?
A lot of security testing was done during the operator monitor phase. So, it’s on the right side. So, so now that the new concept is, if we move on next pictures, right? Is that that you can find 100 different varieties of this chart. Like, when you just Google DevSecOps today, like Mike said earlier, this concept has been around, you know, for 7 years, right? You know some organizations might not call it that cycle. Some organizations just call it AppSec, right? So certain organizations will call them a security pipeline. So, this is a rough representation of what a security pipeline stands for. Right? So, from the start, you have on the planning phase, right?
You have the threat modeling threat analysis. You try and ensure that you baked in all of this modeling while you’re designing solutions. So as, as you code, as you’re going to a second phase, your coding phase, right? You want to make sure you have the hooked. You want to make sure that you have a secure IDE, who’s ever really in real time as developers writing the code actually captured some of the issues in real time. Obviously, that’s not a silver bullet, right? But it’s an additional layer and we’re talking about additional layers in the defense-in-depth cycles. Now, as we move further and further down the process, right? Once you committed to code, right? You want to make sure you have a process – who’s able to provide, uh, a static scan of all of your code to ensure that they check auto dependency, the supply chain, vulnerability, etc, along with software compensation analysis to create a software view of materials that show you what kind of version of software you’re using? How old are they?
Because, you know, I kid you not, I just read a statistic a week or two ago – 25% of the downloads of Apache Log4j is still off the older version that still contains a vulnerability. It baffles me that it’s still a stat, you know, now that we’re almost two years. I don’t know, was it two years or three years from when the first Apache Log4j zero-days vulnerability was announced back in early December? Was it 2021? So, so it’s really something that we need to focus on doing better and having this kind of software conversation/analysis in place to ensure that you know exactly what version of software you’re running.
It’s important. So, then we move towards testing, right? You want to make sure you have internal tests, you have your dynamic tests, you know, implemented to ensure that. We are able to test the application that’s running and see if there’s any kind of vulnerability that can be exploited.
You know this is usually done through fuzzing. Now, what is not shown here in a traditional DevSecOps cycles? Because this all looks pretty standard industry practice, right? As we move right all the way to deploy, monitor, response. Historically, you would put web application firewall, bot manager, API securities, all of their web application API protection solutions on the response and monitor phase, right? This is when you monitor your production traffic, you ensure that there’s no exploit towards.
But what is something to consider is to actually move some of this web application API protections that you have in place. Shift them left as well. Put them on in this case, in the picture, it’s a step forward. Put them on the testing phase as you are doing your dynamic application security test, right? Why don’t you test them through your production security mechanism? So, you know, actually how much of a vulnerability exists between the code, how many of those vulnerabilities can be mitigated, because the important thing is that we are always trying to find ways to improve this current app cycle lifecycles by actually making a development work faster. A general practice when you find a security vulnerability during that test is that you basically stop the train. You go back, right? You fix the code, you re-release them. You go through the eight steps again. But what if I told you that perhaps there’s a way for you to say, “hey, let’s not stop the train?”
Let’s keep the train going. Let’s release that by having a kind of additional test with security solutions in front of step four which will allow you to know well ahead of time what to virtually patch in the production so that you don’t have to stop your train. You keep your train going. You maintain your velocity.
You release the code with the virtual patch in place to mitigate the vulnerability, and then you fix them in the next cycle, hopefully, which will hopefully happen very quickly. This is also one of those ways, the innovative ways that we want, you know, to educate and work with our customers to try to improve the existing CICD security workflow.
Michael Grimshaw: I love that, Richard. I love you calling the fact of pulling, pulling this into shift left. So just to your point is if your game plan is, oh, let’s get this into production and then we’ll worry about it. You’re going to have problems and have something that can mitigate that can cover your backside, both through your development and deployment and operations process. I love what you called out there. And an analogy, and a similar analogy, I would say, be like Chaos Monkey. Here’s the thing. If you have Chaos Monkey working in production, and the only time that you’re dealing with Chaos Monkey is when it is in production, you’re going to have a horrible development and operational experience.
You have to plan, design, and engineer for that well before it hits production. Otherwise, you’re going to be in misery.
Quantifying Metrics to Understand Cost Implications and Success
Richard Yew: Yeah, and Lauren, I like to answer earlier questions, how do we measure success right now that we just look at the whole DevSecOps lifecycle and how we can optimize it. What’s best practice, right?
Very quickly. So we got to track the success. So obviously you need to be able to quantify the success. Right. So, you know, there, there are some of the metrics that could help if you’re a security leader and you’re trying to measure the success of the application security programs, one of the things that you can look at, it’s also what, how much of the application coverage you have, right?
So for example, do you have more than 90/95 percent of all of your applications or internet-facing applications across your organizations covered under the same process? Do you have the same standardized process covering? Right. That everything, including software composition, analysis, SAS, test, test, test, you know, like web application, API protections.
Do you have those things in place to keep tracking coverage? How often do you release and how often do you have to roll back? At what phase because of the security vulnerability that you detect and how often do you have to roll back at the production phase versus how often do you have to roll back during the, you know, code commit phase where you’re doing static analysis because obviously rolling back of productions.
It’s going to be way more expensive than going to fix the code after a bit of static code analysis. Right. The other two stats there, you definitely want to measure as, as Lauren alluded to earlier. The industry average mean time to detect what we call an MTTD is 200 days. So, I believe with this with the right process with right shift left process, you can drastically cut down on the meantime to detect, to much shorter. So, try to start putting metrics together to detect how long does it take from a disclosure of vulnerability to you detecting those one building within your organizations.
And also implement meantime to response, right? MTTR meantime to resolve meantime to resolutions, right? The industry average is 70 days, so it’s 70 days after vulnerability is found, right? Exploited it still takes an average organization 70 days to resolve that. But with this start tracking, how quickly can you resolve? As soon as you find a vulnerable version of logs for J using your code in your software composition analysis, how quickly can you virtual patch them with a firewall, or how quickly can you go and update your libraries to use a different software, right? So, measuring that at a very mature organization, I’ve spoken with some organizations who actually have what we’re talking about four hours of mean time to resolve time for log4j event.
That’s extremely impressive. And that speaks to the maturity of their DevSecOps processes. So, I’ve seen all kinds. And I’ve seen customer organizations who have like weeks or even months of meantime to resolve for critical issues like log4j. So, it’s very important to keep those metrics in mind as you try to improve the process as a whole.
Michael Grimshaw: And there are some other KPIs I want to throw in here is that, like on the platform side, when you’re dealing with infrastructure or in many cases, anything engineering, cost has always been an important element here. But in the last few years with rising interest rates, you know, the spigot is as far as VC money and a lot of that really drying up, but the name of the game and the rising interest rate environment is a beat up very profitable.
And there’s an aspect here. I love this technical. Clearly, you know, director of platform engineering. I love the technical side, but especially in the last few years, a huge part of if you’re working in platform, like I said, infrastructure and things like that, the, the finance aspect and in clarifying and providing feedback to your CFO, as well as your CTO has become imperative.
And so the KPI is around a cost and revenue is, this is another, this is a huge important aspect here as well. And, and I just want to call out some of the things like this is, for example, on the revenue side. If you’re sitting down with a red line discussion, if you’ve got a customer that’s looking to buy your purchase, but your product, you’re going to go through a security red line because security is on everyone’s minds and your customers are going to want to make sure they’re protected.
They’re going to want to minimize their risk here. And if you come to him with the old-school mentality. Oh, yes, we develop things and then we, we let, we make sure our infosec scans them and all that. I’ve been in plenty of red-line discussions and contract discussions, and that just simply does not fly anymore.
The level of questionnaires and questionnaires from your customer’s risk department and legal department has gone to a whole other level of detail in the last five years, let alone 10 years. And, being able to have a fully-integrated shift-left solution to have web applications and API protection – all of this. When you are talking to other people’s lawyers, this moves the needle in a big way. What does that mean? It means it allows you to close deals faster. And one of the things if you’re not practicing shift left or you’re just thinking it’s infosec as an add-on, I’d encourage you to go back and look at your closing ratios and where they broke down and specifically look at the security red line discussions because these types of products issue too often are viewed as a cost center. They’re not, they can unblock revenue and they can save you a huge amount of money.
Earlier in the podcast, we covered a lot of the cost savings as far as internal costs, but there’s revenue in beta implications here that I think is important to call out because that’s where so many eyes are in this rising interest rate world.
Wrap Up
Richard Yew: That’s an excellent point. I’m glad we kind of switched hats a little bit, you know, like put on my SDLC hats and you put on your, your business hat. This is great. I hope all these things that we shared provide a bit of value to our audience.
Lauren Bradley: Thank you both so much. I think that’s a great note to end on. We have covered the importance of shifting left and how to effectively bake web applications and API protection into the DevOps lifecycle. And of course, how to effectively measure success. Are there fewer false positives? What is your mean time resolution? How quickly are you shipping software? And are you earning more revenue?
All of these metrics are vital to a business’s success. So, I appreciate you both, Michael and Richard, for joining me today. It has truly been a pleasure and thank you to our audience as well for joining us on Beyond the Edge. We will see you in the next episode.
