As cybersecurity continues to evolve, Cloud-Native Application Protection Platforms (CNAPP) are becoming a go-to tool for analysts and CISOs. They check a lot of boxes in one place—making them appealing at first glance—but that convenience often comes at the expense of practitioners who find them lacking in depth and effectiveness. That’s why cybersecurity researcher Francis Odum and independent analyst James Berthoty recently released a comprehensive guide on the future of cloud security. Their report redefines CNAPP, exposing its limitations and contradictions while providing a roadmap for navigating cloud security’s future.

At the upcoming Elephant in AppSec Conference we want to highlight fresh perspectives on cybersecurity and put into the spotlight speakers who aren’t afraid to challenge the status quo.

Ahead of the conference, we decided to interview the speakers to give you a glimpse of what you might expect 😊

To give you a preview of what’s in store, we reached out to James Berthoty, keynote speaker in the Tools track and co-author of the CNAPP report. Ahead of his talk, James shared his insights on the most significant limitations of current CNAPP solutions, where they fall short in delivering in-depth protection, and whether developer adoption of CNAPP is even realistic (spoiler: CNAPPs aren’t a developer’s best friend).

With over 10 years of experience in both engineering and security roles, James is a DevSecOps advocate passionate about embedding security into product development. As the founder of Latio Tech, he connects people with the right security solutions. Based in Raleigh, NC, where he lives with his wife and three children, James is also pursuing a PhD in philosophy.

Check out James’ responses to my questions below, and don’t forget to register for the Elephant in AppSec conference for more strong opinions and deep market insights!

What are the most significant limitations of current CNAPP solutions that accelerate the need for a future free from them?

It’s important that we go back to the creation of CNAPP and realize that it was a category created from a vendor idea and not a customer need. Palo Alto had the vision of buying Twistlock (container/workload security) and Redlock (Cloud misconfiguration scanning), putting them into the same tool, and calling it a CNAPP. What this missed was anything around solving a need more focused than “securing the cloud.”

We never would have accepted a single solution for “securing the data center,” but the security team’s broad failure to understand container architecture has allowed vendors to say they do everything when in reality they typically only do one or two things well. 

These problems have only gotten worse over time. Gartner has added more features to CNAPP rather than less, serving the vendor-driven security craze of billion-dollar companies seeking to differentiate on a feature checkbox. There is almost no concern for the user experience, actionability of data, or actually increasing security.

One of the biggest challenges AppSec vendors face is developer adoption. Is it true that CNAPPs do little to address this challenge?

One of the cool things about VSCode statistics is they’re public, so it’s an easy way to laugh at how poorly CNAPP IDE plugins are adopted.

To be sure, part of this is the undeniable fact that IDE plugins are a better marketing experience than reality for developers. Nevertheless, it’s a good glimpse into the dismal adoption CNAPP will face as they try to reach developers. 

Maybe I can answer this in an even easier way: if your security team hates their CNAPP, why would your developers be any more likely to love it?

Runtime asset visibility and vulnerability management have come to define the heart of CNAPP. In environments like Kubernetes, where do CNAPPs fail to deliver in-depth protections?

This is the unfortunate self-inflicted reality of platform chasing: the leading Kubernetes tools of early “CNAPP” have all had to stretch themselves thin across too many types of workloads, while chasing feature parity with behemoth companies. One simple example: only ARMO has Seccomp policy generation for Kubernetes workloads and what I would consider a useable Kubernetes RBAC dashboard. There are other similar examples from other vendors who have stayed focused on Kubernetes, but security teams have unfortunately driven these players to focus on irrelevant features.

Given the identified gaps in CNAPPs – SDLC, SCA, Secrets, and DAST, what criteria should organizations use to choose complementary security tools?

Even these gaps are generalized, for example, Orca has SDLC scanning, Wiz has secrets, and there are other scanners with other gaps. Overall, this is why I like ASPM tools, as they make it so you don’t need to pick and choose different scanners that may or may not be simple to install, and they self-aggregate their findings into a single place. However, DAST remains a gap in most of these platforms as well – typically, SAST and DAST are the reliable gaps from CNAPP players, because they’re hard to build and don’t fit natively into the idea of “infrastructure scanning.”

If CNAPPs are not the answer, what alternative approaches should security engineers consider for securing cloud environments and applications?

Companies with cloud-native architectures should absolutely adopt an Application Security Posture Management (ASPM) + Cloud Application Detection Response (CADR) approach, and drop CNAPP altogether. An ASPM is for scanning all of their code and is built for their developers, and a CADR protects assets at runtime and is built for security operations teams. These tools can be supplemented with an asset management system, whether something like JupiterOne or CloudQuery, or a remediation platform like Phoenix or Opus. 

Enterprises however tend to be a little more difficult to cover, as they need more flexibility to work around existing solutions. In these situations, an agentless first CNAPP like Wiz or Orca is probably best, supplemented by an SCA + SAST vendor, a DAST vendor, and a CADR vendor. In the long run, however, these agentless CNAPP scanners are really just functioning as asset management systems, as the runtime tool has greater visibility and scanning capabilities.

How would moving away from CNAPPs change the daily operations and priorities of security teams?

The largest problem with CNAPP is that it’s not built around any particular end user, so everyone ends up hating it. I prefer the ASPM + CADR approach because the tools are actually built to surprise and delight specific people in specific roles, rather than surprise everyone with how unusable and expensive their platform is.

Without giving away *too* many details, what can attendees expect from your upcoming talk?

In this talk, we’ll cover a lot of what was here! Diving into the failings of CNAPP, and going into more detail about alternative approaches.

Are you excited about the Elephant in AppSec conference? Why or why not?

Of course, hot takes in security are necessary as we seek to constantly validate the purpose behind what we’re doing. Without this, we’re just blind to evolving threats!

You may also be interested in:

• What is ASPM: A breakdown of the current state and its future⎥James Berthoty (Security at PagerDuty)
• Webinar: Building your Product Security Roadmap – Escape x James Berthoty
• How to secure cloud-native applications
• Lack of effective DAST tools⎥ Aleksandr Krasnov

*** This is a Security Bloggers Network syndicated blog from Escape - The API Security Blog authored by Alexandra Charikova. Read the original post at: https://escape.tech/blog/talk-a-future-of-security-free-from-cnapp/