Runtime container credential theft exposes the limits of static scanning

At a glance

What this is: This is an analysis of a container supply chain attack pattern where a benign-looking image executes downloader code at runtime and steals credentials after deployment.

Why it matters: It matters because IAM and NHI teams have to govern container identities, not just scan artifacts, if they want to reduce blast radius when runtime code is fetched dynamically.

👉 Read Hush Security's analysis of runtime container credential leakage

Context

Container security breaks when teams assume that a clean image at rest will behave safely at runtime. In practice, the attack surface includes everything the container can read, reach, or inherit once it starts, which turns credentials, service account tokens, and metadata endpoints into NHI governance problems rather than simple malware problems.

The article describes a pattern that is increasingly common in cloud-native environments: a small bootstrap script inside an image fetches the real payload only when the container starts. That makes static scanning incomplete by design, because the dangerous code lives outside the artifact and appears only during execution. For practitioners, this is an operational, not theoretical, gap.

At a governance level, the starting position is typical for modern engineering teams: rely on image scanning, registry policy, and CI/CD checks, then assume runtime will be safe. That model is now insufficient whenever containers can download and execute code after deployment.

Key questions

Q: How should security teams govern credentials inside containers?

A: Treat container credentials as ephemeral workload identity, not as files any process can read. Use short-lived tokens, minimum necessary scope, and automatic revocation so a malicious startup script cannot harvest durable secrets. If a container must use static credentials, assume they are exposed the moment runtime execution is untrusted and plan for rapid rotation.

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. The image can look clean at rest while the runtime payload is still unknown. That is why scanning must be paired with execution-time policy and behavioural monitoring.

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. Runtime container security checks what the workload actually does after startup, including process creation, file access, and outbound connections. Both matter, but runtime controls are the only ones that can see downloaded payloads and live credential abuse.

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.

Technical breakdown

Why runtime payloads defeat static container scanning

Static container scanning examines the image layers, packages, binaries, and metadata before deployment. That works only when the malicious logic is already inside the image. In this attack pattern, the image contains a small loader such as a shell wrapper that downloads a script at startup, so the harmful behavior is invisible until execution. The scanner can see the downloader, but it cannot predict what the remote server will return or how the fetched code will behave. This is why image cleanliness does not equal runtime safety. Practical implication: treat execution-time code fetches as a separate control problem, not a scanning problem.

Practical implication: Block or tightly constrain startup-time code retrieval, and treat curl-pipe-to-bash patterns as a runtime governance issue, not just a static finding.

How credential harvesters exploit NHI sprawl inside containers

Once the container starts, the payload looks for secrets in the places teams commonly leave them: environment variables, filesystem paths, cloud CLI configuration, Kubernetes service account tokens, and instance metadata endpoints. Those values are non-human identities in operational form, because they authorize workloads, scripts, and pods to act on systems and data. The compromise succeeds when those credentials are long-lived, over-scoped, or accessible by any process in the container. The attacker does not need to break crypto or bypass authentication if the secret is already present and readable. Practical implication: the issue is not only malware execution, but exposed identity material inside the workload boundary.

Practical implication: Minimize where credentials exist in containers, and replace static secrets with short-lived workload identities wherever possible.

Why Kubernetes permissions turn a container compromise into cluster compromise

A container becomes a much larger problem when its service account can read secrets across namespaces, schedule privileged pods, or query cluster resources broadly. In that case, a compromise that began as local credential theft can expand into cluster-wide access by reusing the workload identity already attached to the pod. This is an NHI governance failure, not just a workload security failure, because the identity assigned to the container defines the blast radius. Short-lived tokens help, but scope is the deciding factor. Practical implication: Kubernetes identity should be treated as privileged access and reviewed with the same discipline as human admin access.

Practical implication: Map every pod identity to least privilege and remove cluster-level permissions from workloads that do not explicitly require them.

Threat narrative

Attacker objective: The attacker wants to turn a trusted container start into credential theft and then reuse those identities for cloud and cluster access.

