How do you assign a bug bar severity to a modeled threat that has no proof of concept?
answer
- two different uncertainties, not one
- consequence goes in the bar
- existence goes in a spike
- unproven is not unlikely
- record the assumption you rated on
basics
~20 sBand the threat on the worst credible consequence if it is real, using the bar's flaw-class rows. Absence of a working exploit is not evidence of low severity; genuine doubt about whether the flaw exists becomes a time-boxed verification task, not a downgrade.
solid answer
~50 sBug bars were mostly written for defects someone can reproduce, and a design-time threat has nothing to attach. The move is to separate two uncertainties. The first is *what happens if this threat is real* — a consequence question, answered by matching the threat to the bar's flaw-class row, and it needs no exploit. The second is *whether the design actually has this flaw* — a verification question, whose right output is a time-boxed spike with an owner and a deadline, not a rating of Low. The failure I look for is a threat model whose entire output is Low because nobody demonstrated anything; that is unproven being silently recoded as unlikely, and it destroys the credibility of the exercise. What legitimately moves the band is a control actually present and actually covering the path.
go deeper
Remember the core rule: rate the threat on what happens if it is real, not on whether anyone has demonstrated it. "We have no exploit" is not a reason to call something Low.
Be able to explain the two uncertainties — the consequence if the threat is real, and whether the design permits it — and say which one the bar answers and which one becomes a verification task with a deadline.
Show the operating habits: band in the session against the bar, write the assumption next to the rating so it is falsifiable, give unknowns a time-boxed owner, and notice when a session's output is all Lows because unproven was recoded as unlikely.
Own the systemic version: if unverified findings routinely settle at the bottom band, the bar or the process has an incentive defect. Decide who arbitrates disputed existence claims and how you keep design-time ratings comparable with ratings from testing.
## The mismatch A bug bar is usually written with reproducible defects in mind: someone has a crash, a request that returns another user's record, a log line with a token in it. A threat model produces something different — a claim about what an attacker could do to a design that may not even be built yet. There is no repro, no ticket with steps, sometimes no code. Teams handle this badly in a predictable way: everything the modelling session produced becomes Low or Informational, because "we haven't proven it". ## Separate the two uncertainties The discipline that fixes it is to notice that two very different questions are being smeared together. **Question one: if this threat is real, what is the worst credible outcome?** This is a consequence question. It is answered by matching the threat's shape to a row in the bar — the row is written in terms of what an attacker achieves, and the threat statement already tells you that. No exploit is required to answer it, and the answer does not change when someone later writes one. **Question two: does the design actually permit it?** This is a verification question. It has three honest outcomes: confirmed (band stands, clock starts), refuted with evidence (close it, and record the evidence so the next reviewer does not re-raise it), or unknown. "Unknown" is the interesting case, and the correct product of unknown is a **time-boxed verification task with a named owner and a due date** — read the code path, write the test, ask the service owner. It is not a lower band. Collapsing question two into question one is the classic error, and it always collapses downward, because the person who would have to fix it is the person best placed to say "well, we don't know that it's exploitable". ## Worked example A ride-hail company runs a driver-payout service. A modelling session on the settlement flow raises a tampering threat: the payout amount for a completed trip is recalculated from a trip summary that the driver's own app supplies, and the service trusts the distance and surge fields in that summary. Nobody has written an exploit. The asset is money, the attacker position is an authenticated low-privilege user — a driver with a legitimate account. Banding it: - Match to the row, not to the evidence. If the bar's High row includes "an authenticated user can alter financial records that drive settlement", the threat is High on the day it is modelled. - State the worst credible loss, not the worst imaginable one: repeated small inflations across many trips and many colluding accounts, which is a fraud and reconciliation problem, rather than "the attacker drains the treasury". - Write the assumption you banded on: *assumes the client-supplied summary is not re-derived server-side from telemetry the driver cannot influence*. That single line is what makes the rating auditable and what makes it cheap to overturn. - If the assumption turns out to be wrong — the service does re-derive the amount from trusted telemetry and only uses the client summary for display — the band drops because the **flaw class changed**, not because nobody exploited it. ## What legitimately moves a band, and what does not | Moves the band | Does not move the band | |---|---| | A control that is present and demonstrably covers the path | "No one has written a proof of concept" | | The attacker position turning out to be unreachable in the deployed topology | "That would be hard to pull off" | | The asset being something the bar rates lower than assumed | "It has never happened to us" | | The flaw class being different from the one first stated | "The team is busy this quarter" | Everything in the right-hand column is an argument about likelihood or effort dressed up as an argument about severity. Some of it may be worth discussing separately; none of it changes which row of the bar the threat lands in. ## Practical habits - **Band at the session, not later.** Rating in the room, against the bar, while the design is fresh, is far cheaper than a triage meeting a month on — and it stops the rating from being set by whoever is most invested in the answer. - **Record the assumption with the rating.** A band plus a one-line assumption is a falsifiable claim; a band alone is an opinion. - **Give verification a deadline.** An unverified High with a two-week spike attached is honest. An unverified High with no owner becomes a permanent argument. - **Watch the distribution.** If a session's output is fifteen Lows, the bar is not being applied — unproven has been recoded as unlikely somewhere in the process. ## The interview signal Interviewers ask this because it separates people who have run modelling sessions from people who have read about them. The strong answer names the two uncertainties, puts consequence in the bar and existence in a spike, and says plainly that "we haven't proven it" is not a severity argument.
- A team argues the threat should be Low because exploiting it would be difficult. How do you answer?Difficulty is an argument about likelihood or attacker effort, not about which flaw class the threat belongs to, and the bar's rows are written in terms of what the attacker achieves. I would keep the band, capture the difficulty claim as an explicit assumption next to the rating, and treat it as something to verify. If the bar genuinely has no room for effort anywhere, that is a change to propose to the bar, not to this finding.
- What do you do with a threat where the team disputes that the flaw exists at all?Book a time-boxed verification with a named owner: read the path, write the test, ask the service owner. Three outcomes are acceptable — confirmed, so the clock starts; refuted with evidence, so it closes and the evidence is recorded to stop it being re-raised; or still unknown at the deadline, which escalates rather than expires. What is not acceptable is leaving it rated Low because the question was never answered.
- Does a mitigating control that is already implemented change the bug bar band?Yes, when it demonstrably covers the path, because it changes what an attacker actually achieves and therefore which row applies. The test is whether you can point at the control and the path it closes. A control that exists somewhere in the system, or is planned, or covers a similar-looking route, does not move the band — that is an assumption, and it belongs in writing next to the rating so it can be checked.
saying these in an interview costs you the question
- Rates every unproven threat Low because there is no exploit yet
- Treats absence of a proof of concept as evidence of low likelihood
- Waits for a working exploit before assigning any band at all
- Downgrades because a control is planned rather than implemented
- Records a band with no assumption, so nobody can challenge it later
- Leaves disputed threats unresolved instead of booking a time-boxed check