Decoding The State of ASPM 2024 Report

categories icon Webinar

Join us for an exclusive webinar where Julie Peterson, Product Marketing Manager, will dive deep into the research findings from the world’s first State of ASPM Report - an in-depth analysis of the current Application Security Posture Managementt landscape, based on insights from 500 CISOs and Security leaders. Our speakers will not only share data insights on the most critical and emerging trends across secure software development, but we’ll reveal how ASPM is transforming security and development teams’ approach to application security.

You’ll get the full insights behind:

  • Why 77% of CISOs believe Software Supply Chain Security is a bigger blindspot than generative AI
  • Why 88% of CISOs admit that alert fatigue means developers aren't fixing critical vulnerabilities
  • Why 90% consider consolidating all AppSec tools into a single platform

Presented by:

Julie Peterson
Julie Peterson
Sr. Product Marketing Manager

Have questions or
want a custom demo?

Get a personalized demo and learn how you can develop secure software, faster with Cycode.

By submitting this form I agree to be contacted by Cycode, and receive occasional offers & product updates via phone or email in line with Cycode's Privacy Policy.
Transcription

Julie Peterson:

Hi everyone, I’m Julie Peterson and we’re here today to talk about decoding our State of ASPM 2024 report. I’m going to give everyone just about one more minute before we start, but welcome and we’ll get started soon.

Okay, I think without much further delay, we’ll jump right on in. Today is episode 13 of our AppSec Secrets webinar, where we flip the script on AppSec and share and learn all sorts of great things on how to make our tech services more manageable and reduce our risk. I am Julie Peterson. I’m a senior product marketing manager here at Cycode.

Just a little bit more about me, I have been at Cycode for a couple of years now. I’ve worked in the AppSec space and technology in general longer than I care to admit. I’ve worked again in AppSec with a focus on open source and I’ve also worked in the big data AI/ML space. So a lot of really interesting experience. Past employers have included Mend, formerly WhiteSource Software and IBM and I started it all off at IDC.

So our agenda today is first of all, we’re going to look at some of the marketing conditions that led us to start thinking about what was going on to engage in this really big research project. So I’m going to look at some of the questions and concerns that we had that we wanted to dig deeper into. And then I will go over the methodology we used to collect the data. And then finally, we’ll jump into the main event here and talk about some of the insights that we culled from the State of ASPM 2024. And then finally, we will end with any questions, if there are any.

Some housekeeping, everyone is on mute, but if you have questions, please feel free to put it into the tab marked questions. And at the end, if we have time, I’ll do my best to answer as many as I can. If for some reason we don’t have time, I’ll try to follow up with you after. So without much delay, I’m going to jump right on in.

So there were a number of things we saw going on that led us to decide to look into the market a little bit more in depth. And some of the things that we saw were just common pain points that we saw from our customers that we saw the people we talked to that just kind of happening in the market. And the first was the idea that the attack surface is just growing and growing.

Now, we saw early on everybody was attacking the network and we did a great job of locking that down and the application layer was the weak link. And so attackers started going after that. And we’ve done a pretty reasonable job of locking down our code, and so what do hackers do? They go after the software supply chain. So they’re going after the tools and processes and people that build and deliver our software. And so what we’re seeing is just the attack surface is growing and growing with new and novel attacks every day.

So how has security responded to this? Well, we’ve adopted tools to address each complaint. So if you’re looking at the application, SAST has been around for a really long time because we’ve been writing code. Now as we’ve switched to using open source as a methodology to ship code much faster and reuse that functionality, we adopted tools like software composition analysis.

So every time there’s a new attack vector, we try to solve that problem with a new tool. And what ends up happening is that we end up having just this proliferation of tools that are really, really hard to manage. We know that AppSec teams are pretty lean, and if you have a lot of tools, it’s very hard to use them all to their fullest potential.

And one of the outcomes of having all of these point solutions is a lot of silos. So we have data silos from the tools. They’re doing scans, they’re finding alerts, they’re finding vulnerabilities, they’re letting us know, but the tools aren’t talking to one another. And then what’s happening also at the same time is that we’re developing silos between security and dev teams.

