Turning Threats Into Fixes

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.

References

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