[00:00:00] Mark Lambert: Hi and welcome to Let's Talk Software Security. My name is Mark Lambert, Chief Product Officer here at ArmorCode, and I'm joined by Rohan Parakh. Rohan, how are we doing?
[00:00:09] Rohan Parakh: I'm great. How about you?
[00:00:11] Mark Lambert: I'm doing fantastic, as always. So this is really episode three in our ASPM conversation. So previously, we talked about ASPM being driven by DevSecOps, all of the modern cloud orientated delivery mechanisms, this intersection of vulnerability management rolling up under ASPM, we talked about how the tool ecosystem is insanely diverse and, and how do we build a workflow on top of this diverse ecosystem there where we can plug in and out the best of breed tools that we need or changing tool landscapes or new tool that comes in and then that led us to where we're going to talk about today.
So it's not all about cloud though. It's, it's about organizations that are on this journey because you can't leverage an ASPM solution for your cloud initiative and then forget all of the other software that's out there. Many organizations have product security programs where they're deploying software to market where they don't manage what should I say, delivering software to market where they don't manage the deployment.
It's actually deployed on infrastructure that they don't manage. You know, this is a, you know, the traditional way of developing software that now what we now have to do is manage the product. Lifecycle of all of those of those are software artifacts, and then you're that brings in challenges. I have to start correlating findings and vulnerabilities across the versions.
I have to make sure I focus my engineering work in the right way in the right places. Plus, I now need a more strict governor's process on my delivery. So Rohan, I know you've been working specifically on this area with a number of the ArmorCode community members. Talk to me about the challenges that organizations are facing and what you see as the path forward in this world where we're continuously delivering software.
[00:02:04] Rohan Parakh: Right. And it's an interesting problem, right? And. It's not going to go away because a lot of software is going to be delivered in a way that it's not going to be real time in a way that it's the CI/CD past of it. When you say talk about CD, right, it's going to be continuous delivery, cannot continuous deployment and it will always be on the users of the software in terms of how they want to consume it.
Now, there are a few challenges here, right? Number one is every version or every release of a product or a software. Is different at the same time, not different, right? It's different because it's probably has a lot of same code base and maybe as a result of that same issue, same vulnerability as well.
And it's not different because there are some changes, some enhancements that have been added to the new code base, which means that there might be new vulnerabilities also, or maybe the older ones have been closed. So the challenge that comes often is how do you make sure that you're managing it in a way that you are number one, not missing anything.
But more importantly, not kind of overwhelming yourself and doing the same work twice. And that's where correlation of these findings across different releases become super important so that you are able to make sure that when you have gone and triaged a finding or assigned a particular vulnerability to be fixed for, for a particular developer, right?
That has done across different core branches. And as a result of that different. Versions as well. So you're able to kind of track them in the different releases and you're able to kind of manage that as well. Number two is not a lot of software is going to be fixed on a timely basis. Right. And that will happen because There are no patches available, right?
You know, there are the dependencies that don't have a fixed version available at the time of release and release has to go out because it's, it's essentially business also, right. I know for these organizations and there are some other ways to mitigate the risks that have been put in place, but the vulnerabilities of findings still exist on those software platform.
Typically, most organizations take a route of exception. Exception is, is more of an exemption. To say that we are not going to fix those vulnerabilities in this software or more specifically in this release for next few months or next few weeks, which number there are two aspects to it, right? One is you want to make sure that it has gone through all the stakeholders and number two, you are able to go back six months down the line and track back and say that the version that we had released six months back, what vulnerabilities, what findings were, you know, we had taken exceptions on.
That part of the overall process is something that we are kind of trying to actively work with and within some of enhancements that we have made on a platform also is essentially incorporating that and it cannot be ignored because it is part of the overall risk management cycle and making all the stakeholders involved and kind of updated as the product lifecycle goes from releases to releases.
[00:04:57] Mark Lambert: Yeah, this concept of the risk register, right? The things that I know exist and I, but I'm going to accept that they exist. And I also like to think about these two different, there's the concept of changing the state associated with a particular individual finding and say, I'm going to accept the risk of this finding or what this finding is associated with versus that exception or your way you can say, yeah.
[00:05:24] Mark Lambert: I, I, I need to fix this. I'm not going to accept it, but I'm gonna cover it under my exception plan and, and I will mitigate it within a, a certain period of time, or I will address it. You know, there's, there's other things like that. The poem report, right? The, the you know, acceptance and, and mitigation plan.
There's also the cater, so the con continuous authority to operate where we are doing this on a rapid cycle and, and as you said, being able to track the governance of. Who did that and who approved it is is critical for these organizations for internal compliance when it comes to, you know, let's say I'm delivering as I said software that's deployed the way I can't manage it.
I have an internal governance compliance reason because when there's a vulnerability that's exploited. We need to be able to document why we we said that wasn't an issue. But then also when we talk about your regulatory compliance as well, I need to be able to provide that documentation to to my GRC team.
So, yeah, I think this is a key component that a lot of folks are not really looking at. When they think about ASPM, they're really kind of like much more focused on the cloud native world where it's a little bit more I don't want to say wild west but it kind of like, you know, if I have a problem Well, what do I do?
I fix in the code and I push to production can't do that in the product security world you need a better process. So great conversation. Thank you very much. Thank you everybody for watching click, like, subscribe check out the show notes. We'll be including links to our state of application security report.
We'll also be including links to some Gartner research that touches upon this area as well. So thanks very much, everybody. Stay tuned for our next episode.