Security and dev teams really need to work together. Here at Cycode, we always say that security needs to be a team sport, security can’t do it alone. But we see these big sort of silos in this gap between security and developers, whereas there’s this impression that security is just throwing alerts over the wall willy-nilly and devs don’t know what to do with it.

At the same time, developers are still expected to innovate fast. They are comped and evaluated on how quickly they can get innovative features out. That is their job. Security is kind of like that mosquito buzzing in their ear. They know they should do something about it, but they just don’t have the time.

So what we see is the gap between the ideal scenario and the reality is what we call AppSec chaos. And in AppSec chaos, we see that there’s a lot of alert fatigue. We have more data and more alerts than ever before. The quality of the alerts coming out are highly variable. Some are great, some are not so great. Some are false alarms. So we have that. The volume of alerts is slowing innovation and innovation is really the key to growing our business.

As a result of all this noise, we’re missing critical risks, risks that actually represent something that could potentially harm your business. And as a result of all these factors, the distress between developers and security is just growing. They’re not working together towards a solution. They’re butting heads and working against each other. So security is in this place where they’re always being reactive. They don’t have time to actually reduce risk and focus on strategy that might prevent risk. They’re just firefighting and putting out fires from a day-to-day basis.

We saw this going on in the market and a lot of our customers were coming to us and really reiterating and saying that this is what they were focusing, so we wanted to dive deeper into it. So we commissioned our State of ASPM 2024 research report.

So for this report, we commissioned an independent vendor-agnostic company to survey 500 security professionals. We did not look specifically at our customers. We went out there and it didn’t matter who you were, you could talk to the vendor. We had 500 respondents. We focused on CISOs, AppSec directors, and DevSecOps. So we wanted to get the big picture and then really drill down into what the day-to-day practitioners were doing.

We focused solely on US organizations of greater than 1,000 employees. Half of the organizations that we talked to had between 1,000 to 5,000 employees and the other half had 5,000 or more. The data was collected late September through October of last year. So it’s really brand spanking new and we’re excited now, I’m excited now to share some of the insights that we gained from our data.

The first one again is something that I’ve already talked about and is really no big surprise, and that is that AppSec chaos reigns over today’s attack surfaces. So when we asked people if they felt the attack surfaces were unmanageable, about 71%, so our total cohort, said that they felt that the attack surface was unmanageable. Now, when we drilled down and looked at specifically CISOs, 8 out of 10 CISOs felt that today’s attack surface was unmanageable compared with only 61% of DevSecOps.

And we feel that perhaps some of the explanation about why CISOs are so concerned is first of all, they’re responsible for the big picture, and second of all, they’re being increasingly held personally responsible for data breaches. So if we look at cases like Uber or SolarWinds, the C-level executive there has been held personally liable and has been sued. So I think there is an increased concern there at the C-level. So certainly it explains the differentiation between the C-level and DevSecOps.

If we drill down into vertical markets, interestingly, the top three industries who were concerned about attack surfaces being unmanageable, were travel with 90% of respondents, retail with 85% of respondents, and then finally finance with 82% of respondents. And considering that these are high value targets, particularly with finance, and definitely a lot of customer-facing with a lot of opportunities for breach and certainly a lot of fines if customer data is exposed, it’s no wonder that they’re very concerned about tax surfaces today.

Our second insight is about tool sprawl. I mentioned early on that we saw that departments were adopting more and more tools to address specific problems, and we haven’t really solved all those problems. So what we’re seeing is that having more tools actually is doing more harm than good.

So one of the things that we looked at was how big the size of AppSec teams were. And we found, and this won’t be a surprise to really anybody who works in AppSec, that those teams were very, very lean. Out of the 500 people we talked to, there was not a team who had more than 10 employees. We did have an option for 11 or more employees on the team, and nobody had a team that big. So your team is expected to do a lot more with less. At the same time, I’ve heard from a number of AppSec leaders say that it’s easier for them to get funding for a tool than it is for them to hire and get funding for a new full-time employee.

