CNAPP: Connecting Cloud Posture, Workloads and Code

TL;DR: A cloud-native application protection platform (CNAPP) connects several cloud security jobs. Evaluate the chain from collection to a verified repair, and keep configuration snapshots, data inspection and runtime observations distinct.

A platform is a collection of evidence paths

CNAPP is a product category rather than a protocol or a guarantee of a fixed feature set. Typical capabilities include cloud posture, entitlement analysis, workload vulnerability assessment and runtime detection. Some platforms also connect code, data security and AI inventory. The important design question is which component observes which risk and which component can change the affected system.

An API collector can inspect configuration without entering every workload. A disk snapshot can expose installed packages and files at a point in time. A runtime sensor can observe selected process, file or network events while healthy and supported. These are complementary views. Neither an agentless scan nor an installed agent establishes complete visibility by itself.

Join on stable identity and time

Join cloud resource identifiers, account and region, workload identity, deployment digest and source provenance. Keep the timestamp and confidence of each relationship. A vulnerability in yesterday's image should not be attached blindly to today's replacement workload merely because a reused IP address matches.

The platform's own permissions matter. Snapshot access can expose sensitive disk data; classification can read sensitive records; response integration can disable a service. Separate collection from remediation identities, constrain each to its purpose and record where copied data is retained. The security platform becomes a privileged dependency that needs audit, monitoring and revocation procedures.

Evaluate one complete scenario

Use a fictional externally reachable document worker with a vulnerable library and a role that reads a sensitive bucket. Require the platform to show each supporting observation. Then change one condition at a time: remove the sensor, revoke a collector permission, replace the image or make the bucket classification stale. The platform should expose the resulting uncertainty.

Next repair the workload and confirm that the deployed digest, exposure and permission changes are reflected. Check whether a rollback reopens the risk. This exercise tests the workflow a defender actually needs, including missing evidence and ownership, rather than the number of alert tiles.

Product map, checked November 2026

Orca's SideScanning brief is a reference for agentless workload inspection. Aqua's runtime documentation describes workload enforcement. Cortex Cloud connects the Prisma Cloud lineage with CDR. Lacework's acquisition explains the Fortinet lineage. Upwind's sensor architecture provides a concrete runtime collection example.

These descriptions identify approaches, not winners. A deployment may combine a cloud provider's native services with specialist products. Require documented coverage for the exact operating systems, managed services and regions you use.

Explain the boundary in an interview

Separate prevention at admission or execution from detection after an observation and containment after a decision. Ask whether a claimed block happens synchronously before the harmful effect or through a later response action. That distinction determines the residual exposure window.

Continue with agentless scanning, CSPM and workload sensors.