Mantener vivo el modelo cuando cambia la aplicación

Un modelo de amenazas describe la aplicación en una fecha. Revisarlo entero cada semana es imposible y no revisarlo nunca lo vuelve un documento de archivo. La salida práctica es fijar de antemano qué tipo de cambio obliga a volver a abrirlo, y dejar que el resto pase sin reunión. Los disparadores habituales son cambios de diseño: una entidad externa nueva, un flujo nuevo que cruza un límite, un almacén nuevo, un cambio en cómo se autentica o se autoriza a alguien, o un tipo de dato personal que antes no se trataba.

Lo que no cambia el diseño no lo dispara: un cambio de colores, un parámetro ajustado o una dependencia actualizada, que tiene su propio control con el análisis de dependencias.

Entre noviembre y enero se integraron siete cambios en la rama principal. Pásalos uno por uno por los criterios de revisión de la empresa. Un cambio dispara la revisión si cumple al menos un criterio; no hace falta que cumpla varios. Cuidado con los que parecen de seguridad, como un ajuste de límites, pero no cambian el diseño.

De los cambios que disparan la revisión, hay que empezar por el que manda datos personales fuera de la empresa a alguien que no estaba en el diagrama. Esa pieza nueva se dibuja como entidad externa, su flujo cruza el límite hacia terceros y, además, abre preguntas que no son técnicas: si el cliente autorizó ese uso de sus datos y qué contrato tiene la empresa con quien los recibe.

Un modelo que vive en una presentación olvidada se desactualiza sin que nadie lo note. El que vive en el repositorio, en texto, junto al código, se revisa con el mismo flujo que el código: la plantilla de cada solicitud de cambio pregunta si toca alguno de los disparadores, y si la respuesta es sí, el cambio no se integra sin actualizar el diagrama y el registro. El historial del repositorio muestra entonces qué versión del modelo corresponde a cada versión de la aplicación.

Mantener vivo el modelo no es solo añadir. Cuando un cambio quita una función o un dato, las amenazas que dependían de ella quedan sin objeto, y dejarlas abiertas ensucia el registro: consumen tiempo, esconden lo que importa y hacen creer que hay trabajo pendiente donde no lo hay. Se cierran con una nota que diga qué cambio las dejó sin objeto. Y se mira si el reemplazo trae amenazas propias: confirmar una entrega con un código corto tiene las suyas.