Threat modeling: pensar como el atacante antes de programar

El threat modeling es el ejercicio de mirar un sistema (o una feature) y preguntar, de forma sistemática, qué puede salir mal, quién podría causarlo y qué hacemos al respecto. Ocurre antes o durante el diseño, cuando cambiar una decisión cuesta una conversación y no un sprint entero.

SAST, DAST y SCA encuentran defectos que ya existen en el código o en el entorno. El threat model encuentra defectos de diseño: el servicio que confía en un header que controla el cliente, el flujo de restablecimiento de contraseña que filtra si el correo existe, el bucket que mezcla datos de tenants. Ningún scanner ve eso porque ninguna línea de código está "mal".

El método más simple cabe en cuatro preguntas, repetidas en cada cambio relevante de arquitectura:

STRIDE es un mnemónico de Microsoft que asocia cada letra con una propiedad de seguridad violada. Al mirar un flujo en el diagrama, preguntas si cada una de las seis categorías aplica:

El modelo no tiene por qué vivir en una diapositiva olvidada. Herramientas como pytm describen el sistema en código, generan el DFD y listan las amenazas aplicables. Versionado junto al repositorio, el modelo pasa por code review y cambia en el mismo PR que cambia la arquitectura.

El disparador más práctico es el mismo del code review: una feature nueva que toca autenticación, datos sensibles, un servicio externo o una frontera de confianza pide media hora de threat model antes del primer commit. Para el resto, una revisión rápida de amenazas en la plantilla del PR ya alcanza.

Las amenazas se vuelven ítems rastreables: cada mitigación apunta a una prueba, una regla de SAST o un gate del pipeline. Así el threat model deja de ser un documento y pasa a generar verificaciones que corren solas, y el mapa cierra el ciclo: el diseño informa qué deben revisar el SAST, el DAST y los gates.