CNAPP: The Key to Securing Cloud‑Native Applications from Containers to Lifecycle

As more enterprises adopt cloud‑native containers and related technologies, container security and cloud‑native security have become issues that must be taken seriously. Containers, as OS‑process‑level tools, bring convenience to developers and operators but also introduce many potential risks such as open‑source code vulnerabilities, trojan viruses, and privilege escalation. With containers increasingly used as the foundation of cloud‑native infrastructure, container security evolves into cloud‑native security, and comprehensive cloud‑native security is a key measure to protect business applications and data.

In the past, container security focused on image security, DevOps security, and related topics. Today, comprehensive cloud‑native application protection has developed into a complete system, such as CNAPP and cloud‑native security maturity models, which describe cloud‑native security content and related technologies in a systematic and comprehensive way.

Domestic awareness of the importance of container security and cloud‑native security is insufficient. Early domestic market efforts were limited to a few vendors experimenting with container security and proposing concepts (e.g., CNAPP). Most companies still rely on traditional security and are gradually shifting toward container and cloud‑native security.

With the penetration of cloud‑native technologies and the rise of cloud‑native security awareness, many traditional security vendors and even large companies such as Tencent and JD.com are gradually supporting cloud‑native security. Their focus has expanded from container security to a full cloud‑native security system, covering horizontal lifecycle protection and vertical component protection, as well as real‑time security posture visibility, evolving into comprehensive cloud‑native protection.

Comprehensive cloud‑native protection usually requires many tools from multiple vendors (a single vendor cannot meet all needs). These tools are difficult to integrate and are often designed only for security professionals, not for collaboration with developers and operators. Fragmented tools generate excessive alerts, waste development and operations time, and make remediation unfocused. The CNAPP solution allows enterprises to use an integrated product to identify risks across the entire lifecycle and various elements of cloud‑native applications, placing developers at the core of application‑risk responsibility. Its responsibilities include SAST/DAST/SCA scanning, runtime protection and monitoring, infrastructure authorization, and network security.

The CNAPP view based on the detailed cloud‑native application lifecycle includes both traditional security capabilities and new‑technology‑driven risks, forming a complete integrated security risk management and defense system.

Comprehensive cloud‑native security construction can expand from container security to the entire system, encompassing traditional security content, or gradually incorporate containers and application security into traditional security. The main challenges involve cross‑departmental collaboration and the limited security awareness of traditional security teams, which often cannot meet cloud‑native security requirements. Traditional security measures are unsuitable for the cloud‑native era, hindering progress and incurring additional costs and duplicate efforts.

To improve security management, many companies are subdividing security domains and adding numerous regulations and lengthy processes, which contradict the integrated architecture evolution of cloud‑native environments. The application of containers and other native technologies thus makes the environment and management more complex, severely hindering digital transformation.

How to solve this? Raising the security awareness of traditional security personnel is one important aspect; another is the design and guidance from enterprise architects and integrated architecture teams. Regarding container and cloud‑native security implementation, there are two main routes:

Main Technical Route 1: From Container Security to Comprehensive Cloud‑Native Security Construction

Background & Principle

The introduction of containers and micro‑services makes developers increasingly responsible for operational tasks such as vulnerability remediation, infrastructure‑as‑code deployment, and production deployment, update, and decommissioning. This drives the need for tools and platforms that support DevOps, SRE, and platform engineering. Security is often ignored by developers, leading to heavy operational investment. To reduce risk during deployment and operation, security must be shifted left to the development stage using methods such as SCA to identify potential risks early and provide developers with sufficient context for rapid remediation, supporting agile iteration, CI/CD, and stable, secure operation.

Key characteristics of cloud‑native applications include:

1) Loose‑coupled micro‑service architecture interacting via APIs.

2) Frequent changes supported by CI/CD pipelines.

3) Extensive use of open‑source tools, code, and libraries.

4) Management and scheduling of containers via Kubernetes, forming a cloud‑native PaaS platform.

5) Support for more frequent changes with stable, secure operation.

6) Immutable management principle where production changes go through the development pipeline.

The Cloud‑Native Application Protection Platform (CNAPP) is a unified, tightly integrated set of security and compliance capabilities designed to protect cloud‑native applications in development and production environments. CNAPP consolidates previously isolated functions such as container scanning, cloud security posture management, infrastructure‑as‑code scanning, software composition analysis (SCA), cloud infrastructure authorization, runtime workload protection, runtime vulnerability/configuration scanning, as well as traditional static application security testing (SAST) and dynamic application security testing (DAST). Its functions span the entire development and operation lifecycle, addressing unknown and unexpected risks caused by the increasing complexity of cloud‑native development and deployment.

The transition from container security to cloud‑native security and then to CNAPP reflects the gradual building of cloud‑native capabilities within enterprises. This process can be lengthy, involve multiple projects and vendors, and often leads to duplicate construction, integration difficulties, and eventual re‑engineering.

Development Trend

Container security and cloud‑native security are evolving toward a systematic CNAPP approach. CNAPP is not a single platform but a complete system requiring engineered architecture and a series of project works to accomplish.

Many CNAPP products originate from vendors initially focused on runtime workload visibility and protection (cloud workload protection platforms). As development models shift to cloud‑native applications, these vendors “move left” to provide container scanning, followed by cloud security posture management (CSPM) capabilities. Some CNAPP products come from CSPM‑focused vendors, but customers also demand pre‑deployment scanning of infrastructure‑as‑code scripts.

