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.
At a glance
What this is: This is an analysis of container images that look clean at scan time but execute malicious bootstrap code at runtime to steal credentials and move laterally.
Why it matters: It matters because IAM, NHI, and container security teams have to govern what a workload can do after start, not just what was present in the image layer at build time.
Context
Container image scanning only evaluates a static artifact, while malicious payloads can arrive later through runtime execution. In this attack pattern, the image looks legitimate during build and registry checks, then pulls attacker-controlled code when the container starts, which is why conventional supply chain controls miss the real exploit surface.
The governance gap is that container security often assumes image cleanliness implies runtime trust. For NHI practitioners, the issue is not the image alone but the credentials, tokens, and file-based access that the running workload can reach once a container process begins executing arbitrary code.
Key questions
Q: What fails when a container passes scanning but runs malicious startup code?
A: Static image scanning fails because it validates the artifact at rest, not the commands a container downloads and executes after start. When the malicious payload arrives only at runtime, the scanner has already finished. Teams need controls that observe process behaviour, credential access, and network egress while the container is running.
Q: Why do static credentials increase the impact of runtime container compromise?
A: Static credentials turn a short runtime execution window into a reusable access event. If the container can read SSH keys, cloud tokens, or Kubernetes service account files, the attacker gains identities that may remain valid after the workload is gone. Short-lived, scoped credentials reduce that blast radius materially.
Q: What are the signs that a container is abusing runtime identity access?
A: Look for unexpected shell launches, reads of credential files, access to metadata endpoints, and outbound connections to unapproved domains immediately after startup. Those signals indicate the container is not just running application code but probing for secrets or exfiltrating them. The earlier those behaviours are caught, the smaller the incident.
Q: Should teams rely on image scanning or runtime monitoring for container security?
A: They need both, but they solve different problems. Image scanning reduces known build-time risk, while runtime monitoring catches code that appears only after deployment. If the threat involves downloaded payloads, credential theft, or post-start behaviour, runtime monitoring is the control that actually sees the compromise.
Technical breakdown
Why static image scanning misses runtime payloads
Static scanners inspect layers, dependencies, and binaries that exist when the image is built or mirrored. They cannot predict what a bootstrap script will download after startup, which is the key asymmetry here. A curl-to-bash loader can look harmless in a manifest because the malicious code is not present yet. That means the scanner validates packaging, not execution. In container terms, the attack surface shifts from artifact integrity to process behavior the moment ENTRYPOINT or CMD runs. This is why image hygiene alone cannot answer whether a container is safe once deployed.
Practical implication: treat scan results as build-time evidence only, not as proof that runtime execution is trustworthy.
How credential harvesting works inside a running container
Once the loader runs, the malware can search the filesystem, environment, metadata endpoints, and mounted service account paths for usable secrets. That includes SSH keys, cloud provider credentials, API keys, and Kubernetes tokens. The container does not need special exploit primitives if the surrounding environment still exposes high-value identity material as readable files or variables. This is an NHI problem as much as a container problem, because the attacker is abusing non-human identity material already present in the runtime context. If those credentials are long-lived or broadly scoped, the harvest becomes immediately useful.
Practical implication: remove static credentials from container reach and scope any runtime-issued identity to the smallest possible task.
Why runtime behavior becomes the enforcement boundary
A container can be image-clean and still malicious in motion. Runtime controls such as behavioral detection, eBPF observation, and identity-scoped access policies are designed to watch what the process actually does after start. That matters because the exploit is not the presence of a known vulnerable package, but the moment a new process opens secret files, reaches unexpected domains, or queries a cloud metadata service. In other words, the trust decision moves from image vetting to process governance. For modern container estates, that is the only boundary that reflects how the attack actually works.
Practical implication: enforce policy on execution, file access, and network egress instead of relying only on pre-deployment image approval.
Threat narrative
Attacker objective: The attacker aims to steal reusable credentials and convert a benign-looking container deployment into access for cloud, host, and Kubernetes environments.
- Entry occurs when a developer or pipeline pulls a typosquatted or compromised container image that appears legitimate during static review.
- Credential access begins when the container starts and the ENTRYPOINT script downloads attacker-controlled code that searches for SSH keys, cloud credentials, and Kubernetes tokens.
- Escalation follows if the harvested identity material includes overly permissive service account access or instance metadata credentials that can reach additional systems.
- Impact is achieved when the attacker exfiltrates the collected secrets and uses them to attempt lateral movement or cluster compromise.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
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 trust debt is the core failure mode: container programmes still treat a successful image scan as evidence that execution is safe. That assumption was designed for static artifacts, not for code that fetches its payload after start. The implication is that identity and process governance must move closer to runtime, because the image layer no longer contains the whole threat.
Credential reach, not image cleanliness, determines blast radius: the exploit succeeds when a running container can read SSH keys, cloud credentials, metadata tokens, or Kubernetes service account material. Those assets are non-human identities in practice, and if they remain file-based or long-lived, any post-start loader can consume them. The practitioner conclusion is that the useful control is not just scan depth but identity exposure reduction.
Static controls are now necessary but insufficient: provenance checks, image signing, and registry policy can reduce known risk, but they do not inspect what a container downloads at runtime. This is the limit that many security programmes miss because they optimise for supply chain hygiene rather than process behaviour. The practitioner conclusion is to govern the workload after it starts, not only before it ships.
Runtime detection should become the primary assurance signal: a container that opens secret files, spawns unexpected shells, or reaches unknown endpoints is expressing risk that static analysis cannot see. That gives security teams a more honest control plane for non-human identity behaviour inside containers. The practitioner conclusion is to anchor monitoring to runtime events that reveal actual identity use, not assumptions about package safety.
Ephemeral credential trust debt: this attack shows why letting containers inherit durable secrets creates a hidden liability that compounds after deployment. The risk is not merely leakage, but the fact that one short-lived runtime event can expose identities that remain useful long after the container exits. The practitioner conclusion is to shorten credential lifetime and narrow scope wherever a workload can execute arbitrary startup code.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
What this signals
Runtime trust is the new control boundary: container programmes that still equate a clean image with a safe workload are optimising for the wrong moment in the lifecycle. The practical shift is to govern what the process can do after start, because that is where secret access, exfiltration, and lateral movement become visible.
For NHI teams, the important change is that container credentials should be treated as runtime identities with sharply limited scope and lifespan. That means reducing secret reuse, eliminating file-based exposure where possible, and watching for behaviours that show a workload has moved beyond its intended identity boundary.
For practitioners
- Replace static secret exposure in containers Move cloud credentials, SSH keys, database passwords, and Kubernetes tokens out of files and environment variables that a startup script can read.
- Require runtime-issued, scoped workload identity Issue short-lived tokens only when the container actually needs them, and scope them to the minimum permissions needed for that task.
- Monitor startup behaviour for secret access Alert on unexpected process spawns, reads of credential paths, and connections to unapproved endpoints during container start.
- Verify image provenance before deployment Use digest pinning and signing checks so typosquatted or tampered images are easier to detect before they reach production.
Key takeaways
- A clean scan does not prevent a container from downloading and running malicious code after startup.
- The attack becomes severe because the runtime workload can read secrets, tokens, and keys that were never part of the image.
- The best containment is to reduce static credential exposure and enforce behaviour-based monitoring during execution.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on secrets exposed to a running container at runtime. |
| NHI-04 — Insecure Authentication | The attack abuses weak runtime identity handling and token exposure. | |
| NHI-07 — Long-Lived Secrets | Long-lived container credentials create the harvestable material this attack depends on. | |
| Recommendation — Scan for secret leakage paths and remove credentials that a container can read after startup. Replace exposed static auth material with runtime-issued identities that are harder to reuse. Shorten credential lifetime so a container compromise cannot reuse the same secrets indefinitely. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central when runtime malware can harvest auth material. |
| Recommendation — Apply authenticator management controls to rotate or revoke any credential a container can access. | ||
| MITRE ATT&CK | TA0006;TA0010;TA0008 — Credential Access; Exfiltration; Lateral Movement | The attack chain explicitly includes credential theft, exfiltration, and lateral movement attempts. |
| Recommendation — Map container startup abuse to credential access, exfiltration, and lateral movement detections. | ||
| CIS Controls v8 | CIS-5 — Account Management | The incident exposes unmanaged account and token sprawl inside container environments. |
| Recommendation — Reduce account and token sprawl by inventorying all identities a container can reach. | ||
Key terms
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
- Bootstrap Loader: A bootstrap loader is a small startup command or script that fetches and executes additional code when a container begins running. It often looks harmless during image review, but it can act as the delivery mechanism for credential theft, exfiltration, or other malicious runtime behaviour.
- Tool Credential Harvesting: The abuse pattern where an attacker uses an agent’s connected tools to retrieve secrets, tokens, or API keys. It matters because the tools created to make the agent useful can also become the easiest route to adjacent privileges and broader enterprise access.
- Static Scanning Gap: The static scanning gap is the blind spot created when security tools evaluate container images before execution but cannot inspect what the image downloads later. It explains why a workload can pass build-time checks and still become malicious the moment it starts.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 17, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org