Why ASPM is Critical Now—And How You Can Make It Happen

Originally published by Dazz.

Written by Tomer Schwartz, Co-founder & CTO, Dazz.

By 2026, 40% of organizations will have an Application Security Posture Management solution (ASPM) in place, according to Gartner.

What’s driving the need for ASPM solutions? The Cloud Security Alliance (CSA) recently surveyed 2,000+ practitioners to uncover pain points in vulnerability remediation and security posture management and the results illuminate why these solutions are critical to cybersecurity practitioners:

• Only 23% of organizations have full visibility into their cloud environment
• 77% experience less-than-optimal transparency
• 75% of organizations spend over 20% of their time performing manual tasks—despite 83% reporting using some kind of automation in remediation
• 18% of organizations reported taking more than 4 days to address critical vulnerabilities, with 3% exceeding two weeks.

The list of challenges goes on and on.

More code → more vulnerabilities → more attacks

Businesses are building applications faster than ever. According to Grand View Research, the “size of the global market for bespoke custom software development was estimated at USD 24.46 billion in 2021, and is anticipated to increase at a CAGR of 22.3% from 2022 to 2030.”

Security analysis can almost never keep up with the pace of development, and as applications are built faster, there are more potential pitfalls—which has a direct correlation with more vulnerabilities and more attacks.

This strengthens the issue we’re talking about here: visibility into the security posture of an application.

Primary challenges in application security fall into a few categories:

1. ‍Manual processes - addressing issues becomes a problem across different business units.‍
2. Unification of security tools - hinders visibility into the overall security posture, given the fragmented nature of the different security tools.‍
3. Consolidation of security tools - they're doing their job, but spitting duplicate findings.‍
4. Security analysis pace - the development pace is too fast for security analysis to be able to catch up.‍
5. Open source dependent - more apps use open-source libraries that are not vetted for security risks.‍

Application Security Posture Management to the rescue!

We’re focusing this article on implementing ASPM, but as a quick review on what it is, Application Security Posture Management is a way to keep an eye on the entire software development lifecycle, correlating the findings of your variety of security tools, identifying root causes, and prioritizing the most critical fixes first.

Take a look at this video that covers the most common questions about ASPM:

Making ASPM happen

How can you make sure you’re part of the 40% or organizations with a plan in place to implement ASPM? What does your solution need to do? Three important considerations here:

1. Ensuring full coverage. The application security posture management solution you pick needs to be able to ingest data across your code-to-cloud environment, complete with strong integrations with developer tools, app security tools, scanners, and ticketing processes. Integration is absolutely a key factor here; testthe integrations—don’t just check the box that a solution does them—to confirm you get the coverage required. Most ASPM implementations begin here – connecting systems and gathering data from each into one unified view.

2. Faster triage and remediation. If you’re easily able to start spotting root causes for security issues, you’ll know you’ve got your ASPM solution set up for success. Ideally, you’ll be able to drill down all the way to lines of code and owners in finding where an issue originated. (This capability has become critical in light of instances like the Log4Shell vulnerability).

Consider this anecdote as laid out in Application Security Posture Management (ASPM) for Dummies:

“One financial services company took an ASPM approach to the Log4Shell vulnerability fix, and got its frightening wildfire under control in just a few days. It learned that it had nearly 3,200 vulnerable applications…but root cause analysis narrowed it down to 144 affected images that were vulnerable.
The root cause analysis dug further and pointed to just 62 Dockerfiles that needed to be fixed, and it identified about a dozen code owners who’d committed the code to these Dockerfiles to take care of the fixes. Getting to the root of the problem quickly allowed the company to put fixes in place incredibly efficiently in a time of significant security crisis.”

3. Tracking down owners. Who’s the person responsible for fixing the identified issue? Perhaps it’s the developer who wrote the code, or perhaps it’s the person responsible for your cloud infrastructure. Your ASPM solution should automatically surface up that answer. Keyword: automatically. Determine how issue resolution happens in your organization and plug that information into your identification logic. Once your ASPM solution understands how to assign ownership, it will be simple to orchestrate fixes and report on your security posture.

Finding the finish line

So how do you know when ASPM has “happened?”

Once your fix is detected and assigned, your ASPM solution should be able to automatically create remediation workflows. The ticket for the responsible developer should show up in the platform the developer already uses and provide full context into the whys and wherefores of the fix.

Developers can then examine and test the fix suggested by the ASPM solution and implement it if acceptable. Note that this stage can be completely automated depending on your comfort level and the scope of the fix (whether it’s an internal or external application, business criticality, etc.).

At this point you’ll want to make sure you’ve hit the ultimate goal of ASPM: to manage and reduce the risk of applications that your organization builds. You’ll want to keep an eye on risk and trends over time, visualizing them to ensure issues are remediated fast and that risk windows are fully closed. Make sure you can report on applications that have the most vulnerabilities and how long they’ve been sitting unfixed. Teams (both security and development) can also use this data to identify gaps in the process and make improvements.