Pre-deployment scanning checks images, manifests, and registry content before workloads run. Runtime protection watches the live workload for process changes, network activity, and exploit behaviour after deployment. In Kubernetes, the difference is the gap between intended state and observed state, and that gap is where attackers often operate.
Why This Matters for Security Teams
Pre-deployment scanning and runtime protection solve different problems in the control stack. Scanning is designed to catch known issues before a workload is admitted, such as vulnerable images, risky manifests, embedded secrets, and policy drift. Runtime protection is about detecting what the workload actually does once it is live, including process spawning, unexpected outbound traffic, privilege escalation attempts, and exploit patterns. NHI risk is relevant because workloads often carry identities and secrets that can be abused long after the build has passed.
That distinction matters in Kubernetes, where intended state and observed state can diverge within minutes. A clean pipeline does not guarantee a safe workload after admission, and a strong runtime control cannot fix an image that already contains hardcoded credentials. Guidance from NIST Cybersecurity Framework 2.0 reinforces the need to pair preventive and detective controls rather than treating either one as sufficient. In NHI programmes, this also aligns with the findings in the Ultimate Guide to NHIs — What are Non-Human Identities, where excessive privilege and weak visibility repeatedly widen exposure. In practice, many security teams encounter misuse only after a workload has already been admitted, rather than through intentional validation of both build-time and live behaviour.
How It Works in Practice
Pre-deployment scanning usually runs in the CI/CD path or on registry admission. It compares artefacts against known bad patterns and policy rules before deployment is allowed. That makes it best for finding static issues: vulnerable base images, open permissions, exposed secrets, missing signatures, and unsafe Kubernetes settings. Runtime protection starts later and watches the workload in execution, often with kernel, eBPF, audit, or telemetry-backed signals. It is designed to detect deviations from the approved baseline, not to rediscover what the build pipeline should have blocked.
The two controls work best when paired with identity and policy discipline. A workload should not only be scanned for flaws; it should also receive only the credentials it needs, for as long as it needs them. The Schneider Electric credentials breach is a reminder that once credentials are exposed, downstream control gaps can turn a static issue into an active incident. For Kubernetes operators, the practical sequence is:
- scan images, manifests, and Helm charts before promotion;
- block known secrets and policy violations before admission;
- issue short-lived credentials to the runtime rather than long-lived static tokens;
- monitor process trees, DNS, outbound connections, and file writes once live;
- alert on behaviour that does not match the approved workload profile.
This maps cleanly to the preventive and detect functions in NIST Cybersecurity Framework 2.0, but current guidance suggests treating runtime as a compensating control, not a substitute for build hygiene. These controls tend to break down in heavily autoscaled clusters with rapid pod churn because the runtime baseline changes faster than the detection rules can be tuned.
Common Variations and Edge Cases
Tighter runtime protection often increases operational overhead, requiring organisations to balance stronger containment against noise, latency, and policy maintenance. That tradeoff shows up most clearly in ephemeral environments, where one-off jobs, sidecars, and short-lived pods may never live long enough to justify deep behavioural baselines. In those cases, best practice is evolving rather than settled: some teams favour aggressive admission controls and lighter runtime telemetry, while others use strict runtime enforcement only for the highest-risk namespaces.
Another edge case is the difference between benign drift and malicious behaviour. A new package installation, an unusual outbound domain, or a changed process tree can be either a legitimate release pattern or an attack, depending on context. That is why runtime tools work best when combined with policy-as-code, workload identity, and clear ownership of each service account. The NHI data in the Ultimate Guide to NHIs — What are Non-Human Identities shows why this matters: when identities and secrets are overexposed, runtime alerts become the last meaningful stop before abuse. The practical rule is simple: scanning reduces what should never ship, runtime protection reduces what should never continue, and mature programmes need both. Without both layers, environments with frequent redeployments and many third-party integrations become difficult to defend cleanly.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Compares static secrets at build time with live NHI abuse risk. |
| NIST CSF 2.0 | DE.CM-1 | Runtime protection depends on continuous monitoring of workload behaviour. |
| NIST Zero Trust (SP 800-207) | SC.L5 | Least privilege and continuous verification support both build and runtime controls. |
Scan for exposed NHI secrets before release and monitor live usage for abuse.
Related resources from NHI Mgmt Group
- What is the difference between static scanning and runtime protection for Java?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between prompt injection risk and identity abuse in agents?
