Notifications
Clear all
Topic starter
17/05/2026 9:39 am
TL;DR: Malicious container images can pass static scanning yet still execute bootstrap code at runtime that steals SSH keys, cloud credentials, and Kubernetes tokens, according to Hush Security. The security boundary has shifted to runtime behavior, where identity scope, credential form, and execution monitoring now matter more than image cleanliness.
NHIMG editorial — based on content published by Hush Security: runtime container credential leakage attack analysis
Questions worth separating out
Q: How should security teams govern credentials inside containers?
A: Treat container credentials as ephemeral workload identity, not as files any process can read.
Q: Why do image scanners miss some container supply chain attacks?
A: Image scanners analyse static artifacts before deployment, but some attacks place the malicious code on a remote server and fetch it only when the container starts.
Q: What is the difference between static image security and runtime container security?
A: Static image security checks what is stored in the image layers, packages, and metadata before release.
Practitioner guidance
- Implement runtime credential elimination Replace static SSH keys, cloud keys, and long-lived service account tokens with short-lived workload identities that are issued only when the container needs them.
- Restrict startup-time code fetching Flag and review ENTRYPOINT and CMD patterns that download and execute remote scripts, especially curl to bash or similar loader chains.
- Scope Kubernetes service accounts tightly Remove cluster-wide permissions from pods and limit each workload to the minimum namespace and API verbs required for its function.
The practical consequence is that credential form now matters as much as image provenance, and teams should prefer short-lived workload tokens over secrets embedded in files or environment variables?
👉 Read Hush Security's analysis of runtime container credential leakage →
Explore further
17/05/2026 9:39 am
Runtime execution, not image cleanliness, is now the decisive control boundary. Static analysis can only judge what is present in the image. It cannot fully assess code that arrives after the container starts, which is why runtime fetch-and-execute patterns create a governance gap that image scanning will always miss. Practitioners need to move from artifact confidence to execution control.
A few things that frame the scale:
- Popular images with misleading titles like azurenql accumulated over a million downloads before detection, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, and 75% of organisations still express strong confidence in their secrets management capabilities.
A question worth separating out:
Q: When does a container compromise become a broader NHI governance problem?
A: It becomes an NHI governance problem when the container can access secrets, tokens, or service account privileges that extend beyond the workload itself. At that point the attacker is not just running code inside a pod, but reusing non-human identities to move through cloud and cluster services. Scope, not just detection, determines blast radius.
👉 Read our full editorial: Runtime container credential theft exposes the limits of static scanning
