What it means
CNAPP is a platform category that brings together several cloud security capabilities. Common combinations include configuration assessment, workload protection, vulnerability information, and development-pipeline findings. Some offerings also emphasize identity permissions or relationships between findings. The category label does not define a universal feature set: supported cloud services, collection methods, licensing, and response capabilities differ. Evaluate the actual capabilities against your applications and operating model. A combined view can help identify related problems, but it does not replace application-specific authorization tests or accountable engineering ownership.
The idea at a glance / Cloud
Related-looking findings need an exact connection.
Keep the image assessment, running artifact, network setting and missing runtime coverage together.
Synthetic suite AtlasCloud retains F173 for scanned image I173. Running resource R173 uses different image I174 under the same mutable tag appointments:prod. A posture snapshot records a public listener. The runtime connector is absent. Sam must validate the actual deployment and access path rather than infer them from a suite view.
READ THE PICTURE
Identity beside coverage
F173 belongs to scanned I173, while R173 runs I174 despite the shared tag. Public-listener configuration and missing runtime coverage do not prove a deployed exploit.
Keep in mindI173/I174 are illustrative JSON artifacts, not OCI container images. A173 is a fictional calendar-kit 1.x advisory, not a real CVE. Trusted inventory and complete selected artifact hashes are assumed. No public request, exploit or runtime response has been tested. A missing exact connection does not establish I174 is safe. CNAPP features and prerequisites vary by offering.
Read the complete example
- Identity beside coverage. F173 belongs to scanned I173, while R173 runs I174 despite the shared tag. Public-listener configuration and missing runtime coverage do not prove a deployed exploit. I173 contains synthetic calendar-kit 1.0.0 and full SHA-256 eee7188874c21f93840c1081219893fec162743eda6d3cb089499e8ca8bc9381. Fictional A173 covers calendar-kit versions from 1.0.0 inclusive to 2.0.0 exclusive. I174 contains 2.0.0 and SHA-256 c2f877882f9e5af01d7368edca3c9bf5f88e55a32e30e668f48b13d5a0822483. The selected inventory ties R173 to I174 by complete digest; joining on the mutable appointments:prod tag would falsely attach I173’s finding. The exact resource/artifact join does not attach F173 to R173. That narrow result says nothing about other defects or older deployments. N173 records a configured public listener, not demonstrated data access. Runtime connector C173 is absent, so behavior and response coverage remain unknown. Sam’s follow-up is unperformed. The original artifacts, finding and deployment snapshot remain; the suite category itself adds no proof.
I173/I174 are illustrative JSON artifacts, not OCI container images. A173 is a fictional calendar-kit 1.x advisory, not a real CVE. Trusted inventory and complete selected artifact hashes are assumed. No public request, exploit or runtime response has been tested. A missing exact connection does not establish I174 is safe. CNAPP features and prerequisites vary by offering.
Diagram references: Microsoft: cloud posture and distinct CNAPP capabilities
AN ILLUSTRATIVE SCENARIO
Same tag, different running artifact
F173 concerns scanned I173; R173 actually runs I174 under the same mutable tag. Complete hashes prevent a false connection. A public-listener setting and absent runtime connector remain separate from actual access or exploit evidence. Sam’s runtime checks are still open; the suite name does not fill the gap.
Put it to work
- Map required capabilities to your applications, cloud services, and development workflows. Confirm supported environments and exactly which features need additional access, agents, or licenses.
- Connect findings to stable resource identities and owners. Validate important relationships, such as whether a scanned image is the one actually deployed to a reachable workload.
- Route fixes into engineering and operations workflows. Verify changes in both deployment definitions and running systems, and track collection gaps or unsupported resources explicitly.
How to check your work
Follow a representative issue from source or image to the deployed workload, responsible team, completed fix, and runtime verification. Confirm that disconnected accounts or unsupported services appear as coverage gaps rather than silently passing.
Connect the ideas
- CSPM
Checks of cloud configuration against policy, such as public storage or open security groups.
- SCA
Inspection of dependencies and libraries for known vulnerabilities and license issues.
- Shared responsibility
The split of security duties between a cloud or SaaS provider and the customer, which varies by service.
- Coverage
An explicit statement of which sources, time windows, and rows were actually collected, including truncation.