Your threat model produced 60 threats: how do you turn them into backlog items teams actually close?
answer
- The model is not the deliverable
- Granularity decides accountability
- Team's own queue, not a second tracker
- Threat, control, evidence, owner, date
- One epic called security is the anti-pattern
basics
~20 sOne ticket per threat, in the team's normal delivery backlog, each carrying the threat statement, the agreed control, a named individual owner and a due date. A single 'security' epic hides ownership and lets the whole batch stall.
solid answer
~50 sEach threat becomes its own item in the team's normal delivery backlog, not a parallel security spreadsheet. A usable ticket carries four things: the threat in one sentence (who does what, to which asset), the control the model agreed on, the evidence that will show the control is actually on, and a named person plus a date. The link back to the model — which diagram element and which flow the threat sits on — goes in the ticket so a reader six months later can reconstruct why it exists. The failure I have seen is a public-sector benefits portal whose 60-threat model was filed as one epic titled `security`: one owner for sixty unrelated problems, no per-threat date, and closing the epic tells you nothing about which threats were answered. A threat that never leaves the model document is, in practice, unmanaged.
go deeper
Be ready to say what a threat ticket contains: the threat in a sentence, the control, who owns it, and when it is due. Knowing that findings go into the team's normal backlog is most of the answer at this level.
Explain why granularity matters — one closable ticket per threat — and what each field buys you. An interviewer expects you to name the aggregated-epic anti-pattern and describe the link back to the diagram element the threat came from.
Show the operational side: getting tickets into a backlog another team owns, setting dates against real release trains, and refusing fictional dates that make a dashboard look calm. Talk about how you keep traceability intact months later.
Own the question of where this work lives organisationally: one backlog with a security view versus a parallel queue, what you standardise in the ticket template across many teams, and how you avoid a linkage process so heavy that teams route around it.
### The claim A threat model changes a system only through the delivery backlog. Everything a modeling session produces — the corrected picture, the shared understanding, the list of things that could go wrong — decays back to nothing unless each threat becomes a work item with the same shape as every other work item the team executes: an owner, a date, a definition of done, and a place in the queue the team actually looks at. ### Granularity: one threat, one ticket The single most common linkage defect is aggregation. A public-sector benefits portal ran a thorough model of its claim-submission and payment flows, produced roughly sixty threats, and filed all of them as one backlog epic titled `security`, assigned to the tech lead, with a due date at the end of the quarter. Everything that makes a backlog useful is destroyed by that move: - **Ownership collapses.** Sixty unrelated problems have one nominal owner, who cannot personally do sixty fixes. In practice nobody owns any individual one. - **Dates become meaningless.** A single date across sixty items is either wildly pessimistic for the trivial ones or fantasy for the hard ones, so the date stops carrying information and everyone learns to ignore it. - **Closure carries no signal.** When the epic closes, you cannot say which threats were answered, which were quietly dropped, and which were never understood. - **Nothing is re-openable.** If one assumption later turns out to be false, there is no specific item to bring back — see the third question on this leaf. The rule of thumb: a ticket should be closable by one person, in one change, against one testable statement. If a threat is too big for that ("the whole payment path can be replayed"), split it at modeling time into the specific flows, not at ticket time into vagueness. ### Ticket anatomy A threat ticket that survives contact with a sprint has five parts. Using a food-delivery courier app where the model found that a courier can replay a completed-delivery callback and be paid twice: | Part | Content in this example | | --- | --- | | Threat statement | An authenticated courier replays a signed delivery-completion callback and is credited for the same drop more than once. | | Asset and adversary | Payouts (money); an authenticated low-privilege user of our own app. | | Model anchor | Flow 7, courier app to payout service, crossing the trust boundary at the payout API. | | Control | Per-delivery idempotency key enforced server-side on the payout write, plus a uniqueness constraint on the credit record. | | Evidence | A check that submits the same callback twice and asserts exactly one credit — it must fail if the constraint is dropped. | | Owner and date | Named engineer on the payouts team; date inside the release the payout change is going into. | The adversary and asset lines are what stop the ticket degrading into "add validation". They tell a reader who was not in the room what the change is defending and against whom, which is exactly the context that goes missing when only the control survives into the ticket. ### Which backlog Put the ticket where the team already works. A separate security tracker creates a second queue nobody grooms, and it removes the threat from the conversation where capacity is actually allocated. If security needs its own view for reporting, that is a label or a query over the same backlog, not a second home for the work. The same applies to the reverse temptation — leaving the threats as rows in the model document with a "status" column maintained by the security engineer. That column is always out of date, because the people changing the status are not the people doing the work. ### Owner and date across team boundaries An owner must be a person, not an alias, and the person must be able to make the change or to commission it. Threats frequently land outside the modeling team: a connected door-lock product had a firmware-update threat whose control belonged to the embedded team, whose releases go out on a hardware train, not a two-week sprint. The honest handling is to move the ticket to that team's backlog with an owner there and a date that matches their real train, and to record the exposure between now and then explicitly. What you must not do is keep a fictional date on your own board so the dashboard looks calm. ### What good looks like Six months after the session, a reader who was not there can open any threat from the model, follow the link to its ticket, see who owns it, when it is due or when it closed, which change carried the control, and what evidence proves the control is on. That traceability, not the number of threats found, is what makes a modeling practice worth running twice.
- The fix belongs to another team entirely — how do you keep the owner field honest?Move the ticket into that team's backlog with a named owner there, and set the date against their real release cadence rather than your sprint. A firmware control on a hardware release train may be months out; say so on the ticket and make the interim exposure visible. A ticket parked on your board with a name that cannot ship the fix is worse than an openly long date, because it looks handled.
- Should threat findings live in the team's backlog or in a separate security tracker?In the team's backlog. That is where capacity is negotiated and where work is groomed; a second queue is groomed by nobody and quickly stops reflecting reality. If security reporting needs its own view, build it as a label or saved query over the same items. The test is simple: if the item is not visible in the meeting where the sprint is planned, it is not really scheduled.
- What in the ticket lets someone reconstruct the threat six months later?An anchor back to the model — which diagram element or flow, and which trust boundary it crosses — plus the adversary and the asset in the threat statement. Without those, the ticket degrades to a bare instruction like 'add validation', and the next person cannot tell what it defends or whether a redesign has made it moot.
A threat model left in a document is a building inspector's punch list left on a desk. Nothing changes until each line becomes a work order with a trade assigned, a date, and a sign-off.
saying these in an interview costs you the question
- Files all findings as one epic titled security
- Assigns tickets to a team alias with no individual owner
- Leaves threats in the model document with a status column
- Writes the ticket as a bare control with no threat statement
- Keeps a separate security tracker nobody grooms
- Treats due dates as optional for security work