Some vendors start handling artifact scanning (e.g., software composition analysis and API security testing) early in the development lifecycle, but customers require the platform to expand to related capabilities.

Product Maturity

Although many security vendors can provide container and cloud‑native security capabilities, no single vendor offers the breadth and depth required to integrate all components between development and operations, deliver unified security posture visibility, and provide comprehensive risk management.

Industry Application

Many organizations that adopt containers have purchased varying degrees of container security products. As security awareness rises, container and cloud‑native security are being accepted, but CNAPP’s systematic construction is limited by traditional monolithic IT thinking, lack of unified enterprise architecture, and insufficient enterprise architects and project planners, resulting in inefficient CNAPP implementation.

Technical Difficulty

While container security technology itself is not highly difficult, building a systematic cloud‑native security framework is challenging. It requires constructing a cloud‑native environment and security system independent of traditional business, which many enterprises lack the architectural expertise to execute.

Implementation Cost

Domestic security projects are generally not large. Because security benefits are hard to quantify, even achieving 99% coverage may still leave 1% of vulnerabilities exploitable, which can be catastrophic. Proper planning can reduce implementation costs by several times.

Technical Risk

Comprehensive cloud‑native security expands security from simple containers and images to full‑lifecycle and multi‑layer protection. Building an independent cloud‑native environment alongside traditional environments introduces many open‑source tools and technologies, increasing technical complexity and the risk of mis‑understanding, misuse, or over‑use. Developers continuously create containers and services, shifting security risk management left, which requires deep knowledge of development pipelines and platforms to identify and remediate risks early.

Main Technical Route 2: From Traditional Security to Comprehensive Cloud‑Native Security Construction

Background & Principle

Traditional security usually refers to network‑related capabilities such as firewalls, VPNs, password protection, access control, as well as compliance and graded protection. Traditional security teams are often unfamiliar with containers and cloud‑native concepts, and the zero‑trust model conflicts with traditional network security segmentation. Consequently, traditional security teams may misunderstand or not support cloud‑native security, leading to additional costs and problems.

The China Academy of Information and Communications Technology (CAICT) together with Alibaba, Qing‑Teng Cloud, etc., proposed a cloud‑native security assessment framework covering five capability domains, 15 capability items, 46 practice items, and about 400 detailed requirements (see figure). This framework can be used as a reference for building comprehensive cloud‑native security capabilities, though it explains the “what” without fully addressing the “why”.

Development Trend

The shift from traditional security to cloud‑native security typically moves from host security to container security, then integrates platform tool security and DevOps lifecycle security, and finally to application security. Over the past ten years, cloud has become the foundational infrastructure for many companies, supporting agile resource scheduling and management. Building cloud‑native DevOps platforms and applications on top of the cloud enables rapid iteration and experimentation, making security—especially data and privacy protection—crucial. Traditional network and host security are gradually extending to cloud security, container security, and comprehensive cloud‑native security.

Product Maturity

Traditional network security products are abundant, but few vendors plan security capabilities from a holistic perspective. The proliferation of products creates integration challenges, especially as container and cloud‑native security demands increase, complicating both underlay and overlay networks.

Industry Application

Many enterprises deploy cloud‑native clusters within traditional network security domains, resulting in separate security environments for each cluster—a practice that is strongly discouraged.

Technical Difficulty

Transitioning from traditional security to cloud‑native security is difficult because many traditional security personnel lack understanding of containers and cloud‑native technologies, leading to misconceptions and resistance.

Implementation Cost

Compared with building an independent cloud‑native security domain, this approach adds redundancy and interaction complexity, resulting in higher costs.

Technical Risk

The technical risk is relatively higher, requiring a gradual improvement of awareness and potentially causing repeated construction.

Construction Suggestions

By integrating vendors, consoles, policies, and contracts, operational complexity can be reduced, risk identification and remediation can be improved, and configuration errors can be minimized. This enables:

Defining consistent security policies across development and operations in a single place.

Consistently enforcing security policies across all application artifacts—code, containers, VMs, and serverless functions.

Eliminating overlapping policies among different products and standardizing policy objects across all development documentation.

A single‑vendor solution should provide a unified data lake, data model, and graph database for all event logs, reports, alerts, and relationship mappings, enabling RiskOps to identify root causes, assign responsible personnel, and prioritize remediation, thereby reducing attack surface and shortening fix times. Consistent policy execution and risk‑prioritized remediation improve developer experience, integrate security testing throughout the lifecycle, and feed findings back to development for faster fixes.

CNAPP products mainly focus on identifying known vulnerabilities, misconfigurations, and hard‑coded secrets using a combination of static and dynamic techniques. Traditional SAST/DAST tools focus on discovering unknown vulnerabilities in custom code. CNAPP and AST tools are complementary but increasingly overlapping. In the coming years, some CNAPP products will extend to traditional SAST/DAST use cases, and vice‑versa.

For modern cloud‑native applications, traditional host‑based agents may be difficult or impossible to deploy. In some cases, DevOps product teams will not accept agent‑based approaches, and the operational overhead of agents can outweigh the value of runtime visibility for short‑lived workloads.

Overall, the integration of comprehensive cloud‑native security and vendor consolidation is a clear trend that will enhance the construction, capability, and efficiency of the entire cloud‑native security ecosystem.