Why ASPM Requires an Independent Approach: Exploring the Role of ASPM vs. CNAPP | Part 1

Exponential growth in code, an unmanageable attack surface as a result of Cloud + DevOps, accelerated development cycles, and tool sprawl have overwhelmed both development and security teams, making it impossible to effectively pinpoint and fix the most critical issues that have the most impact with the limited amount of time and resources organizations have.

Application security continues to evolve as modern development practices and cloud native adoption such as containerization, Infrastructure-as-Code (IaC), and GitOps have blurred the line between application and infrastructure. As a result, application security continues to converge with cloud security. Point solutions that only provide partial capabilities – like scanning custom code and open source libraries – will no longer be sufficient to identify and analyze risk holistically in context across the software development lifecycle (SDLC), leaving critical gaps in security coverage. Having multiple point solutions, often owned by different teams, also leads to duplication of efforts, causing developers to drown in confusion on what to fix and who to trust.

It is clear that a platform solution is required to cover all layers of an application lifecycle and provide an aggregated risk context across all the findings as it moves across the SDLC into its ultimate destination. This platform solution should identify and bring all the risk context from multiple capabilities across the SDLC and generate actionable remediation guidance. The platform solution should also unify stakeholders across development, operations, and security who often operate in silos.

This is where Application Security Posture Management (ASPM) comes in. 

Inclusive and transformative, ASPM is designed to unify point solutions and secure everything that happens within development. This, in turn, helps developers accelerate their ideas into production safely.

This is similar to what Cloud Native Application Protection Platforms (CNAPPs) were designed for:  unifying point solutions to secure everything that happens within the cloud.

In this blog post, we’ll explore what ASPM is, how it’s evolved over time (aka the 3 waves), the key differences between ASPM and CNAPP, why ASPM should stay independent, and what to look for in an independent and Complete ASPM platform.

The Definitions of ASPM vs. CNAPP

What is ASPM?

ASPM is a unified approach to identifying and managing risks holistically by providing visibility, prioritization, and remediation capabilities across the entire SDLC. ASPM is designed to ensure that security teams have complete coverage and can discover issues across development quickly and accurately. It also helps developers – who are constantly under pressure to deliver code faster – prioritize risks based on full context and take the right actions.

At Cycode, we define ASPM as a complete solution that offers full coverage to discover and identify risks holistically across the SDLC. The solution should covers all the code artifacts across different SDLC stages sourced both internally or from a third-party supply chain, the build and deployment pipeline systems as code moves through the SDLC process, and finally, the deployment itself where the fully packaged software runs – regardless of the destination: cloud, on-prem, or hybrid infrastructures. 

Unlike point solutions that focus solely on only specific capabilities such as secrets, supply chain, or application security testing (SAST, DAST, SCA), a complete ASPM platform integrates all of these capabilities, augmented and further enriched by its own native capabilities, into a single, unified interface that aggregates, contextualizes, and prioritize risks that are easily actionable by developers.

Importantly, the ASPM market is still early and not all ASPMs are created equal. 

Some solutions are incomplete, lacking either the quality or coverage needed to provide full visibility, risk context, and remediation capabilities. To explore this further, we need to take a look back at the evolution of ASPM, focusing on the different waves of solutions that have emerged in recent years.

The Evolution of ASPM: The 3 Waves

The types of ASPM’s can be divided into three distinct waves, each representing a different level of maturity in the overall ASPM market.

Standalone ASPMs (Legacy ASOC)

These early ASPM solutions, also called Application Security Orchestration and Correlation (ASOC) focused primarily on consolidating third-party security tool data into a single platform for improved visibility and management. They were a specialized subset of Risk-Based Vulnerability Management (RBVM), focused on the application layer. 

While helpful, these tools only focused on aggregating data across different scanners with some deduplication capabilities. And, unlike infrastructure, vulnerabilities for modern application stack are super complex. That means that without context, everything could become noise. 

The bottom line: Early ASOC vendors lacked critical capabilities to enrich data with risk context for proper prioritization, resulting in aggregating more noise across tools with results being even less actionable for remediation. 

Supply Chain ASPMs

With the rise of software supply chain attacks, some supply chain security vendors began to reposition themselves as ASPMs, despite significant gaps in their offerings. 

