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.
Editorial analysis by NHI Mgmt Group, based on content published by Hush Security: “Malicious Container Images: Runtime Container Secret Detection When Static Scanning Fails”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: A clean scan does not prevent a container from downloading and running malicious code after startup.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/05/2026 9:39 am
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Runtime container credential theft exposes the limits of static scanning