Your threat model readout goes to a risk committee: why is a CVSS score a poor headline, and what replaces it?
answer
- scores rank, they do not decide
- name the actor and the asset
- cost stated in their units
- the rating belongs in the appendix
- leave with a decision, not applause
basics
~20 sA CVSS score describes technical severity, not what the business loses. Lead each threat with a scenario: who does what, to whose money or data, and what it costs. Use the score only to rank items against each other.
solid answer
~50 sA score is a comparison device, not a decision input. A risk committee cannot act on `7.6`; it can act on "one adviser can reassign another adviser's clients, and the fee stream that follows them, and the audit trail records the change as if the owning adviser made it". So I give each top threat four lines: the scenario in the committee's own language, who the attacker is (here an insider or a rival adviser on the same platform, not an anonymous outsider), what it costs if it happens, and what the fix or the acceptance costs. The rating stays in the appendix for anyone who wants the method. I close with an explicit decision ask per threat - mitigate, redesign, transfer or accept - and the names I need on each, because a readout that ends in "any questions?" produces no decision at all.
go deeper
Be ready to say what a threat model readout is for: turning a rated list of design-time threats into decisions someone owns. Know that a severity score ranks items against each other and does not by itself say what the business loses.
Explain the translation. An interviewer expects you to turn a finding like elevation of privilege in a service into a sentence about who can do what to whose money or data, and to say why a base severity score is environment-free and so cannot carry a cost figure.
Show you have run one. Expect to give the per-threat structure, an explicit attacker position, a cost stated in the audience's units, and a closing decision ask with named owners and dates - plus what you cut to fit ten minutes.
Own the framing across many models: which threats reach a committee at all, what standing format keeps ratings comparable from one briefing to the next, and how you stop a decision forum from degrading into a status update nobody acts on.
## What a readout is actually for A threat model produces a list of things that could go wrong in a design, each with a rating. That list is an engineering artifact. A risk committee - executives, a finance owner, legal counsel, sometimes an external member - is not there to review engineering artifacts. It is there to make one of four calls on each item: fund a fix, change the product so the threat stops existing, move the loss to someone else by contract or insurance, or accept the exposure. **The readout exists to make one of those four possible for every threat you bring.** Anything on the slide that does not serve a decision is decoration. This is the difference between reporting and briefing: reporting says what you found, briefing hands a decision to the person with the budget to make it. ## Why the score cannot lead A CVSS base score rates the intrinsic characteristics of a weakness: how it is reached (attack vector), how hard exploitation is, what privileges and user interaction are needed, whether impact crosses a scope boundary, and the impact on confidentiality, integrity and availability. It is **deliberately environment-free**. The separate environmental metric group is what lets a consumer re-weight a base score for their own deployment and their own security requirements, and the threat/temporal group is what accounts for exploit maturity. So the number you inherited says nothing about your data, your compensating controls, or what a loss costs you. Two systems can carry the same base score and differ by an order of magnitude in consequence. DREAD has the mirror problem in the other direction. Its five dimensions - damage, reproducibility, exploitability, affected users and discoverability - are scored subjectively and combined, so the resulting number looks precise while encoding one engineer's guesses. Discoverability in particular rewards obscurity, which is why many teams drop or fix that dimension. Either way the output is **ordinal**. It tells you this threat ranks above that one. "Is a 7.6 bad?" is not answerable in the committee's frame, and a briefing that leads with the number invites exactly that question and then stalls on it. ## The translation The move is from a statement about a component to a statement about a person doing something to an asset. Take a wealth-advisory platform where advisers each own a book of clients and earn fees from it. The model says: > Elevation of privilege on the book-of-business service: the client-reassignment endpoint authorises on the adviser identifier in the request body rather than on the caller's session. The committee sentence is: > One adviser - or anyone using an adviser's session - can move another adviser's clients, and the fee stream attached to them, onto their own book. Our records will show the change as though the owning adviser made it, so a disputed transfer cannot be resolved from our own audit trail. Four lines carry it: 1. **Scenario** - the sentence above, in their vocabulary. 2. **Who** - an insider or a rival tenant on the same platform, not an anonymous internet attacker. Naming the actor changes both the plausibility and which controls are relevant. 3. **What it costs if it happens** - books to unwind and prove, adviser and client attrition, a segregation failure a regulator would care about, and disputes you cannot settle from your own records. 4. **What the response costs** - engineering effort and lead time for the fix, or the residual exposure if it is accepted. A compact mapping helps when several threats land at once. Each STRIDE category violates one security property, and each property has a plain business reading: | Model statement | Property violated | What the committee hears | | --- | --- | --- | | Spoofing at the API edge | Authentication | Someone can act as one of our customers | | Tampering with a ledger write | Integrity | A number we bill from can be changed silently | | Repudiation on the transfer path | Non-repudiation | We cannot prove who made a change | | Information disclosure in an export | Confidentiality | One client's holdings are visible to another | | Denial of service on quoting | Availability | The platform is unusable during market hours | | Elevation of privilege in the book service | Authorization | One adviser can take another's clients and fees | ## Shape of the ten minutes One slide of context: what was modeled, what was in scope, when it was last refreshed. Then **three to five threats, one slide each**, in the four-line form. Then a decision slide that names, per threat, the proposed treatment, the person you need to own it, and a date. Method, full rated list and vector strings go in an appendix - present, auditable, not on the critical path of the conversation. The audience also shapes what leaves the room. Internal leadership can see everything. A customer's security reviewer during procurement gets the conclusions, the control coverage and the residual risks they inherit, not the data-flow diagram and not the unmitigated specifics - that is both a map for an attacker and your own design IP. ## The failure modes Score theatre, where the slide is a table of numbers and the meeting becomes a debate about the numbers. Everything marked critical, which is the same as nothing being ranked. Invented likelihood percentages, which cost you credibility the moment someone asks how you derived them. Assuming an anonymous outsider when the real actor is an insider or a partner. And the most common one: finishing on time, being thanked, and leaving with no decision, no owner and no date.
- The committee asks whether a 7.6 CVSS base score is bad. How do you answer?I say the base score is deliberately environment-free: it rates the flaw's intrinsic characteristics, not our deployment, our data sensitivity or our compensating controls. Two systems can share a 7.6 and differ enormously in what a loss costs. So 7.6 tells us this item ranks above our 5.x ones and below our 9.x ones, and nothing more. The cost line on the slide is the thing to decide on.
- How does the readout change when the audience is a customer's security reviewer during procurement rather than your own leadership?The conclusions travel; the architecture does not. I share that a model exists, when it was last refreshed, which threat categories were considered, the control coverage and the residual risks the customer inherits - enough for their own risk decision. I do not hand over the data-flow diagram, internal component names or unmitigated specifics, because that is both a map for an attacker and our design IP. Anything deeper goes under an agreement and in summary form.
- What do you want to walk out of the room with?Named decisions, not agreement. Per threat: a treatment choice, a person who owns it, and a date. Anything the committee defers I want recorded as a deliberate deferral with a review trigger, so it returns on its own rather than depending on me remembering. If I leave with only "good briefing", the model has changed nothing and the next one will get less time.
A severity score is a thermometer reading. It is real and comparable, but nobody books surgery off it - the surgeon is told what the patient can no longer do and what it costs to fix.
saying these in an interview costs you the question
- Reading CVSS vector strings aloud to a non-technical audience
- Calling every top threat critical, so nothing is ranked
- Quoting a likelihood percentage you cannot derive
- Ending the readout with no decision ask
- Assuming the attacker is always an anonymous outsider
- Treating a base score as if it included your environment