These solutions lacked native scanning capabilities, prioritization, and automated remediation tools. Without these features, security teams were still left manually sorting through vulnerabilities, making remediation time-consuming and inefficient.

Complete ASPM

Now, the third and most advanced wave has arrived: Complete ASPM. 

A true Complete ASPM platform like Cycode offers end-to-end security across the SDLC, covering application security testing for both application and infrastructure code artifacts (sourced both internally or from third-party supply chain), deployment pipeline system configurations and secrets, and advanced prioritization and remediation tools that are also enriched by production infrastructure security and runtime security context. 

Cycode’s platform also includes ConnectorX, which seamlessly integrates with cloud-native applications, and the Risk Intelligence Graph (RIG), which dynamically surfaces attack paths from infrastructure, pipeline, workloads, or code artifacts and map them all the way to source code and project owners, allowing for faster, more efficient remediation. This level of visibility and control is crucial for ensuring that organizations can secure both cloud and on-prem environments while keeping development velocity high.

The Evolution of CNAPP

CNAPPs provide a unified approach to securing cloud-native applications running in the cloud by combining several critical security functions into one comprehensive platform. Originally, CNAPP was meant to bring together two foundational cloud security capabilities that were operating in silos: Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP). 

CSPM focused on identifying cloud layer misconfigurations across various cloud native services against a set of compliance standards. CWPP focused on the cloud workloads layer, providing deeper visibility into the IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service), and sometimes Function-as-a-Service (FaaS) workloads across virtual machines, containers, container orchestration layer, and serverless functions (code). CWPP could be considered an extension of Endpoint Security designed for the cloud. 

The original version of CNAPP vendors was simply an acronym that described vendors who have both CSPM and CWPP capabilities as a single platform, organically developed or via acquisition. There was no contextual correlation and prioritization between the two, similar to the ASOC era of ASPM. 

Later, the second generation of CNAPP vendors was able to advance the contextual correlation between CSPM and CWPP by leveraging an innovative agentless approach of taking and analyzing cloud workload snapshots and correlating them to cloud configurations via graph database. With a more holistic risk context, these solutions could prioritize the most toxic combination of issues with the greatest impact, versus non-actionable reporting on every single non compliant finding. The second generation of CNAPP solutions also leverages more lightweight agents using techniques like eBPF to extract real-time context to enrich their findings. 

But was that enough? As more organizations invested in CNAPP and attempted to operationalize it at scale across multiple clouds, it was evident that there were still gaps. 

As an example, CNAPP only provided surface level identity misconfigurations such as checking whether MFA is enabled or not, or determining over-privileged services or workloads. CNAPP could not inventory dormant identities and validate their blast radius, nor could they monitor role assumptions, permission-chaining, or detect cross-account privilege escalation attacks. As a result, Cloud Identity and Entitlement Management (CIEM) solutions emerged to specialize in cloud identity security, augmenting CNAPP.

Similarly, CNAPP could identify toxic combinations of cloud and workload misconfigurations, to include data stores and database workloads. However, CNAPP does not have visibility into what sensitive data resides in those data stores, who has access to those data stores, or what operations those identities could perform on those data. As a result, Data Security Posture Management (DSPM) emerged as a separate category to address cloud data security holistically, augmenting CNAPP.

As cloud security continued to evolve, vendor consolidation began to accelerate. Major CNAPP vendors began to acquire CIEM and DSPM solutions. This is an acknowledgement that the foundation of CNAPP was not designed to go deep into a particular domain like identity and data. 

As these acquisitions continued, many industry research analysts began to refine the definition of CNAPP, essentially adding in these additional capabilities based on vendor acquisitions, not by logical categorization. If we apply the same approach to security solutions on-premise, then network security, endpoint security, data security, and IAM would all just collapse into Infrastructure security. 

Interestingly, in some analyst reports, CNAPP, DSPM, and CISM remained as separate categories, along with ASPM and AST as separate categories. To truly achieve comprehensive security and embrace the concept of defense-in-depth, we need multiple categories of solutions to complement one another. 

CNAPP cannot be the end-all-be-all solution that goes deep and wide across the entire IT stack.

The Gaps and Challenges of Expanding CNAPP to Cover Application Security

Modern development and the adoption of containerization, IaC, and GitOps do require treating programmable infrastructure components the same way as a piece of software as they move through the development and deployment process. Therefore, these components need to be secured the same way software is, and issues need to be addressed as early as possible in development. 