So what we see here is that the number of tools have grown. On average, AppSec teams had 49 tools. And this isn’t necessarily just a scanning tool, but any of the tools that they’re using to fight the security battle. And 80% of security professionals said that they had a hard time managing those tools. So if you have a team of four to five employees and you’ve got 47 tools, it’s no wonder that you’re not using them all to their greatest potential. There’s no way that you can optimize every tool in your arsenal. So we likely have a lot of tools that we’re not using or not using adequately.

And interestingly enough, I saw the CISO of Intel speak a few months back, and he was saying that when he started at Intel, they had more than 900 different security tools and that each year his mandate was to jettison about 100 of them. So now they’re down to about 200 security tools. So again, there’s this idea that we thought tools were going to save us, but really they are becoming part of the problem.

And one of the things we wanted to really understand were what were the blind spots in your security posture and what attack surfaces were you concerned about? And I think we were all surprised when the data came back that software supply chain edged out gen AI. I mean, it’s only one percentage point. So again, everyone’s very highly concerned about them, but software supply chain still is slightly more concerning than gen AI.

And when you think about gen AI and how much hype and discussion and talk we all did about it last year, it still is really interesting that we’re still concerned slightly more about supply chain security. And I think part of that can be explained by the fact that we’ve had a number of very, very high profile attacks on the software supply chain, and have not yet had quite that same headline breaking, gen AI attack. So I think that’s really one of the reasons why software supply chain slightly, very slightly, edged out.

But as you can see, I think when you look at open source, proprietary code, pipelines, clouds, ISE, I mean we’re just generally concerned as AppSec professionals. We’re just generally concerned across the board that these could potentially be blind spots. And I think it’s interesting that we have a lot of tools and we’re still concerned about blind spots. So I think the idea that these tools aren’t talking with each other and we don’t have a really great macro picture of our environment is really a concern for many people.

Alert fatigue, we’ve been talking about it, I’ve been talking about it for more than five years now. Noisy tools, they’re a problem. They put a strain on developers, they put a strain on our security team. So instead of fixing the problems, you’re wading through trying to figure out what is really the problem. So when we surveyed our cohort, 81% said that developer teams experienced too much vulnerability noise and too much alert fatigue. Of the CISOs who said that they thought alert fatigue was a problem, 88% of them, so close to almost all, said that they felt that developers just weren’t remediating vulnerabilities.

And we think that there’s a couple of reasons for that. First of all, volume of course is the number one reason, but we also feel that all too often, security tooling doesn’t give developers the right context. It doesn’t give them the right tools and information on how to resolve a vulnerability or a defect in a quick, straightforward manner. So again, they’re not really incented on the security and releasing secure code. They’re more worried about releasing new features. And so we know that a lot of things are falling through the cracks, that our security debt is increasing, that the number of alerts coming in is greater than the number of alerts that we’re resolving.

So insight number five is that security and dev teams aren’t working well together. We know that in order to really tackle this problem, security is managing the process and identifying the issues, but they really do need developers to do the fix in the vast majority of situations. So what happens if the teams are not working well together? You have friction and you’re not resolving the risk that you need to be addressing on a day-to-day basis. So 90% of our respondents said that the relationship needed to improve. 9% were neutral on it, and only 1% thought that that relationship was working well.

I was just talking to an AppSec leader at Ford last week, and he felt that the number one indicator for success for any security program he was going to roll out was culture. That the culture of collaboration was there, that the teams trusted each other, that they were working together. And as you can see, 90% of respondents really say that that is not working smoothly, that it needs to improve. So we need to improve that relationship. And yet the vast majority of us, 76% say that developing that culture of collaboration is still a challenge. So definitely work needs to be done there.

We also wanted to look at the regulatory and compliance landscape. As you know, there have been a lot of increased regulations and compliance standards, whether we’re talking about SLSA or SSDF or the executive order around SBOMs. But definitely, organizations are getting a lot of push on having to now redo extended reporting.

