Pre-deployment scanning stops being enough when the security question depends on runtime state, not source code. If exploitability hinges on live privileges, container behaviour, dependency drift, or authentication chains in production, the scanner cannot answer it alone. That is where runtime enforcement and telemetry become mandatory.
Why This Matters for Security Teams
Pre-deployment scanning is valuable, but it answers a narrower question than cloud-native risk actually presents: what looks vulnerable in code, manifests, or images before release. Once workloads run in Kubernetes, serverless, or ephemeral infrastructure, the decisive factors are runtime identity, privilege, network reachability, secret exposure, and drift. That is why runtime controls and telemetry matter alongside tools aligned to the NIST Cybersecurity Framework 2.0.
NHIMG research shows why confidence often lags behind deployment speed. In The 2024 Non-Human Identity Security Report, only 19.6% of security professionals expressed strong confidence in their organisation's ability to securely manage non-human workload identities, while 88.5% said their non-human IAM practices lagged behind or merely matched human IAM. That gap becomes visible when a container image passes scanning but later inherits broader permissions, mounts a secret, or reaches a sensitive API through an unexpected path. In practice, many security teams encounter exploitable exposure only after production behaviour has already created it, rather than through intentional pre-deployment review.
How It Works in Practice
Effective cloud-native assurance treats pre-deployment scanning as one input, not the final decision point. Scanners can flag known CVEs, misconfigurations, and policy violations in IaC, images, and dependencies. They cannot reliably determine whether a vulnerability is reachable from a live workload, whether an identity token is over-scoped, or whether a service can pivot after authenticating. That is where runtime enforcement, workload identity, and continuous telemetry become essential.
Practitioners usually combine three layers. First, they gate builds with image and dependency checks. Second, they enforce least privilege at runtime using workload identity, short-lived credentials, and policy evaluated at request time. Third, they monitor actual execution for anomaly detection, secret access, lateral movement, and container escape indicators. Guidance from the NIST Cybersecurity Framework 2.0 supports this shift from static assurance to ongoing risk management, while the 230M AWS environment compromise illustrates how large-scale cloud exposure can emerge from access and configuration issues rather than from a single bad artifact.
- Use pre-deployment scanning to reduce known software and configuration defects.
- Issue ephemeral credentials tied to workload identity, not shared secrets.
- Evaluate policy at runtime for the actual request, identity, context, and destination.
- Record telemetry for privilege use, secret reads, and unusual service-to-service paths.
This approach aligns with what security teams learn from incidents involving secret leakage and privilege expansion, including the Azure Key Vault privilege escalation exposure. These controls tend to break down when organisations keep long-lived secrets in highly dynamic environments because the runtime state changes faster than the scan-to-deploy cycle.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, so organisations must balance deployment speed against security precision. That tradeoff becomes especially visible in serverless, autoscaled Kubernetes, and CI/CD-heavy environments where workloads appear and disappear quickly.
Current guidance suggests pre-deployment scanning may remain sufficient for low-risk internal services with stable dependencies, fixed network paths, and minimal privileges. Even there, best practice is evolving toward runtime verification because dependency drift and inherited permissions can change reachability after release. For internet-facing services, shared platforms, or workloads handling secrets, scanning alone is rarely enough. The Snowflake breach is a reminder that identity and access conditions often matter more than whether a binary looked clean at build time.
One practical edge case is policy-heavy environments with strong admission control but weak observability. Another is regulated environments where scanners are treated as evidence, even though auditors increasingly expect runtime controls and traceability. The best answer is not to abandon scanning, but to define exactly what it can prove and what only runtime enforcement can verify. If the question is whether a workload can use a permission safely in production, static scanning is not the right control to rely on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Runtime access decisions depend on least privilege and identity governance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Ephemeral secrets and runtime identity address static credential risk in cloud-native systems. |
| NIST AI RMF | AI risk governance is relevant where autonomous systems change production state at runtime. |
Replace long-lived workload secrets with short-lived credentials and rotate on task completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
