Configuration file scanning looks for risky settings before deployment, such as insecure policies, exposed services, and excessive privileges. Runtime scanning observes active workloads and can catch behaviors that only appear after deployment. Used together, they give better coverage than either alone, because one finds problems before release while the other helps confirm whether live cluster activity matches expected security boundaries.
Why Configuration Scanning and Runtime Scanning Answer Different Security Questions
Configuration file scanning is about intent, while workload scanning is about observed behaviour. The first checks whether manifests, Helm charts, or other deployment definitions encode insecure defaults before they reach the cluster. The second checks whether running pods, containers, or supporting services behave in ways that diverge from that intended state. For Kubernetes teams, the distinction matters because a clean repository does not guarantee a safe cluster, and a secure-looking runtime does not prove that risky settings were never deployed.
That split is why Kubernetes security programmes usually need both policy review and runtime visibility, not one or the other. configuration scanning can surface weak network exposure, privileged settings, or misapplied security context controls early enough to prevent a bad release. Runtime scanning can reveal drift, unexpected processes, mounted secrets, or live activity that was not obvious from static files. In practice, many security teams discover the gap only after a deployment has already reached production and the live workload has started behaving differently from the reviewed configuration.
How the Two Scanning Modes Work Together in a Cluster
Configuration scanning inspects source-controlled or packaged Kubernetes definitions before they are applied. It is strongest when teams want to catch unsafe intent early, because it can be embedded into developer workflows, pull request checks, and CI pipelines. That makes it useful for preventing obvious misconfigurations such as containers running as root, overly broad service exposure, or missing security constraints. It also scales well because the review happens before the workload consumes cluster resources.
Runtime scanning inspects what is actually running. That can include current process activity, unexpected binaries, shell access in containers, anomalous network connections, mutable filesystem changes, or a workload whose live permissions do not match its reviewed manifest. This matters because Kubernetes environments can change after deployment through manual changes, sidecars, operator actions, image drift, or compromised credentials. Runtime scanning therefore acts as a confirmation layer, not merely a duplicate of the pre-deployment check.
A useful way to think about the difference is:
- Configuration scanning answers whether the declared deployment is acceptable before release.
- Runtime scanning answers whether the live workload still behaves within expected boundaries.
- Configuration scanning is preventive; runtime scanning is detective and validation oriented.
- Runtime findings often need more context, because some deviations are benign and some indicate compromise.
Teams get the best result when policy, admission controls, image assurance, and runtime detection are connected. For example, a manifest may look acceptable, but the container image may still launch unexpected tools or access paths once it starts. Likewise, runtime evidence can show whether an exception granted during deployment remained tightly bounded or expanded in practice. The SPIFFE workload identity specification is useful background when teams are separating workload trust from the cluster control plane, because it clarifies how machine-to-machine identity can be asserted for workloads that need stronger runtime verification. The guidance breaks down when teams expect static review alone to prove operational safety, or when runtime monitoring is so noisy that it cannot distinguish normal orchestration from genuine drift.
Where Kubernetes Security Teams Get the Boundary Wrong
Tighter inspection often improves confidence, but it also increases operational overhead, so teams must balance early prevention against runtime certainty.
One common misunderstanding is treating runtime scanning as a substitute for fixing insecure manifests. That creates a reactive programme that keeps detecting the same problems after deployment instead of preventing them. The better pattern is to use configuration scanning to block or at least flag weak intent, then use runtime scanning to verify that approved intent is what actually happens in production. Another edge case is admission of legitimate exceptions, such as a privileged maintenance job or a debugging session. Those cases may look risky in static review, but the real question is whether they are tightly authorised, time-bounded, and observable at runtime.
There is also a difference between workload drift and compromise. A modified runtime state can result from a legitimate operator action, an autoscaling event, or a security incident, and the scanner alone may not know which one. That is why consensus in the industry is strongest on the need for both controls, while there is less agreement on exactly how much runtime deviation should trigger escalation. The right threshold depends on whether the cluster is handling regulated data, internet-facing services, or high-trust internal workloads.
For that reason, the most defensible approach is to treat configuration scanning as the release gate and runtime scanning as the assurance gate. When those two views disagree, the discrepancy itself becomes the security signal that deserves investigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Covers reviewing Kubernetes manifests and deployment settings for unsafe configuration. |
| Recommendation — Apply secure configuration checks to block risky Kubernetes settings before deployment. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Relevant where workloads' effective permissions differ from declared access intent. |
| DE.CM-8 — Container and VM Monitoring | Fits runtime scanning of active containers and workload behaviour. | |
| Recommendation — Verify live workload permissions match approved access boundaries. Monitor running Kubernetes workloads for unexpected activity and drift. | ||
| MITRE ATT&CK | T1611 — Escape to Host | Runtime scanning can reveal behaviours associated with container compromise or breakout attempts. |
| Recommendation — Map suspicious runtime activity to container attack techniques and escalate on breakout indicators. | ||
Practitioner Guidance
What to prioritise: Use configuration scanning to prevent unsafe deployment patterns, then decide which runtime detections are needed to catch state changes that cannot be inferred from manifests alone. If the cluster uses dynamic controllers, operators, or frequent emergency changes, runtime visibility becomes more important because declared state will drift more often.
What to verify: Check that the runtime scanner is validating the same security assumptions that the manifest review enforces, such as privilege boundaries, network exposure, and container execution context. If the two tools report different interpretations of the same workload, treat that as a governance problem rather than a tooling quirk.
Practitioner takeaway: The real decision is not which scan is better, but which control answers which question at which stage of the workload lifecycle.
Related resources from NHI Mgmt Group
- What is the difference between runtime detection and posture scanning for Kubernetes security?
- What is the difference between dependency scanning and container scanning in Kubernetes?
- What is the difference between image scanning and runtime protection in Kubernetes security?
- What is the difference between OAuth device flow and storing secrets in CLI configuration files?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
