What happens when CNAPP focuses only on pre-deployment checks?

Why pre-deployment CNAPP controls are only half the story

Pre-deployment checks are valuable for catching misconfigurations, missing policy settings, and obvious compliance gaps before a workload ships. The limitation is that they evaluate a point-in-time configuration, not the workload’s live state. Once code runs, cloud services, identities, network paths, and data flows can behave differently from what passed review.

That gap matters because cloud risk is often created by what changes after approval: autoscaling, new permissions, temporary secrets, sidecar behaviour, configuration drift, and unexpected service-to-service paths. A pre-deployment-only programme can therefore create a false sense of closure, especially when the workload’s runtime exposure is larger than its declared design.

Runtime-aware CNAPP needs to treat deployment as the start of monitoring, not the end of control. That means observing actual workload activity, correlating it with policy, and detecting whether enforcement still matches the approved posture after release and during change.

What gets missed between approval and execution?

The most common blind spots are the ones that cannot be proven in a build pipeline. A template may be clean while the live service later acquires broader permissions, reaches new endpoints, or consumes secrets in ways that were not visible at review time. Static approval also struggles with ephemeral infrastructure, where the object being assessed may not be the object that is actually running.

Runtime controls fill that gap by watching for privilege drift, unexpected outbound connections, suspicious process behaviour, and policy violations that only emerge under load. For cloud environments, NIST Cybersecurity Framework 2.0 is useful here because it separates governance, protection, detection, response, and recovery into an operating model rather than a one-time approval step.

This is also where NIST SP 800-53 Rev 5 Security and Privacy Controls becomes practical, especially where configuration management, audit, access control, and continuous monitoring need to work together instead of sitting in separate tooling silos.

When pre-deployment checks dominate, teams usually miss the control that matters most after go-live: whether the runtime still conforms to the assumptions that justified release in the first place.

How runtime CNAPP changes the operating model

Runtime CNAPP does not replace build-time checks, it completes them. The real change is that enforcement becomes dynamic, so the control plane can react when a workload is behaving in a way that was not visible during scanning. That can mean blocking risky connections, revoking overbroad access paths, alerting on unexpected privilege use, or isolating a workload before an error becomes a broader incident.

This is particularly important for cloud-native systems where identity, network reachability, and data access are tightly coupled. A workload that was acceptable during deployment can become risky once it inherits a new role, a new token, or a new integration. CSA MAESTRO agentic AI threat modeling framework is a reminder that modern systems often change behaviour at runtime, so control assumptions must survive execution, not just review.

For practitioners, the key design question is not “Did it pass?” but “What will the platform do when the live workload deviates from the approved state?” If there is no answer to that question, the programme is still operating mostly as a pre-release review function.

Runtime coverage also gives defenders better evidence. Instead of relying on configuration snapshots alone, teams can compare intended policy with observed behaviour, which makes it easier to identify drift, mis-scoped permissions, and unsafe interaction patterns before they spread.

Risk and Threat Considerations

When CNAPP stops at pre-deployment checks, the main risk is exposure that appears only after release. Attackers and failures alike can exploit the period where a workload is approved on paper but materially different in execution, especially when runtime permissions, secrets, or connections change after deployment.

Failure mechanism: Static checks validate the manifest or image, but they do not continuously enforce least privilege, detect drift, or stop unexpected runtime behaviour. A benign release can therefore become an exposed service once it starts using broader access than was reviewed.

Impact: The organisation loses blast-radius containment. A small misstep can turn into lateral movement, data exposure, or a wider cloud incident because there is no active control watching the workload after the gate has opened.

Practitioner Guidance

What to prioritise: Keep pre-deployment checks, but treat runtime policy enforcement and detection as mandatory for any workload that can reach sensitive data, privileged APIs, or production dependencies. If the service can change state after deploy, it needs live monitoring.

What to verify: Confirm that the platform can show observed network paths, privilege use, secret access, and policy violations for the running workload, not just the image or template that was scanned. If you cannot observe runtime behaviour, you cannot prove control effectiveness.

Common mistake: Assuming a clean pipeline result means the workload is safe. That assumption fails as soon as autoscaling, ephemeral credentials, or post-deploy configuration changes alter the effective attack surface.

Practitioner takeaway: The control objective is continuous containment, not one-time approval, because cloud exposure is usually created by what the workload becomes after deployment.

Related resources from NHI Mgmt Group

• What breaks when pre-deployment security checks are left out of rapid application delivery pipelines?
• What happens when cloud policy checks are moved into pull request workflows instead of after deployment?
• How should security teams assess container risk when runtime behavior may differ from pre-deployment checks?
• What happens when API security is left mostly to development teams and pre-deployment testing?