Turn each agreed response into a testable requirement, assign an owner, and link it to a test. The OWASP Threat Modeling Cheat Sheet says agreed mitigations should become security requirements and be kept current. Without that step, a model is just a document that ages.
Write requirements a test can check
A useful requirement says what must be true and how you would know.
- Weak: "The API must be secure against brute force."
- Better: "The sign in endpoint rejects further attempts for an account after a configured number of failures within a window, and responds with the same message for unknown accounts."
If you cannot imagine a test, the requirement is probably too vague.
Use the story format
Put each requirement on the backlog next to the feature it belongs to. Use the same estimation and review as other work. The OWASP Top 10 recommends adding security language and controls to user stories. Acceptance criteria are a natural home for them.
Pick the right kind of test
- Unit tests for validation rules and permission checks.
- Integration tests for flows that span services, including misuse cases.
- Contract or configuration checks for settings like headers and timeouts.
- Manual checks for things automation cannot see, such as a confusing consent screen.
The OWASP guidance mentions unit and integration tests that verify threat mitigations, covering both use cases and misuse cases.
Keep traceability light
Give each threat an ID in the model. Put the ID in the ticket title and the test name. A simple search then tells you which tests defend which threat. The abuse case page describes the same idea, using IDs in design documents and code references so scripts can show where each case is handled.
Keep the model current
When the design changes, revisit the affected threats. Delete requirements that no longer apply. Remove stale diagrams. The Manifesto values continuous refinement over a one off deliverable.
A weekly rhythm
- During refinement: decide whether a feature needs a model.
- During the session: end with requirements, owners and ticket links.
- During review: check that tests exist for the requirements.
- Monthly: scan the list for threats with no owner.
Where policy checks fit
Some requirements can be enforced automatically in CI as policy checks. Safeguard supports policies and gates that can block a pull request on defined conditions. Whether to block or only warn is a team decision. Try the gate pull request demo to see the idea.
Click through it at your own pace, or open it full screen.
A small template
Use one line per response: threat ID, requirement in one sentence, owner, ticket link, test link and status. Keep it in the repository beside the diagram. When a status is open for longer than a sprint or two, bring it to refinement. Visible gaps get closed far more often than hidden ones.
Quick check
Who owns the security requirement?
The team that owns the feature. The security team advises, but a requirement without a product owner gets dropped.
Sources
- OWASP Threat Modeling Cheat Sheet
- OWASP Top 10 2021, A04 Insecure Design
- OWASP Abuse Case Cheat Sheet
- Threat Modeling Manifesto
Last reviewed: 19 October 2026.
