ASPM breakdown: Pros and cons of different application security posture management approaches

Despite the maturity of the AppSec landscape and the plethora of tools on the market, security teams continue to struggle with maintaining holistic visibility into their application security posture. Application security testing (AST) and software supply chain security (SSCS) tools have solved the detection problem, but they’ve also created new challenges. They produce a huge volume of findings that lack the context of the broader application and business, making it difficult to understand the true security posture of an application and address critical risks effectively.

So in order to solve a new challenge, there has to be a new acronym…right? 😏

Kidding aside, ASPM (short for application security posture management) has the potential to transform AppSec, offering a holistic approach that connects application risk visibility, assessment, prioritization, and remediation.

What is application security posture management (ASPM)?

The goals and foundations of ASPM solutions are universal:

1. Bring security signals together to correlate and prioritize them by risk.
2. Take action on those risks with automated workflows and policies.

But how ASPM solutions execute against those goals, and the extent to which they’re achieved, varies widely. While there are some commonalities between ASPMs—namely how automation is leveraged to trigger alerts and processes—there are stark differences in how ASPMs ingest, correlate, and enrich security findings to deliver the value of ASPM, which we’ll explore in this post.

Different approaches to ASPM

Each approach to ASPM has its value and purpose in distinct scenarios. It’s crucial to understand the differences between them and the kind of value that you’ll see with each method.

ASPMs that rely on code vs. runtime

Some ASPMs focus more on runtime and risks in production, making them more similar to cloud security posture management (CSPM)—but focusing on the application versus the infrastructure layer. Others are more rooted in code, making them more closely aligned to developers and the development lifecycle. These are the pros and cons of each:

Runtime ASPM pros and cons

• Pro: Runtime solutions do have the benefit of knowing exactly what is deployed as well as insights such as whether a vulnerability is internet-exposed or behind an API gateway. Those are often the most pressing issues, so it is valuable to get a consolidated view of those production risks.
• Con: Relying on reverse engineering to understand applications yields fragmented visibility into your application attack surface and makes it difficult to accurately correlate risks to their root cause and code owners.
• Con: Solutions that take this approach are typically deployed via an organization’s environment through CI/CD pipelines, which can be arduous, complex, and time-consuming to deploy across multiple pipelines.
• Con: Focusing on risks that are already released into production forces a more reactive approach, making it difficult to effectively prevent risk. Risks found in production need to be fixed out of band to development cycles, creating re-work and context switching for developers.

Code-based ASPM pros and cons

• Pro: Code-based ASPMs allow for real-time, continuous application inventory, material code change detection, and assessment across anything defined in code or activity in repositories. That includes data models, APIs, pipelines, security controls, code modules, infrastructure as code, containers, developer behavior, etc. as well as their relationships and changes over time. Since code is the source of truth for applications, this provides a more complete picture of your application attack surface.
• Pro: Integrating with code repositories is simple, fast, and does not impact production, which provides fast time-to-value and reduces the risk of performance issues or interruptions.
• Pro: Deep contextual knowledge of code allows ASPM solutions to understand a risk’s impact (i.e. a vulnerability in an application handling sensitive data has a greater potential impact) and likelihood (i.e. whether a risk is in applicative vs. test code is more likely to manifest as a real risk) through the contextual lens of the application and organization. This allows for better prioritization of risk, ultimately decreasing the backlog, reducing noisy findings from false positives, and improving the mean time to remediation (MTTR).
• Pro: By analyzing commits and pull requests, code-based solutions can be embedded directly into development tools and workflows to proactively prevent risk and ensure compliance with data-driven developer guardrails, policies, and standards.
• Con: Without reliable context as to whether a risk is in a deployed, internet-facing, or reachable component, it’s hard to understand the likelihood of a risk for accurate prioritization.
• Con: Since this approach requires connecting to code, it’s critical to select a vendor that has depth and breadth across languages, frameworks, and technologies.

The solution: Code-to-runtime context

Leveraging an ASPM that has both a strong code foundation and reliable runtime context is the best way to get the most complete visibility and context you need for prioritizing findings while also being able to tie production issues to their root cause and code owner and be proactive about addressing risky changes and risks earlier in the development lifecycle.

ASPMs that only integrate vs. provide native solutions

Some tools focus more on integrating and aggregating findings from third-party security testing tools while others provide native solutions themselves. The former evolved from application security orchestration and correlation (ASOC), while the other proposes to replace application security or software supply chain security tools, in many cases, taking a more “next-gen” approach.

Integrator ASPM pros and cons

• Pro: For organizations that have existing scanners in place, being able to ingest and unify findings from SAST, SCA, DAST, etc. tools in an ASPM is a great way to enhance existing investments. To get the ASPM value, however, it’s crucial that there is an intelligent layer of context on top of the aggregation for correlation and prioritization.
• Pro: By aggregating those results into a single control plane, you not only get a centralized picture of your application risks but also a single workflow or policy engine to trigger processes or embed developer workflows without getting alerts or tickets from multiple tools.
• Con: Getting findings in one place is the first step, but without strong context, this approach lacks the depth of analysis you can get from detecting specific risks natively. Without native context, it’s challenging to accurately deduplicate, correlate, and assess risk, watering down the prioritization and remediation insight these solutions were built to provide.
• Con: Depending on the vendor, integrations could be challenging to set up and maintain, and because integrations are as much a breadth play as they are a depth play, the latter is often lacking. When selecting a vendor based on the integrations it supports, make sure that they not only check the box but that integrations are as robust and built out as possible.

