The only thing more debated than the meaning of Application Security Posture Management (ASPM) is whether the investment into an ASPM tool is worth it. Since the unveiling of the category, vendors of every type rushed to claim that they do it, but not a lot of ink has been dedicated to whether it’s actually the future. Ultimately, the future of application security is best addressed by understanding what its biggest problems are. In this article, we’ll talk about what problems created the category of ASPM, and assess if it offers the solutions the market is looking for.
Problems in Application Security
Too many scanners
Since I originally argued for ASPM including 8 kinds of scanners, at least two more have popped up. Security teams can stomach scanners, but only if they make sense to be different. Scanning servers at runtime doesn’t necessarily need to be in the same place as what’s scanning repositories. The problem is that repositories have become a more reliable source of truth for where to find and fix vulnerabilities.
While being one place, a repository can hold dozens of different files doing many different things. Traditionally, security teams needed to set up multiple different docker images or binaries to scan these files as they were changed and deployed. Maintaining scanners could easily be multiple full time jobs, as they all also needed special configurations to work on different pieces of code.
Security teams need the visibility of all these different scanners, but benefit tremendously from the simplicity of either “agentless” pipeline webhooks that scan with zero configuration, or at least telling a single tool to scan. ASPM tools do a great job of providing simple visibility.
Too many false positives
The counterpoint to wrapping every scanner into a single place is that people argue there will be a degradation in scan quality. I’m sensitive to this concern, but have two counter points. First, many tools are just wrapping the same open source stuff anyways, the all in one scanners are just being more honest about it. Second, these arguments always rely on the idea that it’s just impossible for someone’s scanner to be as good as their own.
Ultimately, the problem is just solving the issue of too many false positives. Reachability is the idea of discovering if a vulnerability can actually be exploited or not. Many ASPM tools have built in “good enough” versions of reachability, so it’s getting harder every day to argue that it can’t be done.
Worst of all, scanning for CVEs alone can leave critical blind spots, which is why I appreciate providers like Xygeni for two reasons: first, their scanning upstream for malware instead of just vulnerabilities. Second, their commitment to look for other exploitable configurations like pipeline misconfigurations, as well as detect if these attacks have happened.
Fixing things is really hard
Security teams see very little velocity in fixing their vulnerabilities. I’ve heard numerous horror stories of even the most egregious zero days taking months to fix across entire enterprise ecosystems. While many tools have said the issue is “prioritization” you can prioritize all day, but if engineers can’t fix something easily, it’s all for nothing.
This has been a trend more on the “vuln management” side of ASPM, but helping developers fix vulnerabilities should be the real goal of ASPM.
Too much code, too fast
If we think that the cloud accelerated code deployments, generative AI has only increased the velocity of code. Another under-discussed point is how generative AI continues to open new audiences to code – allowing everyone from sales teams to accounting to create python scripts that do simple things.
These developments have made scanning frequently, often, and in diverse environments more important than ever. If a lengthy approval process is needed to set up new applications with scanning, you’re just going to be prepared to go blind.
Environments are too diverse
While the number of scanners can be overwhelming, when you add everyone’s flavor of the month Javascript framework, language variant, or other frameworks, finding “best in class point solutions” just isn’t possible anymore. I don’t see security teams looking for a best in class scanning solution for every flavor of Javascript. A single ASPM tool can make scanning coverage much more widely available than trying to go on a language by language basis.
ASPM Tool Solution?
These problems are why I defined ASPM as:
Application Security Posture Management provides everything needed to scan and remediate your application for vulnerabilities. It provides security scanning across your SDLC pipeline, ingests results, and builds remediation workflows.
In practice this comes to fruition as an all-in-one source code integration that seamlessly scans your code for vulnerabilities, prioritizes them, and helps get them assigned to the right people. Let’s look at how this solves all the main problems in AppSec:
Too many Scanners
- This is self explanatory – there’s just no reason anymore to have 8 different point solutions when one can be good enough to cover most of your stack
Too many False Positives
- While the idea of “better point solutions” persists, ASPM’s typically have much more holistic visibility into how an application works. Whether it’s mapping build dependencies, or the “code to cloud” picture – these tools typically do a better job eliminating false positives.
Fixing things is really hard
- To be fair, this is where (in general) many providers who have stayed off scanning have built better engines for fixing things. Either way, this is where ASPM excels over CSPM – it actually has a method for getting findings to the people who can fix them.
Too much code, too fast
- The fact that automatically deploying scanners into new repositories is such a rare feature tells you how only webhook based ASPM allows security to scale as fast as the amount of code in an environment is
Environments are too diverse
- While there may always be edge cases, “best in class” is getting harder and harder to evaluate – is a security team supposed to test 8 scanners against 5 languages with 10 proof of concepts?
I stand by ASPM (and ASPM tools) being the future of application security, it solves most of the problems faced by application security professionals. As soon as existing contracts are up, or even before, practitioners are going to be running to these newer solutions. The only thing stopping them is awareness that there’s a better way.
