Cuando se omiten buenas prácticas, las aplicaciones pueden ser vulnerables a ataques, filtraciones o daños.

En este mural se muestra cómo implementar un software seguro desde la planeación hasta la ejecución, aplicando el modelo de amenazas STRIDE y técnicas reales de validación, análisis y cifrado, usando como ejemplo una aplicación de agenda de amigos.

STRIDE no es una lista estática, sino una guía activa para hacer preguntas durante el diseño: ¿qué pasaría si alguien se hiciera pasar por otro usuario?, ¿si modificara los datos?, ¿si accediera a información que no le corresponde? Al responder estas preguntas y aplicar medidas concretas, el equipo de desarrollo puede crear sistemas mucho más resistentes y confiables.

El video “Microsoft STRIDE Framework Explained” ofrece una introducción clara al modelo STRIDE, utilizado para anticipar amenazas en el diseño de software. En apenas pocos minutos se explican las seis categorías de riesgo (suplantación, manipulación, repudio, divulgación, denegación y elevación de privilegios), y cómo este enfoque ayuda a fortalecer la arquitectura desde el inicio.

El objetivo fue demostrar cómo se puede construir una aplicación sencilla aplicando técnicas estandarizadas de protección y validación, sin necesidad de un sistema complejo. Para ello, se utilizaron herramientas como el modelo de amenazas STRIDE, validaciones robustas en los formularios, cifrado de datos sensibles y análisis automático del código fuente.

El desarrollo de esta aplicación permitió comprender que la seguridad no debe ser un añadido al final del proceso, sino una práctica constante durante la planificación, codificación y validación. A través de este mural, se evidencian las decisiones tomadas para garantizar la integridad, confidencialidad y confiabilidad del software construido.

Medidas aplicadas:

• Se validan todos los campos del formulario para evitar entradas vacías o manipuladas.

• Se impide el registro de contactos con datos repetidos, especialmente correos electrónicos.

• Se prevé que en futuras versiones se implemente autenticación con contraseña para usuarios y control de sesiones.

Ejemplo real: Cuando alguien intenta registrarse usando el nombre o correo de otra persona para hacerse pasar por ella.

Ejemplo real: Si alguien manipula los datos del formulario para inyectar scripts (XSS) o comandos peligrosos.

Ejemplo real: Un usuario niega haber agregado un contacto, pero no hay registros que lo confirmen.

Ejemplo real: Almacenar y mostrar números de teléfono sin protección podría permitir que alguien acceda a información personal.

Ejemplo real: Enviar miles de registros con datos excesivos para ralentizar o bloquear la app.

Ejemplo real: Un usuario sin autorización logra modificar datos internos o acceder a funciones de administrador.

Medidas aplicadas:

• Se implementó una función de sanitización de las entradas, eliminando caracteres especiales que podrían usarse para inyectar código (como <, >, ', ").

• Se establecieron límites de longitud para cada campo, evitando entradas excesivas que puedan alterar el comportamiento del sistema o generar errores intencionales.

• Se rechazan campos numéricos o de formato incorrecto, como correos sin arroba o celulares con letras.

Medidas consideradas:

• Se plantea incluir un sistema de auditoría que registre cada acción (crear, editar o eliminar un contacto) junto con fecha, hora y usuario responsable.

• Se evalúa incorporar logs firmados digitalmente para garantizar la trazabilidad.

Medidas aplicadas:

• El número de celular se cifra utilizando la librería cryptography, evitando que se almacene en texto plano.

• En la interfaz gráfica, el dato cifrado no se muestra directamente; se presenta un mensaje genérico como “[Teléfono cifrado]”.

• Se proyecta el uso de cifrado completo de datos en almacenamiento persistente en versiones futuras, especialmente si se guarda información en bases de datos o archivos.

Medidas aplicadas:

• Se controla la longitud de los campos de entrada (por ejemplo, máximo 50 caracteres en el nombre).

• Se evita el ingreso masivo mediante validaciones sincronizadas y mensajes claros al usuario.

• Se bloquea la posibilidad de añadir registros sin pasar por todas las validaciones, evitando automatización simple desde consola.

  
  

Medidas previstas:

• Se evalúa una arquitectura futura donde cada usuario tenga un rol (ej. invitado, editor, administrador), y los permisos se asignen de acuerdo al rol.

• Se implementarán restricciones para que solo usuarios autorizados puedan editar o eliminar contactos.

El análisis se realizó utilizando GitHub Actions, lo que permite que cada vez que el código se actualiza, se ejecute automáticamente una revisión completa sin intervención manual. Este proceso automatizado es parte de las buenas prácticas del ciclo de vida del desarrollo de software seguro (SSDLC).

Resultados del análisis:

• No se encontraron vulnerabilidades ni problemas críticos.

• Se verificó la mantenibilidad del código y la correcta estructura lógica.

• El análisis arrojó una calificación satisfactoria en los ejes de seguridad, fiabilidad y limpieza del código.

  
  

La integración de SonarCloud no solo permitió validar la calidad del desarrollo, sino que dejó una evidencia clara y objetiva de que se siguieron estándares de codificación seguros.