As a result, container security solutions that checks raw Dockerfile and IaC security solutions that scans both IaC templates and container orchestration manifest files and tightly integrate with both development and cloud began to gain popularity. Both AST platforms and CNAPPs began to develop these capabilities. However, neither had the full context. 

AST vendor’s solutions did not have the cloud and runtime context, while CNAPP vendor’s version did not have developer and broader SDLC context. While both parties tried to close the gap, CNAPP vendors had made several acquisitions in the space, such as Bridgecrew, Cider Security, Soluble, Apolicy, and others. This again demonstrated the foundational gap within CNAPP.

CNAPP was designed to secure everything in the cloud, not everything that happens during development. This is where ASPM plays in. While both ASPM and CNAPP are crucial to an organization’s security posture, they serve different purposes and must operate independently to maximize effectiveness. 

Here are some of the gaps with CNAPPs and their reach into application security: 

1. 1. Different DNA. CNAPP vendors have no foundation that could be leveraged to build quality application code scanners that integrate across development tool chains that focus on developer experience. CNAPP’s core foundation was built around cloud configurations (CSPM) and cloud workloads (CWPP). Even with the late enhancements of cloud identity (CIEM) and cloud data (DSPM), CNAPP’s core DNA is still very much built to secure everything that happens within the cloud and with some ties into both DevOps and SecOps workflows.

      ASPM, on the other hand, is built with a core DNA to secure everything in development, the code artifacts, and the software factory process that turns organic and third-party code artifacts into running applications in production across ANY environment: cloud, on-prem, or hybrid. ASPM may draw context from CNAPP on running workloads or cloud configuration settings to further enrich issues found in development, but it is not designed to cross over and replace CNAPP.

   2. Developer Security Context. Given the blurred line between application and infrastructure in the age of cloud native, while there are overlaps into development workflows where container and infrastructure-as-code security capabilities do span across both development and cloud, CNAPP has no application layer context the way ASPM does.

      As an example, CNAPP vendors may have Software Composition Analysis (SCA) capabilities as an extension of their container security capabilities that detects application library packages in a container image, but they do not have the ability to inspect package manifest files and build a dependency tree that shows both direct and transitive dependencies.

      SCA scanners from CNAPP also can’t correlate with SAST scanners to identify which application libraries actually have an exploitable path from a custom function call in the source code. In the software supply chain risk management context, open source libraries could be modified and injected with malware during the SDLC process, and only an ASPM tool with software supply chain and pipeline context could detect that change.

   3. Developer Experience. Modern application security solutions should focus on developer experience. This means that the solution must be able to integrate across the SDLC (IDE, IDP, source code repositories, on pull-request checks, ticketing system, ChatOps, during the build process, and any software factory repositories) to meet developers where they live, while remaining flexible for workflow optionalities.

      ASPM was designed for the end-to-end developer experience with all the common SDLC integrations, where CNAPP was not.

      Additionally, discovery and inventory in development are very different than in the cloud. CNAPP’s discovery and inventory function was designed to discover and manage all cloud assets and group them under cloud accounts and subscriptions. Discovery and inventory in development is more nuanced and requires careful grouping and CMDB mapping to attribute code artifacts to repositories, projects, branches, development teams, and developers. ASPM was designed for discovery and inventory in development, where CNAPP was not.

ASPM Should Remain Independent from CNAPP

For CNAPP to cover full application security capabilities across the SDLC comparable to a Complete ASPM, it will take years to build a new foundation from scratch, incrementally adding and integrating each individual capability into the broader platform, and optimizing for enterprise scale.

While CNAPP vendors continue to make acquisitions to expand their portfolios, it will also take time to fully integrate acquisition into parent platforms. This was evident in the last few years as the CNAPP platform evolved. 

Furthermore, relying both development and cloud security on a single vendor is risky. 

In the event of a vendor outage or failure, it is not a big deal in the cloud where the agentless side of the CNAPP solution will simply not detect any new risks. It may be a big deal and a bunch of unhappy developers if a security scan via pull-request timed out where code could not be merged and promoted to the next stage. This is the easiest way for the security team to lose trust.

For now, ASPM and CNAPP should remain separate. In fact, they complement each other very well. In part two of this blog, we will deep dive into how ASPM and CNAPP could augment each other and enhance each other’s capabilities.