Native solution-driven ASPM pros and cons

• Pro: As we covered in the previous section, contextualizing security findings is core to ASPM. Because that context requires extensive analysis—especially for code-based solutions—it may be a natural progression to also surface insights related to risks. For example, when analyzing APIs and their changes, it’s natural to also be able to detect potential weaknesses.
• Pro: For less mature AppSec teams that don’t have any security tooling or have gaps or for one-off projects that you need quick coverage on, leveraging an ASPM with native security solutions is a great way to quickly get off the ground running or fill gaps where testing coverage might not yet exist. When enabled by a single integration point, ASPMs with native security context can provide very fast coverage compared to purchasing, onboarding, and implementing multiple tools.
• Pro: ASPMs that integrate and aggregate have to stitch together metadata from external and internal sources to correlate and prioritize, leading to some inevitable misalignment or missing insights. For ASPMs with native solutions, connecting the dots between a security finding and related context is easier, leading to improved accuracy and comprehensiveness.
• Con: Compared to best-of-breed tools that specialize in a particular vertical, some ASPMs will not be able to deliver the same depth for each category of risk. When investing in an ASPM to help get initial coverage, be sure to understand the support matrix across disciplines and technologies and make sure that is satisfactory for your expectations and requirements.

The answer: Open platform with native context

Investing in an ASPM that has strength in both integrations and native risk detection capabilities and context is ideal. For large enterprises that have existing tools, especially, ASPMs need to ingest findings seamlessly for correlation, deduplication, and prioritization. For less mature AppSec teams, getting out-of-the-box detection is valuable. Regardless, ASPMs need to have foundational context derived from native scanning, code analysis, and runtime context to enrich findings and truly deliver the value of prioritization.

Apiiro’s deep ASPM solution

Apiiro’s deep, multidimensional approach to ASPM goes above and beyond the basics, combining the best of all ASPM approaches.

Deep code analysis and runtime context

To empower AppSec teams to prioritize, remediate, and assess application risk, you need a deep, code-level foundation of your application attack surface with additional context across the development lifecycle. To provide that foundation, Apiiro continuously ingests, analyzes, and contextualizes data from ticketing systems, code repositories, CI/CD pipelines, API gateways, Kubernetes clusters, and more.

Our continuous code analysis also allows us to detect potentially risky material code changes that need further investigation or assessment—an often overlooked component of application attack surfaces.

This rich, continuous inventory and graph-based model of your applications, software supply chains, and associated risks provides the visibility and context you need to deeply understand, accurately prioritize, and efficiently manage application risk.

Open platform with native AppSec and SSCS

At Apiiro, we are dedicated to providing deep, built-in integrations with existing security tools. We’re continuously adding new integrations with application security testing (AST) tools and have an API to ingest security findings from any tool or manual process like a bug bounty program or penetration test.

We also recognize that many organizations might have partial application or software security testing suites and that onboarding new tools can be taxing (or out of budget). For that reason, we extend our inventory to include native context around risks such as exposed secrets, API weaknesses in code, sensitive data exposure, open source vulnerabilities, license compliance issues, and more. With our simple SCM integration, you can get near-instant insight into existing risks, contextualized and prioritized.

Multidimensional prioritization based on likelihood and impact

Using the aforementioned code-to-runtime inventory, Apiiro provides correlation and prioritization based on actual risk. By taking into account your application architecture, the nature of your business, and the exploitability or validity of a security finding, Apiiro’s multidimensional prioritization minimizes false positives and helps focus on what matters most.

With our deep code analysis, we can determine whether a vulnerability is in applicative versus test code, the business impact of the associated application based on the type of data handled, and whether it is in active development. Our runtime context helps determine whether a finding is deployed or exposed to the internet. Those pieces of context, plus external data from vulnerability databases like CISA KEV and EPSS, give us unparalleled accuracy.

Risk-based control plane to automate remediations and processes

The goal of an ASPM is to reduce risk as efficiently as possible. In that way, prioritization is a means to an end, cutting down your backlog of irrelevant security issues so you can focus on addressing critical risks. But that’s just step one of efficiently fixing and preventing risks. Apiiro’s actionable remediation guidance, correlation of risks to code owners, and automated workflows help streamline the remediation process.

Prioritization also helps reduce friction between security and development teams by right-sizing the response when specific security weaknesses are flagged. For example, you may want to block a build only for a business-critical risk that involves sensitive data and not every 8+ CVSS score vulnerability. This risk-based approach empowers your organization to balance development velocity and security.

Lastly, by providing a single pane of glass for your application components, changes, and risks, Apiiro surfaces the key performance metrics and trend-based insights you need to benchmark, measure, and report on risk. This enables data-driven decisions on program priorities, strategy, and investment that will strengthen your security posture.

To learn the ins and outs of taking a multidimensional, risk-based approach to AppSec, download our ASPM Deep Dive e-book.