Use static scanning to block known bad code, images, and configuration before deployment, but treat runtime control as the control that governs live behaviour. The two are complementary, not interchangeable. If a workload can access secrets or services in production, security decisions must continue after release, when actual process, network, and identity behaviour can be observed.
Why Static Scanning and Runtime Control Solve Different Problems
Static scanning is the right place to catch known-bad patterns before a workload ever runs: vulnerable images, risky code, exposed secrets in manifests, and obvious misconfigurations. runtime control answers a different question, which is whether the live workload is behaving within acceptable bounds after deployment. If the workload can reach production secrets or downstream services, pre-deploy checks alone are not enough.
That distinction matters because static controls are only as good as the artefacts and assumptions they inspect. A clean scan does not prove the deployed workload will remain safe once it starts calling APIs, opening network paths, or interacting with cloud credentials. Runtime control gives you the enforceable guardrails and observation you need when actual process behaviour, network calls, and identity use matter more than the original scan result.
In practice, the balance is not “which one wins,” but which one is the last control standing for the risk you still carry after release. Static scanning reduces the chance of shipping obvious defects; runtime control reduces the blast radius when a workload is misused, compromised, or simply behaves differently in production than it did in testing.
Where the Hand-off from Build-Time to Live Enforcement Breaks Down
Teams often overestimate what a static pass can tell them about a workload that is dynamically configured, rapidly scaled, or dependent on external services. A container image may scan cleanly, but the running pod can still inherit mounted credentials, permissive network reachability, or an overly broad cloud role. That is why runtime policy, process visibility, and network enforcement belong in the control set for anything with meaningful production access.
The most common failure is treating deployment approval as the end of security review. In reality, cloud workloads can accumulate risk after deployment through sidecars, injected secrets, service-to-service trust, API permissions, and environment-specific configuration drift. Runtime controls are what keep those changes observable and, where possible, constrained.
Static scanning still has value as an early gate, especially for supply-chain hygiene and configuration baselines. But it cannot tell you whether the workload’s live behaviour is acceptable under real traffic, whether it is making unexpected outbound connections, or whether it is using privileges that were never evident in the build artefact alone.
How to Design the Two Controls as a Single Defense
The strongest pattern is to use static scanning as a preventive filter and runtime control as the operational policy layer. That means shipping only what clears code, image, and configuration checks, then enforcing least-privilege access, network segmentation, and behavioural monitoring once the workload is active. For cloud workloads, the runtime layer should be able to constrain what the workload can do even if the build-time controls missed something.
For workloads that interact with secrets or other sensitive services, runtime control should be tied to the actual identity and access path the workload uses in production. A workload identity that can be revoked, scoped, or segmented is far more useful than a one-time approval based only on the image. SPIFFE workload identity specification is a useful reference point for that model, because it treats runtime trust and workload identity as first-class concerns.
Cloud-native teams also benefit from a clear separation between preventive scanning and runtime enforcement in their operating model. NIST SP 800-190 Container Security is helpful here because it frames container risk across image, registry, orchestration, and runtime layers instead of collapsing everything into a single pre-deploy check.
Risk and Threat Considerations
When teams rely too heavily on static scanning, the main risk is false confidence: a workload can be “approved” while still carrying live access paths that matter more than its scanned contents. Threat actors do not need the original artefact to be malicious if they can abuse its production permissions, intercept its secrets, or pivot through its network reach once it is running.
Failure mechanism: Build-time checks miss runtime realities such as injected credentials, inherited cloud permissions, service-to-service trust, or behaviour that emerges only under live traffic. An attacker or misconfiguration can then turn a nominally clean workload into an effective access path.
Impact: The result is excessive blast radius, unexpected data exposure, or a workload that continues to operate with privileges it never needed. In cloud environments, that can mean a small deployment error becomes a production compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Catches malicious or altered workload artefacts before deployment. |
| AC-6 — Least Privilege | Limits what live workloads can do once running in cloud environments. | |
| CM-6 — Configuration Settings | Supports baseline checks for insecure cloud and workload configuration before release. | |
| Recommendation — Apply SI-7 to block untrusted images and code before they reach production. Apply AC-6 to restrict each workload to only the permissions it truly needs. Use CM-6 to standardize and enforce secure workload configurations. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Directly addresses insecure software and cloud configuration before deployment. |
| CIS-6 — Access Control Management | Supports ongoing control of what deployed workloads can access. | |
| Recommendation — Enforce secure baselines with CIS-4 before workloads are promoted to production. Use CIS-6 to tightly manage runtime access paths and privileges. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access Decisions | Zero trust requires continuous authorization, not a one-time deploy-time decision. |
| Recommendation — Apply least-privilege runtime decisions for every workload request. | ||
Practitioner Guidance
What to verify: Confirm that static scanning blocks the artefacts you do not want to ship, then verify that runtime policy still constrains the workload after deployment. If the workload can read secrets, call internal services, or reach administrative APIs, treat those paths as live controls that must be tested in production-like conditions.
What good looks like: A workload can pass scanning, deploy cleanly, and still be denied anything it does not need at runtime. The observable state you want is “approved to run, but tightly bounded while running,” not “scanned once, therefore trusted.”
Practitioner takeaway: Use static scanning to reduce preventable defects, but use runtime control to govern the access and behaviour that actually determine production risk.
Related resources from NHI Mgmt Group
- How should cloud security teams balance agentless scanning with agent-based runtime protection?
- How should security teams balance cloud cost savings with control when choosing between static and dynamic service models?
- How should security teams balance agility with identity control in cloud and AI environments?
- How should security teams replace static service account keys in cloud workloads?