1. Entry occurs when a container starts and executes a tiny bootstrap script from the image ENTRYPOINT that downloads attacker-controlled code at runtime.
2. Escalation follows as the payload searches the filesystem, environment, and metadata services for SSH keys, cloud tokens, and Kubernetes service account credentials.
3. Impact is achieved when the harvested credentials are exfiltrated and reused for broader cloud and cluster access, including attempts to compromise Kubernetes resources.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Container credential leakage is an NHI problem before it is a malware problem. The payload succeeds by harvesting secrets, tokens, and service account material that already exist inside the workload boundary. That means the real failure is overexposed non-human identities, not just an infected container. The right question is whether the workload ever had credentials a process could steal.

Blast-radius control matters more than perfect detection in this pattern. If a malicious image can start once, the most important question becomes how much identity scope it can inherit before detection lands. Short-lived, narrowly scoped tokens, enforced runtime policy, and rapid revocation limit damage even when a scanner misses the initial threat.

Identity should be ephemeral at runtime, not merely hidden at rest. Ephemeral credential trust debt: every static secret stored for convenience creates future exposure when runtime code is untrusted. The more containers depend on reusable secrets, the more the organisation accumulates risk that only appears when the image executes. Practitioners should assume that any secret readable by a container is a secret on borrowed time.

Security teams should stop treating container supply chain controls as a complete defence. Provenance checks, signatures, and registry policy reduce exposure, but they do not neutralise runtime behaviour. The mature position is layered governance: restrict execution, reduce standing credentials, and monitor process behaviour as the source of truth.

From our research:

• 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.
• For a broader breach lens, review The 52 NHI breaches Report for patterns that show how exposed identities expand attack reach after initial compromise.

What this signals

Ephemeral credential trust debt: every container that can read a reusable secret adds future exposure to the programme, even if the image passes every pre-deployment check. 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.

With 6 distinct secrets manager instances on average, fragmentation is already a control problem in many environments, according to The State of Secrets in AppSec. That fragmentation makes container runtime compromise harder to contain because the same workload may touch multiple identity stores and rotation processes.

The next control decision is not whether to scan harder, but whether runtime identity can be made disposable enough that a single malicious startup script has little to harvest. Practitioners should align container policy with least privilege, fast revocation, and behavioural monitoring rather than relying on artifact assurance alone.

For practitioners

• 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.
• Add runtime behavioural monitoring Detect unexpected process spawns, credential file access, and unusual outbound connections so that exfiltration attempts are visible when they begin.
• Rotate and revoke exposed secrets quickly Assume any credential available to a malicious container may have been copied, then revoke and reissue keys before the attacker can reuse them.

Key takeaways

• Container images can look clean and still execute malicious code after deployment, which makes runtime behaviour the real security boundary.
• Credential theft in containers is fundamentally an NHI governance failure because the attacker targets secrets, tokens, and service accounts already exposed to the workload.
• The practical response is to reduce standing credentials, scope workload identities tightly, and monitor execution because static scanning alone cannot stop fetched payloads.

Key terms

• Runtime Container Security: Runtime container security is the practice of controlling what a container does after it starts, not just what its image contains. It focuses on process behaviour, file access, network connections, and identity use so teams can detect malicious execution that static scanning cannot see.
• Ephemeral Workload Identity: Ephemeral workload identity is a short-lived credential issued to a container, service, or agent for a specific task window. It reduces exposure by avoiding durable secrets on disk or in environment variables, which limits what an attacker can steal if runtime code is compromised.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause by reusing a stolen identity. In NHI environments, the scope of permissions, the lifetime of tokens, and the number of systems a credential can reach all determine how far the compromise spreads.

Deepen your knowledge

Container runtime identity, secrets elimination, and workload-scoped access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from static scanning to runtime governance, the course gives that transition a structured starting point.

This post draws on content published by Hush Security: runtime container credential leakage attack analysis. Read the original.