In our previous blog, we demonstrated that the application security component of a traditional CNAPP is deficient and should be evolved into a Runtime CNAPP to meet modern security requirements.
In this blog, we outline the necessary steps that evolve a CNAPP: from Static to Runtime, from Intermittent to Always-Active, from Visibility to Observability, and from Advice to Actions. In the figure below, we visualize the evolution and mark the path with arrows from a Traditional to a Runtime CNAPP.
The following are the necessary evolutionary steps in detail:
From Static to Runtime
Runtime CNAPP enables the evolution of security from Static to Runtime. Traditional static technologies exhibited by their representatives, such as SAST and SCA, capture static insight, such as code or composition of applications, before their runtime execution. Static technologies lack insight into processes/services. They are never right on time. The scan is done either before the application has been running, or when static insight is too late (when an application is already in operation)
From Intermittent to Always-Active
Runtime CNAPP enables security to evolve from intermittent scanning (e.g., SAST, DAST, SCA) to continuous monitoring, with security controls always actively in place. Traditional scanners leave broad and dangerous security gaps between scans. Always-Active Runtime CNAPP will not leave an application unattended, unobserved, or unprotected for even a moment.
From Visibility to Observability
Runtime CNAPP enables security to evolve from superficial visibility to deep observability into application/service processes. Runtime CNAPP predecessors, such as SAST, DAST, SCA, and WAF/WAAP, were focused on the surface of applications. They have never enabled visibility beyond static code and components in repositories (e.g., SAST, SCA) or beyond API traffic (e.g., WAF/WAAP). The same WAF/WAAP can provide visibility into traffic moving North-South to the application, but not into East-West traffic between applications. Traditional security visibility is centralized, typically originating from the midway point of scanning (e.g., SaaS for SAST, DAST, SCA) or from a critical point in WAF/WAAP firewalling.
Runtime CNAPP, on the contrary, enables observability: service- and process-level insight into all application/microservice/API events.
We intentionally position observability vs. visibility. While visibility provides superficial insight into the application, observability provides process- and service-level details. Moreover, Runtime CNAPP provides not only North-South but also East-West observability. This is possible because Runtime CNAPP controls are typically interfaced with all running application/microservice entities (for example, via eBPF-based technologies). This also makes security distributed and federated. Each Runtime CNAPP control can run autonomously, observing each runtime entity. At the same time, security can be “federalized” through a cloud-based platform that enables customers to set up rules and policies for distributed Runtime CNAPP controls and to collect and analyze insights from all those controls.
From Advice to Actions
Runtime CNAPP enables security to evolve from advice to actions. Runtime CNAPP predecessors (such as SAST, DAST, and SCA) provide customers with recommendations and prescriptions. On the contrary, Runtime CNAPP makes decisions and then acts on them. These actions are remediation and mitigation (e.g., they can stop the malicious process).
The evolution has already started. The Runtime CNAPP market has been emerging and maturing. See an implementation example here: www.rooncyber.com.
