WTF is a Cloud Native Application Protection Platform (CNAPP)?
Death to CNAPP!
WTF is ASPM was easy to write because it was what I had hoped Snyk would become when they branched out of SCA with Snyk SAST back in 2020 - the all in one configuration scanner. Finally, I’d be able to throw my Cloud Security Posture Management (CSPM) tool into the dustbin of history. Early CSPM triggered thousands of alerts for the most obscure or mundane of misconfigurations, and modern CSPM is not much better.
Cloud Native Application Protection Platform (CNAPP) was an acronym bestowed upon us from on high to try and make sense of disparate cloud functionalities getting wrapped into single platforms. Gartner defines CNAPP as:
a unified and tightly integrated set of security and compliance capabilities designed to secure and protect cloud-native applications across development and production. CNAPPs consolidate a large number of previously siloed capabilities, including container scanning, cloud security posture management, infrastructure as code scanning, cloud infrastructure entitlement management, runtime cloud workload protection and runtime vulnerability/configuration scanning.
This definition directly explains the problem with CNAPP, its goal is to consolidate rather than solve a customer problem. Consolidation was driven by an arbitrary “platform play” to try and increase revenues, not out of a customer need. For comparison, ASPM is solving a problem, “I have too many vulnerabilities from too many scanners;” conversely, CNAPP solves the vendor’s problem, “People seem to be buying this thing, so let’s do that too.”
Since trying to define ASPM, I’ve been asked this follow-up question most frequently: “WTF is CNAPP?” On the one hand, this question is urgent because it’s the bigger market - all of the biggest cloud security companies have invested in this acronym because the projected market cap exceeds 20 billion dollars. On the other hand, “WTF is CNAPP?” is hard to answer because, unlike CSPM, CNAPP was created primarily for vendors and not for customers. At the heart of CNAPP lies an unverified assumption: that having everything in the same place provides security value.
In this article, we’ll briefly cover a history of the term CNAPP, where it seems to be going, and where I’d like it to go.
Table of Contents
CNAPP v1: CSPM + CWPP = CNAPP
More than anything, Palo Alto’s brilliant acquisition of Redlock (CSPM) and Twistlock (CWPP), set the stage for CNAPP. Slapping these two tools together and wrapping them with duct tape allowed Palo to say they had something beyond CSPM - they weren’t just scanning cloud APIs for misconfigurations, but also providing runtime defense and vulnerability scanning of the workloads. As an aside, for the remainder of the article I may use CWPP and EDR interchangeably, as CWPP was just EDR that worked in container contexts.
From there, the arms race was on. This is why CNAPP is defined more for vendors than for customers: it’s a collection of almost random capabilities, with no clear way that they benefit each other besides all being “in the cloud.” The image below shows the number of legitimate point solutions that are swallowed up by CNAPP vendors because they happen to get the same logs; however, having access to the same logs is not the same thing as building for a customer use case.
CNAPP v1 in all its messy glory
At the end of CNAPP v1, CNAPP included:
CWPP (Linux/Container EDR) - Some kind of visibility into workloads for detection and response
CSPM - Scanning Cloud APIs for misconfigurations (including identity, CIEM) and getting logs back for changes
Vulnerability Scanning - Checking images and hosts for CVEs
DSPM - Some kind of visibility inside databases
The above diagram also illustrates why everybody is a CNAPP, and nobody is a CNAPP. Vendors can arbitrarily choose any bespoke functionality in the shaded box and argue that “that tool isn’t a real CNAPP, they don’t even do {functionality} well.” Or, “you need to buy our CNAPP, because we offer {functionality}.”
When it came to early CNAPP adoption, I cared about CWPP because I cared about Kubernetes Runtime security, that’s why I always loved Sysdig the most. Those that loved open source loved Aqua. Those that loved CSPM loved Wiz. Those that already had contracts with Palo love Prisma (😉). Those with a CDR bent loved Lacework.
Mapping CNAPP v1 by Ease of Use and Fullness of Response Capabilities - a diagram truly everyone can complain about.
Until recently, I thought Wiz was so far ahead because ease of use trumped every other factor; however, I think it’s actually that Wiz stumbled upon an overlap of CNAPP functionality that had the largest use case. It benefits customers to have asset management and vulnerability scanning in the same place, because you need to scan every asset for vulnerabilities. Additionally, doing so agentless-ly remains pivotal because agent maintenance sucks in non-container environments. Providing these common functionalities without an agent made it too good to ignore.
As CNAPP expands outside of CSPM and Vulnerability Scanning, the bundling makes less sense. Is there a benefit to having the same tool that knows where my database is tell me the risks with table permissions and sensitive data? Is there a benefit to combining my container vulnerability scanner with my container runtime protection? Do I want an agent doing vulnerability scanning to also do runtime defense?
CNAPP v1 Categories
Since Wiz found the right functionality overlap, namely asset management + vulnerability scanning, the race has been on to slap more buzzwords together to try and differentiate.
Unfortunately for customers and vendors alike, the state of the market has become, “is our {functionality} better enough than {CNAPP_Vendor} to justify owning it separately?” This is unfortunate because the better question would be, “does this tool help us protect what matters to us?” The more we think in terms of categories instead of use cases, the further away we get from meaningful improvements.
CNAPP v2
Again, more to drive revenues than solve problems, CNAPP providers are expanding into application security. Below is what they’d love to have us conceive of as the future of CNAPP, rolling ASPM in as just another use case.
CNAPP v2 is the inclusion of ASPM
Once again, CNAPP providers are ingesting more data and figuring out the use cases later. Assuming there’s value in having ASPM in the same place as DSPM, CSPM, CWPP, Vulnerability Management, etc. This is why it’s so hard to answer the question I get all the time, “do you think it’s harder to shift left or shift right?” The real question is, “why do I want to do that at all?”
The proposed benefit of including ASPM into the fold is the “code to cloud” picture of an application; however, being able to provide a picture of an application is not by itself a value proposition. This is why a lot of examples are - “look, you can map all of your vulnerabilities to the cloud for full application context allowing you to…prioritize!” Companies have expanded into so many bespoke scanning capabilities that they need to start selling solutions to the problems they’ve created!
Will it Work?
As an engineer, rolling ASPM into CNAPP sounds like a diabolical plan to make my day to day life more miserable as yet another half baked scanner enters the fold. However, from an investor perspective, there are very solid business reasons to try and keep the consolidation play going.
Pros of CNAPP v2
Markets prefer consolidation and a single vendor
Existing install bases make expansion easier than net new purchases
Already having large amounts of data make new features easier to add
“You never get fired for buying a CNAPP” - it’s a low risk purchase
Cons of CNAPP v2
The end users of CNAPP encompass personas across all of engineering - meaning a bunch of users feeling meh about their tool
CNAPP prices are already insanely high with arbitrary pricing models
More and more features getting shoved together without a strategy creates bloated platforms
Features without a use case create alert fatigue and decrease real security
All this to say that I’m not a fan of rolling ASPM into CNAPP for the same reasons I’m not a fan of CNAPP as a concept in the first place - it’s a consolidation play for revenue more than a product plan to help human beings do their jobs better and with more joy. The pros are all business, the cons are all day to day life for engineers.
CNAPP v3 - Death to CNAPP!
Instead of chasing acronyms, let’s take a step back and ask “what should CNAPP be?”
First, the Gartner definition will never be meaningful, because there will never be an all in one total security vendor. Instead, the largest vendors in the space will be those that address the most total common use cases in the easiest way. The future of CNAPP ought to be use cases, not acronyms.
Second, ASPM and CSPM are unique in that they’re fundamentally configuration scanning tools, which is why I think they will continue to unify into SPM at some point. It’s the CWPP aspect of CNAPP that makes it more unique; however, I maintain that these tools being in the same place only provide accidental value. That is, companies tend to stumble into the benefits of combining data.
Third, we should begin viewing CNAPP as a combination of separate use cases more than a single tool. Customers should evaluate CNAPP platforms on their ability to meet use cases against smaller companies, rather than evaluating them one on one against each other.
Configuration Scanning vs? Runtime Protection
Arguing that CWPP and CSPM/ASPM being united doesn’t provide real value requires a little more nuance - many configuration scanners are being amplified by endpoint context, and vice versa; however, they serve different purposes. Even those like Oligo and ARMO who best bolster configuration scanning with runtime context, while also offering runtime protection, have to recognize that those capabilities are really two separate products.
Here’s an example, if there was value in these tools being in the same place, the XZ backdoor was a perfect opportunity to showcase it: Detecting the CVE (vulnerable version) at runtime required layers of visibility, and detecting the exploit itself at runtime required advanced EDR. But notice even Oligo’s positioning in their detection article:
Our existing product, in its existing state, could have detected and stopped the
XZbackdoor before it did any damage.We’re not talking about vulnerability scanning (though we can do that, too).
Startups like Oligo and Armo (and others) are providing both configuration scanning and runtime protection, but not because these tools directly complement each other in any way for the end user, instead, it’s because they’re building around use cases! The original goal of CNAPP built SPM and EDR together because the use case was “protecting the cloud,” Armo and Oligo do it because they’re trying to secure specific technologies from end to end.
To further elaborate, CVE detection is fundamentally proactive and targeted at developers to fix potential exploits. Runtime context helps in confirming the validity of those exploits. Conversely, runtime detection and response is reactive and targeted at operations teams to respond to actual exploits. Configuration context helps in confirming the responsible team and sometimes at delivering a fix.
In this way, configuration scanners having access to runtime data make fixing better, and runtime detectors having access to configuration scanners make detection better. However, having both outcomes, remediation and response, in the same place, provides zero intrinsic value unless tied to a more specific use case. Such use cases include “complete Kubernetes protection” and “complete API protection” - eventually “complete application protection” will require RASP’s revival.
Building for End Users or Building for Use Cases?
From a market analysis perspective, this revelation, that the closer one gets to a use case, the more the line between configuration and runtime scanning blurs, has been extremely helpful to me. The most outcome built companies - like Oligo and Deepfactor for open source security, Armo and Rad for Kubernetes Security, Impart and Levo for API Security - have built products that span runtime and configuration scanning, because they’ve attacked use cases rather than acronyms. It also explains why I tend to rank these companies so highly - I love the act of actually securing things more than the act of “helping improve the life of users.” Not that these things aren’t related, just in terms of my personal preference.
Conversely, tools that focus on their target end user, like Endor and Arnica for open source (developers), Gem and Sysdig for runtime (SOCs), have tended to commit very hard to either configuration scanning or runtime protection, rarely both. I believe this even helps to explain why Snyk oscillated for so long on adding runtime scanning into the fold - it fit the use case but not the end user.
Returning then to “WTF is CNAPP,” here are two ways I see this playing out:
Splitting Features by End User
The first is to split features by end users, or even groups of ends users. I think it’s feasible to build for two of these at the same time, but not all three. Product organizations will not and should not, fundamentally align to security as its chief goal. This is why there’s tension between combining these different use cases into the same platform - they’re attempting to combine different end users into the same dashboards and tools.
Splitting Features by Outcomes
I think splitting features by outcomes is the better solution, and one that means we kill CNAPP as an acronym. No one goes to buy a tool to “protect every theoretical application configuration across every possible environment.” Instead, people look for the tool that will best protect their environment. In the future, I won’t evaluate CNAPPs against CNAPPs, but instead use cases against use cases.
It’s all about the use case
Focusing on use cases means that the big CNAPP providers like Wiz, Orca, Lacework, Prisma, Sysdig, etc. get evaluated on their ability to provide end to end protection for a specific use case, and then weighed on how many other applicable use cases they cover. This is why I truly don’t have a “favorite CNAPP” - I have legitimately recommended each of them to different security teams. From an investment perspective, this is a math equation of (Average Joy of Using an Applicable Feature) x (Market Size of Applicable Use Cases) they cover.
The below graph maps this out from a “likelihood to win the market” perspective rather than any particular customer useable graph. Customers don’t look for CNAPP, instead, for example, Sysdig, Wiz, and Lacework should be evaluated against other tools for specific outcomes - such as Kubernetes, Cloud Configuration, and Linux Host Vulnerability scanning - and then the fact that they each do all three is weighed against using point solutions. For customers, the question is just “by using this platform instead of a point solution, am I giving up a feature that makes a material difference?” Oftentimes, the answer is yes, oftentimes, the answer is no.
Mapping CNAPP from a “who wins the market” perspective, not from a buyer perspective. Keep in mind average satisfaction is just my personal one!😊
An interesting application of this approach is that ASPM should eventually build runtime protection - but I think the strategy here should be an imported library-esque RASP, akin to DataDog, rather than eBPF agent, although either would technically work. However, the tension will always be that you’re building for different end users, so this shouldn’t be a priority item. Delight your end users (developers, developers, developers!) first, then build the additional use cases.
Core Questions and Conclusions:
If you’re a startup, assume that CNAPP is coming to try and eat your lunch. CNAPP has the ruthless goal of shoving every security tool together, whether it makes sense or not.
If you’re a startup, the key question is, “what makes our technology so good at a use case that you would buy us on top of a CNAPP?” Some Examples I love:
Supply Chain Security (Container Vulnerability and SCA, specifically malware protection)
Application Protection (ASPM)
If you’re a startup, start focusing exclusively on use cases and outcomes instead of features like “reachability” that amount to checkboxes anyone can add to their platform. For example, the goal isn’t reachability - it’s 98% vulnerability noise reduction.
Bespoke scanners will be commoditized only because they run into a feature check box competition with upstream platforms. If you’re building a really good one of these scanners, you need to focus on the outcome that differentiates you from what a CNAPP can provide.
Why did the GRC Automation market escape the battle with CNAPP? Both tools have access to the same data, but those like Vanta and Drata built around a use case to the point where they’re not even seen as competitive platforms even though they have a ton of overlap.
If you’re a CNAPP vendor, get out of the acronyms arms race - it’s a losing battle. Wiz won CNAPP v1 not because they have the most acronyms (they still don’t), they won because they combined the two people wanted combined: asset management and CSPM. This is why I also love Sysdig - the use case is cloud runtime protection, not “look how many acronyms we have.”
If you’re a CNAPP vendor, delight your end user, then build the extra use cases for other customers. The alternative is a platform everyone hates, or, a recipe for churn.
Is there an answer to the question, “what’s the best way to protect your cloud?” Would anyone have asked the question, “do you have a datacenter security platform?”
If you’re looking for a CNAPP tool, define your use case before you talk to vendors. Don’t let them guide you with their RFP that, shockingly, they’ll be really good at!
How to Choose a CNAPP
Know your general architecture and highlight important functionalities. Ask questions like:
What technologies are at the core of our infrastructure?
How do our services get exposed to the internet?
Where do services get configured?
Experiment with Open Source tools first to get an idea of the scope and implementation challenges that will come up
Assume you’re going to get more findings than you can fix, and select tools in light of that
Don’t purchase a tool before you fix an alert that comes out of it
Stay focused on the use case rather than the features list
Latio List v1.11
Added Seedata to Boundary Breakers - Honeypots as a service is dope and underrated
Added SecOps Solution to Remediation Platforms - Network based vuln scanning and patching. It's not the cleanest fit but I don't have a separate category for general vuln scanning
Added Infield to Code Fixers - Great team offering SaaS and services for painful version upgrades
Added Sonrai to Cloud Identity - Probably the fastest way to get your cloud 80% more secure than it was before by focusing on boundaries instead of least privileged
Added Push Security to Corporate Identity - Browser plugin for detecting unsafe SaaS use/risk from employees