Why do image scanners miss some container supply chain attacks?

Why This Matters for Security Teams

Image scanners are useful, but they only inspect what is present in the artifact at scan time. That leaves a blind spot when attackers keep the payload outside the image and retrieve it after startup, or when a build pipeline pulls in a dependency that behaves differently at runtime. The result is a clean report for a container that can still become a delivery vehicle for secrets theft, command execution, or lateral movement once it is live.

This is why NHI security has to extend beyond static artefacts and into execution identity, policy, and behaviour. The pattern shows up across supply chain incidents such as the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where trust in software components outpaced trust in the execution context. The broader NHI problem is also visible in The 52 NHI breaches Report, which shows how often identity and secrets exposure become the real attack surface.

Current guidance from OWASP Non-Human Identity Top 10 and CISA cyber threat advisories points toward layered controls, because no single scanner can determine what a workload will fetch, call, or execute after deployment. In practice, many security teams encounter this only after the container has already contacted an attacker-controlled endpoint.

How It Works in Practice

The practical failure mode is simple: the image is assembled with no malicious payload inside it, but the container entrypoint, init logic, or downstream dependency reaches out to a remote location and retrieves the harmful code only when runtime conditions are met. Static scanners cannot prove that the remote payload is safe, and they cannot see whether the container will later use a stolen token, call an unexpected API, or unpack a second-stage script.

To close that gap, current guidance suggests combining image scanning with runtime controls that evaluate behaviour at request time. That usually means workload identity, tight egress policy, process and file monitoring, and secrets that are short-lived rather than embedded for the life of the image. In agentic or automated build systems, the same logic applies to tool use: the workload should prove what it is before it is allowed to fetch, run, or mutate anything. The Anthropic report on AI-orchestrated cyber espionage is a useful reminder that automated systems can chain actions quickly once they obtain usable access.

• Bind the container to a workload identity instead of relying on image provenance alone.
• Issue just-in-time secrets with short TTLs so a stolen token has little reuse value.
• Block or alert on unexpected outbound connections and runtime downloads.
• Log process creation, script execution, and post-start file changes as security events.
• Use policy checks that can deny tool use or network access when context is wrong.

The Ultimate Guide to NHIs — Key Challenges and Risks and OWASP NHI Top 10 both reinforce the same operational point: identity and runtime context matter as much as artifact hygiene. These controls tend to break down when containers run with broad network egress and long-lived secrets because the attacker can wait until after the scan has finished.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, so organisations have to balance reduced attack surface against debugging friction and deployment speed. That tradeoff is real, especially in platforms that auto-scale, spin up ephemeral jobs, or rely on third-party images that expect external downloads during startup.

There is no universal standard for this yet, but best practice is evolving toward separating safe image validation from runtime trust decisions. Signed images and SBOMs still matter, yet they do not answer whether the container will later fetch code from an untrusted host. That is why teams should treat runtime allowlists, egress restrictions, and secret issuance windows as first-class controls rather than optional hardening. The Ultimate Guide to NHIs — Why NHI Security Matters Now is especially relevant where machine identities outlive the job that created them.

Edge cases include init containers that legitimately download model files, build systems that fetch private dependencies, and AI agents that call tools based on changing goals. In those environments, static deny rules can cause outages unless they are paired with context-aware authorisation and explicit approvals for sensitive actions. The MITRE ATLAS adversarial AI threat matrix and DeepSeek breach illustrate how quickly automated systems can turn a small trust mistake into a wider compromise.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How can organizations counter AI-driven cyber attacks?
• How should security teams reduce the risk of secret theft from npm supply chain attacks?
• Why do npm supply chain attacks often become NHI governance failures?