Which supported release lines get the security backport, and how do you decide?

## The decision is mostly made in advance The question sounds like an incident-time judgment call, and partly it is — but a maintainer who first asks "which lines do we support?" while an embargo clock runs has already lost. **A written support policy, published before any of this, is the instrument that makes the decision defensible**: which release lines are maintained, what each receives (security fixes only, or fixes generally), and when each reaches end of life. Without one, every backport decision looks arbitrary to the customer who did not get one, and every exception you make becomes the new expectation. With a policy in place, the incident-time work is narrowing and exception handling rather than invention. ## Narrowing by evidence, line by line For each supported line, four questions: 1. **Does the flaw exist here?** Lines diverge. The vulnerable function may postdate an older line, or an intervening refactor may have removed the pattern. Verify rather than assume — in both directions, since the assumption that an old line is *not* affected has caused as much harm as the reverse. 2. **Is the vulnerable code reachable?** A flaw in code that no supported configuration of that line can invoke is a different priority from one on the default path. Reachability is about whether the vulnerable code can be executed at all in that build; it is not the same as an attacker being able to reach it in a deployment, and both matter. 3. **Can it be patched safely here?** Sometimes the clean fix depends on an API introduced later, and backporting means either a behavioural change consumers did not sign up for, or a more invasive rewrite reviewed by very few eyes under time pressure. 4. **Can this line's consumers act on it?** This is the question teams skip, and it is often the one that matters most. ## When the fix arrives faster than the consumer can move Consider an embedded SDK with four supported lines. Two are used by ordinary integrators who can rebuild and ship quickly. The other two are used almost exclusively by customers whose firmware must be re-certified before it can be deployed — a process measured in weeks or months, and one that cannot be compressed because the flaw is urgent. For those two lines, a backport delivered on disclosure day protects nobody on disclosure day. That does not make it worthless — it starts their clock, and they need it eventually — but it changes what you owe them *most*. What actually helps is something applicable without re-certification: a configuration that disables the affected feature, a deployment-level control, guidance on detecting exploitation, or a statement precise enough that they can judge whether their product is exposed at all. Note also what is at stake here: not customer records, but the safety and availability of deployed devices, and a device bricked by a hurried patch is a worse outcome than the flaw the patch closes. The general principle: **the value of a backport is the exposure it actually removes, not the number of lines you can list as fixed.** ## Capacity is real and unusually tight Backporting under embargo is not the same work as backporting normally. The circle of people allowed to see the patch is small by design, which means review, build and test capacity for every line is drawn from that same few. Four backports, four build matrices, four sets of integration tests, one weekend, three cleared engineers — this is where quality collapses quietly. An untested backport shipped to hit a date is a real risk you are choosing to take, and it should be a decision someone makes deliberately rather than a side effect of an ambitious scope. Staging is legitimate: ship the lines you can test properly on the disclosure date, and be explicit that another line's fix follows on a stated date. Honesty about a gap is far better than an unverified patch. ## Lines you decide not to fix An unsupported or out-of-scope line that is nonetheless affected still needs a statement. Silence gets read as "not affected", which is the one interpretation that harms users. Say plainly that the line is affected, that no fix is coming, and what the alternatives are — upgrade path, mitigation, or migration. That is an obligation you carry as the upstream regardless of what your policy says about maintenance. The hardest version of this is the unsupported line carrying most of your installed base. Two defensible options exist and one indefensible one. You can make a one-off exception, stating explicitly that it is the last, and pair it with a migration plan. You can hold the policy and invest in making migration genuinely achievable. What you cannot do is hold the line silently and let those users believe they are safe. ## Afterwards Every incident tells you whether the support matrix matches reality. If most of your users are on a line you had declared unsupported, the policy is fiction and the fix is to change the policy or change the adoption — before the next report arrives.