The owner will fund one: rewriting the memory-unsafe parser, or another year of exploit mitigations. How do you frame the choice?

## The framing to refuse The question will arrive as *are we safe*. Answering it in those terms loses either way: yes is false, and no sounds like the mitigations were wasted. The truthful frame is price. Every mitigation on this surface - randomised layout, non-executable data pages, stack guards, control-flow constraints - removes one link of an exploit chain and forces the attacker to buy a replacement. The chain remains constructible. What changes is what it costs, and cost is what decides *who* can still run it. So the sentence to put in front of an owner is: with the current mitigations, exploiting this defect class requires an additional memory-disclosure defect and a purpose-built chain, which is roughly a month of a competent specialist. That is a number the owner can reason about against the adversary they believe they have. ## What each option actually buys **Another year of mitigations.** - Estate-wide. One build configuration and a deployment change protect every service that shares the toolchain, not just this parser. - Cheap per unit and fast to land. - Prices out the population that reuses published exploits unmodified - which is most of the volume most estates ever see. - Does not remove the class. The next parsing defect arrives at the same price, and the year is bought again. - Priced by deployment, not by flags. If workers are copies of one parent rather than fresh loads, retries are free to the attacker and the mitigations are worth materially less than the datasheet implies. Fixing that is a small change with a real effect, and it belongs in this proposal rather than in the rewrite. **Rewriting the parsing surface in a memory-safe language.** - Removes the class for that component, permanently, for every future defect in it. - Costs engineering time and calendar, and the estimate is usually wrong in the familiar direction. - Imports different risk. New code carries new logic defects, the interface between the safe component and the rest of the process is a new surface, and any period of running two implementations invites disagreement over inputs. - Is not all-or-nothing, and this is the part the owner will not have been offered. The untrusted-input parsing surface is typically a small, well-specified fraction of the daemon and the fraction that touches attacker-controlled bytes first. Porting only that, and leaving the rest, gets most of the benefit for a fraction of the cost. ## The third option to put on the table Both of the above reduce the *likelihood* of a successful exploit. Neither reduces what the attacker gets when one succeeds. Running the parsing component as a separate low-privilege process behind a narrow interface changes the outcome of a win rather than its probability: a compromised parser holds no credential, opens no connection, and reaches nothing worth having. It is often cheaper than a rewrite and it composes with either choice. Denying that process the ability to make pages executable is a related, smaller move in the same direction. An architect who presents only the two options that were offered has failed the owner. ## How to decide Facts that settle it, in rough order of weight: - **Remaining service life.** A daemon with five years ahead of it amortises a rewrite. One being retired in eighteen months should buy the year and spend the engineering on the replacement. - **Reachability.** Unauthenticated exposure to arbitrary senders is a different risk from a surface behind an authenticated boundary, because it changes how many adversaries can even attempt it. - **Defect history.** A component that has produced memory-safety defects repeatedly will produce more; that history is the best available evidence that mitigation is a recurring cost rather than a one-off. - **Adversary in scope.** If the organisation has decided it defends against opportunistic use of public exploits, mitigations plus fresh worker creation meet that bar honestly. If a funded operator is in scope, a month of their time is not a deterrent and the class has to go. ## What to commit to in writing Never *this is now safe*. Commit to statements that survive being wrong: this class is removed from component X; for the remaining components the class is present and priced at roughly this much work; here is the retry cost per attempt after the worker-creation change; here is the date the rest is scheduled. An owner who is told a price can revisit the decision when the price changes. An owner who is told *safe* will find out otherwise from somebody else.