Blocked Upgrade Paths

## What a blocked upgrade path is Most vulnerability findings are boring to fix: an advisory names a package and a fixed version, you bump the version you declare, the finding clears. A **blocked upgrade path** is the case where that does not work. The flagged package is *transitive* — you never named it. It is present because something you did name requires it, and the version that ends up installed is chosen by that intermediate's declared constraint, not by your intent. So there are two different sentences that sound the same and are not: - "No fix exists" — the maintainer has published nothing, the project is dead, the flaw is unpatched. - "A fix exists and my graph will not take it" — the patched release is sitting in the registry, and something between you and it refuses to allow it. This question is about the second one, and the distinction matters because the responses are completely different. ## Why your own manifest is not the last word Every ecosystem resolves a graph, not a list. Your project declares a handful of direct requirements; each of those declares its own, and so on. When a package appears on more than one path, the build tool has to pick one version, and the constraints along those paths are inputs to that choice. If the only path to the flagged package runs through a library that says "I need exactly `2.4.1`", then `2.4.1` is what the resolver is being told to honour. An exact pin is the sharpest version of this — one `==` in someone else's metadata can hold an entire estate one patch release below a fix. Ranges block too, just more quietly: an upper bound like `<3` blocks a fix that first shipped in `3.0.1`, and a fix backported only to a newer minor is out of reach for anyone stuck on the old one. ## The four exits, and what each costs **1. Wait for the intermediate to release.** The cleanest outcome and often the fastest one, if a release is days away. Cost: you are carrying a known finding, and "the maintainer said soon" is not a plan you can hand an auditor without a date. **2. Override the resolved version.** Most ecosystems offer some facility to say "whatever the graph asks for, install this" — a replace directive, an overrides block, a constraints file. Cost: you are now running the intermediate library against a version of its own dependency that it never declared and never tested against. If the delta is a patch release this is usually safe; if it crosses a major version, you have swapped a security finding for a possible runtime failure, and the failure can be silent until a rarely used code path executes. **3. Exclude the vulnerable package and declare the fixed one directly.** Functionally similar to an override, but it also makes you the declaring owner of that package, which is useful — the dependency is now visible in your manifest rather than buried. Cost: the same compatibility gamble, plus a durability problem, because an exclusion is written against a coordinate and a path and both can change under you. **4. Open a pull request upstream.** The only exit that fixes the cause rather than your copy of the symptom, and the only one that helps everyone else stuck behind the same constraint. Cost: latency you do not control. These are not mutually exclusive, and the mature answer usually pairs the last one with one of the first three: ship an override now with an expiry, land the upstream change so you can delete it later. ## What a green scan actually proves After any of these, the scanner going quiet proves one thing only: the artifact it read no longer lists the vulnerable version. It does not prove the patched code is what loads. Confirm the fix by looking at the resolved graph or lockfile the build actually produced, and by scanning the built artifact rather than only the manifest — an override that failed to apply, a second path you did not exclude, or a vendored copy inside another package all produce a green manifest and a vulnerable runtime. ## The framing that reads as senior A candidate who says "just add it to the manifest" has not met a real graph. A candidate who says "we would have to fork it" has jumped past three cheaper options. The answer interviewers want names the blocker precisely — *which* dependency's *which* constraint holds the version down — and then picks an exit with its cost stated out loud.