A guessable cross-tenant report identifier or a critical parser memory bug — which gets the one remediation slot you can fund this quarter against commodity criminals?
answer
- severity rates impact, not reachability
- who can afford the conversion cost
- one slot may be a false choice
- name the assumption that would flip it
- public reliable attack collapses distance
basics
~20 sFund the identifier. It is usable on reading by every account holder, so a crew with no exploit-development budget can use it today, while converting the parser defect needs funded research they would have to buy. Severity ranks impact, not distance.
solid answer
~50 sTwo axes decide this, and the advisory rating only carries one of them. Impact says the parser defect could be worse *if* someone reaches execution; distance says the cross-tenant identifier is already a working attack for anyone with a login. Against commodity criminals with no exploit-development capability, distance dominates: they buy or reuse converted work and cannot fund conversion themselves, so the memory defect stays out of their reach until somebody else packages it. Then check the cost side, because "one slot" is often false — a vendor version bump is usually near-free and should just be scheduled, while removing an identifier-as-authority pattern is design work across an API and genuinely needs the slot. Finally, state the assumption you are betting on and what flips it: if a reliable public attack for the parser defect appears, its distance collapses and the ordering inverts.
code
text · 14 linesfinding A
class missing ownership decision, first-party code
access needed one ordinary account
vendor fix none exists - nothing to install
work to use change one identifier in a valid request
rating medium
finding B
class heap memory corruption, bundled document parser
access needed get a crafted file parsed
vendor fix version bump published
work to use controlled primitive, address leak, code reuse, sandbox escape, reliability
rating critical
...go deeper
Know that a severity rating describes how bad a flaw would be if used, not how easy it is to use. Those are separate questions and both belong in a decision.
Explain why a flaw needing no exploit is reachable by a far larger population than a memory defect, and what work stands between that memory defect and a working attack.
Show that you order remediation by distance to a working attack alongside impact, and that you can articulate the interim controls that reduce a zero-distance flaw before the real fix lands.
Own the budget argument: challenge the one-slot framing by comparing fix costs, tie the ordering to an explicit adversary-affordability assumption, and name the trigger that reverses it so the decision can be revisited without being re-litigated.
## Why this is a decision and not a lookup The severity attached to a finding answers "how bad if someone gets there". It does not answer "can anyone get there, and who". Ranking a remediation budget on severity alone silently assumes both classes are equally reachable, and they are not — that assumption is the entire content of the disagreement you are about to have with whoever ranked the list. ## The two findings as classes **The report identifier.** First-party code serves a tenant-scoped export to any authenticated caller who names the identifier. Distance to a working attack: zero. Population who can use it: everyone who can create an account. Cost per use: nothing. Version dependence: none. There is no advisory, no version number and no vendor fix — the fix is design work you author. **The parser defect.** A memory-corruption bug in a bundled component, rated critical by the vendor. Distance to a working attack: a controlled primitive, an information leak to defeat address randomisation, code reuse to get past non-executable data pages, a plausible sandbox escape, then reliability across builds. Population who can use it *today*: people funded to do exploit development, or anyone who can buy their output. Cost to convert: a research project with an uncertain outcome. ## What naming the adversary class actually predicts Commodity criminal crews are not defined by incompetence; they are defined by **economics**. Their model is volume against many targets at low cost per target, which means they reuse what already works and do not finance uncertain research against one product. So a flaw usable on reading is not merely available to them — it is close to the whole of their accessible market, and it is available at the moment it is described. The parser defect is priced out of their reach unless somebody else converts and packages it, at which point it is no longer the same decision. This is the concrete answer to "what does naming an adversary class buy you": it is a claim about what they can *afford*, and affordability maps onto weakness class more cleanly than onto severity. ## The wrong answer, stated plainly The common senior answer ranks the memory defect first because it *sounds* harder, and treats the missing check as unserious because "nothing is technically broken". That reasoning has the axis backwards. Difficulty of the underlying bug is a measure of the **attacker's cost**, and a high attacker cost is protection, not danger. The flaw that requires no skill is the one that has already been weaponised by the act of being described. ## The cost side, which is where the principal answer lives Before accepting the framing, challenge it. "One remediation slot" bundles two very different fixes: - The parser defect is typically a dependency version bump: hours of work plus a regression test cycle. It rarely deserves a slot at all — it deserves a schedule. - The identifier pattern is an API design change: a tenancy decision at every read path, a migration for existing references, and coordination with any customer integration that already holds those identifiers. That is the item that genuinely consumes a quarter. So the defensible plan is usually "bump the component through normal maintenance, spend the slot on the authorization design" — and being able to say that, rather than choosing between two items as offered, is what separates the answer from a coin flip. ## Making the call defensible to the person who ranked it Write down three things and you can survive the disagreement: 1. **The assumption**: no reliable public attack exists for the parser defect, and our expected adversaries cannot fund one. 2. **The trigger that flips it**: a public, reliable, packaged attack for that defect, or intelligence that a funded actor is targeting this product. At that moment the parser defect's distance collapses and it goes first. 3. **The interim**: what reduces exposure to the identifier flaw before the design work lands — rate limits on the export path, tenancy scoping at the gateway, or turning the feature off for tenants who do not use it. A partial control on a zero-distance flaw usually beats a complete fix on a long-distance one. ## The trap on the other side Do not convert this into a rule that logic flaws always outrank memory defects. The moment a memory defect has a public, reliable attack, its distance is zero too, and every organisation is now equally reachable regardless of adversary funding. The durable principle is not a ranking of classes; it is that **you rank by distance and by who can afford it, and you re-rank when either changes**.
- What would change your ordering within a week of making it?A public, reliable and packaged attack for the parser defect. That collapses its distance to zero and puts it inside the budget of exactly the crews you named, so it goes first regardless of the original severity argument. Intelligence that a funded actor is working against this specific product does the same thing for a different reason.
- The finding owner insists the critical rating must be honoured. How do you close that out?Agree that the rating is right about impact and say what it cannot express: whether anyone in your threat model can reach it this quarter. Then remove the conflict by refusing the false choice — schedule the version bump through routine maintenance, which costs almost nothing, and spend the design slot on the tenancy decision. Record the assumption and its trigger so the call can be revisited rather than re-argued.
- Is there anything you can do about the identifier flaw before the design work lands?Usually yes, and partial mitigation of a zero-distance flaw often beats a complete fix elsewhere: enforce tenancy scoping at a single gateway or shared filter ahead of the endpoint, cap the export rate per account so enumeration is slow, or disable the export for tenants who never use it. None is the real fix, but each raises a cost that is currently zero.
saying these in an interview costs you the question
- Ranks the memory defect first because it sounds technically harder
- Treats the vendor severity rating as the whole decision
- Accepts the one-slot framing without comparing fix costs
- Names an adversary class without saying what it predicts
- States no trigger that would reverse the ordering