After a malicious dependency version lands, do you freeze the lockfile, pin around it, or roll forward?

## Three moves, three different jobs Candidates who treat this as "pick one" miss that the options operate on different things and different clocks. The strong answer sequences them by cost and reversibility. | Move | Stops | Costs you | Time to undo | | --- | --- | --- | --- | | Freeze resolution | further drift into the bad version | blocks legitimate patches; fixes nothing deployed | minutes | | Pin or override the package | the bad version specifically | keeps you on the same publisher; the pin rots | minutes to hours | | Roll forward to a trusted version | the exposure, durably | needs a version you can justify; drags other changes | a release cycle | ## Freeze: buy time, then give it back Freezing means locking resolution where it is — no new resolutions, no automated updates — across the affected repositories, and often just for the affected ecosystem rather than everything. Its virtue is that it is nearly free and undone in a commit, so it is the right first move while your scope is still uncertain: it prevents the embarrassing case where a repository that was clean at 09:00 resolves the bad version at 09:40 because someone triggered a build. Its costs are real. A freeze also stops security updates arriving, so a long freeze quietly converts one incident into a growing patch backlog. And it is a control on future resolution only: nothing in a freeze touches an artifact already built or a credential already read. Give every freeze an owner and an expiry at the moment you declare it, or it becomes permanent by neglect. ## Pin or override: surgical and fast, but it ages Pinning the specific transitive package to a known-good version — or declaring an override that forces resolution away from the malicious release — is the smallest change that removes the bad code from your graph, and it ships without waiting for anyone upstream. That is why it is usually the interim answer. What it does not do: it leaves you consuming other releases from a publisher whose account or release process you have just decided you cannot trust, and it plants a constraint that will silently conflict with legitimate upgrades months later, long after everyone has forgotten why it is there. Record the reason next to the pin and put a review date on it. ## Roll forward: the durable answer, and the trap inside it Rolling forward to a clean release is where you want to end up. The trap is the word "clean". A fix release published minutes after the incident **from the same publishing identity that was compromised** carries exactly the assurance that identity now has, which is none. "Upgrade to latest" is not a remediation argument. What justifies trust is one of: a version published before the compromise window (last-known-good) that you pin by digest or content hash; a release whose provenance shows it was built by a builder you accept, from the source you expect; or a version you have reviewed or rebuilt yourself. Absent one of those, roll *back* to before the window rather than forward into it. Rolling forward also drags whatever else changed between your version and the target, which is why it is rarely the first-hour move on a large estate — the regression surface is unbounded at exactly the moment you have no spare attention. ## The decision rule Ask which choice is cheapest to undo if your current understanding turns out wrong, because during the first hour it frequently is. That ordering falls out as freeze, then pin, then roll forward — and it survives the discovery, two hours in, that the exposure window was longer than you thought. ## A worked case A malicious version of a transitive dependency reaches a nightly ETL job that writes to the production ledger. Freezing costs nothing here — the job's dependency set does not need to move today — and it prevents tonight's run from re-resolving. A pin ships in one change and lets the job run. But the durable question is whether the publisher's later releases can be trusted at all; if not, the roll-forward is not an upgrade, it is a replacement of the dependency, and that is a planned piece of work rather than an incident action. Meanwhile neither the freeze nor the pin touches what already happened to the ledger's credential or to any rows written during the window — those are separate workstreams. ## The step everyone forgets None of the three is applied to production by merging a change. The artifact carrying the fix must be **rebuilt on a host you trust and redeployed**, and every already-built artifact from the window has to be rebuilt too. A response that ends at a green pull request has fixed the repository, not the estate.