Threat modeling in design

Threat modeling in AppSec analyzes a feature or application at the design stage to find flaws before writing code. It’s the highest-return practice of the Secure SDLC: fixing a design flaw on a diagram takes minutes; in production, an incident. (For the general theory see Threat modeling.)

When and why

- at the DESIGN of a new feature/service, and when changing anything relevant in architecture
- output: a PRIORITIZED list of threats + mitigations that enters the backlog
- not a dead document: kept alive as the system evolves

Agile process (Shostack’s 4 questions)

1. What are we building?   simple diagram (DFD): components, flows, TRUST BOUNDARIES
2. What can go wrong?      STRIDE per element/flow (see cti-modelado)
3. What do we do?          mitigation per threat (control, accept, transfer)
4. Did we do it well?      review; mitigations become requirements/tests

STRIDE applied to a feature

Spoofing              how does each actor/service authenticate? (tokens, mTLS)
Tampering             is input validated? data integrity in transit/at rest?
Repudiation           is there enough logging of sensitive actions? (def-deteccion)
Information disclosure sensitive data encrypted? per-object access control? (web-logic)
Denial of service     rate/resource limits? inputs that amplify cost?
Elevation of privilege authorization on each endpoint? IDOR/escalation? (web-api)

Integration into the dev flow

- "threat modeling as code" / as part of the design in the architecture PR
- lightweight templates per service type; Security Champions facilitate the session (dso-sdlc)
- OWASP Threat Dragon / pytm to model; link threats to tickets and tests
- review against ASVS: turn mitigations into verifiable requirements

Common mistakes

- doing it too late (already in code) -> loses the "design" value
- giant models nobody maintains -> better lightweight, iterative, per feature
- not prioritizing -> an infinite threat list with no action
- forgetting PRIVACY (personal data, GDPR) -> add LINDDUN (cti-modelado)

Blue Team / AppSec

Model in design, lightweight and iterative, per feature; output = prioritized mitigations in the backlog.
Focus on trust boundaries and apply STRIDE per flow; enrich with ATT&CK/CTI.
Turn mitigations into verifiable requirements (ASVS) and tests; keep the model alive.
Scale with Security Champions and templates; don’t leave it as a one-off exercise.

CVEs and real-world cases

Access control flaws (IDOR/BOLA, #1 of the OWASP API Top 10) are prevented by modeling authorization in design (API Security (OWASP API Top 10)).
Breaches from unencrypted sensitive data or endpoints without authorization that a threat model would have flagged.
Organizations with threat modeling in the SDLC reduce the cost and number of design flaws in production.

Testing checklist

Diagram (DFD) of the feature with trust boundaries
STRIDE per element/flow
Enrich with real TTPs (ATT&CK) and privacy (LINDDUN/GDPR)
Prioritize threats and define mitigations
Mitigations → ASVS requirements and tests
Link threats to backlog tickets
Keep the model alive with each change