La mayoría de los problemas de seguridad comienzan mucho antes del primer `git init`. Están integrados en las decisiones de arquitectura, suposiciones pasadas por alto y requisitos faltantes. La planificación es donde debería comenzar el desarrollo seguro, no porque sea divertido, sino porque es económico. Detectar un modelo de autenticación defectuoso en una sesión de pizarra es más rápido que parchear una brecha en producción dos sprints después. Esta sección te muestra cómo diseñar con la seguridad en mente desde el principio. Aprenderás a realizar un modelado de amenazas ligero y eficaz, a escribir historias de usuario centradas en la seguridad y a clasificar datos como un profesional. Sin rodeos. No se requiere un doctorado.

Imagen de marcador de posición: Descripción de la imagen: Flujo de la fase de diseño con iconos para modelado de amenazas, clasificación de datos y plantillas de historias de usuario seguras —superpuesto en un tablero de planificación de sprint.

Modelado de amenazas ligero para equipos de desarrollo – No se requiere un doctorado ni un taller de tres días.

No necesita pasar días construyendo árboles de ataque o ejecutando un taller de modelado de amenazas con 14 partes interesadas. Solo necesita detenerse y hacer las preguntas correctas en el momento adecuado.

¿Qué podría salir mal?

Esta es la pregunta clave. ¿Qué sucede si un token se filtra? ¿Si alguien manipula una entrada? ¿Si un usuario elude un control del lado del cliente? Revise los flujos básicos de su funcionalidad y busque sus puntos débiles. No está diseñando para usuarios ideales, está defendiéndose contra el abuso creativo. Incluso 10 minutos de pensamiento del tipo "¿qué pasaría si...?" pueden detectar fallos lógicos, validaciones ausentes o límites de confianza obvios.

Victorias rápidas: STRIDE-per-Feature, Sesiones de pizarra

No necesita modelar toda su aplicación. Simplemente haga un modelado de amenazas de lo nuevo. Pruebe STRIDE por característica. Tómese cinco minutos y pregunte si la característica introduce suplantación de identidad (spoofing), manipulación (tampering), fugas de información, problemas de privilegios o denegación de servicio. O coja una pizarra y dibuje el flujo de datos. ¿Quién se comunica con qué? ¿Dónde entra la entrada del usuario? ¿Dónde debería tener controles? Se sorprenderá de cuánto detecta simplemente al ralentizar y dibujar líneas.

Integrar la seguridad en las historias de usuario y los requisitos.

La seguridad no puede limitarse a los documentos de arquitectura o al backlog del equipo de seguridad. Debe formar parte del flujo de trabajo de desarrollo, empezando por cómo se escriben las historias.

"Como usuario, quiero que mis datos sean..."

Las historias de usuario son un excelente lugar para integrar expectativas. No te limites a escribir 'Como usuario, quiero restablecer mi contraseña'. Prueba con 'Como usuario, quiero que el restablecimiento de mi contraseña sea seguro y esté protegido contra ataques de fuerza bruta'. Esa única frase desencadena discusiones sobre limitación de velocidad, expiración de tokens y registro, antes de que se escriba el código. La seguridad debe ser parte de la definición de 'hecho', no una ocurrencia tardía añadida a QA.

Clasificación de Datos: Saber qué necesita Fort Knox frente a un simple candado

No todos los datos se crean igual. Algunos campos —como los nombres de usuario— son públicos. Otros —como los números de la seguridad social o los tokens de autenticación— requieren cifrado, control de acceso y un registro estricto. Durante la planificación, pregúntate: ¿qué datos estamos recopilando? ¿Dónde se almacenan? ¿Cuál es el impacto si se filtran? Etiquétalos en consecuencia. Esto te ayuda a diseñar protecciones que se ajusten al riesgo. No necesitas una estrategia de gobernanza de datos completa para empezar, solo un poco de etiquetado y sentido común.

El desarrollo seguro no consiste en detener la innovación. Se trata de hacer las preguntas correctas a tiempo para no tener que solucionar los problemas difíciles tarde. 

Pasemos a la fase de código y hablemos de cómo escribir lógica segura sin convertir cada pull request en un incidente de seguridad.