What should teams do after a malicious image is discovered in a container registry?

Remove the image from circulation, publish a clean replacement, and revoke any credentials that could be used to reintroduce the malicious artifact. Then rotate the keys associated with image publishing and review how the attacker got access in the first place. The incident response goal is to stop reuse, reduce blast radius, and prevent a repeat in the same pipeline.

What containment should happen first

A malicious image is an integrity problem before it is anything else. Teams should treat the registry artifact as tainted, remove it from circulation everywhere it may be pulled, and replace it with a known-good build so deployment systems stop reusing the compromised version. That containment step matters even if no runtime abuse has yet been observed.

Registry cleanup needs to be paired with distribution cleanup. If the image was mirrored, cached, referenced in a manifest, or already promoted into another environment, those copies and references need to be invalidated as well. The practical aim is to stop the artifact from surviving in places that normal rebuild and deploy paths would otherwise trust.

Revoke or disable any publishing paths that can reintroduce the image.
Replace the artifact with a clean rebuild from trusted source and pipeline inputs.
Invalidate downstream references so old tags, digests, and promotions cannot be reused.

Why registry compromise often becomes a pipeline problem

A malicious image in a registry usually signals that the attacker already had some combination of publishing access, build access, or supply-chain reach. That means the incident response scope should extend beyond the image itself to the account, token, key, or CI/CD path that allowed the artifact to appear in the first place.

For container supply chains, the attacker’s advantage is persistence through trust. If teams only delete the image but leave the publish credential, signing key, or build integration untouched, the same compromise path can be used again. NIST’s container guidance on Container Security is useful here because it frames images, registries, and deployment pathways as one security boundary, not separate problems. The broader lifecycle and revocation angle is also covered in NHI Lifecycle Management Guide, especially where publishing credentials and rotation are part of operational control.

Where the malicious image contained embedded secrets or was introduced using stolen publisher credentials, the cleanup should also account for any keys that may have been harvested during the same compromise. NHIMG’s Docker Hub Auth Secrets in Container Images and Massive Docker Hub Secrets Leak are directly relevant examples of how images can become a credential-exposure vector rather than just a deployment artifact.

What to verify before closing the incident

Teams should verify that the malicious artifact cannot be pulled, that its clean replacement is the only active version, and that every credential used to publish or promote it has been rotated or revoked. The verification target is not just “the registry entry is gone”; it is “the attacker no longer has a reusable path back into the pipeline.”

That means checking the full chain of trust, including image signing, registry access, CI/CD service credentials, and any automation that copies images between registries or environments. If the build or publish path is still trusted without change, deletion alone is only a temporary cleanup.

Confirm the malicious digest is blocked or removed from every environment that can deploy it.
Confirm the replacement image was rebuilt from trusted inputs, not edited in place.
Confirm publisher credentials, signing material, and automation tokens were rotated or invalidated.
Review access logs and pipeline history to identify the original entry point and any lateral use of the same access.

Risk and Threat Considerations

A malicious image in a registry creates two linked risks: supply-chain reuse and credential re-entry. If the attacker can republish, retag, or re-sign artifacts, the compromise can reappear even after the visible image is deleted. If the image contained secrets or was published with stolen credentials, the same access path can be used to stage follow-on compromise.

Failure mechanism: Teams remove the bad image but leave behind the publish token, signing key, registry permission, or CI/CD credential that enabled the upload, so the attacker can reintroduce the artifact or a variant of it.

Impact: Malicious code can be redeployed, build trust is eroded, and the blast radius expands from one artifact to the whole publishing pipeline.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Registry cleanup depends on revoking the access that allowed malicious publishing.
	8 — Audit Log Management	Incident review requires registry and pipeline logs to trace how the artifact was introduced.
	12 — Network Infrastructure Management	Containment requires stopping distribution of the malicious image across environments.
Recommendation — Revoke compromised publishing access and remove any lingering registry permissions. Review registry and CI/CD logs to identify the original publish path and any reuse. Block distribution paths and ensure only the clean image can be deployed.
NIST CSF 2.0	PR.AC — Access Control	The incident hinges on limiting who can publish and reintroduce registry artifacts.
	RS.MI — Mitigation	Response actions must remove the malicious artifact and prevent reuse.
	RC.RP — Recovery Planning	Recovery requires replacing the compromised image with a trusted clean build.
Recommendation — Tighten publishing access and invalidate credentials that can reintroduce the image. Remove the image from circulation and block its reuse in deployment paths. Restore service with a verified clean replacement and confirm downstream trust paths.

Practitioner Guidance

What to prioritise: Rotate or revoke the publishing path before treating the incident as contained. If a key or token can still push to the registry, the image cleanup is incomplete.

What to verify: Make sure the clean replacement is rebuilt from trusted source, not patched over the compromised artifact, and verify that downstream deployers cannot resolve the malicious digest or tag anymore.

Practitioner takeaway: The right response is to break the attacker’s ability to republish, not just to delete the evidence of one bad publish.