ASPM and Modern Application Security
Gartner’s 2024 Hype Cycle for Application Security is making the rounds, and Application Security Posture Management (ASPM) continues to climb up and around the famous curve, from the Peak of Inflated Expectations in 2023 to this year’s slide towards the Trough of Disillusionment. That’s pretty fast movement for a technology that we haven’t yet succeeded in clearly defining! It’s an important concept, however, and well worth taking the time to consider how we got here and what we think is the smart road forward.
The before times
For a very long time, the prevailing attack surface was the network layer. Naturally, organizations focused on plugging holes in the network layer, and over time, network security tools became extremely efficient at keeping attackers at bay. So, just as naturally, attackers moved on to greener pastures—and they found plenty of opportunities in the application layer.
Despite the number of breaches that began piling up, organizations still largely looked at application security as a compliance exercise, externally motivated by regulation, customer requirements, and executive mandate. Do the scan, check the box, move on.
This was (and still is in some places) immensely frustrating to all of us who always want to see real security happen. Because breaches continue to occur and continue to get worse.
More recently, organizations have begun to see the light. (Serious data breaches have a way of doing that.) Now, we see growing concern about real risk, which has created an internally motivated drive to move from a compliance approach to one based on managing application risk. Finally, popular opinion is coming round to what we’ve known the whole time: AppSec matters.
ASPM represents that shift from compliance to risk. We are entering the era of actually managing risk in application security, instead of either doing nothing or running around like chickens with our heads cut off (still doing, effectively, nothing).
But just what is ASPM?
ASPM is still evolving as a market, and what exactly it is and does is still up for discussion and innovation. At Mend.io, we break it down into two values:
1. Consolidation and standardization
Thus far, SAST, SCA, container, etc., scan findings have largely been seen as their own separate results. But because each finding equates to some amount of risk, all of these scans should be compared and contrasted. This means both consolidation and standardization, and both are still emerging areas.
For instance, it’s useful to evaluate if Finding #12 in my open source code is more or less risky than Finding #8 in my custom code. Putting all of the vulnerability findings on one scale makes for easier prioritization across the entirety of the application security domain.
2. Context
No one is going to fix all of the vulnerabilities, because it’s simply not feasible. But fixing the wrong vulnerabilities—the ones that have no actual bearing on real risk—is worse than fixing none at all. It’s both money poured straight down the drain and can be demoralizing to the teams tasked to do the work.
With ASPM, more contextual data on findings is possible, including but not limited to:
- Reachability
- Exploitability
- Is a fix available?
- Is the application in production?
- Is it business critical?
- Is it internet-facing?
In turn, this means better prioritization and effective remediation of the 5% of findings that actually affect 95% of your security posture.
ASPM ≠ single pane of glass
ASPM needs to be more than yet another dashboard bringing information in via API.
It should not be about simply seeing, but rather about assigning true risk to a vulnerability through accurate evaluation. That brings us back to the importance of consolidating, standardizing, and contextualizing risk management data.
As we see it, there are currently three approaches to adding that context:
- Filtering. Filter by exploitability, reachability, severity score, etc. It seems good in theory and it will work for one-off projects, but it falls apart as developers keep adding things over time.
- Risk scores. This involves assigning points to things like exploitability and reachability, to create a final risk score that organizations can use to remediate those that have the highest score. The problem here is that no one believes the scoring. It’s a one-size-fits-all approach that assumes average and standard organizations to begin with, when there’s really no such thing.
- SLA-based risk scoring. We think there is a third alternative. Prioritization scores mean nothing if no one believes them. This is an ongoing issue with vulnerability findings and nothing new to ASPM, but we think the better option is to build a score that’s believable because each organization builds it themselves based on their own SLAs and other factors that make sense for their specific goals.
Understanding the future of application security starts with learning the lessons of technology history, and we have certainly seen this pattern of hype to consolidation and standardization before. As threat actors continue to focus their indefatigable efforts on the application layer, the motivation to quickly mature ASPM will only grow, so we expect to see rapid and ongoing innovation in this area. Stay tuned!
