What is your definition of done for a threat-model finding before its ticket can be closed?

### Why a threat needs its own definition of done Ordinary feature work closes when the behaviour a user asked for exists. A threat closes when a behaviour an adversary wanted stops being available — an absence, not a presence. Absence is much easier to claim than to demonstrate, which is why threat tickets close on weaker evidence than feature tickets and why teams end up with backlogs that look finished while the system is unchanged. ### Terms, kept straight - A **threat** is what could go wrong: an adversary in some position doing something to an asset. - A **vulnerability** is the specific flaw that makes the threat possible in this system. - A **control** is what you build so the threat stops working. - **Evidence** is the artifact that shows the control is presently in force. Closing a ticket is a claim about the control and the evidence, not about the threat. The threat itself never goes away; you assert that it is no longer reachable in the running system. ### The three conditions **1. Merged and running where the threat lives.** A control that exists on a branch, in a design document, or in a lower environment does not close a production threat. The environment matters more than people expect: a control enforced in the application but bypassable by a second path — an admin console, a batch job, a support tool that writes directly to the store — has not closed the threat, because the model named the asset, not the code path. **2. Evidence that fails without the control.** This is the sharpest test available and the one that separates a real closure from a hopeful one. Ask: if someone deleted this control tomorrow, what would go red? If the answer is "nothing until the next model review", the ticket is not closed, it is unmonitored. Evidence can be a check that exercises the abusive input and asserts the refusal, a database constraint whose absence breaks a check, a configuration assertion, or a monitor that alarms when the control is off. The property required is negative sensitivity: the evidence must be capable of failing. Evidence that only exercises the happy path proves the feature still works, not that the threat is blocked. **3. The model updated, and the closure recorded.** When the control ships, the picture changes: a boundary moves, a store becomes append-only, a new component appears. If the diagram still shows the pre-control design, the next person to model this system reasons about a system that no longer exists. And the ticket should record what the closure rests on — which change carried the control, which evidence guards it, and what was assumed to remain true — so that a later reader can judge whether the closure still holds. ### The failure this prevents A B2B document-signing service modeled tampering with its signature audit log — the asset is non-repudiation, the record that a named person signed a specific document at a specific time, and the adversary of concern was an operator with legitimate database access. The agreed control was an append-only write path with a hash chain over entries. The threat's ticket was closed at the end of the design review, on the strength of a note describing that control, because the design was agreed and the sprint was ending. The implementation slipped, then was descoped in favour of a customer-facing feature, and nothing ever reconciled the descoping with the closed threat. Months later the log was still a mutable table. Notice what went wrong: nobody lied and nobody was careless. The ticket simply used the wrong closure criterion — agreement instead of existence — and the backlog then reported the threat as handled, which is worse than reporting it as open, because it stopped anyone looking. ### Common weak closures, and what they actually mean | Closure claim | What it really establishes | | --- | --- | | "The design review agreed the control." | The team knows what to build. | | "The pull request is open." | Someone started. | | "It is enforced in staging." | The control can work; production is untested. | | "A reviewer approved it." | One person read the change. | | "There is a test." | Something runs; ask whether it fails when the control is removed. | | "Control is merged, deployed, and a check fails without it." | Done. | ### Who closes The engineer who did the work should be able to close it, provided the evidence is attached and mechanically checkable. Requiring a security engineer to hand-close every finding turns a bottleneck into a queue and teaches teams to batch and hurry. The scalable version is that the criterion is objective enough that closure can be self-served and later audited: a sample review of closed threats that asks, for each, "show me the thing that would fail if the control vanished". A closure that cannot answer that question re-opens.