What Tool Best Compliments CNAPP?
Despite what they'd tell you, CNAPP's don't do everything
Whether good or bad, many companies have entered the world of cloud security with CSPM tooling. In the quest for market domination, CNAPP’s have chased acronyms with as many acquisitions as their investors could buy. Unfortunately, this has led to radically different levels of maturity around various CNAPP use cases.
In this article we’ll ask, “how can you best compliment your CNAPP tooling?” When every CNAPP says they do everything, we need to parse out exactly what sets of features are the most commonly missing from providers. We’ll start by dissecting what a CNAPP is, before asking what the best complimentary features are.
The Heart of CNAPP
CNAPP began with CSPM, which in its most rudimentary form was interrogating cloud API’s for misconfigurations. Security teams needed visibility into their cloud environments, and this was the fastest way to get it. CSPM was quickly disseminated and commoditized by various open source projects and companies rapidly began trying everything to achieve “cloud security.”
“Agentless” scanning from Orca and Wiz took a firm hold on the market following CSPM because they continued the trend of easy visibility into your cloud workloads. At its core, agentless scanning is a smart way to offer deep asset management capabilities, which is why the Orca/Wiz CSPM has been stickier than the earlier alternatives that didn’t look at underlying machine volumes. By cloning underlying disks instead of installing agents, security teams get vulnerabilities and asset visibility into their runtime cloud environment with little effort.
Runtime asset visibility and vulnerability management have come to define the heart of CNAPP. Even CNAPPs that started with an agent, such as Sysdig and Palo Alto, now offer agentless scanning because of how it addresses the core difficulty of maintaining an agent just for vulnerability scanning. Conversely, agentless scanners now advertise “realtime” agentless scanning.
Because CNAPP vendors focused on “cloud security” holistically, they have developed their entire technological approaches around cloud runtime environments. Sysdig and Aqua saw containerized workloads as the core of cloud, so they matured quickly around container protection and scanning. Conversely, Wiz and Orca saw the workload volumes as the source of truth for cloud infrastructure, so have built robust platforms around what they can pick up on disk.
Now that Orca and Aqua have an official partnership, it’s more clear than ever that the cloud assets at runtime are the priority for CNAPP providers. Even Wiz has an agent for runtime protection, showing their commitment to “shielding right” with doing cloud protection. The next big focus for CNAPP is getting into the SOC, not into the IDE.
These are the two features at the heart of CNAPP: the core is asset & vulnerability management at runtime, and what’s coming next is greater runtime detection & response capabilities. To be frank, everything else exists only enough to be able to say they do it.
What’s Missing with CNAPP?
CNAPP providers realized early on that they could scan containers and infrastructure before it was deployed by providing container and IaC scanning. Because of this, they were fast to copy their existing rule sets into the pipeline. This was a fairly simple integration for them to make, since they were scanning both kinds of assets at runtime anyways.
Most recently, some CNAPP providers have made tepid steps into SCA and SAST scanners, but this entry has a fundamentally different level of challenge for them because they are not comparable to any existing scanning abilities. CNAPPs have zero existing view into how applications work when they’re deployed. Some try to fake it by looking at Kubernetes configs or public IPs, but none of them have an understanding of how applications are coded or what kinds of vulnerabilities exist in the app itself.
Scanning developer code is the core weakness of CNAPP for several reasons:
Developer languages, frameworks, and patterns are far more diverse than cloud infrastructure
Getting visibility into application execution at runtime requires complex instrumentation
Developer workflows don’t translate well into security operations contexts
The biggest challenge application security vendors face is developer adoption, and CNAPPs do little to address this challenge. As an example, it seems that it will be a long time before a security practitioner has any luck implementing a Palo Alto VS Code plugin.
Fundamentally, these tools are built around production environments and shift left security has always been an afterthought for them (debatably, Aqua gets an exception here). I would argue many security teams are frustrated with shift left because they’ve never used tools that meaningfully make developer’s lives easier.
In terms of scanners, I suggest there are 8 kinds of scanning that go into complete visibility of a cloud and application environment. SDLC (scanning configuration settings), SCA (open source dependencies), Secrets, SAST (code vulnerabilities), IaC (infrastructure configuration), Container (app + os), DAST (code at runtime), and CSPM (infrastructure at runtime). Ultimately, each of these scanner results need to end up back in a developer’s hand, something CNAPPs are not designed for.
How to Compliment Each Other
In this time of tight security budgets, many teams are willing to give up best in class point solutions and lean on their existing tools. CNAPPs universally offer IaC, Container, and CSPM scanning. There are a few exceptions to this, but for the most part, these are the gaps: SDLC, SCA, Secrets, and DAST. Of these, DAST is a bit of an outlier because it requires special instrumentation to scan the app at runtime. We'll leave it alone because of its identity crisis at the moment with API Security.
If CNAPPs provide IaC, Container, and CSPM scanning, it makes the most sense to bucket these capabilities as “infrastructure scanning.” What remains is “code scanning,” composed of SCA, Secrets, and SAST at their core.
Therefore, platforms like BackSlash that provide SAST, SCA, and Secret scanning in a single place provide a no-brainer compliment to your existing CNAPP solution to cover the visibility gap.
Personally, I think having all of your “security posture scanning” in a single place is the most elegant solution, but I’m all too aware that my picture of elegance break apart when it hits the complex reality of enterprise - where infrastructure and application teams can be segmented and CNAPP becomes non-negotiable in terms of runtime vulnerability scanning requirements.
For companies that have adopted more cloud native practices, all in one scanning makes more sense; but for companies with more segmentation between development and infrastructure teams, it can make sense to maintain the different tooling for the time being.
For product recommendations, on the ASPM side, there are solutions like Ox, Aikido, Apiiro, Xygeni, Cycode and JIT do all in one scanning. On the pure AppSec side, Backslash, Endor, Arnica, Oligo, and Kodem do a great job of providing developers with enough of the runtime context they care about (this function is executing and “reachable”), without overwhelming them with information they never care about (like the IP addresses of specific pods).
This post was created in collaboration with Backslash Security.