And while I think the vast majority of people feel that this is a good move and that it’s really important to implement good security practices and hygiene, they feel that these compliance regulations are pushing them to do it at a much faster pace. And even though they want to do it and everybody wants to release the most secure code they can, budget constraints are still a reality out there. So there’s still a lot of concern that organizations don’t have the manpower or the correct tooling to easily meet these compliance standards. And this has even pushed off some of the deadlines. They’ve extended them.

Interestingly, when I looked at this data by vertical, the top three verticals that were concerned about compliance and regulatory requirements were healthcare, manufacturing, utilities, and finance. 100% of respondents in the healthcare industry said that they were concerned about regulatory requirements. Manufacturing and utilities, that was 89%, and in finance that was 87%. And I think there’s really no surprise there. Those three are all very highly regulated industries, and so they’re feeling the brunt of this pressure quite a lot.

So we’ve been talking about shifting security left for so long that it’s almost become a dirty word or a dirty phrase. We all want to address security flaws in the development phase when it’s a lot less expensive and a lot less time-consuming to address. But the reality is that things still get through the cracks and a lot of the pressure now is for security to not only identify the right issues that need to be resolved, that top 1% that represents real risk, but also getting the right vulnerabilities to the right developer at the right time. So getting it while it’s still fresh in the developer’s mind, giving them the right context so that they understand how to fix the defect.

And when we looked at this and asked this question, are you able to do it? Only 17% of respondents said that they were always able to get the vulnerabilities to the right person at the right time. So that means that 83% either can only do it sometimes, they can do it only rarely in 9% of the cases, or they can never do it. And if you have 83% of the time where you cannot guarantee you’re getting the alert to the right person at the right time, it’s really, really a significant concern and certainly something that we need to focus on.

Our next insight is about who owns application security. So we asked a couple of different questions around this particular issue, and first was, is it clear who in your organization owns AppSec? And a surprising 77% of respondents said that they felt that identifying and understanding who owns the problem is challenging. Now remember, we’re talking to CISOs, AppSec directors and some DevSecOps people. So if they’re not sure on who owns the problem, then I think it’s fair to say that there’s a fair amount of confusion across the board.

We then followed up that question by saying, who do you think should be responsible? We had a pretty broad split here. 44% felt that security should be responsible for managing AppSec. 35% felt that it was the developer’s responsibility. They’re the ones who made it, they should be the ones who fix it. Only 21% felt that both teams should be equally responsible for resolving security vulnerabilities.

And again, I think this goes to show that we don’t have a clear sense of partnership between security and engineering, and that is really, really a defect that needs to be addressed. We need to have the sense that we’re working together towards the same goal so that we can fix it. Ultimately, we do not want our product to be breached. We do not want to suffer the headlines or the fines, the loss of customer trust and brand reputation in the market.

So I think if you look at this, the thought of who owns or is responsible for resolving security vulnerabilities, the fact that we have such a big split does indicate that there is a problem. Again, we’d love to see this middle number here that both are equally responsible grow, so that we’re really doing a team effort here.

There’s some issues here. I think number one is that developers, we don’t always have buy-in with developers, and also they don’t necessarily have the knowledge to really understand how to fix security responsibilities. They come out of computer science programs without really looking at security. It’s just not a focus. We’re focused on how to create features, not on how to create secure software.

Again, I feel like I’ve been saying this over and over again, but our insight here, number nine, is that we need to do more to encourage a collaboration between security teams. I think we’ve used the stat earlier, but 76% find implementing this culture of collaboration between security and development teams challenging. So we need to look at it from both sides.

Again, we need to look at it from a developer point of view, and maybe they need to have more goals that are security focused. Maybe they need to have more training that is teaching them how to securely code. But also, we need to look at it from the security point of view and saying, “How can we give them more context? How can we be a better partner? How can we support them so that they know easily and immediately how to fix a defect?”

So I definitely think from people that I’ve talked to for quite some time, customers and other people out there, this is definitely something that is a known issue and a known need that we need to really work on this relationship between the two partners.

