✳ The reference desk / In practice

CNAPP

A bundled category covering cloud posture, workload, and related application-risk features; boundaries vary by vendor.

Cloud-native application protection platform

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.

CNAPP: Keep the image assessment, running artifact, network setting and missing runtime coverage together. The explanation below describes the relationships.AtlasCloud · selected suite evidenceOne tag; different artifact identitiesImage assessment · F173I173: calendar-kit 1.0.0Synthetic A173 covers 1.xR173 · running artifactRuns I174, not scanned I173Full digest, not tag, was checkedPosture snapshot · N173Public listener is configuredReal request has not been testedRuntime connector · C173Not connected · behavior unknownSam’s runtime checks still openCONNECTION AND COVERAGE OPEN

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
  1. 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

  1. Map required capabilities to your applications, cloud services, and development workflows. Confirm supported environments and exactly which features need additional access, agents, or licenses.
  2. 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.
  3. 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.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.