From threat to control

Why this matters

A threat model is worthless if it doesn't change the code. Every identified threat must either get a concrete control (validation, rate limit, encryption, audit log) or get explicitly accepted with a written justification. The discipline of mapping threats → controls → tickets is what separates security theatre from real engineering.

Demo

Threat: 'attacker brute-forces login credentials'. Possible controls: rate limit per IP (cheap, partial), rate limit per account (better, harder), CAPTCHA after N failures (annoying, effective), WebAuthn for high-value accounts (slow rollout, gold standard). Decision: ship the first two now, plan the next two.

Try it yourself

1. Take three threats from a threat model and write the controls. Be specific: 'rate limit at 5 attempts per IP per 10 min via Redis sliding window' beats 'add rate limiting'.
2. For each control, write the test that proves it works (e.g. 'integration test that floods login and verifies 429s appear').
3. File a ticket for each. Now the threat model has produced code, not just diagrams.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain why mapping threats to controls is the load-bearing step.

2. Why it works (the mechanism)

Walk me through translating a threat model into a backlog of security tickets.

3. Advanced — application & what's next

Some threats can't be controlled, only accepted. Walk me through the discipline of explicit risk acceptance.

References

• NIST SP 800-53 — Security Controls
• OWASP — Proactive Controls