And then we finally asked a question, we actually asked a series of questions here, about how willing you would be to consolidate onto one platform and how quickly would you be willing to do this? And when we asked our respondents, I think we were kind of blown away that 90% would consider consolidating all of their AppSec tools onto a single platform.

So there is definitely this desire to cut down on the number of tools that we’re managing on a daily basis, partly because we have budgetary constraints and we want to do more with less. We’re either getting level funded or our budgets are getting cut. And so we need to figure out what tools aren’t pulling weight so we can jettison them.

And then I think also really, I want to go back to that, our AppSec teams are super lean. They’re really, really small, and so you need to do more with less. We really have moved similar to what cloud security has done, where they went from point solutions, have moved over to platforms. We see now that there is this movement towards a platform play where you can get all of your alerts and all of your information in one place.

Now, when it comes to an application security posture management platform, that has the added benefit of giving you context across your entire SDLC. So you can trace a vulnerability from your repos through to your build and your artifacts all the way out to your cloud environment. And instead of having to fix five vulnerabilities, you can realize that hey, they all have one single source and you can start and fix it once and have it corrected all throughout.

So I think there’s a lot of advantages that people are starting to see from moving to a platform play and the willingness to go that route is much bigger than we anticipated, and it’s definitely something people want to do in a very short period of time. So we’re definitely seeing with our customers and with other people in the market that there’s this idea of tool consolidation and moving to a platform, has a lot of advantages, budgetary, easier to manage, better context and insights. And so we really feel that this is the future of the market.

So those are my top 10 insights from the State of ASPM. You could certainly go to our website and download the full report for more insights. Before I move on, if anybody has any questions, please feel free to stick them in the question box on the webinar interface and I’d be happy to answer them. But just a little bit about Cycode before we do move on to questions and answers.

We are a complete application security posture management. We have a really great pipeline security solution that looks at and locks down your pipeline. So it helps you prevent against software supply chain attacks. It does things like scan for hard-coded secrets. We can lock down your CI/CD tools and understand who has access. We also do code leakage detection and much, much more. We have a whole application security testing suite of tools. So we have our own native scanners for software composition analysis and SAST as well as IAC and container scanning. So you can come to us for one-stop shopping for a whole AST platform if you’d like.

We also have a posture management platform or component to our platform, I should say, where we have the ability to connect with your existing tooling. So there’s a lot of reasons why maybe you don’t want to rip out a scanner that you’ve had and you fine-tuned and you spent a year implementing. Maybe you want to pull in that data. We allow you to do that so you can connect to that data to our platform to get all of your scan results in one place.

So we are the only complete application security posture management platform on the market in that we have our own scanning tools and we allow you to connect and connect your existing scanning tools if that’s the route you want to go. So you can choose our own, choose your own, or do some kind of hybrid combination thereof.

And at this point, I would love to take any questions you might have. Just feel free to stick them in the box. I don’t have any questions at the moment, but while you’re thinking, if there’s anything you’d like answered, I want to just share one other tidbit of information that isn’t in the presentation and isn’t in the report, but I think is really, really interesting as well.

And that is we looked at some of the main barriers for adopting new AppSec tools. So it goes into the, are you interested in consolidating? And interestingly enough, creating cross-functional teams to support the tooling was the number one barrier to adopting. Again, that goes into the whole culture of collaboration.

The second most important barrier, as indicated by our respondents, was training developers. So again, 37% of respondents said that that was a barrier. There were a couple of outliers. So when we looked at the healthcare industry, training developers was their number one concern. That’s 56% of them said that that was their number one barrier for adopting new information or new tooling. And then manufacturing said that time to value was really a challenge for them.

All right, so I guess that brings us to the end of our time here together. Thank you so much for attending. I really appreciate your time and we hope to see you next month when we have more information. Oh, actually I have one more question that came in. Let me just see if I can find it. It’s a question about Veracode. I can take that offline with you. So great. Thank you everybody. We appreciate your time and we will talk to you soon.