What does mitigating a vulnerable dependency in place mean, and when do you do it instead of patching?

## Two different words that get used as one **Remediation** changes what is installed: the vulnerable version of the component is replaced with one that does not contain the flaw. **Mitigation** leaves the vulnerable code exactly where it is and removes the attacker's route to it. Both reduce risk; only one of them makes the finding go away. Emergency response almost always uses mitigation first, because mitigation is usually a configuration change that takes minutes, while remediation is a build, a test cycle and a rollout. A vulnerability is the flaw in the code. An exploit is a working attack against it. Mitigation does not touch the flaw at all — it makes the exploit unable to reach it. ## The three families of in-place mitigation **1. Turn the vulnerable code path off.** Many advisories affect an optional feature: a parser for a format you do not use, a protocol handler, a template expansion, a deserialization mode. If the library exposes a flag that disables it, that is the cheapest mitigation available, because it does not require you to reason about where the input comes from. **2. Take the input away.** If the vulnerable path only fires on a particular kind of untrusted input, reject that input in front of the component — at the edge, in a validating layer, or by disabling the endpoint that accepts it. This is more fragile than a flag: you have to be right about every route into the code, and you may be wrong. **3. Take the network path away.** Many high-severity dependency flaws are only useful to an attacker if the compromised process can then reach something — an outbound callback, a lateral connection, a secrets endpoint. A default-deny egress rule on the affected workloads, or an access-control rule on the broker or service in front of them, breaks the exploit chain without touching the application. On a shared-runtime platform where you do not control the host, this is often the only lever you have. ## Choosing between them under time pressure Prefer the mitigation whose correctness is easiest to *check*, not the one that feels strongest. A configuration flag either appears in the running process's effective configuration or it does not. An input filter depends on you having enumerated every path, which under incident pressure you have not. Rank the candidates by how quickly you can produce evidence the mitigation is live everywhere. A worked shape: a warehouse robot fleet runs a controller firmware that embeds a vulnerable message-broker client. Patched firmware exists, but over-the-air rollout across a fleet takes days because robots only update between shifts and a half-updated fleet is an operational hazard. The mitigation is server-side: an access-control rule on the broker that refuses the topic patterns the exploit needs, applied in one place, verifiable in one place, effective for every robot immediately. The asset being defended here is not customer data — it is the safety of a physical process — and the attacker position it assumes is someone who can already speak to the broker on the local network. Both of those shape which mitigation is worth anything. ## What a mitigation is not - **It is not closure.** The vulnerable code is still in the artifact. A flag can be flipped back, dropped by a later configuration refactor, or missed on a newly provisioned instance. Every mitigation needs an owner and a tracked expiry that ends with the real upgrade. - **It is not invisible to your scanner.** The component and version are unchanged, so tooling will keep reporting the finding. That is correct behaviour, not noise; if you want the tooling to reflect your analysis you need a separate, deliberate statement of status, which is its own discipline. - **It does not travel downstream.** If you publish an artifact — an image, a library, a firmware bundle — your consumers get the vulnerable component and none of your compensating configuration. A mitigation protects your deployment, not your customers' deployments of your product. - **It is not a substitute for knowing whether you were exposed before you applied it.** Mitigating forward does nothing about the window that already passed. ## Writing it down while you do it Record, at the time: what you disabled or blocked, on which workloads, who approved it, what the mitigation is expected to prevent, and what evidence shows it live. That record is what lets you answer, after the incident, the two questions that actually matter — were we exposed, and for how long — and it is what a post-incident review and any customer notification rest on. A mitigation nobody wrote down is indistinguishable, a week later, from a mitigation nobody applied.