What is the difference between image scanning and runtime protection for malware like Kaiji?

Why image scanning and runtime protection answer different security questions

Image scanning evaluates the artefact before or at deployment, so it is strongest at finding known issues in what was packaged, copied, or built into the image. runtime protection evaluates the live workload, so it is designed to catch behaviour that only appears after start-up, including unpacking, process injection, unexpected child processes, or tampering that never existed in the image itself.

That distinction matters because some malware is visible only in execution. A clean scan does not prove the running workload is safe if the malicious logic is fetched later, triggered conditionally, or hidden behind persistence logic that activates after launch. Runtime protection closes that gap by watching behaviour rather than only artefacts.

For containerised and workload environments, the image is a snapshot, but the real security question is whether the live process is behaving within the bounds you intended. NIST SP 800-190 Container Security explains the split between image, registry, orchestrator, and runtime risk, and why runtime controls belong in the defence model for containers and similar workloads.

Why malware like Kaiji shifts the balance toward runtime controls

Malware such as Kaiji is a good example of why artefact-only review can be insufficient. Threats that rely on persistence, fileless execution, command tampering, or post-launch abuse can evade static inspection if the dangerous action is created only during execution or arrives through a later stage of the attack chain. In that case, the decisive security event happens after deployment, not inside the original image.

Runtime protection is therefore better suited to answer questions like: did the process spawn an unexpected shell, did it attempt to alter commands, did it reach out for follow-on instructions, or did it try to keep itself alive after restart? Those are operational behaviours, and they are often what separate harmless code from an active compromise.

Static scanning still has value, especially for catching known malware signatures, exposed packages, and risky dependencies before release. But for a threat profile built around living-off-the-land behaviour and persistence, static review is only one layer. The image can be clean while the runtime state becomes hostile.

How to use both without confusing their roles

Image scanning and runtime protection work best as complementary controls. Scanning reduces the chance that you deploy something obviously bad. Runtime protection reduces the chance that a workload becomes dangerous after deployment, whether because of an injected payload, a compromised dependency, or behaviour that only emerges under real conditions.

NHI Lifecycle Management Guide is useful here because the same logic applies to identity-bearing workloads and their credentials: what matters is not only what was provisioned, but whether the live access path remains governed, visible, and revocable.

Shai Hulud npm malware campaign shows how malicious activity can turn into secret exposure after the artefact has already been delivered, which is exactly the kind of failure static-only thinking misses. CircleCI breach 2023 reinforces the same lesson: once runtime access or session material is compromised, the damage comes from live abuse, not from the original build artefact alone.

Risk and Threat Considerations

Static scanning creates a false sense of closure if teams treat “passed scan” as equivalent to “safe in production.” Malware that activates later, hides behind process behaviour, or tampers with commands can remain invisible until runtime, at which point the workload may already have reach into data, credentials, or downstream systems.

Failure mechanism: The defender inspects the packaged image but does not observe the live process tree, network behaviour, or command execution path, so a delayed or fileless payload survives release and executes after launch.

Impact: The compromise shows up as active workload abuse, persistence, or lateral follow-on activity, and response becomes harder because the malicious action is now blended into normal execution.

Practitioner Guidance

What to prioritise: Use image scanning to block known-bad artefacts before deployment, but require runtime controls wherever the workload can execute untrusted code, unpack content, or make outbound connections. For malware patterns like Kaiji, the deciding question is whether the control can see the attack at the moment it becomes active.

What to verify: Confirm that runtime tooling can detect process anomalies, command tampering, suspicious child processes, and persistence attempts, and that alerts are tied to the actual workload identity and host context. If your control stack only reports image vulnerabilities, it is not covering the full threat path.

Practitioner takeaway: Treat image scanning as pre-deployment hygiene and runtime protection as the control that proves the workload is behaving safely after launch; for behaviour-driven malware, the latter is the more decisive signal.

Related resources from NHI Mgmt Group

• What is the difference between image scanning and runtime protection in Kubernetes security?
• What is the difference between static scanning and runtime protection for Java?
• What is the difference between pre-deployment scanning and runtime protection?
• What is the difference between image scanning and runtime threat detection?