Malicious Dependency Response

## What this question is really testing When a malicious version of a package reaches your dependency graph, the instinct is to treat it as a bad dependency: remove it, resolve something clean, commit the lockfile, move on. That instinct is wrong in one specific way, and this question exists to find out whether you know which way. ## Installing is executing Installing a dependency is not the same as copying a file into a folder. Across mainstream ecosystems — npm, PyPI, RubyGems, and build-plugin ecosystems on the JVM — resolving and installing a package can execute publisher-supplied code on the host doing the install, and even where it does not, the unpacked artifact is immediately compiled, loaded or executed by the next build step. The working assumption for a response is therefore blunt: **if a machine resolved and installed the malicious version, attacker-controlled code ran there with the privileges of whoever ran the install.** That is not a dependency defect. That is code execution on your build hosts and your engineers' laptops. This is also why the usual triage vocabulary does not apply. Reachability — whether your application actually calls the vulnerable function — is the right question for a vulnerable dependency, because a flaw that is never called cannot be exercised. It is the wrong question for a malicious dependency, because the code did not wait to be called. "We never import that package" is not a defence. ## What removal actually changes A lockfile is a statement about what a future resolution should produce. Reverting it makes the *next* install clean. It does not touch: - **Credentials** that were readable from the affected environments: environment variables injected into the job, files in the workspace, credential files in a developer's home directory, and any ambient role or token the runner could assume. - **Artifacts** already produced on those machines. An image built on a hostile runner is suspect even if the malicious package does not appear anywhere in that image's own dependency list — the build environment, not the dependency list, was the problem. - **Actions already taken** with anything that was stolen: artifacts published, keys or users created, webhooks or automation added. ## The order that shows you understand it 1. **Scope the environments.** Which laptops, runners and build hosts resolved the bad version inside the exposure window. 2. **Cut re-entry first.** Revoke or rotate anything that grants deploy, publish or signing power before anything else — otherwise you clean a system an attacker can immediately re-poison. 3. **Rotate the rest**, ranked by what the credential reaches. 4. **Rebuild** artifacts produced on affected machines during the window, on a host you trust. 5. **Then** fix the dependency — remove, pin or roll forward — and only then redeploy. Notice that the dependency fix, which is where the naive answer starts, is step five. ## Wrong answers worth recognising - *"The registry yanked the version."* A yank stops new installs. It un-runs nothing, and it does not tell you who already pulled it. - *"We rolled back the deploy."* Rollback restores the running version of your service. It does not rotate a token that left the building an hour ago. - *"Only CI installed it, and CI is ephemeral."* Ephemeral runners limit persistence on the host; they do not limit what a job could read while it was alive. A short-lived token still had full authority during its life. - *"The payload only read environment variables."* Analysis of the published payload is useful for *prioritising* rotation, not for skipping it — and what you fetched for analysis is not necessarily what was served to every consumer. ## A worked framing A nightly ETL job pulled a malicious version of one of its dependencies. The job is unglamorous — it moves rows — but it holds a credential with write access to the production ledger. The blast radius here is not customer personal data; it is money and audit truth. The response is the same shape: assume the credential is gone, rotate it, and then go read the ledger's own change history for the window, because rotating the credential does not undo a write it already made. ## What a strong answer sounds like "Assume every environment that installed it during the window ran attacker code. Rotate everything readable from those environments, starting with anything that can deploy or publish. Rebuild artifacts they produced. Fix the dependency last, and verify by rebuilding from a clean host — not by looking at the lockfile."