What should teams look for when scoping exposure to a compromised open source package after cleanup in the registry?

What evidence shows a compromised package actually touched your environment?

Start by treating the registry as only one source of truth. A cleanup in upstream infrastructure does not erase package copies, install artifacts, or traces left by build and runtime systems, so scoping has to focus on whether the package name, exact version, or import path appears in places that prove it was pulled, cached, or executed.

Look for lockfiles, dependency manifests, package manager caches, cached wheels or tarballs, CI artifacts, container layers, and host telemetry that record installation or execution. If those traces show the compromised version, you have stronger evidence than the registry alone can provide, because the bad build may already have propagated into workstations, runners, or gateways.

For open source supply chain cases, the practical question is not just “was the package removed?” but “where did that version land, and what systems preserved it?” This is why cleanup in the registry is a containment step, not proof of safety. A good search path is to correlate package metadata with runtime markers such as install logs, import events, command history, and process execution evidence.

Which traces matter most for scope and blast-radius analysis?

The highest-value traces are the ones that connect a package reference to a real system state. Lockfiles tell you what was intended to be installed, caches and tarballs tell you what was preserved locally, and endpoint or server logs tell you whether the code ran. Those signals let you separate “seen in dependency graph” from “executed on a host.”

Version precision is important. A compromised package name alone is usually too broad, because downstream environments may have pinned a safe release or rebuilt from a later artifact. By contrast, evidence that ties the exact compromised version to an install path, a container image layer, or a build job gives you a defensible scope boundary for remediation and notification.

Also check for adjacent artifacts that survive cleanup, such as vendored dependencies, archive mirrors, artifact repositories, and build caches. In practice, the most common miss is assuming that if the registry page is clean, every copy is gone. That assumption breaks whenever a developer laptop, CI runner, or long-lived image retained the bad package.

How should teams decide whether the package ever executed?

Execution evidence matters because exposure severity changes once code has run. Search for runtime markers that show the package was imported, loaded, or invoked, including application logs, job history, telemetry from endpoint detection, and any instrumentation that records module loading or process ancestry. If you can show execution, you move from inventory exposure to confirmed compromise exposure.

When execution is uncertain, distinguish between “downloaded” and “run.” Downloaded artifacts can still be dangerous, but runtime evidence changes the response because it suggests possible credential access, data access, or secondary payload behavior. That is especially relevant for packages that were malicious at install time or that performed actions during build or import.

Teams should also look for indirect proof, such as a build pipeline that used a cached dependency, a container image that already includes the package layer, or a gateway host that imported the package as part of a plugin or extension workflow. Those paths often survive registry cleanup and are the reason retrospective scoping must go beyond registry records.

Risk and Threat Considerations

Registry cleanup can create a false sense of closure if teams stop searching after the public package disappears. The risk is residual exposure, because cached artifacts, immutable images, build systems, and endpoint copies can keep serving the compromised code long after the upstream record has been removed.

Failure mechanism: The attacker’s payload or tampered build is preserved in local caches, lockfile-pinned builds, mirrored artifacts, or runtime environments, then continues to execute or remain available even after the registry is remediated.

Impact: Teams may underestimate blast radius, miss affected hosts, and fail to rotate credentials or inspect downstream systems that handled the package before cleanup.

Practitioner Guidance

What to prioritise: Build the scoping workflow around evidence of presence and execution, not around registry status. Search from the package identifier outward into developer machines, CI runners, container images, artifact stores, and gateway hosts.

What to verify: Confirm the exact version, the install or fetch path, and whether the artifact was only downloaded or actually executed. If you cannot establish those three points, keep the scope open rather than closing it early.

Common mistake: Treating a cleaned registry entry as proof that remediation is complete. In supply-chain incidents, the durable evidence is usually on the consumer side, not the publisher side.

Practitioner takeaway: The registry tells you where the package started, but host-side traces tell you where it actually landed, and that is the basis for credible scoping.

Related resources from NHI Mgmt Group

• How should security teams respond when a trusted open-source package is compromised and starts stealing credentials?
• How should security teams detect compromised open-source maintainer accounts before malicious code lands in a package?
• What should organisations do when a critical open-source package is compromised?
• What should teams do after a malicious package is discovered in the registry?